RE: excalibur-thread-impl failure in Gump
Bret/Adam: Just a note on this dependency mapping question .. within the Magic build system we doing something similar. Dependencies declared in a magic project definition typically match up with the name of an artifact (id in maven). In cases where Gump declares a scoped name (e.g. junit relative to the ant-junit project, we include additional meta info within the magic project definition (loosely equivalent to maven's project.xml). Here is an example of the definition of an external resource (close to a maven dependency declaration). Within magic the groupId is 'ant' and the artifactId is 'ant-junit'. We have additional metadata to handle the mapping to a gump alias/id combination. Using the alias/id we can automatically resolve the gump resource and allocate this to the project group/name key. resource info groupant/group nameant-junit/name version1.6.2/version typejar/type /info gump classpath/ aliasant/alias idjunit/id /gump /resource This works quite well and we don't have any naming conflicts. Cheers, Steve. p.s. Just another thought - the build.properties file generated by Gump seems to be including all inherited project references irrespective of the definition in gump. For example, I recently removed all of the inherit attributes from the gump descriptor for the threads project (bringing it in line with the maven generated gump task output, but the properties file still contains a much larger set of dependency mappings. Would it be possible to simply restrict gump to generating only those properties that are explicitly declared (i.e. no inherited properties)? Cheers, Stephen. -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: 24 September 2004 05:24 To: Gump code and data Subject: Re: excalibur-thread-impl failure in Gump Ok, this time I got the reply-to right :) Unfortunately it has junit, the reason being was that Gump 'jar ids' were within the scope of the project, so the 'ant' was implied. Since Gump only has 'jar id' that is the only thing that Gump can pass to Maven. Hence we need to make Gump 'jar ids' globally unique, and (for want of a better) match Maven 'artifact ids'. Ok, I should explain Maven id's to clear this up a bit. They are composed of a group and an artifact ID. The group must be unique (this is easier to control than the whole id being unique), and the artifactId must be unique within the group (also easy for those maintaining the group to control). This guarantees the whole ID is unique. At the moment, groups are things like commons-collections, ant, and maven (see the root directory of http://www.ibiblio.org/maven/ for a list), but eventually we intend to move to a package structure, so the group would be org.apache.ant and such. The notation for an id is groupId:artifactId. Usually, artifactId is the same as the filename (files are built as artifactId-version.jar by default). This makes it much easier to remember and look up. For the above example, the ids should be junit:junit and ant:ant-junit respectively. JAR overrides do have a limitation in that they currently don't really support the Maven id structure of group:artifact, which is planned to be fixed for 1.1. So what I was saying here is that we never used to have a groupId - and the overrides you are using are a hangover of that. The property must match either the artifactId or id part of a dependency in project.xml. But if we have a project with ant:junit and junit:junit as dependencies - there'll be a problem as in both cases the old id is just junit. If you have time to explain in more detail I'd appreciate that, I'm not quite following. Hope this helped. I agree. I was saying correct because I thought it used junit, so I feel it ought ask for it (not have Maven transparently add it). In this way, Maven attempts to separate the build from the actual produced JAR (it isn't always successful, but we're working on that :) excaliber doesn't depend on junit in any way to use it AFAIK, so its not a dependency. It is a dependency of the excalbier unit tests though. Maven will specify that for you to avoid having to do it yourself only if you use the test plugin. In the same way, checkstyle is not a dependency of excaliber - but it is used if you run the maven checkstyle plugin report. Tests admittedly are a bit more fuzzy because you code and compile portions of your source against junit, but it should be treated the same. Or we build Maven from scratch using Gump'ed artifacts? I think this can happen now if you are game to try. Start by building from MAVEN-1_0-BRANCH and then later move to HEAD. If you want to build a Maven distribution using Maven 1.0, that's doable now. If you want to use ant 1.5, I'd need to modify the bootstrap to accept JAR overrides. Which do you prefer? Maybe start with Maven
Re: excalibur-thread-impl failure in Gump
resource info groupant/group nameant-junit/name version1.6.2/version typejar/type /info gump classpath/ aliasant/alias idjunit/id /gump /resource This works quite well and we don't have any naming conflicts. Yep, well this is identical to Maven for the first part. This is good, because that means there shouldn't be any conflict in having gump adopt the same identification mechanism. I don't quite get the contents of the gump section - at first glance, I think the relationship is back to front: a project shouldn't need to declare gump information like this. p.s. Just another thought - the build.properties file generated by Gump seems to be including all inherited project references irrespective of the definition in gump. For example, I recently removed all of the inherit attributes from the gump descriptor for the threads project (bringing it in line with the maven generated gump task output, but the properties file still contains a much larger set of dependency mappings. Yep, this seems to be the core of the current problem (the id conflict is more of a potential problem that gump faces regardless of what build system a project is using). Would it be possible to simply restrict gump to generating only those properties that are explicitly declared (i.e. no inherited properties)? Yeah, we've gotten a bit sidetracked, but this was one thing I proposed earlier: just what is in project.xml + any parent projects (which is what you get if you generate the gump descriptor with Maven - this might be an even better idea, with enhancements such that it updates instead of overwrites and adds more metadata as needed). If the id issue is resolved, it would make this unnecessary, but that is probably more of a long term goal. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: excalibur-thread-impl failure in Gump
On Friday 24 September 2004 18:16, Brett Porter wrote: I don't quite get the contents of the gump section - at first glance, I think the relationship is back to front: a project shouldn't need to declare gump information like this. It is the fact that Gump project names doesn't necessarily correspond to the names Maven have given them. So, Magic is capable of declaring the discrepancy. Mind you, Magic has the ambition of no hand editing of generated gump descriptor, in fact we are now looking at how to tell Gump to generate the descriptors from the Magic model prior to Gump starting. Q; Are you suggesting that we just run some Maven goals on the Excalibur codebase, and edit the output? My concern is that too many of the Excalibur projects are named differently internally in the POM than they are in Gump, and that a series of downstream changes are required. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: excalibur-thread-impl failure in Gump
Brett wrote: Seems the problem of 'jar id' != 'artifact id', i.e. where Gump and Maven don't have a shared view of the names of these things. Recall, Gump had 'context sensetive' jar ids (within the context of that project) it did not have unique ones, like Maven does/requires. I don't quite understand here... what gump ID does ant-junit have compared to junit that they ended up the same in Maven? Unfortunately it has junit, the reason being was that Gump 'jar ids' were within the scope of the project, so the 'ant' was implied. Since Gump only has 'jar id' that is the only thing that Gump can pass to Maven. Hence we need to make Gump 'jar ids' globally unique, and (for want of a better) match Maven 'artifact ids'. JAR overrides do have a limitation in that they currently don't really support the Maven id structure of group:artifact, which is planned to be fixed for 1.1. If you have time to explain in more detail I'd appreciate that, I'm not quite following. Shorter term, I say we look at making the Gump ids closer to unique ids (and/or equal to those in Maven). Agreed. There's nothing particularly special about the maven ones, so a group:artifact structure should be reasonable to match. In Ant's Gump descriptor, these problably ought change: I'm curious how they got there in the first place. I understand that you are traversing the dependency tree, but if you are building with Maven, why is there a dependency on ant-1.6 in there? I assume this is because of the magic dependency in there? No clue. I agree, not sure why they are there. It just seems that a couple of things are being mixed together in here, which doesn't seem quite right. So 1 to not quite 1. ;-) Any problem if we add it for correctness of Gump metadata? No, but I would argue with your definition of correctness :) I don't think a build should be offered up several dependencies it hasn't asked to use. I agree. I was saying correct because I thought it used junit, so I feel it ought ask for it (not have Maven transparently add it). If, for Maven builds, build.properties matched the dependencies in project.xml for each directory - nothing more, nothing less - then the project can determine it's own fate in terms of clashes. Agreed, and if they used your gump plug-in to make the Gump descriptor they would. This does mean some JARs used by plugins such as junit will not be overriden here. The solution to this that each plugin in the maven installation also needs a build.properties file to accompany its project.xml. Or we build Maven from scratch using Gump'ed artifacts? That said, this would be simpler if all clashes could be avoided by making gump id's unique and 1:1 with Maven id's, because with that guarantee you could simply declare all ID's in ~/build.properties (a global override) and not have to modify every project. I agree, make them match. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: excalibur-thread-impl failure in Gump
Ok, this time I got the reply-to right :) Unfortunately it has junit, the reason being was that Gump 'jar ids' were within the scope of the project, so the 'ant' was implied. Since Gump only has 'jar id' that is the only thing that Gump can pass to Maven. Hence we need to make Gump 'jar ids' globally unique, and (for want of a better) match Maven 'artifact ids'. Ok, I should explain Maven id's to clear this up a bit. They are composed of a group and an artifact ID. The group must be unique (this is easier to control than the whole id being unique), and the artifactId must be unique within the group (also easy for those maintaining the group to control). This guarantees the whole ID is unique. At the moment, groups are things like commons-collections, ant, and maven (see the root directory of http://www.ibiblio.org/maven/ for a list), but eventually we intend to move to a package structure, so the group would be org.apache.ant and such. The notation for an id is groupId:artifactId. Usually, artifactId is the same as the filename (files are built as artifactId-version.jar by default). This makes it much easier to remember and look up. For the above example, the ids should be junit:junit and ant:ant-junit respectively. JAR overrides do have a limitation in that they currently don't really support the Maven id structure of group:artifact, which is planned to be fixed for 1.1. So what I was saying here is that we never used to have a groupId - and the overrides you are using are a hangover of that. The property must match either the artifactId or id part of a dependency in project.xml. But if we have a project with ant:junit and junit:junit as dependencies - there'll be a problem as in both cases the old id is just junit. If you have time to explain in more detail I'd appreciate that, I'm not quite following. Hope this helped. I agree. I was saying correct because I thought it used junit, so I feel it ought ask for it (not have Maven transparently add it). In this way, Maven attempts to separate the build from the actual produced JAR (it isn't always successful, but we're working on that :) excaliber doesn't depend on junit in any way to use it AFAIK, so its not a dependency. It is a dependency of the excalbier unit tests though. Maven will specify that for you to avoid having to do it yourself only if you use the test plugin. In the same way, checkstyle is not a dependency of excaliber - but it is used if you run the maven checkstyle plugin report. Tests admittedly are a bit more fuzzy because you code and compile portions of your source against junit, but it should be treated the same. Or we build Maven from scratch using Gump'ed artifacts? I think this can happen now if you are game to try. Start by building from MAVEN-1_0-BRANCH and then later move to HEAD. If you want to build a Maven distribution using Maven 1.0, that's doable now. If you want to use ant 1.5, I'd need to modify the bootstrap to accept JAR overrides. Which do you prefer? Maybe start with Maven and work back to Ant? Thanks for your feedback Adam. Let me know what I can do for you. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: excalibur-thread-impl failure in Gump
-Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: 22 September 2004 01:31 To: Gump code and data Subject: Re: excalibur-thread-impl failure in Gump Short answer: It has a problem in build.properties. There are two maven.jar.junit properties, and the second points at ant-junit.jar, which I assume does not declare junit.framework.TestCase. Ant-junit.jar is ant extensions to junit. This would be introduced with any dependency with a runtime inheritance property set (which is the case of the thread-impl gump project definition). I've just updated the def to remove the runtime inheritance stuff so that should simplify things a touch. Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: excalibur-thread-impl failure in Gump
Short answer: It has a problem in build.properties. There are two maven.jar.junit properties, and the second points at ant-junit.jar, which I assume does not declare junit.framework.TestCase. Seems the problem of 'jar id' != 'artifact id', i.e. where Gump and Maven don't have a shared view of the names of these things. Recall, Gump had 'context sensetive' jar ids (within the context of that project) it did not have unique ones, like Maven does/requires. If you look for 'junit' in here, you'll see the problem. http://brutus.apache.org/gump/public/gump_xref/output_id_project.html Hmm, I wonder if Gump ought check/warn about such overlaps. Shorter term, I say we look at making the Gump ids closer to unique ids (and/or equal to those in Maven). In Ant's Gump descriptor, these problably ought change: jar name=lib/ant.jar id=ant/ jar name=lib/ant-launcher.jar id=ant-launcher/ jar name=lib/ant-jmf.jar id=jmf/ jar name=lib/ant-junit.jar id=junit/ jar name=lib/ant-stylebook.jar id=stylebook/ jar name=lib/ant-swing.jar id=swing/ jar name=lib/ant-trax.jar id=trax/ jar name=lib/ant-nodeps.jar id=nodeps/ I assume these are coming from the gump descriptor. This should be changed in one of the following ways: - gump generates build.properties only for project.xml dependency entries (including anything in extended POMs), rather than everything in the gump descriptor - gump descriptor has a flag on dependencies for ones that should be controlled in build.properties Not understanding the need for the extra libs and not being familiar with Avalon, I'm not sure what the best solution is here. I always thought that the gump deps to Maven deps would be 1:1. I agree they ought be 1:1, so I am not sure there is need to fix anything but that. gump descriptor generated from maven project should be ok, as it only lists project.xml dependencies. Agreed. Any additions to the Maven Gump plugin are welcome - just file them in JIRA and I'll take a look. (BTW, You don't need a junit dependency, as Maven adds it). So 1 to not quite 1. ;-) Any problem if we add it for correctness of Gump metadata? regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: excalibur-thread-impl failure in Gump
On Mon, 20 Sep 2004, Stephen McConnell [EMAIL PROTECTED] wrote: Nope ... excalibur-thread-impl still failing. Time for a maven expert? Probably yes. Maybe the junit plugin doesn't honour the jar overrides in project.properties? Maybe it's a classloader issue and the fact that junit.jar is on the CLASSPATH is hurting Maven? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: excalibur-thread-impl failure in Gump
-Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 21 September 2004 09:49 To: [EMAIL PROTECTED] Subject: Re: excalibur-thread-impl failure in Gump On Mon, 20 Sep 2004, Stephen McConnell [EMAIL PROTECTED] wrote: Nope ... excalibur-thread-impl still failing. Time for a maven expert? Probably yes. Maybe the junit plugin doesn't honour the jar overrides in project.properties? Maybe it's a classloader issue and the fact that junit.jar is on the CLASSPATH is hurting Maven? I took a look at excalibur-pool-impl which is almost identical (and has testcases) and it's working ok. I've just updated the project.xml to follow it as closely as possible. I don't think it's a classpath thing because maven ignores the gump supplied classpath anyway. So it's down to something in the project.xml, maven.xml or generated properties. Anyway - let's give it another run to see if the last change actually impacts anything. Steve. 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: excalibur-thread-impl failure in Gump
On Tue, 21 Sep 2004, Stephen McConnell [EMAIL PROTECTED] wrote: I took a look at excalibur-pool-impl which is almost identical (and has testcases) and it's working ok. I've just updated the project.xml to follow it as closely as possible. db-grafolia[1] works as well. But it doesn't even list a dependency on JUnit in the Gump descriptor. Stefan Footnotes: [1] http://brutus.apache.org/gump/public/db-commons-sandbox/db-commons-grafolia/gump_work/build_db-commons-sandbox_db-commons-grafolia.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: excalibur-thread-impl failure in Gump
-Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 21 September 2004 11:20 To: [EMAIL PROTECTED] Subject: Re: excalibur-thread-impl failure in Gump On Tue, 21 Sep 2004, Stephen McConnell [EMAIL PROTECTED] wrote: I took a look at excalibur-pool-impl which is almost identical (and has testcases) and it's working ok. I've just updated the project.xml to follow it as closely as possible. db-grafolia[1] works as well. But it doesn't even list a dependency on JUnit in the Gump descriptor. The listing in the gump descriptor is only going to effect the Gump ordering - not the execution in Maven. The junit target in maven fires off a junit plugin which has the junit stuff in its classpath - or at least is should. The excalibur-thread-impl has just failed again. I'm kind of at the end of ideas for possible solutions. Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: excalibur-thread-impl failure in Gump
I caught a discussion of this on commons-dev... I'm going to bed soon, but I'll take a look in the morning. I'm not sure if I can help out, but it sounds familiar. - Brett On Tue, 21 Sep 2004 15:14:29 +0200, Stephen McConnell [EMAIL PROTECTED] wrote: -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 21 September 2004 11:20 To: [EMAIL PROTECTED] Subject: Re: excalibur-thread-impl failure in Gump On Tue, 21 Sep 2004, Stephen McConnell [EMAIL PROTECTED] wrote: I took a look at excalibur-pool-impl which is almost identical (and has testcases) and it's working ok. I've just updated the project.xml to follow it as closely as possible. db-grafolia[1] works as well. But it doesn't even list a dependency on JUnit in the Gump descriptor. The listing in the gump descriptor is only going to effect the Gump ordering - not the execution in Maven. The junit target in maven fires off a junit plugin which has the junit stuff in its classpath - or at least is should. The excalibur-thread-impl has just failed again. I'm kind of at the end of ideas for possible solutions. Steve. - 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: excalibur-thread-impl failure in Gump
On Tue, 21 Sep 2004, Stephen McConnell [EMAIL PROTECTED] wrote: From: Stefan Bodewig [mailto:[EMAIL PROTECTED] db-grafolia[1] works as well. But it doesn't even list a dependency on JUnit in the Gump descriptor. The listing in the gump descriptor is only going to effect the Gump ordering - not the execution in Maven. I understood that much 8-) The junit target in maven fires off a junit plugin which has the junit stuff in its classpath - or at least is should. Since we want this to be our version of JUnit and not some arbitrary other one, we should hope the plugin recognizes jar overrides and make Gump add junit to the project.properties. I'll just throw in a dependency on JUnit and we'll see what's going to happen. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: excalibur-thread-impl failure in Gump
-Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 20 September 2004 11:11 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: excalibur-thread-impl failure in Gump Hi, for some reason Maven doesn't seem to pick up JUnit, even though it is listed in the project.properties generated by Gump - and it doesn't complain about it missing either. Since I know next to nothing about Maven, the following observation may be completely insignificant, but ... In project.xml all dependencies have groupId and artefactId elements while the one for JUnit only has an id element (which the others have not). Have already updated the project.xml to reflect the same convention. What's interesting is that the project build locally without any issues. Anyway - we'll see if this is the problem or not shortly! Cheers, Steve. 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: excalibur-thread-impl failure in Gump
-Original Message- From: Stephen McConnell [mailto:[EMAIL PROTECTED] Sent: 20 September 2004 11:35 To: 'Gump code and data' Cc: [EMAIL PROTECTED] Subject: RE: excalibur-thread-impl failure in Gump -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: 20 September 2004 11:11 To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: excalibur-thread-impl failure in Gump Hi, for some reason Maven doesn't seem to pick up JUnit, even though it is listed in the project.properties generated by Gump - and it doesn't complain about it missing either. Since I know next to nothing about Maven, the following observation may be completely insignificant, but ... In project.xml all dependencies have groupId and artefactId elements while the one for JUnit only has an id element (which the others have not). Have already updated the project.xml to reflect the same convention. What's interesting is that the project build locally without any issues. Anyway - we'll see if this is the problem or not shortly! Nope ... excalibur-thread-impl still failing. Time for a maven expert? Steve. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
