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. > > > > 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). I do like the idea of copying in the commons-build pieces at build time using the scm plugin or somesuch. That can help us untangle the current navigation mess, among other things. To get around the tagging / versioning problem, I have thought about suggesting in the past that we check local copies into release branches and tag these as part of releases. So, when working in trunk you do something like what you have described above, but then when cutting a release, you create an svn release branch that includes the local copies. These then go into the release tag and you can later duplicate the release from the tag. The plugin could support a branch goal that would create the release branch with the local stuff in it. > > Should I have go at it? I have not made a plugin before, but there's a > first time for everything... > Agree with Robert's comments below. I will chime in as time and knowledge permits :-) Have a look at the jdiff and changelog plugins for examples of how to use the scm stuff. Phil --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
