Re: Setting goals for Wheezy
On Feb 10, 2011, at 6:23 AM, tony mancill wrote:
> On 02/09/2011 05:26 AM, Stefane Fermigier wrote:
>> So yes, I'm sure this kind of service can help, but I'm not sure it can really bring us as far as we'd like to.
>
> I think the Maven repo will be a great step forward, and know that multiple
> versions of the same library libraries will co-exist in the repo. However, it
> seems like it would be a disservice to the community if we allowed it fill up
> with just any cruft. As an example, picking through the supplied list of build
> dependencies:
>
>> ./oro/oro/2.0.7/oro-2.0.7.jar
>> ./oro/oro/2.0.8/oro-2.0.8.jar
>
> I checked the upstream changelog and 2.0.8 is simply a bug-fix release of 2.0.7.
> There was also a minor bit of refactoring in the build.xml regarding the output
> folder for the examples and migration tools (there were moved into their own
> package), but that's it. And the last change to the library was in December of
> 2003.
Indeed. We only ship 2.0.8 in the product, and our poms only depends on 2.0.8.
2.0.7 seems to be needed by Maven itself, or one of its plugins.
> Other examples which appear to be minimally different and should be trivial to
> switch to the newer version:
>
>> ./stax/stax-api/1.0/stax-api-1.0.jar
>> ./stax/stax-api/1.0.1/stax-api-1.0.1.jar
>
>> ./org/apache/ant/ant/1.7.0/ant-1.7.0.jar
>> ./org/apache/ant/ant/1.7.1/ant-1.7.1.jar
>
>> ./org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
>> ./org/apache/ant/ant-launcher/1.7.1/ant-launcher-1.7.1.jar
Same.
>> ./org/codehaus/plexus/plexus-archiver/1.0-alpha-12/plexus-archiver-1.0-alpha-12.jar
>> ./org/codehaus/plexus/plexus-archiver/1.0-alpha-7/plexus-archiver-1.0-alpha-7.jar
>> ./org/codehaus/plexus/plexus-archiver/1.0-alpha-9/plexus-archiver-1.0-alpha-9.jar
In this case, we don't event ship plexus. Plexus is only needed by Maven.
> These for xmlbeans, these are the same JAR, no?
>
>> ./org/apache/xmlbeans/2.3.0/xmlbeans-2.3.0.jar
>> ./org/apache/xmlbeans/xmlbeans/2.3.0/xmlbeans-2.3.0.jar
Same jar under two different names.
One (the one using the standard group and artifact naming scheme) is needed by us. The other one is needed by one of the dependencies.
We only ship one of them, eventually.
> This isn't to say that there aren't still quite a number of dependencies where
> multiple versions of the libraries are warranted, or that the problem is somehow
> now simple - it's not. It is only to suggest that the Debian repo shouldn't
> become a snapshot machine,
This is what I've been saying all along, actually.
> and that it is possible for projects to accumulate
> technical debt by depending on strict version numbers.
OTOH, this is a HUGE source of instability and hard to debug bugs (as we've found to our expense) to depend on loose version numbers.
> That is, there are good
> reasons to actively cull for and remove cruft. (Am I'm missing the point?)
Not entirely ;)
Anyway, the cruft is not on our side (Nuxeo). While there may be still a few redundancies, we've spent a fait amount trying to make sure that there is only version of each library used for the build.
But we don't have control about the transitive dependencies's dependencies, nor the Maven ecosystems'.
S.
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com/ - +33 1 40 33 79 87 - http://twitter.com/sfermigier
Join the Nuxeo Group on LinkedIn: http://linkedin.com/groups?gid=43314
New Nuxeo release: http://nuxeo.com/dm54
"There's no such thing as can't. You always have a choice."
Reply to: