You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Antoine Levy-Lambert <an...@gmx.de> on 2011/03/01 20:58:53 UTC

Re: svn commit: r1075910 - in /gump/metadata/project: directory-apacheds.xml directory-shared.xml

Hello Stefan,

Apache Directory Server has a lot of maven projects in it and they do a 
lot of refactoring.

Would there not be something to do to automate the maintenance of gump 
descriptors for maven based projects ?

Or even better, could gump be made able to read parent pom.xml files 
directly and reinterpret them as gump metadata ?

I do not have CPU cycles to develop that but my guess is that it would help.

Regards,

Antoine


On 3/1/2011 11:54 AM, bodewig@apache.org wrote:
> Author: bodewig
> Date: Tue Mar  1 16:54:44 2011
> New Revision: 1075910
>
> URL: http://svn.apache.org/viewvc?rev=1075910&view=rev
> Log:
> more refactorings in directory-shared
>
> Modified:
>      gump/metadata/project/directory-apacheds.xml
>      gump/metadata/project/directory-shared.xml
>
>


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


Re: svn commit: r1075910 - in /gump/metadata/project: directory-apacheds.xml directory-shared.xml

Posted by sebb <se...@gmail.com>.
On 2 March 2011 05:04, Stefan Bodewig <bo...@apache.org> wrote:
> On 2011-03-01, Antoine Levy-Lambert wrote:
>
>> Apache Directory Server has a lot of maven projects in it and they do
>> a lot of refactoring.
>
> I know 8-)
>
>> Would there not be something to do to automate the maintenance of gump
>> descriptors for maven based projects ?
>
>> Or even better, could gump be made able to read parent pom.xml files
>> directly and reinterpret them as gump metadata ?
>
> The main problem is the mismatch of ids.  Gump's id space is flat and
> Maven has the tuple of groupId and artifactId.  In many cases we can use
> the artifactId but it is not always possible as things tend to clash
> from time to time (junit-addons is one such example).  I don't see an
> automated way to resolve this.
>
> Another problem is writing a POM parser for Gump that recursively chased
> down parent POMs and knew how to consider the dependencies of plugins
> (almost all mvn projects depend on Velocity via the site plugin).
>
>> I do not have CPU cycles to develop that
>
> Me neither, sorry.

Some of the code is available from Maven itself - e.g.
help:effective-pom - but of course that output would then need to be
parsed.

Someone that knows Maven intermals well could probably produce a
plugin that returned the information Gump needs in a format that Gump
could easily use.

But I don't currently have that knowledge.

> 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: svn commit: r1075910 - in /gump/metadata/project: directory-apacheds.xml directory-shared.xml

Posted by Stefan Bodewig <bo...@apache.org>.
On 2011-03-01, Antoine Levy-Lambert wrote:

> Apache Directory Server has a lot of maven projects in it and they do
> a lot of refactoring.

I know 8-)

> Would there not be something to do to automate the maintenance of gump
> descriptors for maven based projects ?

> Or even better, could gump be made able to read parent pom.xml files
> directly and reinterpret them as gump metadata ?

The main problem is the mismatch of ids.  Gump's id space is flat and
Maven has the tuple of groupId and artifactId.  In many cases we can use
the artifactId but it is not always possible as things tend to clash
from time to time (junit-addons is one such example).  I don't see an
automated way to resolve this.

Another problem is writing a POM parser for Gump that recursively chased
down parent POMs and knew how to consider the dependencies of plugins
(almost all mvn projects depend on Velocity via the site plugin).

> I do not have CPU cycles to develop that

Me neither, sorry.

Stefan

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