Packaging large Java software stacks ?

[Emmet Hikory]

Matthias Klose wrote:
> Thierry Carrez schrieb:
>> That's a difficult one to answer, since there is no API versioning in
>> JARs, but apparently a lot of new releases do. The Geronimo developers
>> told me the slightest version change frequently breaks the TCK JavaEE
>> compliance tests, and using the latest is usually not the best. To get
>> an idea of the (runtime) components versioning complexity, see [1]. The
>> -Gnnnnnn versions means it's a Geronimo-patched version of the JAR that
>> is used.
>>
>> [1] http://cwiki.apache.org/GMOxDOC22/component-versions.html
> 
> I don't think all of these should translate into packages. Looking at Netbeans
> you have hundreds or more components or modules, but just a few packages. I
> doubt that we do want to package those all separately.

    In the specific case of NetBeans, there was an analysis of what
existing packages were of general use, and an effort to get any
NetBeans-specific patches applied upstream so they would be included
with Ubuntu.  The NetBeans codebase was then broken down into chunks
based on expected reuse (e.g. the platform library is separate from the
API because other applications may use the platform as a high-level
toolkit).  In one case, a library became a separate upstream project.
Once the analysis was complete, there were only a few new source
packages, and when uploaded in the right order, they were then
self-sustaining.

    Since then, the NetBeans team has been taking advantage of PPAs to
ensure that the stack continues to build against Ubuntu, and can be
tested as Ubuntu adjusts, so that Ubuntu can carry whichever release of
NetBeans is available at FeatureFreeze with some expectation that it
will be useful to users without additional download.

    Additionally, NetBeans has a plugin system that allows some
components to be added post-install, at user discretion.  While the
packaged NetBeans includes sufficient functionality for most uses,
end-users are able to use the plugin system to further extend the
packaged NetBeans, which reduced the packaging requirements to a
manageable level.  At the current time there does not seem to be
sufficient demand for packaging of most of these optional plugins for
them to warrant additional packages in the archive.

    I'm not sure how much of that would apply to the stacks in question,
but at least the application of a similar analysis may reduce the number
of packages required, depending on reuse in other environments.

    Mind you, this doesn't address the issues with maven, or
incompatibilities with library versions, or any of that.

-- 
Emmet HIKORY