| Item |
Section |
Comment |
Response |
| XXX-# |
#.# |
Comment |
Response |
| jfdipol-001 |
4.13 |
I think there should be a section on IPS package dependencies. Due to a limitation in dependency resolution in the version of IPS in UC2.3 all package dependencies in the GlassFish set of packages should use the same level of version information. Today the incorporation is fairly specific in its dependencies, but the other packages are loose (often leaving off version information). This can result in either mixing of packages across builds/releases or constraint violations with the incorporation since the unversioned dependencies will try and pull in the latest version of a package instead of the version capped by the incorporation. The safest approach is if we pick how specific we want the version info to be (say to the build #) and then make sure that all package dependencies of all types in all packages use that same level of version specification. If we do that then we will never have packages mixed across builds – let alone releases – and will avoid constraint violations. Note that I think in later versions of IPS the dependency resolution logic is smarter and it will find the set of packages that avoid constraint violations – but that's not the case in the version of IPS in UC2.3. |
Agreed - we'll need to enforce dependencies more stringently although if I understand correctly, I can still only enforce lower bound in "require" type dependency whereas "incorporate" dependency acts as optional in a sense that it will not automatically enforce installation of dependency packages but that should be fine if we specify version up to the build number. In any case, I'll add section on this and describe limitations. For most packages we'll want to go up to the build number level with some potential exceptions for packages such as jersey which do get independently updated from time to time. |
| alexismp-001 |
4.1 |
Clarification Will the existing 3.0.x packages also preserve the same dependencies as they have today? |
No, some of existing package dependencies will also change - for instance, glassfish-gui will depend on glassfish-management instead of glassfish-amx. This information should be captured and I'll add such changes to the table.
|
| alexismp-002 |
4.5.1.1 |
Question Any updates to the "classification" meta-data? What about other meta-data such as maintainer, upstream code, etc, which seem to be available in the latest UC2 and associated maven plugin? This is maybe more of a question for non-core GlassFish packages. |
I do plan to add some more metadata to packages although I am not sure we'll cover everything described in Additional Package Info section of Best Practices. I'll file an enhancement for this and refer to it in Issue/RFE section of one-pager.
|
| alexismp-003 |
4.5.1.1 |
Question Should shoal and glassfish-ant-tasks packages which currently are listed as not having any dependency depend on at least, say glassfish-nucleus? |
shoal will have dependency on glassfish-nucleus, given that it is installed in glassfish/modules directory and intended for use within GlassFish installation. glassfish-ant-tasks, however, contains ant task jar library and truly does not require any other GlassFish package to run.
|
| alexismp-004 |
4.5.1.1 |
Clarification What is the expected size of glassfish-cluster-gui? Would it make sense to have this be part of glassfish-gui instead? I would imagine a user wanting all or nothing when it comes to GUI, not everything expect the cluster-related part |
At this point glassfish-cluster-gui is officially dead :-) We'll follow the existing rule that admin CLI and GUI modules are collocated with their base container/feature so this content will be part of glassfish-cluster package.
|
| alexismp-005 |
4.5.1.1 |
Clarification Those packages available only from the update center, it should probably be stated that this is from the "stable" repository |
Yes, the intent is to make them available in "stable". Will add note.
|
| alexismp-006 |
4.5.1.1 |
Question With IPS, how can one package glassfish-jms-ra replace another glassfish-generic-ra? |
I believe that the exposure to glassfish-generic-ra was rather limited but we can publish one-off update of glassfish-generic-ra package which will have no payload and defined dependency on new glassfish-jms-ra package - this should take care of seamless update for users which had glassfish-generic-ra already installed.
|
| alexismp-007 |
4.9 |
Question Will the I18N and L10N packages double the number of packages available from the update center? If I installed the non-ML version, can I just not see them? |
Not all of packages have their localized counterparts, but yes, their presence potentially doubles the number of available packages. One way to cut down would be to deliver localized content in the base package and filter it on pkg level using variant or facet definitions but I don't think we'll have bandwidth to do something like this in 3.1 release.
|
| alexismp-008 |
4.10.3 |
Clarification Can you explain the role of incorporation packages? |
Will further clarify the need for metapackages and incorporation packages.
|
| alexismp-009 |
4.13.2 |
Question Is UpdateCenter 3.2 the version that presents the user with the license when installing a package from the CLI (pkg)? |
You meant Update Center 2.3, right? Current update version of updatecenter 2.3 does not contain pkg drop with interactive license prompt functionality. I am not sure if it is possible to get selective fix for this since integration of new pkg version would probably warrant going to updatecenter 2.4. I will add a note on this.
|
