After talking this over some more with Brian Fox, I'm convinced that
this approach of segregating plugin and project repositories will
result in a large amount of duplication of effort for ~90% of
projects, since so many project-dependency repositories also host
plugins. This is especially true as the community migrates to a more
general use of proxies. So, this would tend to support my original
changes, where all artifacts are drawn from the <repositories> list,
even for plugin resolution. To keep Maven from resolving snapshot
versions of plugins in this new setup, it would be great if we could
add two new flags to the repository syntax:
- dependencies (true|false)
- plugins (true|false)
These flags would combine with the existing settings for releases and
snapshots, and allow fine-grained control over what a specific
repository is used for. They also line up very nicely with the types
of information typically stored in real repositories, where for
instance you'd probably never see snapshots of project dependencies
living alongside releases of plugins in the same repository...which
would be one case where the new flags would require two separate
repository entries pointing at the same URL.
Again, we can't really put these new flags in place until we have a
means of accommodating new modelVersion numbers in the POM...which
requires a refactoring of the DefaultMavenProjectBuilder at a
minimum. Brett, what do you think about this approach to flagging
repositories instead of putting them in two lists?
-john
On Jan 8, 2008, at 10:21 AM, John Casey wrote:
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
---
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
