Agreed on the first two. artifactIds and sourceDirectories changed. Rest still feels up in the air. Am also tempted to do some releases :)
On Sun, Jan 11, 2009 at 6:11 PM, Rahul Akolkar <rahul.akol...@gmail.com> wrote: > So I think we're doing well on the m2 stuff (thanks for getting it started > Hen). > > Various observations that came to mind as I looked at this during the > last couple of days: > > * Artifact IDs - Lets have the invariant part first (so > 'taglibs-string' rather than 'string-taglib') ... I like the former > better, similar to Commons and I've used such artifactIDs for the RDC > build. > > * The <sourceDirectory> defined in the parent pom is non-standard, > required overrides in RDC modules. However, RDC is the only taglib > using the standard directory for this so may be less effort to let > this be rather than redo rest of the taglibs. > > * The RDC build uses multiple modules, particularly because the size > of the taglib is much bigger compared to some of the others, and we > have a couple of sample apps so its important to separate out the > sources etc. TBD whether all taglibs should do the same, but this > approach scales very well (perhaps standard can adopt it). > > * The RDC taglib does not use the taglib-plugin to generate the docs > (I have a couple of changes to the site in mind and will publish it in > a day or two). Its hard to un-inherit a plugin from the parent so I've > worked around it a bit, but again, since all other taglibs are using > it I think we should leave it in the parent. > > * At this point, the distros produced by the RDC build are close > enough to what we had before and immediately usable IMO. We can slap > an 'rc' profile on the parent pom for sums, sigs etc. and then use the > release plugin. So releasing will amount to: > > mvn -Prc release:prepare > mvn -Prc release:perform > > Given the above, I'm actually tempted to produce an RC for RDC v1.1. > There were a bunch of improvements couple of years ago (a new > component, an SCXML-based dialog manager, minor improvements here and > there) and it'd be good to get a release out. Will also be a good test > to see if we have enough folks around at Taglibs. > > Thoughts? > > -Rahul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org > For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: taglibs-dev-unsubscr...@jakarta.apache.org For additional commands, e-mail: taglibs-dev-h...@jakarta.apache.org
