On Wed, Dec 30, 2009 at 2:45 AM, Jason van Zyl <ja...@sonatype.com> wrote:
> > On 2009-12-29, at 8:05 PM, Arnaud HERITIER wrote: > > >> > >>> What I recall discussing with Brian at ApacheCon was having a new > project > >> descriptor but making sure that when projects are installed or deployed > a > >> pom compatible with the current format would also be deployed along with > the > >> new descriptor. If the new project descriptor allows extension then this > >> could continue to work as things change. > >> > >> > >> Yah, I think we've been beating this around for a while... in my mind, > it's > >> still a unified repository metadata format that the POM translates to > (and a > >> parallel 4.0.0 POM / maven-metadata for old clients). > >> > >> It seems like that and the POM and the deprecations can be the single > focus > >> for 3.1... we just need to ship "Snow Maven" at this point so we can > move on > >> to new things. > >> > >> > >> > > Do we have in 3.0 a mechanism to have a constraint when we develop a > plugin > > to say that it requires a minimal version of POM. > > I would argue this should never happen in the future. A plugin should > define what it needs in its own configuration. I'm also going to push for > getting plugin specific POM elements back into the plugins that operate on > that data. Like pushing the resources elements into the resources plugin, > the distribution management information back into the deploy plugin, source > roots to the compiler plugin and anything akin to it. It's the only way to > continue scaling. There are changes that need to be made to the POM but I > really don't want to see proliferation of POM elements to service specific > plugins. > > I don't agree with Ralph that there needs to be a general POM extension > mechanism. It's going to happen primarily inside plugins. > ok for me to push what we can in plugins configurations but won't we have quickly some plugins incompatibilities because they'll share some info like resources, sources and many others (encoding, compiler version) and if the plugin which stores this info changes the name of the config or something like that, all others will be broken ? I wouldn't like we have again the maven 1 experience where plugins used others and finally we didn't control them ! Another thing if we move more data in plugins is the verbosity of our config. Even if we'll have alternative format, instead of overriding/extending build/resource we'll have to do it in build/plugins/plugin/config/resources ..... (many lines for a little change). To end another disadvantage to have more things in plugins config is that we won't validate them (with a schema and at runtime) and we'll ignore wrong settings which is always a big issues for our users because they don't quickly see if they made a misprint in the config. > > > Let's imagine we add a new data in the pom in 4.1.0 and a plugin needs to > > use them, thus maven shouldn't automatically check when it load a plugin > > that it is compatible with the POM version. > > Sure, we can augment whatever is necessary in preparation for 3.1. > > > > > Another question about 3.0, did we reintroduce // dowloads ? I think it > > wasn't here in the last alpha. > > One form of it is in the Jetty Wagon we have at Sonatype. There is a new > interface called the RepositorySystem which encapsulates everything with far > fewer interfaces then the legacy system. We also have another set of > interfaces which is a complete internal replacement. Benjamin has this on a > branch. So if someone wants to try and implement or backport Don's work then > that's cool too. If we want to get a 3.0 sometime around the beginning of > February then I'm not sure that will make it into 3.0. Might be soon after > that. > > I'm still more in favour IT quality, getting the JIRA issues cleaned up and > getting out the 3.0. > > If people want this released soonish and want specific features then speak > now and commit your time. > > > > > Arnaud > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > ---------------------------------------------------------- > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
