Hi, I have read Brett's reply to this message. Just to add some more info to the points:
On Wed, 2006-12-13 at 10:57 -0500, Jason van Zyl wrote: > On 13 Dec 06, at 10:26 AM 13 Dec 06, Carl Trieloff wrote: > > > > > I don't see that there is a consistent view yet on this. It would > > be nice to get to a conclusion on whether the Maven community would > > like to work with the downstream distros teams so that we can > > provide a consistent and good experience. Is there any more > > information that is needed to get to a view point, and if so how > > can I help? > > > > If the distros works with us to provide something that is familiar to > our current users, to which our documentation, practices, and current > body of user knowledge apply then I don't think anyone would be > opposed here. So that means: > > - Using an installation layout that is consistent with our current setup Short answer to this -- yes, this is doable and I don't see it as being an issue (I just sent an email to another thread a few minutes ago, the details are there). > - Using the Maven repository as the source for satisfying > dependencies for development work This too, is doable. Any changes that the patches I posted makes, are optional. By default, the maven from the rpm behaves just like the zipped maven, so all repositories can be used as needed. When the appropriate switches/flags/properties/whatever are given, the idea is to switch maven to an "offline" only behaviour where it uses system installed jars for everything. > - Maven running with a standard JDK and not being compiled with GJC > or anything weird like that. With Java being GPL now that shouldn't > be a problem > Until Java can make it into FC, it will have to be built with gcj. Java may be GPL, but that is Java 7, not 5/6, and additionally, certain parts are encumbered/non-free and need working on. Until such a time that the entire class library is open, Fedora may not be able to include it, and may have to rely on gcj. However, Fedora uses ecj as the byte-code compiler. ecj itself is quite stable and I don't think it'll be much of an issue. No more than say, using the BEA compiler to compile maven2. If the user then wants to use maven with the Sun class library, they can just install the Sun JVM afterwards. > Any variation from this I would consider potentially harmful to Maven > users and I personally would tell people to avoid the potential > complication for their enterprise environments. Simply conveying my > first hand experience. I really think this is the only way you're > going to get buy-in from from Maven users and would be a win-win for > everyone involved. I have far stronger opinions about this stuff and > you certainly don't need my buy in to do whatever you want and I'm > sure others here would work with you. I just don't see the point > frankly if you roll something different. > > A couple questions that weren't really answered were: > > - How far into the graph do you need to build from sources This can be discussed in-depth at a later time, however, I think the first couple or so levels (so direct dependencies of maven, and their dependencies, etc.) should be fine. We certainly wouldn't expect all-level dependency building, as it may very well end up being the entire java stack in Fedora, if not most of it. > - Would a self-contained Maven repository with the binary > dependencies work and then build Maven itself from source or do you > want to walk back down the entire graph? Please see above. If only the top few levels are built by you, they can be built on top of lower levels (which too, will be from source, and built by other maintainers). Everything in Fedora has to be built from source unless it is the initial bootstrap build. > - Are you guys willing to compromise and make something that uses our > current layout. I think we could live with some symlinks to /usr/bin > or whatever > This is already the case. Please see my mail in the other thread. /usr/bin/mvn is just a wrapper that does a pushd into /usr/share/maven2 (the M2_HOME) and runs the bin/mvn there. Cheers, Deepak > Jason. > > > > Carl. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
