Phil Steitz wrote:
Dennis,
Thanks!! +1 for the commons-plugin. See comments interspersed. One
thing to keep in mind is to try to keep it as simple as possible. I
think we got a little too complicated in the site generation stuff and
it has been a pain to maintain. Other nice-to-haves are ease of
migration to maven 2 and reusability outside of commons (group of
related, but independent projects wanting to share some common
resources).
On 12/5/05, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
<snip>
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.
Yes, the trick is how to do this while keeping projects self-contained.
Exactly.
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?
Definitiely sounds doable and reasonable to me; with the exception of
the POM inheritance bit. I am not yet 100% convinced of the need for
project-parent and I am not sure about the consequences of this from a
maven repo standpoint. I don't know if you can inherit from an
"abstract" POM or even if such a thing exists - i.e., IIUC your
project-parent would have to have a groupID/artifactID and the local
repo (and eventually apache/ibiblio) might get corrupted/confused, as
this could change over time. The latter actually is the core of the
issue - in order for the releases to be really self-contained, either
we have to tag and version the common stuff with each component
release, or they need to be able to essentially fork it (as they more
or less do now).
My idea was to actually check in all of the common bits and pieces into
each and every commons-component. The job of keeping these bits updated
would be handled by the plugin. That way the tagging would be solved by
each component. It would mean a lot of copies of these common files, but
I don't see that as a problem.
We would need to add a mandatory step in the release cycle to run the
commons-plugin and check in the common files that have changed.
<snip/>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
