You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Stefan Bodewig <bo...@apache.org> on 2004/06/21 16:47:01 UTC
commons-compress - Gump/Maven issues?
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.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: commons-compress - Gump/Maven issues?
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: commons-compress - Gump/Maven issues?
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 21 Jun 2004, Stephen McConnell <mc...@apache.org> wrote:
> 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
This is what build.sysclasspath does for Ant (and thus should work for
magic as well IIUC). build.sysproperty is tightly integrated into
quite a few Ant tasks and has been created just for Gump.
This may be a lot more work on the side of the build system than we'd
want to impose, though.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: commons-compress - Gump/Maven issues?
Posted by Stephen McConnell <mc...@apache.org>.
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: commons-compress - Gump/Maven issues?
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> > 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).
Gump does run Maven in offline mode.
> 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)
Yeah, we could nuke this at the start of the run. Hmm, trouble is I think I
have to run maven at least once w/o offline to get some plugins into that
repository or no builds work. :(
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: commons-compress - Gump/Maven issues?
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 21 Jun 2004, Niclas Hedhman <ni...@hedhman.org> 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: commons-compress - Gump/Maven issues?
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 21 Jun 2004, Eric Pugh <ep...@opensourceconnections.com>
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: commons-compress - Gump/Maven issues?
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: commons-compress - Gump/Maven issues?
Posted by Niclas Hedhman <ni...@hedhman.org>.
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: commons-compress - Gump/Maven issues?
Posted by Mario Ivankovits <im...@apache.org>.
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
RE: commons-compress - Gump/Maven issues?
Posted by Eric Pugh <ep...@opensourceconnections.com>.
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:niclas@hedhman.org]
> 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: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: commons-compress - Gump/Maven issues?
Posted by Niclas Hedhman <ni...@hedhman.org>.
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org