commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <dennis.lundb...@mdh.se>
Subject Re: [all] Sharing maven setup [was Re: HELP!]
Date Mon, 05 Dec 2005 22:04:29 GMT
Stephen Colebourne wrote:
>>> I don't much like the idea of adding dependencies to each of the
>>> individual POMs, but understand that this makes the dependency
>>> explicit, which is a good thing.  So I guess I am +0 for this
>>> approach.  Actually +1 as in "will help" if others agree we should go
>>> this route instead of the updatePlugins approach.
>>
>> I'm more than happy with the updatePlugins approach. It's KISS at its 
>> best.
>> ;-)
>>
>> I remain -1 on reverting to extending the commons-build POM
> 
> I agree that we should not extend the commons-build POM. However we 
> could do with a way to share stuff.
> 
> I have in my mind that what we need is a commons maven plugin. It would:
> - create target/commons
> - download commons-build within target/commons
> - update the local maven installation
> - merge the latest mandatory POM settings
> - merge the latest mandatory POM properties
> - merge the latest mandatory xdocs
> 
> Thus, to push a site or release out you do:
> maven commons
> then any other command:
> maven ...
> 
> This is probably a pipedream though, as I doubt anyone has the time to 
> write this (ie. I don't!)

Yes, of course! A plugin is the way to go.

Most people seems to agree that extending commons-build is a bad thing, 
so we need to figure out a way to make each commons component 
self-supporting.

Imagine this directory structure in the commons component of your choice:

/
+- commons-<component>/
    +- site/
    |  +- menus/
    |  |  +- ...
    |  +- parts/
    |  |  +- ...
    |  +- commons-site.jsl
    |  +- cvsusage.xml
    |  +- ...
    +- project.properties
    +- project.xml
    +- project-parent.xml

First we make sure that every commons-component extends the *local* 
project-parent.xml, see directory-structure above. This would be a 
one-time job.

If we then create a plugin that does the following, it might just work:

- Download commons-build/project-parent.xml via anonymous SVN to 
commons-<component>/project-parent.xml
- We would probably need to do something similar for project.properties, 
I'm not sure how that would work though
- Download commons-build/site/menus/ , commons-build/site/parts/ et al 
via anonymous SVN to commons-<component>/site/

This way we don't have to think about merging xml documents and other 
fancy stuff - just download some files from SVN.

Does this sound at all possible?

Should I have go at it? I have not made a plugin before, but there's a
first time for everything...

-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message