You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "Mark Struberg (JIRA)" <ji...@codehaus.org> on 2011/04/26 14:40:22 UTC
[jira] Created: (MNG-5080) revert separation of plugin and
dependency repositories
revert separation of plugin and dependency repositories
-------------------------------------------------------
Key: MNG-5080
URL: http://jira.codehaus.org/browse/MNG-5080
Project: Maven 2 & 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.0.3, 3.0.2, 3.0.1
Reporter: Mark Struberg
I fear we need to rething the changes done in MNG-4191.
While expressing my dislike about the strict classpath separation on IRC a few times already since quite a few months, this now really turns out into having a huge kickback.
Basically every business project I saw being upgraded to maven3 compat got all their <repositories> sections dupped into <pluginRepositories>.
This can't be it!
The reason for it is that _lots_ of plugins needs dependencies to 'normal' artifacts.
* hibernate-maven-plugin
* jboss-maven-plugin
* tomcat-maven-plugin
* cargo
.... you name it ...
basically ALL plugins which serve as helper for any 3rd party libraries and products.
In addition, this problem hits a lot use cases where plugins get 'resources' via dependencies like
* maven-checkstyle-plugin
* maven-pmd-plugin
* emma-maven-plugin
* maven-remote-resources-plugin
* etc
Have you ever had one project which uses _none_ of those plugins? Then you are happy and don't need that. But for all other projects there is a good chance that you will end up duplicating all your repository sections as pluginRepository ...
In most of our Apache projects this just doesn't show off because maven.central is by default defined as both <repository> and <pluginRepository>. But once you hit a company situation, you will get this problem
Jason already proposed to drop the <pluginRepository> section completely in MNG-2750.
Maybe that's the way to go?
--
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
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5080) revert separation of plugin and dependency
repositories
Posted by "Jason van Zyl (JIRA)" <ji...@codehaus.org>.
[ https://jira.codehaus.org/browse/MNG-5080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason van Zyl updated MNG-5080:
-------------------------------
Assignee: Jason van Zyl
> revert separation of plugin and dependency repositories
> -------------------------------------------------------
>
> Key: MNG-5080
> URL: https://jira.codehaus.org/browse/MNG-5080
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 3.0.1, 3.0.2, 3.0.3
> Reporter: Mark Struberg
> Assignee: Jason van Zyl
>
> I fear we need to rethink the changes done in MNG-4191.
> While expressing my dislike about the strict classpath separation on IRC a few times already since quite a few months, this now really turns out into having a hugely negative kickback.
> Basically every business project I saw being upgraded to maven3 compat got all their <repositories> sections dupped into <pluginRepositories>.
> This can't be it!
> The reason for it is that _lots_ of plugins need dependencies to 'normal' artifacts.
> * hibernate-maven-plugin
> * jboss-maven-plugin
> * tomcat-maven-plugin
> * openjpa-maven-plugin
> * cargo
> .... you name it ...
> basically ALL plugins which serve as helper for any 3rd party libraries and products.
> In addition, this problem also hits all use cases where plugins get 'resources' via dependencies, like:
> * maven-checkstyle-plugin
> * maven-pmd-plugin
> * emma-maven-plugin
> * maven-remote-resources-plugin
> * etc
> Have you ever had one project which uses _none_ of those plugins? Then you are happy and don't need that. But for all other projects there is a good chance that you will end up duplicating all your repository sections as pluginRepository ...
> In most of our Apache projects this just doesn't show off because maven.central is by default defined as both <repository> and <pluginRepository>. But once you hit a company situation, you will get this problem
> Jason already proposed to drop the <pluginRepository> section completely in MNG-2750.
> Maybe that's the way to go?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-5080) revert separation of plugin and
dependency repositories
Posted by "Mark Struberg (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-5080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mark Struberg updated MNG-5080:
-------------------------------
Description:
I fear we need to rethink the changes done in MNG-4191.
While expressing my dislike about the strict classpath separation on IRC a few times already since quite a few months, this now really turns out into having a hugely negative kickback.
Basically every business project I saw being upgraded to maven3 compat got all their <repositories> sections dupped into <pluginRepositories>.
This can't be it!
The reason for it is that _lots_ of plugins need dependencies to 'normal' artifacts.
* hibernate-maven-plugin
* jboss-maven-plugin
* tomcat-maven-plugin
* openjpa-maven-plugin
* cargo
.... you name it ...
basically ALL plugins which serve as helper for any 3rd party libraries and products.
In addition, this problem also hits all use cases where plugins get 'resources' via dependencies, like:
* maven-checkstyle-plugin
* maven-pmd-plugin
* emma-maven-plugin
* maven-remote-resources-plugin
* etc
Have you ever had one project which uses _none_ of those plugins? Then you are happy and don't need that. But for all other projects there is a good chance that you will end up duplicating all your repository sections as pluginRepository ...
In most of our Apache projects this just doesn't show off because maven.central is by default defined as both <repository> and <pluginRepository>. But once you hit a company situation, you will get this problem
Jason already proposed to drop the <pluginRepository> section completely in MNG-2750.
Maybe that's the way to go?
was:
I fear we need to rething the changes done in MNG-4191.
While expressing my dislike about the strict classpath separation on IRC a few times already since quite a few months, this now really turns out into having a huge kickback.
Basically every business project I saw being upgraded to maven3 compat got all their <repositories> sections dupped into <pluginRepositories>.
This can't be it!
The reason for it is that _lots_ of plugins needs dependencies to 'normal' artifacts.
* hibernate-maven-plugin
* jboss-maven-plugin
* tomcat-maven-plugin
* cargo
.... you name it ...
basically ALL plugins which serve as helper for any 3rd party libraries and products.
In addition, this problem hits a lot use cases where plugins get 'resources' via dependencies like
* maven-checkstyle-plugin
* maven-pmd-plugin
* emma-maven-plugin
* maven-remote-resources-plugin
* etc
Have you ever had one project which uses _none_ of those plugins? Then you are happy and don't need that. But for all other projects there is a good chance that you will end up duplicating all your repository sections as pluginRepository ...
In most of our Apache projects this just doesn't show off because maven.central is by default defined as both <repository> and <pluginRepository>. But once you hit a company situation, you will get this problem
Jason already proposed to drop the <pluginRepository> section completely in MNG-2750.
Maybe that's the way to go?
> revert separation of plugin and dependency repositories
> -------------------------------------------------------
>
> Key: MNG-5080
> URL: http://jira.codehaus.org/browse/MNG-5080
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
> Affects Versions: 3.0.1, 3.0.2, 3.0.3
> Reporter: Mark Struberg
>
> I fear we need to rethink the changes done in MNG-4191.
> While expressing my dislike about the strict classpath separation on IRC a few times already since quite a few months, this now really turns out into having a hugely negative kickback.
> Basically every business project I saw being upgraded to maven3 compat got all their <repositories> sections dupped into <pluginRepositories>.
> This can't be it!
> The reason for it is that _lots_ of plugins need dependencies to 'normal' artifacts.
> * hibernate-maven-plugin
> * jboss-maven-plugin
> * tomcat-maven-plugin
> * openjpa-maven-plugin
> * cargo
> .... you name it ...
> basically ALL plugins which serve as helper for any 3rd party libraries and products.
> In addition, this problem also hits all use cases where plugins get 'resources' via dependencies, like:
> * maven-checkstyle-plugin
> * maven-pmd-plugin
> * emma-maven-plugin
> * maven-remote-resources-plugin
> * etc
> Have you ever had one project which uses _none_ of those plugins? Then you are happy and don't need that. But for all other projects there is a good chance that you will end up duplicating all your repository sections as pluginRepository ...
> In most of our Apache projects this just doesn't show off because maven.central is by default defined as both <repository> and <pluginRepository>. But once you hit a company situation, you will get this problem
> Jason already proposed to drop the <pluginRepository> section completely in MNG-2750.
> Maybe that's the way to go?
--
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
-
For more information on JIRA, see: http://www.atlassian.com/software/jira