> -----Original Message----- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: 12 September 2003 01:07 > To: 'Maven Developers List' > Subject: RE: Core plugins? > > I should clarify what I was getting at. > > The reason to select and bundle "core" plugins is because they are > frequently used, and will be downloaded first run anyway. We want to save > the user some time.
So why don't you bundle the 100 or so needed jars that are required to make these plugin work? :-) I do agree with the idea of a Maven distribution that bundles the latest version of all plugins. There could even be 2: one with core plugins and one with all "well-known" plugins. I don't see how this is related to hosting the core plugins in Maven core. I'd rather they have a separate lifecycle of their own (like other plugins do). However, as Jason pointed out, I agree that we can do it in 2 steps. Step 1, keep the core plugins in Maven core while moving others out. Step 2, separate all plugins from Maven core. > The analogy with Ant would be the regular tasks vs. > the > optional tasks - however they often do distribute the optional tasks too, > so > maybe not the best example :) Is the fact that core Ant tasks (and optional ones) are located in Ant CVS repo good? I don't think so. I think this has been hampering Ant since the beginning. Having an Ant repository of tasks on the web (CPAN for Ant) would have helped I think. That doesn't mean that some of them cannot be bundled with Ant distributions. The only positive point I see is that it simplifies dependency management and stability. Look at JEdit for example. Each plugin has to say what version of JEdit it is compatible with and what other plugin dependencies it requires (with versions). However, that should be doable. > > The other advantage, that also came up in this thread, is not having to > specify a plugin dependency each time. Yep. Hence the idea of a global project.xml that is automatically "inherited". > > I'm doing some work on the versioning of plugins this weekend as discussed > last week. So multiple versions can reside n the $MAVEN_HOME/plugins. What > should happen is the user always gets the latest > - and if that breaks > their > build, they give a plugin dependency to get a version they know works. Cool. > > To obtain a plugin, you can give a dependency, or use the plugin:download > goal. Either way, it gets installed into MAVEN_HOME (this is a problem at > the moment - we're back to the beta-9 and before days of not having a read > only distribution...) ok. > > How do I see it long term? > > For the downloading and use of plugins - exactly how it is now is fine, > however I think that we should replace $MAVEN_HOME/plugins with > $MAVEN_REPO_LOCAL/maven/plugins as the central storage point. More > consistent, less duplication. I do agree. It goes in the right direction of separating plugins from Maven core. > > If we are distributing plugins, they should be copied across to the > repository first run, like install_repo does for the lib/ directory. > > Decoupling core plugins is fine, but we -must- a convenient distribution > of > them and their dependencies. Not everyone has broadband internet, and > there > is nothing more annoying than downloading a program, getting offline, and > not being able to use it because you need to download more stuff to even > compile a single class. > Agreed. Hence the idea of the global project.xml (or whatever you want to call it). > I think what is core is fairly obvious. Off the top of my head clean, jar, > war, ear, plugin, site, dist (probably more) and anything required to run > them - java, test, junitreport, xdoc, all the standard reports, artifact, > deploy, ... > There are probably a few more which are contentious: release/scm, console, > appserver/webserver. Probably better to err on the side of being more > inclusive as they are not that big (although + dependencies they may be). Cactus is core for me! PMD is core for me! JBoss is core for me! Etc. What is core depends on what you use daily ;-) Hence the idea of the global project.xml in which users can modify what is core for them. > > I'm agreeing now that this is probably a 1.1 goal. At least we have an > easy > plugin installation mechanism... However, uninstall is a bit of a nuisance > as it needs to go from several places. That's another fix that needs to be > made. Cool :-) Thanks for the hard work! -Vincent > > Cheers, > Brett > > > -----Original Message----- > > From: Vincent Massol [mailto:[EMAIL PROTECTED] > > Sent: Thursday, 11 September 2003 5:45 PM > > To: 'Maven Developers List' > > Subject: Core plugins? > > > > > > Hi, > > > > Brett mentioned in a an earlier email today that the idea of > > RC1 would be a maven core containing core plugins and other > > plugins which would not be part of the main maven distribution. > > > > What I don't understand is the concept of "code plugins". For > > me a plugin is a plugin and they should all be treated equal. > > > > What is the rationale behind hosting core plugins in the > > maven core? Why couldn't the be download like the other ones? > > Why couldn't they have a spearate lifecycle than the maven core? > > > > Thanks > > -Vincent > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
