> -----Original Message----- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: vendredi 29 avril 2005 14:33 > To: Cactus Developers List > Cc: [EMAIL PROTECTED] > Subject: Re: [EMAIL PROTECTED]: Project jakarta-cactus-integration-ant-12 (in > module jakarta-cactus) failed > > On Fri, 29 Apr 2005, Vincent Massol <[EMAIL PROTECTED]> wrote: > > From: Stefan Bodewig > >> > >> On Thu, 28 Apr 2005, Vincent Massol <[EMAIL PROTECTED]> wrote: > >> > >> > The question is really whether we want to hardcode the > >> > dependencies between Cargo subprojects or let Maven handle this. > >> > >> I have no problem with making Maven do that - as long as everything > >> works. > > > > According to http://gump.apache.org/metadata/builder.html#maven, it > > seems that Gump does not support this feature? > > What is needed? > > I mean, how do you need to invoke Maven to make it happen?
Simply: "maven cargo:dist". I think there's a high chance it'll actually work... > > I'll try it to see if it works (I've just modifier the cargo GOM). > > Seen it, thanks. > > Is there any way (using maven.final.name or something) to provide a > consistent name for the generated jar(s) that does not contain the > version information. The way it currently is, we'd need to modify the > descriptor as soon as 0.5 has been released an Cargo CVS HEAD becomes > 0.6-SNAPSHOT. Yes, I understand that. The problem is that I don't a way to make it work in a multiproject scenario. Normally you could set the maven.final.name property to the full name of the artifact you wish to generate and thus setting the following would work: <property name="maven.final.name" value="cargo-core-util-@@DATE@@"/> However, if we do this for the top level project, it means all subprojects are going to generate artifacts with this name, which is definitely not what we want. Hmm... The only way I can think of would to modify the cargo build itself, add a cargo:gump goal, add or modify each project's maven.xml file and set the maven.final.name property to something expected. But I really would prefer not to do that. Alternatively Cargo could set a version of SNAPSHOT instead of 0.5-SNAPSHOT but I don't like this either... In conclusion: For now I'm happy to modify Cargo's GOM whenever we switch to a new version (it doesn't happen that often) [snip] > > Again the issue is triggering Gump when you debug (otherwise you > > have to wait for a long time to see your change take effect). > > The next Gump that has a remote chance of actually building Cargo is > the JDK 1.5 build. Scheduled to start in about half an hour. We do > have four useful builds per day (three of which use JDK 1.4) by now. > See <http://brutus.apache.org/>. > > The Kaffe build is interesting, but many projects fail due to > dependencies on Sun VMs (in their prereqs, potentially) or Kaffe bugs. Thanks -Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
