Well, I thought the discussion was over IRC, but searching the last
year and a half, I'm at a loss.
The original reasoning here was to clean up the usage of repositories
in 2.1, and since there is no end to problems with pluginRepositories
when people actually use them, this seemed like a good target. We had
some discussion about disabling plugin auto-resolution when the
version is missing on the dev list, but we didn't reach any sort of
consensus there, except to say that not specifying versions is
dangerous, I think. It would be good to drive that discussion to some
resolution, and figure out how we can pin down plugin versions for
everything used in a given build (even in default lifecycle bindings
and such) in a scalable and effective way. However, this will almost
certainly require changes to the project builder, since putting
plugin-version information in released versions of maven itself is
very bad, and there is currently no way to specify plugin versions
for the default lifecycle bindings except through the
pluginManagement section of a parent pom or similar.
In any case, plugin repositories are mixed up with regular
repositories during the plugin resolution process. At one point, I
had written code to resolve only the plugin artifact itself using
only the pluginRepositories list, then take another pass to resolve
the plugin dependencies using the mixture of these two lists. That's
gone now (I'm not entirely sure where it went, or when), and in any
case it wouldn't have produced results that were easy to debug, I'm
guessing. Aligning all artifact resolution to a consistent set of
repositories seemed a good first step down the path of cleaning all
of this up.
However, I'm now starting to wonder whether we want to completely
segregate the build activities - including the artifact repositories
used to drive these activities - from the project dependencies. To
me, it seems a better practice to take a lesson from plugin-level
dependencies, which are kept separate from regular project
dependencies because they are used in the build process and not at
all in project code, and completely separate the two repository
lists. Plugins and their dependencies would only be resolved from
<pluginRepositories>, and project dependencies would only be resolved
from <repositories>. This will prevent any unintentional injection of
snapshots into the mix when resolving plugin versions (which, again,
is a bad feature to be reliant upon...as evidenced by our repeated
failure to control when plugins are re-resolved...see pluginRegistry
and advice on using -U for plugin resolution for some examples).
So, let's have the discussion now. What does anyone think about
separating the pluginRepositories list completely from the
repositories list, and using them in ways that will not ever
intersect within the maven core? I'm definitely -1 for leaving the
current mixture in the 2.0.x line in place, as I believe this causes
a lot of confusion. IMO, the above separation would be the most
intuitive configuration for a new user, where pluginRepositories
clearly implies its use, and is only confused when it's (a) not used
at all, or (b) mixed with the regular repositories list.
Comments?
Thanks,
-john
On Jan 8, 2008, at 12:07 AM, Brett Porter wrote:
John,
Won't that break for 2.0.x when running the ITs against them? I
think 110 totally would irrelevant for 2.1, in which case the
version could just be (,2.1-SNAPSHOT) for the test.
But aside from that - why were plugin repositories deprecated? I
don't recall any discussion, proposal or reasoning for it on the
list. I actually use that separation, because of the auto-
resolution of versions for plugins (which was not disabled in 2.1
after much discussion), and the need to add snapshot repositories
for non-plugins only.
Thanks,
Brett
On 08/01/2008, at 4:20 AM, [EMAIL PROTECTED] wrote:
Author: jdcasey
Date: Mon Jan 7 12:20:33 2008
New Revision: 609772
URL: http://svn.apache.org/viewvc?rev=609772&view=rev
Log:
changing it0043 to use the released version of the help plugin
(2.0.2), and changing it0110 to use regular repositories, now that
pluginRepositories are turned off in 2.1-SNAPSHOT (trunk).
Modified:
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0043/child1/pom.xml
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0043/child2/pom.xml
maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/it0110-pluginDependenciesComeFromPluginRepos/pom.xml
Modified: maven/core-integration-testing/trunk/core-integration-
tests/src/test/resources/it0043/child1/pom.xml
URL: http://svn.apache.org/viewvc/maven/core-integration-testing/
trunk/core-integration-tests/src/test/resources/it0043/child1/
pom.xml?rev=609772&r1=609771&r2=609772&view=diff
=====================================================================
=========
--- maven/core-integration-testing/trunk/core-integration-tests/
src/test/resources/it0043/child1/pom.xml (original)
+++ maven/core-integration-testing/trunk/core-integration-tests/
src/test/resources/it0043/child1/pom.xml Mon Jan 7 12:20:33 2008
@@ -25,7 +25,7 @@
<plugin>
<artifactId>maven-help-plugin</artifactId>
<!-- use 2.0.2-snap until it's released, due to bug described
above -->
- <version>2.0.2-SNAPSHOT</version>
+ <version>2.0.2</version>
<executions>
<execution>
<phase>generate-resources</phase>
Modified: maven/core-integration-testing/trunk/core-integration-
tests/src/test/resources/it0043/child2/pom.xml
URL: http://svn.apache.org/viewvc/maven/core-integration-testing/
trunk/core-integration-tests/src/test/resources/it0043/child2/
pom.xml?rev=609772&r1=609771&r2=609772&view=diff
=====================================================================
=========
--- maven/core-integration-testing/trunk/core-integration-tests/
src/test/resources/it0043/child2/pom.xml (original)
+++ maven/core-integration-testing/trunk/core-integration-tests/
src/test/resources/it0043/child2/pom.xml Mon Jan 7 12:20:33 2008
@@ -42,7 +42,7 @@
<plugins>
<plugin>
<artifactId>maven-help-plugin</artifactId>
- <version>2.0.2-SNAPSHOT</version> <!-- Removing this will
cause MNG-900 -->
+ <version>2.0.2</version> <!-- Removing this will cause
MNG-900 -->
<executions>
<execution>
<phase>generate-test-resources</phase>
Modified: maven/core-integration-testing/trunk/core-integration-
tests/src/test/resources/it0110-
pluginDependenciesComeFromPluginRepos/pom.xml
URL: http://svn.apache.org/viewvc/maven/core-integration-testing/
trunk/core-integration-tests/src/test/resources/it0110-
pluginDependenciesComeFromPluginRepos/pom.xml?
rev=609772&r1=609771&r2=609772&view=diff
=====================================================================
=========
--- maven/core-integration-testing/trunk/core-integration-tests/
src/test/resources/it0110-pluginDependenciesComeFromPluginRepos/
pom.xml (original)
+++ maven/core-integration-testing/trunk/core-integration-tests/
src/test/resources/it0110-pluginDependenciesComeFromPluginRepos/
pom.xml Mon Jan 7 12:20:33 2008
@@ -12,21 +12,22 @@
<issue>MNG-2539</issue>
</properties>
- <!--
<repositories>
<repository>
<id>javamail-local</id>
<url>file://${basedir}/repository</url>
</repository>
</repositories>
- -->
+ <!-- pluginRepositories are deprecated in 2.1-SNAPSHOT (trunk),
use repositories instead. -->
+ <!--
<pluginRepositories>
<pluginRepository>
<id>javamail-local</id>
<url>file://${basedir}/repository</url>
</pluginRepository>
</pluginRepositories>
+ -->
<build>
<plugins>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john
