On 2009-12-30, at 1:48 AM, Arnaud HERITIER wrote: > On Wed, Dec 30, 2009 at 2:45 AM, Jason van Zyl <[email protected]> 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 !
Arnaud, seriously don't worry about it right now. Let's get 3.0 out the door and there is a ton to do just in that. Everything is the same right now, 3.0 should be a drop in replacement. Let's not get ahead of ourselves. > > 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl ---------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
