harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: Status updates and distribution integration
Date Wed, 11 May 2005 22:35:31 GMT
Hash: SHA1

Sorry to get a little off topic, but I noticed the magic M word :)

Karl Trygve Kalleberg wrote:

>Maven is a very problematic us Gentoo packagers. It makes our lives
>difficult. In fact, in Gentoo, we have adopted the stance of just
>ripping out the Maven project.xml and replacing it with a build.xml, so
>that we can get proper packaging done (figuratively; we just generate a
>build.xml and run ant).

Yep, been made aware of this recently and have been working with someone
to get Maven 1.1 packaged for Gentoo, as it has fewer dependencies and
most of the outdated ones have been eliminated. But building from an
unstable development tree is not without other problems :)

One big issue that will always remain is bootstrapping. Several projects
Maven depends on only build with Maven itself. We've so far taken the
approach of generating Ant build files for those dependencies, though
I'd prefer to find a better bootstrapping solution. We have the same
issues with Gump, and have so far gone to a binary solution for Maven.

>1) Part of Maven's seductive appeal is its readily available package
> set which may be used by all Maven users. Need antlr? Sure, just add
> it to your deps, and it'll be fetched for you at build time.
> Needless to say, this is problematic or us packagers. We expressly
> do _not_ want every package to come with its transitive closure of
> dependencies.

Maven 2.x should help address a lot of these through better dependency
version management (ie give me the latest Xerces 2 rather than I'll have
2.4.0 and I'll have 2.6.0 where realistically it works on both).

>2) License awareness is not part of its (current) design. None of the
> packages in the Maven repo come with source code.

Yes, we definitely need to work harder at license support.

About to make deploying the source code the default. Would be interested
to know whether a JAR of sources with a package root the same as the
binary JAR is useful, or whether the full source tarball is better. So
far we are looking at the former, so it can be dropped into IDEs.

>When we
>package a program incidentally written in Java, we want it to use the
>existing Java libraries we have already packaged.

Just another note - we are definitely looking at supporting non-Java
projects in the current development.

>or have it
>"fetch" its jars from our "virtual" repo.

Yep, this is definitely the goal - you should be able to swap in a
different repository provider so that all of the dependencies can be
taken from there, and so that you can handle the signing and management
of them yourself. At least, that's the goal :)

Anyway, now that I'm aware that people want to do this, I hope we can
help out. I'll keep working with Vibhav and see how it goes.

I don't know how/if this will affect harmony, but its good that there's
an open avenue of communication :)


Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


View raw message