Re: commons-compress - Gump/Maven issues?
On Mon, 21 Jun 2004, Niclas Hedhman [EMAIL PROTECTED] wrote: On Monday 21 June 2004 22:47, Stefan Bodewig wrote: (1) The descriptor of commons-compress sets a property named component.version and hopes to get this into the jar name, which obviously doesn't work that way. Maven still uses /project/currentVersion from the POM. If no Maven guys are around... My wild guess would b to try to set pom.currentVersion property instead. Given that I'm still not running Python Gump myself, I can't test it. Sounds like we should give it a try. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-compress - Gump/Maven issues?
On Mon, 21 Jun 2004, Eric Pugh [EMAIL PROTECTED] wrote: I don't know what extent you want to push back on the projects that gump builds, but it seems to me that they are either doing something that pushes maven beyond it's limits, Quite possible. Or maybe not. AFAIU we are successfully replacing all artifacts declared in the POM with Gump built artifacts already - using jar overrides. This probably is enough as long as the projects we build are not trying to defeat Gump. When we build a project with Ant, Gump sets the magic build.sysclasspath property to only. This means that each and every classpath inside the build file will be ignored - which includes the nested elements of the junit task for example. If something we build with Ant runs tests, this means we have to add the directory that will contain the compiled tests to the Gump descriptor (using work) explicitly since the junit task won't find the classes otherwise. Gump adds it to the system CLASSPATH that way. While trying to fix the commons-compress build I noticed that the work entry didn't point anywhere but the test:test goal still managed to find the classes - so the goal uses a Maven provided classloader to load the classes which contains more than the stuff declared in the Gump descriptor. This means there is a way to add stuff to the classpath without giving control to Gump. This hole could be used to defeat Gump's purpose. If this whole can only be exploited consciously, I don't see any problem with it. Projects that want to cheat on Gump should do so. I'm concerned that a project may compile against some dated version unconsciously, though. For Maven plugins that are based on Ant tasks, we may get the same effect as with Ant builds if we set the build.sysclasspath property as a system property. I'm not sure how Maven uses the Ant tasks, but it may make them see the property and work as if they'd be running inside of Ant. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: commons-compress - Gump/Maven issues?
I don't know what extent you want to push back on the projects that gump builds, but it seems to me that they are either doing something that pushes maven beyond it's limits, or the decriptor might be out of date. I checked out jakarta-commons-sandbox/compress to investigate furthur, but I don't see this descriptor property you are talking about.. Could you enlightenme on this? Eric -Original Message- From: Niclas Hedhman [mailto:[EMAIL PROTECTED] Sent: Monday, June 21, 2004 5:30 PM To: Gump code and data Subject: Re: commons-compress - Gump/Maven issues? On Monday 21 June 2004 22:47, Stefan Bodewig wrote: (1) The descriptor of commons-compress sets a property named component.version and hopes to get this into the jar name, which obviously doesn't work that way. Maven still uses /project/currentVersion from the POM. If no Maven guys are around... My wild guess would b to try to set pom.currentVersion property instead. Then it is a question if Maven overwrites it or not... (2) The work entry inside the descriptor pointed to nowhere and there is no work entry for the generated test classes, still the test goal manages to load the freshly compiled test classes. This means that we are not getting the effect of build.sysclasspath=only in Maven builds. The jar overrides will catch the artifacts Gump knows about but Maven will happily let the goals (plugins, tasks, I don't know the correct terms) add more stuff to the classpath itself. Sorry, this is beyond my knowledge, but hardly surprises me. For things like work directories for compiled classes this probably is good, but it may also lead to situations where Gump doesn't manage to substitute a jar from CVS with a freshly compiled one. Generally, Maven will happily download the required Jars from remote repositories, which normally can be disabled by running off-line mode (-o). However, what it builds today will be available in the local repository for use tomorrow, so I guess you are missing to nuke the local repository ( normally in $HOME/.maven/repository) Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - 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: commons-compress - Gump/Maven issues?
Eric Pugh wrote: I checked out jakarta-commons-sandbox/compress to investigate furthur, but I don't see this descriptor property you are talking about.. Could you enlightenme on this? If you mean the gump.xml - i only added fragments of it into gump/project/jakarta-commons-sandbox.xml in the gump cvs. As far as i understood, there is no need to keep them in the project itself. -- Mario - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-compress - Gump/Maven issues?
Stefan Bodewig wrote: Hi all, two notes colored by my complete lack of Maven knowledge: (1) The descriptor of commons-compress sets a property named component.version and hopes to get this into the jar name, which obviously doesn't work that way. Maven still uses /project/currentVersion from the POM. I've adapted the descriptor to match the name we actually see just to get a successful build in Gump, but I'd prefer a way that allows us to get dated jar names via Maven. Probably we are just using the wrong property name or something like that. (2) The work entry inside the descriptor pointed to nowhere and there is no work entry for the generated test classes, still the test goal manages to load the freshly compiled test classes. This means that we are not getting the effect of build.sysclasspath=only in Maven builds. The jar overrides will catch the artifacts Gump knows about but Maven will happily let the goals (plugins, tasks, I don't know the correct terms) add more stuff to the classpath itself. For things like work directories for compiled classes this probably is good, but it may also lead to situations where Gump doesn't manage to substitute a jar from CVS with a freshly compiled one. Have been thinking about this issue for about a week and a bit. My conclusion is that the maven scenario is very similar to the magic scenario. To do real integration you need to be able do to something like set some special property so that magic or maven can take control over classloader definition in the knowledge that the build is a gump build (i.e. effects the repository cache that is used and the semantics concerning artifact handling). That means providing the current cache of artifact that have been generated so that magic or maven can map dependency reference to artifact in gumps cache. Stephen. -- |---| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---| - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-compress - Gump/Maven issues?
On Tuesday 22 June 2004 00:32, Eric Pugh wrote: I don't know what extent you want to push back on the projects that gump builds, but it seems to me that they are either doing something that pushes maven beyond it's limits, or the decriptor might be out of date. I checked out jakarta-commons-sandbox/compress to investigate furthur, but I don't see this descriptor property you are talking about.. Could you enlightenme on this? I am guessing wildly, so don't pay to much attention to me :o) The question is, does Maven fully support disabling the normal 'repository management' allowing Gump to provide the artifacts for each project? Can Maven be told to ignore versions in the POMs ? I have so many questions about the Gump/Maven interaction, and it seems that the main Gump folks have little clue about Maven and vice versa. Maybe this has improved over the last few weeks, and I have just missed it. Well, I don't know... Could you (Eric or someone from the Maven camp) explain what 'hooks' has been provided for Gump? Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-compress - Gump/Maven issues?
The question is, does Maven fully support disabling the normal 'repository management' allowing Gump to provide the artifacts for each project? Theoretically yes, but I think Stefan has disproved that it isn't leak-proof. Can Maven be told to ignore versions in the POMs ? Yes. I have so many questions about the Gump/Maven interaction, and it seems that the main Gump folks have little clue about Maven and vice versa. Maybe this has improved over the last few weeks, and I have just missed it. I don't know how Maven works internally, but this is what I can tell you about the Gump/Maven interaction works at the calling interface: http://gump.apache.org/metadata/maven.html What I didn't add there (but ought) is that Gump generates the build.properties file (setting properties these artifact overrides) before launching Maven. This file (and the others) are listed by Gump: http://brutus.apache.org:8080/gump/jakarta-commons-sandbox/commons-compress/index.html#Project-level+Files regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: commons-compress - Gump/Maven issues?
My conclusion is that the maven scenario is very similar to the magic scenario. To do real integration you need to be able do to something like set some special property so that magic or maven can take control over classloader definition in the knowledge that the build is a gump build (i.e. effects the repository cache that is used and the semantics concerning artifact handling). That means providing the current cache of artifact that have been generated so that magic or maven can map dependency reference to artifact in gumps cache. It could go either way (Gump exposes it's repository of fresh artifacts to a builder, or builder exposes a mechanism [e.g. CLASSPATH] which Gump provides.) I like the idea of Gump maintaining a repository (as it does) that it provides to builders that are aware of such things. That said, if builder present standard mechanisms (like Ant does, like Maven might -- see ongoing discussion) I don't see why Gump doesn't support them. regards Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
