[jira] Commented: (MCOMPONENTS-10) Transparent plugin downloading

[ji...@codehaus.org]

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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org