Just wanted to express my opinion about new plugins.
I don't think that we should add more plugins to maven, unless they are really "core plugins".
I think we have quite a lot of dead plugins and many broken plugins,
I like more the idea of having this plugin elsewhere, so original plugin authors can take responsibility.
I daresay that 2/3 of exising maven plugins is broken and/or orphaned. This is obviously an unacceptable situation.
Below there's a list of plugins taken from current website. I've put marks next to them representing *my personal* opinion on the pluin's condition.
C - core - needed to perform basic tasks M - actively maintained O - obsoleted by other plugins B - broken
# ant # antlr # appserver # artifact M C # ashkelon # aspectj # cactus M # castor # changelog C # changes C # checkstyle M C # clean C # clover M # codeswitcher # console C # deploy O? # developer-activity C # dist C # docbook M # ear C # eclipse # ejb # examples M # faq # file-activity C # genapp # gump # hibernate # html2xdoc # idea # j2ee O # jalopy # jar C # java C # javadoc C # jboss M # jbuilder M # jdee # jdepend # jdeveloper # jdiff # jellydoc # jnlp # junit-report # junitdoclet # jxr C # latex # latka # license C # linkcheck M C # native # pdf M # perforce # plexus # plugin # pmd # pom C # release C # repository # runner # sea # shell # site # statcvs C # struts # summit # tasklist C # test C # torque # touchstone M C # touchstone-partner M C # uberjar # vdoclet # war # was40 M # webserver O? # wizard # word2html # xdoc M C
There is a few plugins there that I don't know/understand so my marks may be off base here and there.
It would be nice if one of the commiters checked in a plugin-map.xml
xdoc that would contain a list of plugins similar to that one above, and
then all commiters would add their name next to the plugins they are willing to work on, and their name in ( ) next to the plugins they
know good enough to fix if they happen to break.
As for the core/obsolete status of each plugin an IRC discussion with a sigle person writing down resolutions would probably be best.
I second Michal's opinion that we should not put any more plugins into maven repository, and that some of the existing one should move away onto another CVS repo on maven.apache.org or even to the repos of their associated software projects.
At the same time I agree with Vincent that this is not really feasible
ATM, because we lack a mechanism for expressing plugin runtime dependencies - both on Maven core version and on other plugins / versions.
The notation for those dependencies is basicly in place, we might need to introduce addtional artifact types for that. Here's a snippet from a hypotetical plugin's project.xml:
<dependencies>
<dependency>
<dependencyType>runtime</dependencyType>
<groupId>maven.apache.org</groupId>
<artifactId>maven-core-plugin</artifactId>
<artifactType>plugin</artifactType>
<version>1.0</version>
<versionMatch>compatible</versionMatch>
</dependency>
<dependency>
<dependencyType>build</dependencyType>
<dependencyType>runtime</dependencyType>
<groupId>maven.apache.org</groupId>
<artifactId>maven-</artifactId>
<artifactType>maven-artifact-plugin</artifactType>
<version>1.0</version>
<versionMatch>equivalent</versionMatch>
<dependency>
</dependencies>tags used:
<dependencyType> - Michal's <kind>: build,runtime,test - a hint for grouping dependencies together for different uses throughout the system
<artifactType> - current <type>: jar,war,ear,plugin... - renamed for contrast with the above
<versionMatch> : perfect,equivalent,compatible,greaterOrEqual - a hint for the Dependency resolver to allow imperfect matches, using Eclipse
conventions (when 1.1.0 is requested, 1.1.1 is considered equivalent,
1.2.0 compatible, and 2.0.0 greaterOrEqual)
maven-core-plugin - maven could ship with a dummy plugin bearing the same version tag as the core, that could be used for expressing
projects/plugins dependency on particular version of the core without
introducing a degenerate <artifactType> (a type that would be valid
for only one special artifact).
Even if all of the above seems easy, it is not. The *real* fun begins when a project insists on using plugins that have conflicting requirements. Once plugins are distributed independently from the core and one another this will be a frequent situation, and maven will need to go to great lenghts to help the users out of the mess. Isolating plugins and merging them into mutualy compatible clusters by the means of serious classworld jugglig comes to my mind...
R.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
