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