Re: more questions - on depends
On Monday 13 December 2004 13:16, Adam R. B. Jack wrote: but I really figured the Gump metadata would be tweaked to fit what Maven had defined. Shame if that isn't so. Well, there are two sides to this story; 1. Gump should circumvent any obstacle provided by the buildsystem in each project. 2. Maven wants to automatically generate a functional Gump descriptor. If you do 2. in Maven, you will need some help from the projects to make it so. If you don't care about 2., you can probably manage with the existing features in Maven, and need to look at the inter-project issues, such as * Mismatch between Gump project names and Maven artifactIDs. * Multiple artifactIDs with the same name, but different groups. * Same artifacts with different artifactIDs and different groups. If you do 2., you can rely on that being set up in each Maven project to aid Gump (just like has been done with Magic for the Avalon projects). I can sense that Brett and myself are leaning more towards the 2. , whereas for instance Adam and Stefan(o) are more favourable of 1. Both have their technical and social strengths. But I think we need to conclude which way to go. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more questions - on depends
On Monday 13 December 2004 16:24, Stefan Bodewig wrote: I think at least Stefan(o) prefer Gump an approach where Gump can parse Maven POMs directly. :o) Cool. But you are back to some of the problems listed for approach 1., e.g. there are artifacts that are not inter-project consistent. So, POM *alone* is not enough, but can remove the need for a gump goal in Maven. Cheers Niclas -- +--//---+ / http://www.dpml.net / / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more questions - on depends
Got a bit lost on this thread :) I agree, Gump should parse Maven POMs (sorry Niclas, if that leaves you on your own :) However, I added the mapping to allow projects to fix themselves until that time arrives. It seems we've gotten to the point where the generated descriptor is correct (I just have to remove property as it is a duplicate of what is already generated, and add an optional id element). I'll release a new version of the gump plugin to use. Anywhere were we have mismatched projects (so several maven projects declaring a dependency differently), that's something that probably needs to be fixed from the Maven end. We manage the central repository, so we can push to doing that. If we are able to do this, do the combination of these two solutions solve our problems now, and going forward? Let's start a list of JAR names that have conflicts. Please add them here: http://jira.codehaus.org/browse/MAVEN-1534 or if they are those pesky sun ones we can't distribute: http://jira.codehaus.org/browse/MAVEN-1472 I'll do what I can to resolve them. - Brett On Mon, 13 Dec 2004 10:48:58 -0500, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Niclas Hedhman wrote: On Monday 13 December 2004 16:24, Stefan Bodewig wrote: I think at least Stefan(o) prefer Gump an approach where Gump can parse Maven POMs directly. :o) Cool. But you are back to some of the problems listed for approach 1., e.g. there are artifacts that are not inter-project consistent. So, POM *alone* is not enough, but can remove the need for a gump goal in Maven. Yep. POM alone is not enough, we should start thinking about a registry of project names on where everybody can agree upon. Brett, what's your opinion on this? -- Stefano. - 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: more questions - on depends
On Mon, 13 Dec 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: Well, there are two sides to this story; 1. Gump should circumvent any obstacle provided by the buildsystem in each project. 2. Maven wants to automatically generate a functional Gump descriptor. ... I can sense that Brett and myself are leaning more towards the 2. , whereas for instance Adam and Stefan(o) are more favourable of 1. I think at least Stefan(o) prefer Gump an approach where Gump can parse Maven POMs directly. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more questions - on depends
Niclas Hedhman wrote: On Monday 13 December 2004 16:24, Stefan Bodewig wrote: I think at least Stefan(o) prefer Gump an approach where Gump can parse Maven POMs directly. :o) Cool. But you are back to some of the problems listed for approach 1., e.g. there are artifacts that are not inter-project consistent. So, POM *alone* is not enough, but can remove the need for a gump goal in Maven. Yep. POM alone is not enough, we should start thinking about a registry of project names on where everybody can agree upon. Brett, what's your opinion on this? -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
more questions - on depends
Hi, Niclas has been a bit unsure, so can someone please explain two things about depend/: - is property valid for the Maven builder, and is it used to set the name of the property to use in the build.properties file? Is the default the project name, ie maven.jar.project? - is id valid for the Maven builder to depend on particular jars of a project? does it default to just the jar names the same as the project? I'm having trouble finding the actual code... I'll dig around more later. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more questions - on depends
Niclas has been a bit unsure, so can someone please explain two things about depend/: Good questions. - is property valid for the Maven builder, and is it used to set the name of the property to use in the build.properties file? Is the default the project name, ie maven.jar.project? I hadn't thought of this before, but I don't think property is (today) valid for Maven, 'cos I think we use the id irrespective of any property name setting there. Maybe that is something to fix, if there is utility in it. That said, I wonder what would happen, I suspect it'd be set and passed using build.properties just like any other property, so it might work. BTW: Maven is a generic Builder, so the metadata is valid -- even if it doesn't process it right now: http://gump.apache.org/metadata/maven.html http://gump.apache.org/metadata/builder.html - is id valid for the Maven builder to depend on particular jars of a project? does it default to just the jar names the same as the project? I beleive so. Do you mean does ID default? Sorta -- we trim dates/.jar and such. Here are what we have: http://brutus.apache.org/gump/public/gump_xref/output_id_project.html I'm having trouble finding the actual code... I'll dig around more later. python\gump\core\build\maven.py is really jsut an interface to launching Maven using Gump's metadata/information. It takes the standard information (that is handled by depend/properties/etc.) and attempts to pass these to Maven. As such, you'll find the interfacing code here, but not much else. Answers to these types of questions would be gleened from knowing what is not in this code, and could be, not what is elsewhere. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more questions - on depends
I hadn't thought of this before, but I don't think property is (today) valid for Maven, 'cos I think we use the id irrespective of any property name setting there. Maybe that is something to fix, if there is utility in it. That said, I wonder what would happen, I suspect it'd be set and passed using build.properties just like any other property, so it might work. I don't think this is necessary as long as the IDs are mapped correctly, so I'll remove it again. - is id valid for the Maven builder to depend on particular jars of a project? does it default to just the jar names the same as the project? I beleive so. Do you mean does ID default? Sorta -- we trim dates/.jar and such. Yeah, so id = project if id is left off? In that case, I'll add an optional gump.id.../gump.id property. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: more questions - on depends
Do you mean does ID default? Sorta -- we trim dates/.jar and such.
Yeah, so id = project if id is left off?
Yes. In python/gump/core/model/project.py
# :TODO: A work in progress, not sure how
# we ought 'construct' ids.
for output in self.getOutputs():
if not output.hasId():
basename=os.path.basename(output.getPath())
newId=basename
# Strip off .jar or .lib (note: both same length)
if newId.endswith('.jar') or newId.endswith('.lib'):
newId=newId[:-4]
# Strip off -@@DATE@@
datePostfix='-' + str(default.date_s)
if newId.endswith(datePostfix):
reduction=-1 * len(datePostfix)
newId=newId[:reduction]
# Assign...
self.addDebug('Output [' + basename + '] identifier
set to output basename: [' + newId + ']')
output.setId(newId)
In that case, I'll add an optional gump.id.../gump.id property.
I'm sorry there are still Gump/Maven id mismatches. I've been out of the
loop on al lthise, but I really figured the Gump metadata would be tweaked
to fit what Maven had defined. Shame if that isn't so.
regards,
Adam
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: more questions - on depends
On Sun, 12 Dec 2004, Adam R. B. Jack [EMAIL PROTECTED] wrote: I'm sorry there are still Gump/Maven id mismatches. Sometimes there doesn't seem to be the Maven id, we have cases where different projects specify the same artifact by different ids, so it's not just our fault 8-) In addition, we only find mismatches after the fact and so far have tried to change our ids ASAP. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
