You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Nikunj Mehta <ni...@oracle.com> on 2006/12/13 01:28:26 UTC
Patched artifacts resolved incorrectly from internal repository
Hi,
I am new to Maven and I need to patch Surefire to support JUnit4.
Therefore, I applied patches as mentioned at
http://jira.codehaus.org/browse/SUREFIRE-31#action_76833. After applying
the patches, I am able to build maven-surefire-plugin as well as
surefire-junit. However, I need to share the patch with others in my
company as well as make the patched artifacts available for use on other
machines.
Therefore, I decided to create an internal repository to host these
patched artifacts (call it internal.plugins). I chased down the
"dragon's tail" and deployed the maven-surefire-plugin as well as
surefire (and its child) projects on this internal repository. I named
this version as 2.1-INTERNAL-r486153-pSUREFIRE-31 for surefire, and
2.3-INTERNAL-r486153-pSUREFIRE-31 for maven-surefire-plugin. All went
fine up until this point.
The trouble starts, however, when I try to use with these new artifacts
by adding internal.plugins to the pluginRepositories of my project.
Maven resolves maven-surefire-plugin as shown in the following debug
output to central:
[INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking
for updates from internal.plugins
[INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking
for updates from apache.snapshots
[INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking
for updates from central
[DEBUG] maven-surefire-plugin: resolved to version
2.3-INTERNAL-r486153-pSUREFIRE-31 from repository central
[DEBUG] Trying repository central
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.3-INTERNAL-r486153-pSUREFIRE-31/maven-surefire-plugin-2.3-INTERNAL-r486153-pSUREFIRE-31.pom
[DEBUG] Artifact not found - using stub model: Unable to locate resource
in repository
org.apache.maven.plugins:maven-surefire-plugin:pom:2.3-INTERNAL-r486153-pSUREFIRE-31
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
internal.plugins (.....maven/internal-plugins),
apache.snapshots (http://cvs.apache.org/maven-snapshot-repository/)
This appears to be erroneous because the version in question is only in
internal.plugins. Can someone explain why this might be happening? What
can I do to get the expected behavior: maven-surefire-plugin is resolved
to internal.plugins and the surefire project artifacts are also resolved
to internal.plugins?
Thanks for helping.
Nikunj Mehta
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Patched artifacts resolved incorrectly from internal repository
Posted by Barrie Treloar <ba...@gmail.com>.
> So are there workarounds?
>
> Yes. Change the artifactId, which makes it unique to your internal
> patch repository and the problem goes away. I would be suggestions
> maven-<original name>-internal-plugin.
>
> Problems with this approach. As long as the bindings are within
> pom.xml there aren't too many hassles. If the user is going to run
> the plugin on the command line then they will need to be educated on
> the new plugin name to use and when an official fully patched version
> arrives then they need to start using the official name again.
>
> Feedback on the workaround?
Bugger.
This workaround also fails.
Why? Transitive dependencies.
I am trying to internally release maven-assembly-plugin.
This is the extract of the dependencies graph from "mvn site"
Note the two instances of org.codehaus.plexus:plexus-archiver, one an
internal "-i" release.
org.apache.maven.plugins:maven-assembly-i-plugin:maven-plugin
* org.apache.maven:maven-archiver:jar
o org.codehaus.plexus:plexus-archiver:jar
* org.apache.maven.shared:maven-plugin-testing-tools-i:jar
o org.apache.maven.shared:maven-invoker-i:jar
* org.codehaus.plexus:plexus-archiver-i:jar
The problem is that there are now two duplicate class jars in the
graph because, obviously, plexus-archiver and plexus-archiver-i are
different artifactIds.
So this brings us down to one workaround, install and configure
mvnproxy for aggregate repositories.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Patched artifacts resolved incorrectly from internal repository
Posted by Barrie Treloar <ba...@gmail.com>.
On 12/16/06, Nikunj Mehta <nr...@gmail.com> wrote:
> > But if you are not already using mvnproxy I wouldn't recommend starting to use
> > it. It's not difficult but the repo aggregation can bring with it
> > other problems, e.g. dont include snapshot repos in mvproxy or else
> > they will also get aggregated.
>
>
> Could you elaborate on the kinds of problems?
I was going to write it up here, when I realized I already had on the wiki:
http://docs.codehaus.org/display/MAVENUSER/Creating+a+Maven+proxy
See the section "Aggregation of proxies may not be your friend"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Patched artifacts resolved incorrectly from internal repository
Posted by Nikunj Mehta <nr...@gmail.com>.
>
> So you could also use mvnproxy to workaround this problem.
Now that might be interesting...
But if you are not already using mvnproxy I wouldn't recommend starting to
> use
> it. It's not difficult but the repo aggregation can bring with it
> other problems, e.g. dont include snapshot repos in mvproxy or else
> they will also get aggregated.
Could you elaborate on the kinds of problems?
Re: Patched artifacts resolved incorrectly from internal repository
Posted by Barrie Treloar <ba...@gmail.com>.
> baerrach wrote:
> >
> >> So are there workarounds?
> >
>
> Sorry if I'm coming late into this and missed some of the finer points but
> we are currently using maven proxy (with an eye to Archiva or Proximity when
> they are finally manage a production quality release) to provide us with
> some control over the repo access order and to prevent our maven projects
> from having to be littered with lots of differing pom.xml defined repo
> declarations. Using the proxy as intermediary has the added benefit of
> allowing us to obscure artifacts present in one repository with those in
> others. Maven itself is only every talking to 2 repos, our RELEASE proxy and
> our SNAPSHOT proxy. the RELEASE proxy repo order looks something like this:
>
> inhouse.corporate.release
> inhouse.central-ovveride.release
> external.central.release
> external.codehaus.release
> ...
>
> Where inhouse.central-override.release does what it says on the tin, namely
> verrides artifacts defined in central with our own custom built versions.
>
> Would this not work for most corporate instances?
When Nikunj posted their problem, I was unable to reproduce it because
like you we are using mvnproxy.
If you turn mvnproxy off then there is no way besides the workarounds
I have listed to resolve the problem.
If you are using mvnproxy, the problem is hidden because mvnproxy
aggregates all the defined repositories. So even though maven is
overriding the artifact's repository to central mvnproxy will return
the artifact from your company's repo.
So you could also use mvnproxy to workaround this problem. But if you
are not already using mvnproxy I wouldn't recommend starting to use
it. It's not difficult but the repo aggregation can bring with it
other problems, e.g. dont include snapshot repos in mvproxy or else
they will also get aggregated.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Patched artifacts resolved incorrectly from internal repository
Posted by jallen <jo...@hotmail.com>.
baerrach wrote:
>
>> So are there workarounds?
>
Sorry if I'm coming late into this and missed some of the finer points but
we are currently using maven proxy (with an eye to Archiva or Proximity when
they are finally manage a production quality release) to provide us with
some control over the repo access order and to prevent our maven projects
from having to be littered with lots of differing pom.xml defined repo
declarations. Using the proxy as intermediary has the added benefit of
allowing us to obscure artifacts present in one repository with those in
others. Maven itself is only every talking to 2 repos, our RELEASE proxy and
our SNAPSHOT proxy. the RELEASE proxy repo order looks something like this:
inhouse.corporate.release
inhouse.central-ovveride.release
external.central.release
external.codehaus.release
...
Where inhouse.central-override.release does what it says on the tin, namely
verrides artifacts defined in central with our own custom built versions.
Would this not work for most corporate instances?
--
View this message in context: http://www.nabble.com/Patched-artifacts-resolved-incorrectly-from-internal-repository-tf2811385s177.html#a7889657
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Patched artifacts resolved incorrectly from internal repository
Posted by Barrie Treloar <ba...@gmail.com>.
> I don't see how the renaming solution would work for a temporary scenario such as
> the one found when patching artifacts. This is because chasing down
> references and changing them could be very difficult and unnecessarily
> burdensome.
[del]
> So are there workarounds?
> >
> > Yes. Change the artifactId, which makes it unique to your internal
> > patch repository and the problem goes away. I would be suggestions
> > maven-<original name>-internal-plugin.
>
>
> This is a no go based on my previous comment
I'm not sure I follow your objections here.
When patching we need to deploy any snapshot dependencies, which
requires checking them out of svn and then updating the pom. With the
workaround there is just two extra steps, change the artifactId name
to include -internal, update the referencing pom to use the new
artifactId.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Patched artifacts resolved incorrectly from internal repository
Posted by Nikunj Mehta <nr...@gmail.com>.
>
> Having multiple repositories for an artifact is a big thing to assume.
> There are two reasons why this might occur;
>
> 1) an artifact moves to another repository, e.g. codehaus to maven.
> In this case the artifiact id usuallu changes too from a form of
> <name>-maven-plugin to maven-<name>-plugin. So this problem would
> never have been noticed before.
IMHO, not knowing much about Maven, there's hardly a way we can enforce that
any artifact anywhere in the world occurs in only one repository. Therefore,
Maven needs to be robust about dealing with situations in which different
versions or a single artifact are found in different repositories. I don't
see how the renaming solution would work for a temporary scenario such as
the one found when patching artifacts. This is because chasing down
references and changing them could be very difficult and unnecessarily
burdensome.
2) you are creating an internal patch repository. Which is our
> current problem.
>
> The reason for the original wiki document was because there was no
> documentation that I could find that gave guidance on this and
> obviously few people are attempting it or there would be more
> complaints. Internal patched plugins are a necessity because the
> release process must not rely on snapshot versions.
Absolutely my point. With OSS, there is bound to be a need to patch an
artifact for internal use before the patch becomes widely available. Just
take the metacase of patching maven itself to correctly resolve patched
artifacts. I would not want to wait until 2.0.6 for this to become
available. Therefore, INTERNAL patched projects are unavoidable at best.
So are there workarounds?
>
> Yes. Change the artifactId, which makes it unique to your internal
> patch repository and the problem goes away. I would be suggestions
> maven-<original name>-internal-plugin.
This is a no go based on my previous comment
Problems with this approach. As long as the bindings are within
> pom.xml there aren't too many hassles. If the user is going to run
> the plugin on the command line then they will need to be educated on
> the new plugin name to use and when an official fully patched version
> arrives then they need to start using the official name again.
>
> Feedback on the workaround?
How about creating a patch for the maven-artifact-manager itself? That would
be a fix not a workaround.
Anyway, a workaround for a workaround sounds doubly bad if you ask me...
Re: Patched artifacts resolved incorrectly from internal repository
Posted by Barrie Treloar <ba...@gmail.com>.
Found the problem.
DefaultRepositoryMetadataManager.loadMetadata
returns a boolean which indicates whether to set the repository (there
are no javadocs for this class)
the setRepository flag is set based on the results of
repoMetadata.getMetadata().merge( metadata ) and Metadata.merge()
returns true if the metadata changed.
Therefore since both internal_plugins and central have metadata
available for the plugins both repositories cause the metadata to
change and hence update the repository for the artifact. The ordering
of repositories is unspecified so the order of which repository gets
used for the artifact is also unspecified. In practice central is
last so it always wins.
This is something I will need to take onto the dev list to work out a
way forward.
I doubt anything will get fixed until 2.0.6 (since 2.0.5 is meant to be soon)
Assuming that it is ok for multiple repositories to provide an
artifact then the versioning information needs to include the
repository that the version came from. Then instead of updating the
repository based upon whether the metadata changed, the repository to
be used should be based on version resolution and obtained from the
versioning information.
Having multiple repositories for an artifact is a big thing to assume.
There are two reasons why this might occur;
1) an artifact moves to another repository, e.g. codehaus to maven.
In this case the artifiact id usuallu changes too from a form of
<name>-maven-plugin to maven-<name>-plugin. So this problem would
never have been noticed before.
2) you are creating an internal patch repository. Which is our
current problem.
The reason for the original wiki document was because there was no
documentation that I could find that gave guidance on this and
obviously few people are attempting it or there would be more
complaints. Internal patched plugins are a necessity because the
release process must not rely on snapshot versions.
So are there workarounds?
Yes. Change the artifactId, which makes it unique to your internal
patch repository and the problem goes away. I would be suggestions
maven-<original name>-internal-plugin.
Problems with this approach. As long as the bindings are within
pom.xml there aren't too many hassles. If the user is going to run
the plugin on the command line then they will need to be educated on
the new plugin name to use and when an official fully patched version
arrives then they need to start using the official name again.
Feedback on the workaround?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Patched artifacts resolved incorrectly from internal repository
Posted by Barrie Treloar <ba...@gmail.com>.
> In the effective POM for my project, I have the following repositories
>
> - apache.snapshots
> - project.snapshots
> - central
>
> And I have the following plugin repositories
>
> - internal.plugins
> - apache.snapshots
> - central
>
> So, this does not have internal.plugins as a repository, only has it as a
> plugin repository.
I think this should be ok.
I vaguely remember needing a normally repository for something in
addition to the plugin repo but I can't recall why that was. It
should be ok for internal_plugins to only be a plugin repo.
>
> verify that the pom has the correct version details for the plugin
> > e.g.
> > <plugin>
> > <artifactId>maven-surefire-report-plugin</artifactId>
> > <version>2.1-INTERNAL-r485987-pMSUREFIREREP-6</version>
> > </plugin>
>
>
> The effective POM of my root project does not show any plugins or their
> versions
If you have been tinkering with snapshots I find that they are used
before released versions so I lock down the version in the pom. YMMV.
>
> delete the maven-surefire-report-plugin from your m2 local repo
> > run mvn -X surefire-report:report > surefire-report-report.txt
> >
> > again delete the maven-surefire-report-plugin from your m2 local repo
> > run mvn -X site > site.txt
> >
> > Now look at the surefire-report-report.txt, I am hoping that you will
> > find that it resolves and downloads the plugin correctly from your
> > internal_plugins.
>
>
> Not sure if you mean surefire-report symbolically or literally. My patch has
> nothing to do with maven-surefire-report-plugin. I have patched
> maven-surefire-plugin and surefire-junit projects.
Ahh, I thought you were patching surefire-report, so you can run that
on the command line.
Are you running mvn site or mvn surefire? Try them both, I think
running surefire directly should work, at least it does for
surefire-report.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Patched artifacts resolved incorrectly from internal repository
Posted by Nikunj Mehta <nr...@gmail.com>.
>
>
> run mvn help:effective-pom > effective-pom.txt
>
verify that internal_plugins is defined in both repositories and
>
pluginRepositories
>
In the effective POM for my project, I have the following repositories
- apache.snapshots
- project.snapshots
- central
And I have the following plugin repositories
- internal.plugins
- apache.snapshots
- central
So, this does not have internal.plugins as a repository, only has it as a
plugin repository.
verify that the pom has the correct version details for the plugin
> e.g.
> <plugin>
> <artifactId>maven-surefire-report-plugin</artifactId>
> <version>2.1-INTERNAL-r485987-pMSUREFIREREP-6</version>
> </plugin>
The effective POM of my root project does not show any plugins or their
versions
delete the maven-surefire-report-plugin from your m2 local repo
> run mvn -X surefire-report:report > surefire-report-report.txt
>
> again delete the maven-surefire-report-plugin from your m2 local repo
> run mvn -X site > site.txt
>
> Now look at the surefire-report-report.txt, I am hoping that you will
> find that it resolves and downloads the plugin correctly from your
> internal_plugins.
Not sure if you mean surefire-report symbolically or literally. My patch has
nothing to do with maven-surefire-report-plugin. I have patched
maven-surefire-plugin and surefire-junit projects.
Re: Patched artifacts resolved incorrectly from internal repository
Posted by Barrie Treloar <ba...@gmail.com>.
On 12/14/06, Nikunj Mehta <nr...@gmail.com> wrote:
> Now I am a little confused
Try the following:
run mvn help:effective-pom > effective-pom.txt
verify that the pom has the correct version details for the plugin
e.g.
<plugin>
<artifactId>maven-surefire-report-plugin</artifactId>
<version>2.1-INTERNAL-r485987-pMSUREFIREREP-6</version>
</plugin>
verify that internal_plugins is defined in both repositories and
pluginRepositories
delete the maven-surefire-report-plugin from your m2 local repo
run mvn -X surefire-report:report > surefire-report-report.txt
again delete the maven-surefire-report-plugin from your m2 local repo
run mvn -X site > site.txt
Now look at the surefire-report-report.txt, I am hoping that you will
find that it resolves and downloads the plugin correctly from your
internal_plugins.
So while surefire-report works correcly there is something wrong with site.
Still investigating.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Patched artifacts resolved incorrectly from internal repository
Posted by Nikunj Mehta <nr...@gmail.com>.
Now I am a little confused
On 12/13/06, Barrie Treloar <ba...@gmail.com> wrote:
>
> Just to re-iterate, since my env has changed a bit in debugging.
>
> I have re-run surefire-report:report with no plugin installed and it
> correctly resolves to internal_plugins, so it looks like mvn site is
> resolving incorrectly.
>
> [DEBUG] Trying repository internal_plugins
> Downloading:
> http://PROXY/maven2_repositories/internal_plugins/org/apache/maven/plugins/maven-surefire-report-plugin/2.1-INTERNAL-r485987-pMSUREFIREREP-6/maven-surefire-report-plugin-2.1-INTERNAL-r485987-pMSUREFIREREP-6.pom
> 1/1K
> 1K downloaded
> [DEBUG] Artifact resolved
> [DEBUG] Retrieving parent-POM:
> org.apache.maven.plugins:maven-plugins::4 for project:
> null:maven-surefire-report-plugin:maven-plugin:
> 2.1-INTERNAL-r485987-pMSUREFIREREP-6
> from the repository.
> ...
>
This means the POM is correctly resolved, which seems to be a problem in my
case. In an earlier email, you said
> From the logs you can see that the version number is being correctly
> identified as the internal version, but then central is incorrectly
> being contacted.
>
Are these two things consistent? Appreciate your looking in to this!
Re: Patched artifacts resolved incorrectly from internal repository
Posted by Barrie Treloar <ba...@gmail.com>.
Just to re-iterate, since my env has changed a bit in debugging.
I have re-run surefire-report:report with no plugin installed and it
correctly resolves to internal_plugins, so it looks like mvn site is
resolving incorrectly.
[DEBUG] Trying repository internal_plugins
Downloading: http://PROXY/maven2_repositories/internal_plugins/org/apache/maven/plugins/maven-surefire-report-plugin/2.1-INTERNAL-r485987-pMSUREFIREREP-6/maven-surefire-report-plugin-2.1-INTERNAL-r485987-pMSUREFIREREP-6.pom
1/1K
1K downloaded
[DEBUG] Artifact resolved
[DEBUG] Retrieving parent-POM:
org.apache.maven.plugins:maven-plugins::4 for project:
null:maven-surefire-report-plugin:maven-plugin:2.1-INTERNAL-r485987-pMSUREFIREREP-6
from the repository.
...
[DEBUG] Trying repository internal_plugins
Downloading: http://PROXY/maven2_repositories/internal_plugins/org/apache/maven/plugins/maven-surefire-report-plugin/2.1-INTERNAL-r485987-pMSUREFIREREP-6/maven-surefire-report-plugin-2.1-INTERNAL-r485987-pMSUREFIREREP-6.jar
2/21K
6/21K
10/21K
14/21K
18/21K
21/21K
21K downloaded
[DEBUG] Artifact resolved
...
[DEBUG] org.apache.maven.plugins:maven-surefire-report-plugin:maven-plugin:2.1-INTERNAL-r485987-pMSUREFIREREP-6:runtime
(selected for runtime)
...
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-surefire-report-plugin:2.1-INTERNAL-r485987-pMSUREFIREREP-6:report'
-->
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Patched artifacts resolved incorrectly from internal repository
Posted by Barrie Treloar <ba...@gmail.com>.
Neither the profile or adding the correct repository definitions to my
pom are working.
(I had missed out the pluginRepo definition which is now as below)
</repositories>
....
<repository>
<id>internal_plugins</id>
<name>Internal Plugin Repository</name>
<url>
http://PROXY/maven2_repositories/internal_plugins
</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>internal_plugins</id>
<name>Internal Plugin Repository</name>
<url>
http://PROXY/maven2_repositories/internal_plugins
</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
>From the logs you can see that the version number is being correctly
identified as the internal version, but then central is incorrectly
being contacted.
[INFO] artifact org.apache.maven.plugins:maven-surefire-report-plugin:
checking for updates from internal_plugins
[INFO] artifact org.apache.maven.plugins:maven-surefire-report-plugin:
checking for updates from central
[DEBUG] maven-surefire-report-plugin: resolved to version
2.1-INTERNAL-r485987-pMSUREFIREREP-6 from repository central
[DEBUG] Trying repository central
I have checked my mvnproxy and the central cache does not have the
internal versions defined.
I am no longer using mvnproxy for internal_plugins so I am not sure
how these are getting confused.
I'll attach the debugger and see if I can work it out.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Patched artifacts resolved incorrectly from internal repository
Posted by Barrie Treloar <ba...@gmail.com>.
> Just to ensure that the repository is available I added a profile:
> <profile>
> <id>internal</id>
> <repositories>
> <repository>
> <id>internal.plugins</id>
> <name>Maven-Proxy Repository</name>
> <url>http://PROXY/maven2_repositories/internal_plugins</url>
> <releases>
> <enabled>true</enabled>
> </releases>
> <snapshots>
> <enabled>false</enabled>
> </snapshots>
> </repository>
> </repositories>
> </profile>
On the way home I realised that this profile does not define a pluginRepository.
Can someone try including that in their profile definition, I will try
tomorrow, but that will be at least 12 hours away. I'm fairly hopeful
that will solve the problem.
<pluginRepositories>
<pluginRepository>
<id>internal.plugins</id>
<name>Maven-Proxy Repository</name>
<url>http://PROXY/maven2_repositories/internal_plugins</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
</pluginRepositories>
If it does, then it will also mean you need to include this in your
parent pom definitions.
I will update the wiki if this works tomorrow with details.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Patched artifacts resolved incorrectly from internal repository
Posted by Barrie Treloar <ba...@gmail.com>.
> Next steps...
> Turning off internal.plugin proxying for mvn-proxy and trying again.
> That will have to wait for tomorrow.
Bingo, I can reproduce the problem that you are seeing:
[INFO] artifact org.apache.maven.plugins:maven-surefire-report-plugin:
checking for updates from internal.plugins
[INFO] artifact org.apache.maven.plugins:maven-surefire-report-plugin:
checking for updates from central
[DEBUG] maven-surefire-report-plugin: resolved to version
2.1-INTERNAL-r485987-pMSUREFIREREP-6 from repository central
[DEBUG] Trying repository central
Downloading: http://PROXY:9999/repository/org/apache/maven/plugins/maven-surefire-report-plugin/2.1-INTERNAL-r485987-pMSUREFIREREP-6/maven-surefire-report-plugin-2.1-INTERNAL-r485987-pMSUREFIREREP-6.pom
[DEBUG] Artifact not found - using stub model: Unable to locate
resource in repository
org.apache.maven.plugins:maven-surefire-report-plugin:pom:2.1-INTERNAL-r485987-pMSUREFIREREP-6
Just to ensure that the repository is available I added a profile:
<profile>
<id>internal</id>
<repositories>
<repository>
<id>internal.plugins</id>
<name>Maven-Proxy Repository</name>
<url>http://sapolnpeapp/maven2_repositories/internal_plugins</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>
</profile>
And ran
mvn -Pinternal -X site > site-noplugin.txt
But I get the same error.
I can see from the debug the repository is available:
[DEBUG] (f) remoteRepositories = [[internal.plugins] ->
http://PROXY/maven2_repositories/internal_plugins, [apache.snapshots]
-> http://people.apache.org/maven-snapshot-repository, [inhouse] ->
http://PROXY/maven2_repositories/inhouse, [external_free] ->
http://PROXY/maven2_repositories/external_free, [external_nonfree] ->
http://PROXY/maven2_repositories/external_non_free, [inhouse_snapshot]
-> http://PROXY/maven2_repositories/inhouse_snapshot, [central] ->
http://repo1.maven.org/maven2]
And I double checked I could browse to the location (I had a typo before)
This may be a maven resolution defect, in that you can not shadow an
existing plugin on a different repository. But that doesn't make
sense since plugins have moved from codehaus to central before.
Not sure what to do next.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Patched artifacts resolved incorrectly from internal repository
Posted by Barrie Treloar <ba...@gmail.com>.
On 12/13/06, Barrie Treloar <ba...@gmail.com> wrote:
> On 12/13/06, Nikunj Mehta <ni...@oracle.com> wrote:
> > surefire-junit. However, I need to share the patch with others in my
> > company as well as make the patched artifacts available for use on other
> > machines.
> >
> > Therefore, I decided to create an internal repository to host these
> > patched artifacts (call it internal.plugins). I chased down the
> > "dragon's tail" and deployed the maven-surefire-plugin as well as
> > surefire (and its child) projects on this internal repository. I named
> > this version as 2.1-INTERNAL-r486153-pSUREFIRE-31 for surefire, and
> > 2.3-INTERNAL-r486153-pSUREFIRE-31 for maven-surefire-plugin. All went
> > fine up until this point.
> >
> > The trouble starts, however, when I try to use with these new artifacts
> > by adding internal.plugins to the pluginRepositories of my project.
> > Maven resolves maven-surefire-plugin as shown in the following debug
> > output to central:
> >
> > [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking
> > for updates from internal.plugins
> > [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking
> > for updates from apache.snapshots
> > [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking
> > for updates from central
> > [DEBUG] maven-surefire-plugin: resolved to version
> > 2.3-INTERNAL-r486153-pSUREFIRE-31 from repository central
> > [DEBUG] Trying repository central
> > Downloading:
> > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.3-INTERNAL-r486153-pSUREFIRE-31/maven-surefire-plugin-2.3-INTERNAL-r486153-pSUREFIRE-31.pom
> > [DEBUG] Artifact not found - using stub model: Unable to locate resource
> > in repository
>
> I wrote that document, but I have never seen your error before.
> It is odd that the deployed version is resolving the version correctly
> but incorrectly identifying the repository as central.
>
> I have a mvn-proxy in the way (since we don't have direct internet
> access) and so it could be that mvn-proxy is finding the plugin for me
> even though it is attempting to access centrl.
>
> It is interesting the mvn surefire-report:report resolves to version
> 2.2 and not the newer version.
>
> I'm running mvn site now to see what is resolved, it should be the new
> version since this is defined in the pom hierarchy.
>
> I've got other things on for the next hour or so, so it will be a
> little while before I have my investigation done and an answer.
>
Ok.
The 2.2 is incorrect as this is surefire-plugin not the
surefire-report-plugin, gotta be careful with that.
Just as a caveat, I'm a maven user not a developer. I wrote those
wiki documents because I found nothing that would allow me to
"release" an internal snapshot version of a plugin while I am waiting
for an official release to arrive. So they are more than likely not
complete. I also have not got to the stage of trying the command outs
on another developer's machine to be sure that the instructions are
correct. That's likely another day or so before I get that far. So
bear all that in mind when you follow the docs.
So to investigate this problem ...
I've run
* mvn help:effective-pom
* mvn -X surefire-report:report
* mvn -X surefire-report:report-only (my local patched version as per
http://jira.codehaus.org/browse/MSUREFIREREP-6)
* mvn -X site
and compared the output. All of these correctly resolve to my version
of 2.1-INTERNAL-r485987-pMSUREFIREREP-6.
Now I deployed the artifact from this computer so the one on
internal.plugins is the one already in my local m2 repo.
When I do -cpu -U this is the log output
[INFO] artifact org.apache.maven.plugins:maven-surefire-report-plugin:
checking for updates from internal.plugins
[INFO] artifact org.apache.maven.plugins:maven-surefire-report-plugin:
checking for updates from central
[DEBUG] maven-surefire-report-plugin: resolved to version
2.1-INTERNAL-r485987-pMSUREFIREREP-6 from local repository
Now I deleted the plugins from my local m2 repository and the log output is:
[INFO] artifact org.apache.maven.plugins:maven-surefire-report-plugin:
checking for updates from internal.plugins
[INFO] artifact org.apache.maven.plugins:maven-surefire-report-plugin:
checking for updates from central
[DEBUG] maven-surefire-report-plugin: resolved to version
2.1-INTERNAL-r485987-pMSUREFIREREP-6 from repository central
[DEBUG] Trying repository central
Downloading: http://PROXY:9999/repository/org/apache/maven/plugins/maven-surefire-report-plugin/2.1-INTERNAL-r485987-pMSUREFIREREP-6/maven-surefire-report-plugin-2.1-INTERNAL-r485987-pMSUREFIREREP-6.pom
1/1K
1K downloaded
[DEBUG] Artifact resolved
So you can see there is some bug somewhere in repository resolution
because the plugin resolved to central.
[DEBUG] maven-surefire-report-plugin: resolved to version
2.1-INTERNAL-r485987-pMSUREFIREREP-6 from repository central
I dont know why this is the case.
Looking at the meta data on the internal.plugin site I notice that the
released version is 2.0 and not 2.1-INTERNAL... like I expected. This
may be because I am using deploy instead of release.
internal_plugins/org/apache/maven/plugins/maven-surefire-report-plugin/maven-metadata.xml
<?xml version="1.0" encoding="UTF-8"?><metadata>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-report-plugin</artifactId>
<version>2.0</version>
<versioning>
<latest>2.1-INTERNAL-r485987-pMSUREFIREREP-6</latest>
<release>2.0</release>
<versions>
<version>2.0</version>
<version>2.1-INTERNAL-r485987-pMSUREFIREREP-6</version>
</versions>
<lastUpdated>20061212031657</lastUpdated>
</versioning>
</metadata>
I will need to post to the dev list and see if someone can point me to
the maven-metadata.xml format as I can't find any information.
Hacking all 2.0's to 2.1s and deleting my local repo plugin again,
re-running mvn -X site gives the following output:
[INFO] artifact org.apache.maven.plugins:maven-surefire-report-plugin:
checking for updates from internal.plugins
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'b0c93eb1aafec9aa8a237e88ce963c15717f9a3f'; remote =
'd03398cbe73cb9dde1a34dd56aff23f0480ee688' - RETRYING
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'b0c93eb1aafec9aa8a237e88ce963c15717f9a3f'; remote =
'd03398cbe73cb9dde1a34dd56aff23f0480ee688' - IGNORING
[INFO] artifact org.apache.maven.plugins:maven-surefire-report-plugin:
checking for updates from central
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'b0c93eb1aafec9aa8a237e88ce963c15717f9a3f'; remote =
'd03398cbe73cb9dde1a34dd56aff23f0480ee688' - RETRYING
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'b0c93eb1aafec9aa8a237e88ce963c15717f9a3f'; remote =
'd03398cbe73cb9dde1a34dd56aff23f0480ee688' - IGNORING
[DEBUG] maven-surefire-report-plugin: resolved to version
2.1-INTERNAL-r485987-pMSUREFIREREP-6 from repository central
[DEBUG] Trying repository central
Downloading: http://PROXY:9999/repository/org/apache/maven/plugins/maven-surefire-report-plugin/2.1-INTERNAL-r485987-pMSUREFIREREP-6/maven-surefire-report-plugin-2.1-INTERNAL-r485987-pMSUREFIREREP-6.pom
1/1K
1K downloaded
I expected checksum to have failed (since I hacked it) but I didnt
expect central to be checked again. This may be working for me and
not you because I am using mvnproxy and it incorrectly aggregates
everything it proxies, hence the contact to central.
So, i've deleted the mirror section from my settings.xml for internal
and lets try another
deleting my local repo plugin again, re-running mvn -X site:
[DEBUG] Skipping disabled repository apache.snapshots
[INFO] artifact org.apache.maven.plugins:maven-surefire-report-plugin:
checking for updates from internal.plugins
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'b0c93eb1aafec9aa8a237e88ce963c15717f9a3f'; remote =
'd03398cbe73cb9dde1a34dd56aff23f0480ee688' - RETRYING
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'b0c93eb1aafec9aa8a237e88ce963c15717f9a3f'; remote =
'd03398cbe73cb9dde1a34dd56aff23f0480ee688' - IGNORING
[INFO] artifact org.apache.maven.plugins:maven-surefire-report-plugin:
checking for updates from central
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'b0c93eb1aafec9aa8a237e88ce963c15717f9a3f'; remote =
'd03398cbe73cb9dde1a34dd56aff23f0480ee688' - RETRYING
[WARNING] *** CHECKSUM FAILED - Checksum failed on download: local =
'b0c93eb1aafec9aa8a237e88ce963c15717f9a3f'; remote =
'd03398cbe73cb9dde1a34dd56aff23f0480ee688' - IGNORING
[DEBUG] maven-surefire-report-plugin: resolved to version
2.1-INTERNAL-r485987-pMSUREFIREREP-6 from repository central
[DEBUG] Trying repository central
Downloading: http://PROXY:9999/repository/org/apache/maven/plugins/maven-surefire-report-plugin/2.1-INTERNAL-r485987-pMSUREFIREREP-6/maven-surefire-report-plugin-2.1-INTERNAL-r485987-pMSUREFIREREP-6.pom
1/1K
So even though I am no longer contacting the mirror for
internal.plugins you can see that mvnproxy provies an aggregation, so
that it looks like it was available from central...
Next steps...
Turning off internal.plugin proxying for mvn-proxy and trying again.
That will have to wait for tomorrow.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Patched artifacts resolved incorrectly from internal repository
Posted by Nikunj Mehta <nr...@gmail.com>.
> > The trouble starts, however, when I try to use these new artifacts
> > by adding internal.plugins to the pluginRepositories of my project.
> > Maven resolves maven-surefire-plugin as shown in the following debug
> > output to central:
> >
> > [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking
> > for updates from internal.plugins
> > [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking
> > for updates from apache.snapshots
> > [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking
> > for updates from central
> > [DEBUG] maven-surefire-plugin: resolved to version
> > 2.3-INTERNAL-r486153-pSUREFIRE-31 from repository central
> > [DEBUG] Trying repository central
> > Downloading:
> >
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.3-INTERNAL-r486153-pSUREFIRE-31/maven-surefire-plugin-2.3-INTERNAL-r486153-pSUREFIRE-31.pom
> > [DEBUG] Artifact not found - using stub model: Unable to locate resource
> > in repository
For those looking for a workaround, physically copying the patch artifact
POM manually to the patch artifact folder of the local repository for the
initially referenced project, in this case
maven-surefire-plugin/2.3-INTERNAL-r486153-pSUREFIRE-31/maven-
surefire-plugin-2.3-INTERNAL-r486153-pSUREFIRE-31.pom
will get the build rolling. And once done, the patch continues to work.
Re: Patched artifacts resolved incorrectly from internal repository
Posted by Barrie Treloar <ba...@gmail.com>.
On 12/13/06, Nikunj Mehta <ni...@oracle.com> wrote:
> surefire-junit. However, I need to share the patch with others in my
> company as well as make the patched artifacts available for use on other
> machines.
>
> Therefore, I decided to create an internal repository to host these
> patched artifacts (call it internal.plugins). I chased down the
> "dragon's tail" and deployed the maven-surefire-plugin as well as
> surefire (and its child) projects on this internal repository. I named
> this version as 2.1-INTERNAL-r486153-pSUREFIRE-31 for surefire, and
> 2.3-INTERNAL-r486153-pSUREFIRE-31 for maven-surefire-plugin. All went
> fine up until this point.
>
> The trouble starts, however, when I try to use with these new artifacts
> by adding internal.plugins to the pluginRepositories of my project.
> Maven resolves maven-surefire-plugin as shown in the following debug
> output to central:
>
> [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking
> for updates from internal.plugins
> [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking
> for updates from apache.snapshots
> [INFO] artifact org.apache.maven.plugins:maven-surefire-plugin: checking
> for updates from central
> [DEBUG] maven-surefire-plugin: resolved to version
> 2.3-INTERNAL-r486153-pSUREFIRE-31 from repository central
> [DEBUG] Trying repository central
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.3-INTERNAL-r486153-pSUREFIRE-31/maven-surefire-plugin-2.3-INTERNAL-r486153-pSUREFIRE-31.pom
> [DEBUG] Artifact not found - using stub model: Unable to locate resource
> in repository
I wrote that document, but I have never seen your error before.
It is odd that the deployed version is resolving the version correctly
but incorrectly identifying the repository as central.
I have a mvn-proxy in the way (since we don't have direct internet
access) and so it could be that mvn-proxy is finding the plugin for me
even though it is attempting to access centrl.
It is interesting the mvn surefire-report:report resolves to version
2.2 and not the newer version.
I'm running mvn site now to see what is resolved, it should be the new
version since this is defined in the pom hierarchy.
I've got other things on for the next hour or so, so it will be a
little while before I have my investigation done and an answer.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org