Re: Setting goals for Wheezy
On 02/09/2011 05:26 AM, Stefane Fermigier wrote:
>
> On Feb 9, 2011, at 11:55 AM, James Page wrote:
>
>> Hi
>>
>> Appreciate that I have been *absolutely* silent on this mailing list
>> since I joined but I would like to get more involved in Java packaging
>> for Debian and have a few opinions on some of this thread.
>>
>> On Tue, 2011-02-08 at 17:07 +0100, Torsten Werner wrote:
>>> - Ship more pom files.
>>
>> +1 on this for me.
>>
>> Maybe installation of Maven artifacts into /usr/share/maven-repo should
>> become part of the Debian Java Library Policy as it is
>> for /usr/share/java?
>>
>> This would really help out when the Java Libraries in Debian mature to a
>> point where packaging of larger applications such as Jenkins, JEE Apps
>> Servers etc... is feasible as the majority of larger Java projects seem
>> to be using Maven these days.
>
> Indeed :)
>
>>> - Set up a real Maven repo based on our packages. Dak may help, too.
>>
>> This is something that we discussed at the Ubuntu Developer Summit last
>> October in one of the Java Development Toolset sessions. Having this
>> type of service would potentially really help upstreams who are not
>> packaging for Debian align to versions of Java libraries already
>> packaged which could make things much easier going forward.
>
> Great. I can provide a whole list of packages that are needed to build Nuxeo. All 583 of them. See below.
>
> This includes both direct build-time dependencies, and transitive runtime dependencies, but not all the transitive build-time dependencies needed to build all these dependencies, so I guess the total number of dependencies needed is probably 2 to 10 times larger.
>
> 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.
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
> ./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
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
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, and that it is possible for projects to accumulate
technical debt by depending on strict version numbers. That is, there are good
reasons to actively cull for and remove cruft. (Am I'm missing the point?)
Thanks,
tony
Reply to: