> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 08 October 2003 08:03 > To: Maven Developers List > Subject: RE: Moving Plugins > > "Vincent Massol" <[EMAIL PROTECTED]> wrote on 08/10/2003 03:39:23 PM: > > > Hi Jason, > > > > I'm fine with moving the following: Cactus, checkstyle, jboss, pmd, > > statcvs and actually all the other remaining plugins... I still don't > > understand why we need to keep any plugin at all in maven core. They can > > be downloaded for bootstrapping (in the same way as all the other jars > > are). > > I'd rather we got the moved plugins integrated into the > distribution/install process so that it's easier to do rc-2, and got the > web site back to it's original functionality. This moving stuff and losing > functionality/documentation shits me.
Agreed. In my opinion we should do both. We already started the plugin move; we should finish it and not let it lie in mid-air. I shall be able to help more in about 1-2 week's time now that my JUnit book is going to press... (yeah :-). It's sooooo good when it's finished). [snip] > > - now that the plugins are decorelated from Maven core, the plugins need > > to state with what version of Maven they have been tested and are > > compatible with. How do we do this? Do we need a new pom tag? > > They should declare it, if needed, using a dependency. Some of them > already do. Yeah I thought about this, but... How is that going to work? 99.99% of the plugin do not depend on the maven jar... Let's take an example; let's imagine I want to say that the maven-cactus-plugin plugin only works with Maven RC1 or later. How do I say that? How is it checked by the Maven core so that Maven will say "Sorry, you need Maven xx or greater for this plugin to work"? In addition, adding this declaration will download the maven jar which is unnecessary for most plugins. > > > - also, now that plugins are externalized it will be more difficult to > > converge in term of jar versions between them. You may end up having to > > I don't see why. We have a dependency convergence report for the core set > (currently http://maven.apache.org/dependency-convergence-report.html ), > and if we could get our act together on setting up a site for the split > plugins, we'd have the same report. It's not that difficult. > > > download 10 versions of log4j, etc. I believe we now need more urgently > > something like the discussed LATEST (which would point to the latest > > released jar): > > > > <dependency> > > <groupId>log4j</groupId> > > <artifactId>log4j</artifactId> > > <version>LATEST</version> > > </dependency> > > > > That would probably require the addition of some metadata file in the > > remote repo (releases.xml for ex), listing all releases. The default > > mode should not connect to internet every time maven builds but rather > > only connects on demand. > > Good idea, and I think we'll need it eventually, but IMHO there are more > important issues to solve, such as getting a distribution of maven > together that includes all the needed jars and plugins. Agreed. In any case I should help if I want to get things done... ;-) Thanks dIon -Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
