You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@excalibur.apache.org by Stefan Bodewig <bo...@apache.org> on 2004/09/20 11:10:37 UTC
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).
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
Re: excalibur-thread-impl failure in Gump
Posted by Brett Porter <br...@gmail.com>.
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
<mc...@apache.org> wrote:
>
>
> > -----Original Message-----
> > From: Stefan Bodewig [mailto:bodewig@apache.org]
> > Sent: 21 September 2004 11:20
> > To: general@gump.apache.org
> > Subject: Re: excalibur-thread-impl failure in Gump
> >
> > On Tue, 21 Sep 2004, Stephen McConnell <mc...@apache.org> 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: 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: excalibur-thread-impl failure in Gump
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 24 September 2004 19:03, Brett Porter wrote:
> This could be true - so probably a long term goal to unify all the
> types of build types. I think we probably need to get a bit more
> experience building these different projects as they are before
> venturing into unchartered territory.
Experience is earned the hard way, unfortunately. The fact that Avalon have
had so many artifacts, and our driving insistance to get them properly built
under Gump have brought _us_ that experience.
And that experience has allowed Stephen to create extraordinary integration
between Magic and Gump, and handling the now 141 artifacts in Avalon is no
big deal, neither from versioning nor Gump integration point of view.
The fact that Magic is Ant extensions, may have helped to a certain degree,
since the Ant support is more well understood in Gump.
Unfortunately, I think the Maven team (you?) have to pull up the sleeves and
starting digging into the nitty, gritty details of classloading issues,
either by respecting the classpath handed to Maven by Gump, or modify Gump
generated output is organized in a Maven repo friendly way, which sounds like
a lot of effort.
On the other side of the fence is to get the "gump" goal in Maven to produce
correct Gump descriptors.
> This is all just my opinion from a distance of course as a Maven
> user/developer. As I said, I'm not familiar enough with gump internals
> to comment on a lot of things.
I am curious about how does Maven's own build get built by Gump? I see a Maven
and a Maven-Bootstrap, but is that all there is? How about all the plugins?
Are they within a single project? Is that not contradictory to the Maven
principle of one artifact per project?
I think the experience required is acquired by building Maven itself,
according to its own principles, and since it would become overwhelming to
maintain the gump descriptors for each of the numerous plugins, the "gump"
goal would probably be solved at the same time by itchy fingers... :o)
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: excalibur-thread-impl failure in Gump
Posted by Brett Porter <br...@gmail.com>.
> 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.
That's what I thought (though didn't get the classpath bit or the
difference between id and alias - I'm not very gump literate at this
point). Like I said, I think the role belongs the other way around
which I think is what you are getting at next.
> 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.
Likewise - running "maven gump" would be ideal if it always generated
exactly what was needed. I don't know how much extra gump stuff is
really needed in there.
> Q; Are you suggesting that we just run some Maven goals on the Excalibur
> codebase, and edit the output?
"maven gump" from each project will generate a standard descriptor. I
haven't done much with this output, but happy to take on any requests
:)
> 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.
This could be true - so probably a long term goal to unify all the
types of build types. I think we probably need to get a bit more
experience building these different projects as they are before
venturing into unchartered territory.
This is all just my opinion from a distance of course as a Maven
user/developer. As I said, I'm not familiar enough with gump internals
to comment on a lot of things.
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: excalibur-thread-impl failure in Gump
Posted by Niclas Hedhman <ni...@hedhman.org>.
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: excalibur-thread-impl failure in Gump
Posted by Brett Porter <br...@gmail.com>.
> <resource>
> <info>
> <group>ant</group>
> <name>ant-junit</name>
> <version>1.6.2</version>
> <type>jar</type>
> </info>
> <gump>
> <classpath/>
> <alias>ant</alias>
> <id>junit</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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
RE: excalibur-thread-impl failure in Gump
Posted by Stephen McConnell <mc...@apache.org>.
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>
<group>ant</group>
<name>ant-junit</name>
<version>1.6.2</version>
<type>jar</type>
</info>
<gump>
<classpath/>
<alias>ant</alias>
<id>junit</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:brett.porter@gmail.com]
> 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 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: 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: excalibur-thread-impl failure in Gump
Posted by Brett Porter <br...@gmail.com>.
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: excalibur-thread-impl failure in Gump
Posted by "Adam R. B. Jack" <aj...@apache.org>.
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: excalibur-thread-impl failure in Gump
Posted by "Adam R. B. Jack" <aj...@apache.org>.
> 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
RE: excalibur-thread-impl failure in Gump
Posted by Stephen McConnell <mc...@apache.org>.
> -----Original Message-----
> From: Brett Porter [mailto:brett.porter@gmail.com]
> 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: excalibur-thread-impl failure in Gump
Posted by Brett Porter <br...@gmail.com>.
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.
More:
The generated file has some strange entries:
http://brutus.apache.org/gump/public/excalibur/excalibur-thread-impl/gump_file/build.properties.html:
eg maven.jar.=/usr/local/gump/public/workspace/excalibur/components/thread/impl/target/classes
and all the ant, magic, etc dependencies which aren't declared in project.xml.
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.
gump descriptor generated from maven project should be ok, as it only
lists project.xml dependencies.
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).
Cheers,
Brett
On Tue, 21 Sep 2004 15:27:29 +0200, Stefan Bodewig <bo...@apache.org> wrote:
> On Tue, 21 Sep 2004, Stephen McConnell <mc...@apache.org> wrote:
> >> From: Stefan Bodewig [mailto:bodewig@apache.org]
>
> >> 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: 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: excalibur-thread-impl failure in Gump
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 21 Sep 2004, Stephen McConnell <mc...@apache.org> wrote:
>> From: Stefan Bodewig [mailto:bodewig@apache.org]
>> 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
RE: excalibur-thread-impl failure in Gump
Posted by Stephen McConnell <mc...@apache.org>.
> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@apache.org]
> Sent: 21 September 2004 11:20
> To: general@gump.apache.org
> Subject: Re: excalibur-thread-impl failure in Gump
>
> On Tue, 21 Sep 2004, Stephen McConnell <mc...@apache.org> 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: excalibur-thread-impl failure in Gump
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 21 Sep 2004, Stephen McConnell <mc...@apache.org> 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
RE: excalibur-thread-impl failure in Gump
Posted by Stephen McConnell <mc...@apache.org>.
> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@apache.org]
> Sent: 21 September 2004 09:49
> To: general@gump.apache.org
> Subject: Re: excalibur-thread-impl failure in Gump
>
> On Mon, 20 Sep 2004, Stephen McConnell <mc...@apache.org> 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: 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: excalibur-thread-impl failure in Gump
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 20 Sep 2004, Stephen McConnell <mc...@apache.org> 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
RE: excalibur-thread-impl failure in Gump
Posted by Stephen McConnell <mc...@apache.org>.
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: 20 September 2004 11:35
> To: 'Gump code and data'
> Cc: dev@excalibur.apache.org
> Subject: RE: excalibur-thread-impl failure in Gump
>
>
>
> > -----Original Message-----
> > From: Stefan Bodewig [mailto:bodewig@apache.org]
> > Sent: 20 September 2004 11:11
> > To: general@gump.apache.org; dev@excalibur.apache.org
> > 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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
RE: excalibur-thread-impl failure in Gump
Posted by Stephen McConnell <mc...@apache.org>.
> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@apache.org]
> Sent: 20 September 2004 11:11
> To: general@gump.apache.org; dev@excalibur.apache.org
> 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: general-unsubscribe@gump.apache.org
> For additional commands, e-mail: general-help@gump.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@excalibur.apache.org
For additional commands, e-mail: dev-help@excalibur.apache.org
Apache Excalibur Project -- URL: http://excalibur.apache.org/
RE: excalibur-thread-impl failure in Gump
Posted by Stephen McConnell <mc...@apache.org>.
> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@apache.org]
> Sent: 20 September 2004 11:11
> To: general@gump.apache.org; dev@excalibur.apache.org
> 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: 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