Re: Gump integration with Maven
Adam R. B. Jack wrote: Agreed. I think the real challenge is at the project level, projects need to establish naming consistent with their Umbrella group, this is a real growing pain at this point, I suspect eventually the entire Jakarta Commons will need to migrate to jakarta-commons/jakarta-commons-foo-x.x.ext from commons-foo/foo-x.x.ext sometime in the near future. But it would probably be good to have the system consistent before that point and keep such transitions separate. Could either of you elaborate, please? Are we having uniqueness problems? If not, what is the issue? regards Adam Its not really a concern at this time, just a groupId naming inconsistency in the Jakarta Commons that will eventually need resolution. Each Jakarta Commons project is defining its own groupId (commons-collections, commons-math, commons-lang) instead of using a global one (jakarta-commons) , this makes each subproject a totally separate project as opposed to just an Artifact of Jakarta-Commons. So currently in the Maven Repository we get /repo/commons-math/jars/commons-math.x.x.jar /repo/commons-collections/jars/commons-collections.x.x.jar /repo/commons-lang/jars/commons-lang.x.x.jar I think the Commons, we would rather eventually see: /repo/jakarta-commons/jars/jakarta-commons-math.x.x.jar /repo/jakarta-commons/jars/jakarta-commons-collections.x.x.jar /repo/jakarta-commons/jars/jakarta-commons-lang.x.x.jar But this is a Commons issue, not a Gump one. However, if you saw a major beneit in this we could use it as ammunition to push forward a change. -Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump integration with Maven
> Agreed. > > > I think the real challenge is at the project level, projects need to > > establish naming consistent with their Umbrella group, this is a real > > growing pain at this point, I suspect eventually the entire Jakarta > > Commons will need to migrate to > > jakarta-commons/jakarta-commons-foo-x.x.ext from > > commons-foo/foo-x.x.ext > > sometime in the near future. But it would probably be good to > > have the > > system consistent before that point and keep such transitions > > separate. > Could either of you elaborate, please? Are we having uniqueness problems? If not, what is the issue? regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Gump integration with Maven
Agreed. > I think the real challenge is at the project level, projects need to > establish naming consistent with their Umbrella group, this is a real > growing pain at this point, I suspect eventually the entire Jakarta > Commons will need to migrate to > jakarta-commons/jakarta-commons-foo-x.x.ext from > commons-foo/foo-x.x.ext > sometime in the near future. But it would probably be good to > have the > system consistent before that point and keep such transitions > separate.
Re: Gump integration with Maven
Brett Porter wrote: Yup, I think we need ASF-wide artefact ids (within group ids). I'd like to think the community and/or communities can come to agreement on what the values are, and if that means defaulting to what Maven/Ibiblio already have, then so be it. Consistency is the key more than anything else. Sounds like a sensible approach. I think the real challenge is at the project level, projects need to establish naming consistent with their Umbrella group, this is a real growing pain at this point, I suspect eventually the entire Jakarta Commons will need to migrate to jakarta-commons/jakarta-commons-foo-x.x.ext from commons-foo/foo-x.x.ext sometime in the near future. But it would probably be good to have the system consistent before that point and keep such transitions separate. -- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Gump integration with Maven
> > What I was thinking was that you would generate the > build.properties > > from the list of gumped projects, rather than dependencies. > > Not quite following the distinction, but maybe I am too close > to the currently implementation. Gump has a list of projects > it is working on and/or knows about, and a project has > dependencies within that list. I assumed projects was a subset of dependencies as some dependencies are not gumped projects. You should need JAR overrides for all gumped projects, but not dependencies that are not gumped for some reason. I'd consider packages to be "gumped", but I think you are right - you should probably use a Maven repository for Maven projects when they use a non-gumped non-packaged JAR instead of creating a new package. (Is this making sense? I'm confusing myself a little with all the jargon :) > What I'm saying it is I can build a build.properties based on > the list of Gumped projects & intersected with the > dependencies. For me to understand what is 'not right' about > this, are you sayign this is fine, but any Maven plug-ins > that the build uses has dependencies that are not listed? No, I think this is exactly what I meant. Gumped projects + packages produce a big list of available JAR files, which go into ~/build.properties which can be used globally assuming that the dependency tree gets traversed correctly and the JARs actually exist by the time they are used. This produces the same end result as a build.properties file for every project, but keeps it in a master copy, and will also affect Maven itself to the extent of the plugins. Anyway, it seems this is academic at this point, as we need to stick to the per project one to avoid breaking Maven for now. > If so, in Gump dependencies into dependencies of the current project. Would > that work here? [Point me back at the archive if I've finally > caught on to what you explain a few mails back.] I'm not sure I get this, sorry. Anyway, I think the current approach is the right one for now and we can look at alternatives down the track when we actually want to gump Maven. Cheers, Brett
Re: Gump integration with Maven
> What I was thinking was that you would generate the build.properties from > the list of gumped projects, rather than dependencies. Not quite following the distinction, but maybe I am too close to the currently implementation. Gump has a list of projects it is working on and/or knows about, and a project has dependencies within that list. Gump does know (in advance of any building) exactly what jars each project ought produce, and where, but without having done any building knowledge of 'failed, but optional' is missing. As such, any behaviour on this (if we chose any) would be lost. What I'm saying it is I can build a build.properties based on the list of Gumped projects & intersected with the dependencies. For me to understand what is 'not right' about this, are you sayign this is fine, but any Maven plug-ins that the build uses has dependencies that are not listed? If so, in Gump If a project is not > gumped, the dependency will have to come from a repository anyway, right? Not quite, see below. > How do you intend to handle this case as projects come on board that use > non-ASF libraries? Just to be clear, we already Gump plenty of non-ASF projects, see: http://lsd.student.utwente.nl/gump/repositories.html and for those we don't we can package: http://lsd.student.utwente.nl/gump/packages.html That said, is this debatably a locally managed repository? I'd say yes, and would like to see it replaced (where legally possible) with one, simply for consistency & leveraging what others do there. regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Gump integration with Maven
> Yup, I think we need ASF-wide artefact ids (within group > ids). I'd like to think the community and/or communities can > come to agreement on what the values are, and if that means > defaulting to what Maven/Ibiblio already have, then so be it. > Consistency is the key more than anything else. Sounds like a sensible approach. > Hopefully we can have Maven bootstrap and plug-in testing in > Gump, to help identify such risk early on. We knew about the problem early on, but weren't prepared to make the core changes required to do this at the stage Maven was at. Sometimes to keep a project moving forward, you don't want the "bleeding edge". > I have concerns that I can't (easily) code what you asked for > (Gump plods through projects, and builds build.properties for > dependencies, it doesn't look ahead to be able to build a > workspace-wide list.) I'll keep an open mind on what you said > though, and see if I can figure out how. What I was thinking was that you would generate the build.properties from the list of gumped projects, rather than dependencies. If a project is not gumped, the dependency will have to come from a repository anyway, right? How do you intend to handle this case as projects come on board that use non-ASF libraries? > Please keep with us, and work with us to bootstrap Maven & > we'll work through these issues. [Again, changing the maven > 'gump' goal to produce prove out what we are doing. Artefact's first...] No problem. Just say when. Cheers, Brett
RE: Gump integration with Maven
The commons-logging ant build has been customised from one generated by Maven. The Maven build does not produce the api JAR, although it could easily be modified to do so in one of two ways: - a custom postGoal on jar:jar in maven.xml to produce the second JAR with the same ant code as is in build.xml - a new goal that gump calls differently (eg commons-logging:generate-api-jar prereqs="jar:jar") - a sub project with artifact id commons-logging-api that takes the original source directory with the relevant exclusions I don't see a problem with either as long as gump can handle it. The third is probably the preferred Maven solution and would fit with what we've been discussing and is a much shorter solution (a cut down project.xml that extends the original and overrides the source directory). Either way, the groupId remains commons-logging, with the artifactIds being commons-logging and commons-logging-api. Cheers, Brett > -Original Message- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: Saturday, 15 May 2004 1:00 AM > To: [EMAIL PROTECTED] > Subject: Re: Gump integration with Maven > > > On Fri, 14 May 2004, Brett Porter <[EMAIL PROTECTED]> wrote: > > > Sorry... I didn't realise that gump had a notion of a project that > > produces multiple artifacts. > > Hmm, commons-logging is built by Maven. Its Ant build file > produces two jars, commons-logging.jar and > commons-logging-api.jar - how does Maven deal with this? Are > these two separate projects? Or a group of two artifacts? > This is the case we need to get mapped when running Gump. > > Stefan > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Re: Gump integration with Maven
I would suspect that the commons logging ant build.xml file has either been customized beyond the capabilities of maven, or was never actually generated from maven. If I think about this with my Maven hat on, a discrepancy arises. groupId: commons-logging artifactId: commons-logging artifactId: commons-logging-api As such these would/should be two separate projects within the commons-logging group. Each having a separate project.xml with the same groupId and different artifactId's. The source would be in separate directories and "commons-logging" would be dependent on "commons-logging-api" -Mark Stefan Bodewig wrote: On Fri, 14 May 2004, Brett Porter <[EMAIL PROTECTED]> wrote: Sorry... I didn't realise that gump had a notion of a project that produces multiple artifacts. Hmm, commons-logging is built by Maven. Its Ant build file produces two jars, commons-logging.jar and commons-logging-api.jar - how does Maven deal with this? Are these two separate projects? Or a group of two artifacts? This is the case we need to get mapped when running Gump. Stefan - 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]
Re: Gump integration with Maven
On Fri, 14 May 2004, Brett Porter <[EMAIL PROTECTED]> wrote: > Sorry... I didn't realise that gump had a notion of a project that > produces multiple artifacts. Hmm, commons-logging is built by Maven. Its Ant build file produces two jars, commons-logging.jar and commons-logging-api.jar - how does Maven deal with this? Are these two separate projects? Or a group of two artifacts? This is the case we need to get mapped when running Gump. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump integration with Maven
> > What about projects that produce multiple jars? > > Sorry... I didn't realise that gump had a notion of a project that produces > multiple artifacts. In maven, project to artifact Id is 1:1, however a > project can produce multiple different 'types' of the same artifact (eg, > documentation, jar, or maybe different types of dist: src, bin, etc) > > So if gump has a project id and a jar id under that which is usually the > same, this sounds something like groupId:artifactId. But to keep it simple - > one gump id per jar produced sounds ok. I am going to keep working on Maven builds via Gump (working up to Geronimo) to see if we can get practical insight into what we need to do. > Ok, I see your point. Maven projects will have been built against these > assuming the structure in ibiblio, so it seems that gump will have to match > up the artifactId in there regardless. Yup, I think we need ASF-wide artefact ids (within group ids). I'd like to think the community and/or communities can come to agreement on what the values are, and if that means defaulting to what Maven/Ibiblio already have, then so be it. Consistency is the key more than anything else. > > Aren't you going to release Maven and the > > plugins rather soon? Wouldn't you want your plugins to work > > with latest Jelly? > > We'd love for it all to work with the latest Jelly and Ant, but the current > structure has prohibited upgrading without a high risk. Post-1.0 this will > be revisited. Hopefully we can have Maven bootstrap and plug-in testing in Gump, to help identify such risk early on. > > Seriously, since we are trying to get things working in the > > first place, we may be better of with using a more > > conservative approach and switch to the mode you propose here > > later - once we have a working setup. I have concerns that I can't (easily) code what you asked for (Gump plods through projects, and builds build.properties for dependencies, it doesn't look ahead to be able to build a workspace-wide list.) I'll keep an open mind on what you said though, and see if I can figure out how. Please keep with us, and work with us to bootstrap Maven & we'll work through these issues. [Again, changing the maven 'gump' goal to produce
RE: Gump integration with Maven
> > So, to sum up this point: I think gump should have just one > id for a > > project, > > What about projects that produce multiple jars? Sorry... I didn't realise that gump had a notion of a project that produces multiple artifacts. In maven, project to artifact Id is 1:1, however a project can produce multiple different 'types' of the same artifact (eg, documentation, jar, or maybe different types of dist: src, bin, etc) So if gump has a project id and a jar id under that which is usually the same, this sounds something like groupId:artifactId. But to keep it simple - one gump id per jar produced sounds ok. > > > If this needes to be done alongside ant projects, I'll > leave it up to > > the gump folk to decide how this is best treated. > > I'm not sure whether I parse this correctly. There will > always be projects that want to be built by Maven but depend > on things that have not been built by Maven. So we'll have > to make up some ids - or use those that have been made up by others. Ok, I see your point. Maven projects will have been built against these assuming the structure in ibiblio, so it seems that gump will have to match up the artifactId in there regardless. > > The downside to this, is I imagine a bunch of Maven plugins > will freak > > out at more recent versions of Jelly or other things, and > this could > > hold up this part for a while to fix it. > > Aren't you going to release Maven and the > plugins rather soon? Wouldn't you want your plugins to work > with latest Jelly? We'd love for it all to work with the latest Jelly and Ant, but the current structure has prohibited upgrading without a high risk. Post-1.0 this will be revisited. > Seriously, since we are trying to get things working in the > first place, we may be better of with using a more > conservative approach and switch to the mode you propose here > later - once we have a working setup. ok Thanks! Cheers, Brett
Re: Gump integration with Maven
On Wed, 12 May 2004, Brett Porter <[EMAIL PROTECTED]> wrote: > I was finding myself a bit confused by the gump talk in context of > Maven, especially with all the different spellings of artifact :) In German it's Artefakt - hard to unlearn 8-) > So, to sum up this point: I think gump should have just one id for a > project, What about projects that produce multiple jars? > If this needes to be done alongside ant projects, I'll leave it up > to the gump folk to decide how this is best treated. I'm not sure whether I parse this correctly. There will always be projects that want to be built by Maven but depend on things that have not been built by Maven. So we'll have to make up some ids - or use those that have been made up by others. > Next, to building projects with maven inside gump, which is > happening now. I think a build.properties file is being generated > per project, and wanted to suggest the generation of an all > encompassing jar override build.properties file in the user home > directory. Sounds interesting. > The downside to this, is I imagine a bunch of Maven plugins will > freak out at more recent versions of Jelly or other things, and this > could hold up this part for a while to fix it. Aren't you going to release Maven and the plugins rather soon? Wouldn't you want your plugins to work with latest Jelly? Seriously, since we are trying to get things working in the first place, we may be better of with using a more conservative approach and switch to the mode you propose here later - once we have a working setup. > The current ant based bootstrap uses an ant task to do the first > build of a maven core, using a set of known dependencies. It then > uses this installation to build all the plugins, and finally it > rebuilds maven completely using maven. At this last step, the jar > overrides would kick in and maven would be completely built using a > latest JAR maven. Sounds OK to me. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Gump integration with Maven
Thanks Brett. I'm in the office (work work) tomorrow, but will dig into this when I next can. Questions will likely follow. regards Adam - Original Message - From: "Brett Porter" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, May 11, 2004 9:51 PM Subject: Gump integration with Maven > Hi, > > I was finding myself a bit confused by the gump talk in context of Maven, > especially with all the different spellings of artifact :) I thought I > should recount how I think they can work together in a way that meets gumps > goals - let me know if I've got it wrong. I apologise for length. > > Firstly, Maven's repository structure is setup to uniquely identify a > particular dependency by a combination of group ID, artifact ID, type (JAR > in all cases for gump I think, maybe extending to encompass plugin) and > version. > > Formerly, groupID = artifactId and was called "id", and there is still a lot > of evidence of that legacy in Maven projects. For now, I think that gump > should concern itself with artifactId and not groupId. If there comes an > occasion that two maven projects with two group Ids produce the same > artifact Id, then we might need to look at alternatives to resolve the > conflict. > > So, to sum up this point: I think gump should have just one id for a > project, that being the artifact Id for now, and using the full Maven ID > (groupId:artifactId:type) later when support and project usage is better. > > If this needes to be done alongside ant projects, I'll leave it up to the > gump folk to decide how this is best treated. I imagine there shouldn't be > clashes as projects will be either maven or ant, not both (while it might be > possible, I imagine they only get gumped with one). > > Next, to building projects with maven inside gump, which is happening now. I > think a build.properties file is being generated per project, and wanted to > suggest the generation of an all encompassing jar override build.properties > file in the user home directory. This will allow specifying the location of > all JARs coming from gump, and will automatically apply to all maven built > projects, including the maven plugins themselves. This should be much easier > to maintain. > > The downside to this, is I imagine a bunch of Maven plugins will freak out > at more recent versions of Jelly or other things, and this could hold up > this part for a while to fix it. I think a fallback needs to be in place, > and I'm not sure the best way to do this (copy the build.properties to all > the projects being built, and remove it from the user home directory so that > Maven itself is the only thing unaffected?) > This is worth trying, as we might get further than expected, and certainly > it appears gumps goal is to go down this path. > > The final item is gumping Maven itself. I've taken a look at building a new > ant based bootstrap for this, and think it isn't necessary. Let me know if > you agree. Based on the following. > > The current ant based bootstrap uses an ant task to do the first build of a > maven core, using a set of known dependencies. It then uses this > installation to build all the plugins, and finally it rebuilds maven > completely using maven. At this last step, the jar overrides would kick in > and maven would be completely built using a latest JAR maven. So while the > whole process is not under gumps ideals, the end result is. > > Is this enough? I'd prefer not to have to modify this bootstrap for now. > > An alternative of course is to use a "known good" maven to build maven which > we have goals for too. > > There is one stumbling block here: even if all the right JARs are put into > $MAVEN_HOME/lib, forehead.conf hardcodes some filenames. Wildcards can be > used, so this can easily be worked around if it becomes a problem. > > Let me know where to go next! > > Also, I seem to have lost the format for the descriptor, so if someone could send that through I'll implement that for > the gump plugin soon. > > Cheers, > Brett > > -- > Brett Porter ~ [EMAIL PROTECTED] > blog: http://blogs.codehaus.org/people/brett > Maven: http://maven.apache.org/ > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
