The following comment has been added to this issue:
Author: Brett Porter
Created: Wed, 14 Jan 2004 6:32 PM
Body:
certainly a great idea. This has been discussed on the list before too.
Some issues:
- transparently downloading is great, but we also need to account for the offline
users that want to be able to download as much as possible in advance. So an optional
plugin bundle distro is still a good idea
- can we really limit plugins to one unique Id like that? I think groupId needs to be
incorporated, but keeping that simple when actually attaining the goals is tricky.
I'm not sure this is the best way to approach it.
- If a project needs a certain plugin to build, then a dependency is a good idea
because you can ensure versions, etc.
- If a user wants a new plugin goal, they have found out about it somewhere, so
probably know where to get the plugin from - maybe we just need to make
installation/management easier than the current plugin:download goal.
Also, we really need the plugin installation mechanism to be a component of maven
itself rather than a responsibility of a plugin so that we can make GUI interfaces and
more.
---------------------------------------------------------------------
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MCOMPONENTS-10
Here is an overview of the issue:
---------------------------------------------------------------------
Key: MCOMPONENTS-10
Summary: Transparent plugin downloading
Type: Task
Status: Open
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: maven-components
Components:
maven-core
Assignee: Jason van Zyl
Reporter: Jason van Zyl
Created: Wed, 14 Jan 2004 6:22 PM
Updated: Wed, 14 Jan 2004 6:32 PM
Description:
Before we start advocating people specify plugins as dependencies in their POMs I
would like to discuss a simple approach that will scale to any number of plugins.
Ultimately, I believe the goal is to ease the burden for the user. To that end I think
plugins being downloaded transparently when required is the ideal to strive for.
Plugins have to be located outside the core and I believe it is entirely possible to
make all plugins external to the core.
By having a simple convention where the goal is prefixed by the name
of the plugin that it belongs to. So something simple like:
antlr:generate
Would simply look for the antlr plugin. So we could also simplify the naming of the
plugins as jar as packaging goes too and stop assuming maven-foo-plugin.
To keep people from complaining about having to type foo:bar we can create a simple
alias mechanism so people can make short cuts for themselves if they wish. But most of
the time someone would check a build out and run the default goal, if anything special
is required it should be automatically downloaded.
This way the maven core can ship with the basic six plugins to build and test projects
and everything above that gets downloaded, but transparently as not to burden the user.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
