directory and gump

[Brett Porter <br...@gmail.com>]

Hi,

I've regenerated the eve gump descriptor using a development version
of the Maven Gump plugin. I'll do the others now.

I reread the documentation and did the following:
- stopped mapping ids (the ability is there for the project to do that
in its descriptor)
- removed work and mkdir (these seem irrelevant for Maven)
- added junitreport
- fixed svn
- added multiproject support

Hopefully that's it...

The only thing I am now unsure about: I set module name to the
artifactId, not the groupId. The reason for this is I believe (though
don't see anything supporting or contradicting it in the doco) that
gump may expect that name to be unique in the workspace, and groupId
will not be.

There is still the risk that there will be namespace issues later, but
we can cross that bridge when we come to it.

So, when/how will I know if this is correct?

Cheers,
Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org

Re: directory and gump

[Alex Karasulu <ao...@bellsouth.net>]

Awesome thanks Brett.  Perhaps we can hear from Niclas on this.

Thanks,
Alex

Brett Porter wrote:

>Hi,
>
>I've regenerated the eve gump descriptor using a development version
>of the Maven Gump plugin. I'll do the others now.
>
>I reread the documentation and did the following:
>- stopped mapping ids (the ability is there for the project to do that
>in its descriptor)
>- removed work and mkdir (these seem irrelevant for Maven)
>- added junitreport
>- fixed svn
>- added multiproject support
>
>Hopefully that's it...
>
>The only thing I am now unsure about: I set module name to the
>artifactId, not the groupId. The reason for this is I believe (though
>don't see anything supporting or contradicting it in the doco) that
>gump may expect that name to be unique in the workspace, and groupId
>will not be.
>
>There is still the risk that there will be namespace issues later, but
>we can cross that bridge when we come to it.
>
>So, when/how will I know if this is correct?
>
>Cheers,
>Brett
>
>  
>

Re: directory and gump

[Brett Porter <br...@apache.org>]

>There is an outstanding issue in Gump that all project names should be 
>synchronized with the Maven artifactIds. 
>  
>
I'm well aware of this, but this is just to ease things in the future. 
It shouldn't stop anything happening now.

>However, there are some artifactIds that are non-deterministic and some that 
>have been moving around;
>  
>
Moving around is always going to be a problem.

>Magic chose to have the Gump support built in to its object model, so that the 
>mapping can be explicit in the model and the desriptor generation is 
>  
>
I still don't get how Magic does this. Would "ant" declare that it is 
also "jakarta-ant" so that projects looking for "jakarta-ant" find the 
right thing? How does this get fed to gump?

Anyway, I added dependency properties so that projects can control their 
own destiny. This means if a project changes names, its dependees will 
all break, but I think they'd want to know that anyway.

<dependency>
  <groupId>...</groupId>
  <artifactId>...</artifactId>
  <properties>
    <gump.project>...</gump.project>
  </properties>
</dependency>

With that, the gump descriptor should not need to be hand edited.

>I am not certain about this. It may be irrelevant to Maven, but is it 
>irrelevant to Gump? OTOH, it will tell quickly.
>  
>
According to the documentation, it was for classpath generation. 
Shouldn't be needed.

>Does Multiproject support aggregates to a single descriptor or generate one in 
>each directory?? Single descriptors per project may not be appreciated by 
>other Gump folks, but I am not sure how it would be perceived.
>  
>
Yes, it does it like you had previously done it for eve. One module, 
many projects.

>Yes, there are in fact namespace issues and I think this is more a Gump 
>problem than a Maven problem. If you check the id= attribute for <jar> 
>elements and the corresponding ids= attribute for <depend> elements, you see 
>the 'hack' to solve some of it.
>  
>
This is what matching the IDs will buy eventually.

So, does eve/trunk/gump.xml now look correct to you? Is there anyway we 
can get it to run and find out?

If there is anything else you want to discuss about the changes I made 
for Maven/Gump, we should probably take it over to the gump list...

- Brett

Re: directory and gump

[Niclas Hedhman <ni...@hedhman.org>]

On Friday 10 December 2004 06:21, Brett Porter wrote:

> I reread the documentation and did the following:
> - stopped mapping ids (the ability is there for the project to do that
> in its descriptor)

There is an outstanding issue in Gump that all project names should be 
synchronized with the Maven artifactIds. 
However, there are some artifactIds that are non-deterministic and some that 
have been moving around;
1. Sun's packages like javamail and jca are examples of the former.
2. xml-apis and logkit are examples of the second.
So I think the Gump Meisters are working on a mapping solution for Gump, BUT 
that makes the automated generation only 'advisory' and not conclusive.
Magic chose to have the Gump support built in to its object model, so that the 
mapping can be explicit in the model and the desriptor generation is 
conclusive (i.e. never need to modify manually - who could manage it for 
Avalon's 250kB descriptor).

> - removed work and mkdir (these seem irrelevant for Maven)

I am not certain about this. It may be irrelevant to Maven, but is it 
irrelevant to Gump? OTOH, it will tell quickly.

> - added junitreport
> - fixed svn
> - added multiproject support

All Great. 
Does Multiproject support aggregates to a single descriptor or generate one in 
each directory?? Single descriptors per project may not be appreciated by 
other Gump folks, but I am not sure how it would be perceived.

> The only thing I am now unsure about: I set module name to the
> artifactId, not the groupId. The reason for this is I believe (though
> don't see anything supporting or contradicting it in the doco) that
> gump may expect that name to be unique in the workspace, and groupId
> will not be.
>
> There is still the risk that there will be namespace issues later, but
> we can cross that bridge when we come to it.

Yes, there are in fact namespace issues and I think this is more a Gump 
problem than a Maven problem. If you check the id= attribute for <jar> 
elements and the corresponding ids= attribute for <depend> elements, you see 
the 'hack' to solve some of it.

Cheers
Niclas
-- 
   +------//-------------------+
  / http://www.dpml.net       /
 / http://niclas.hedhman.org / 
+------//-------------------+