maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <bpor...@f2network.com.au>
Subject RE: Core plugins?
Date Thu, 11 Sep 2003 23:07:04 GMT
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. 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 :)

The other advantage, that also came up in this thread, is not having to
specify a plugin dependency each time.

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.

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...)

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. 

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.

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).

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.

Cheers,
Brett

> -----Original Message-----
> From: Vincent Massol [mailto:vmassol@pivolis.com] 
> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message