[jira] [Comment Edited] (MNG-5846) Maven 3.3.3 ignores repository definition for "central"
[
https://issues.apache.org/jira/browse/MNG-5846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14599746#comment-14599746
]
Torsten Liermann edited comment on MNG-5846 at 6/25/15 2:04 PM:
Please, keep peace. I'm not lookig for a workaround. The example demonstrate
the problem, not more. We can discuss the pro & cons of mirror against fine
repository setup but not here.
was (Author: lier99):
Please, keep peace. I'm not lockig for a workaround. The example demonstrate
the problem, not more. We can discuss the pro & cons of mirror against fine
repository setup but not here.
> Maven 3.3.3 ignores repository definition for "central"
> ---
>
> Key: MNG-5846
> URL: https://issues.apache.org/jira/browse/MNG-5846
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.1
> Environment: n/a
>Reporter: Torsten Liermann
>
> Hi,
> The sample pom.xml works fine with maven 3.0.5 but shows a big problem while
> using maven 3.3.3.
> It's starts correctly and downloads a set of dependencies from the specified
> and overriden central repositories. The, suddenly, during a running build it
> starts downloading dependencies from the default "central" repository (which
> is actually overridden). This behaviour is problematic for us.
> In these log-statements you can see that initial downloads are done from the
> overridden definition and that later the default central repository is used.
> {quote}
>
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";
> xmlns="http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> 4.0.0
> xxx
> yyy
> 5.0-SNAPSHOT
>
>
> org.glassfish.main.appclient.client
> gf-client
> 3.1.2.2
>
>
>
>
> central
> http://www.liermann.ws/maven/
>
> true
>
>
> true
> always
>
>
>
>
>
> central
> http://www.liermann.ws/maven/
>
> true
>
>
> true
> always
>
>
>
>
> {quote}
> Log file snippet
> {quote}
> Downloading:
> http://www.liermann.ws/maven/org/glassfish/metro/metro-project/2.2.0-1/metro-project-2.2.0-1.pom
> Downloaded:
> http://www.liermann.ws/maven/org/glassfish/metro/metro-project/2.2.0-1/metro-project-2.2.0-1.pom
> (31 KB at 532.0 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/com/sun/xml/ws/jaxws-ri/2.2.6-2/jaxws-ri-2.2.6-2.pom
> Downloaded:
> http://repo1.maven.org/maven2/com/sun/xml/ws/jaxws-ri/2.2.6-2/jaxws-ri-2.2.6-2.pom
> (6 KB at 101.3 KB/sec)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5846) Maven 3.3.3 ignores repository definition for "central"
[
https://issues.apache.org/jira/browse/MNG-5846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14601114#comment-14601114
]
Torsten Liermann commented on MNG-5846:
---
My example illustrates the problem at the simplest way. In our continuous
integeration builds all repositories are specified in a build own settings.xml.
The problem occurs as well, if the repositories configured in $MAVEN_HOME/conf.
The problem is not new, even Maven 3.2 was already affected.
> Maven 3.3.3 ignores repository definition for "central"
> ---
>
> Key: MNG-5846
> URL: https://issues.apache.org/jira/browse/MNG-5846
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.1
> Environment: n/a
>Reporter: Torsten Liermann
>
> Hi,
> The sample pom.xml works fine with maven 3.0.5 but shows a big problem while
> using maven 3.3.3.
> It's starts correctly and downloads a set of dependencies from the specified
> and overriden central repositories. The, suddenly, during a running build it
> starts downloading dependencies from the default "central" repository (which
> is actually overridden). This behaviour is problematic for us.
> In these log-statements you can see that initial downloads are done from the
> overridden definition and that later the default central repository is used.
> {quote}
>
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";
> xmlns="http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> 4.0.0
> xxx
> yyy
> 5.0-SNAPSHOT
>
>
> org.glassfish.main.appclient.client
> gf-client
> 3.1.2.2
>
>
>
>
> central
> http://www.liermann.ws/maven/
>
> true
>
>
> true
> always
>
>
>
>
>
> central
> http://www.liermann.ws/maven/
>
> true
>
>
> true
> always
>
>
>
>
> {quote}
> Log file snippet
> {quote}
> Downloading:
> http://www.liermann.ws/maven/org/glassfish/metro/metro-project/2.2.0-1/metro-project-2.2.0-1.pom
> Downloaded:
> http://www.liermann.ws/maven/org/glassfish/metro/metro-project/2.2.0-1/metro-project-2.2.0-1.pom
> (31 KB at 532.0 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/com/sun/xml/ws/jaxws-ri/2.2.6-2/jaxws-ri-2.2.6-2.pom
> Downloaded:
> http://repo1.maven.org/maven2/com/sun/xml/ws/jaxws-ri/2.2.6-2/jaxws-ri-2.2.6-2.pom
> (6 KB at 101.3 KB/sec)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5846) Maven 3.3.3 ignores repository definition for "central"
[
https://issues.apache.org/jira/browse/MNG-5846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14599746#comment-14599746
]
Torsten Liermann commented on MNG-5846:
---
Please, keep peace. I'm not lockig for a workaround. The example demonstrate
the problem, not more. We can discuss the pro & cons of mirror against fine
repository setup but not here.
> Maven 3.3.3 ignores repository definition for "central"
> ---
>
> Key: MNG-5846
> URL: https://issues.apache.org/jira/browse/MNG-5846
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.1
> Environment: n/a
>Reporter: Torsten Liermann
>
> Hi,
> The sample pom.xml works fine with maven 3.0.5 but shows a big problem while
> using maven 3.3.3.
> It's starts correctly and downloads a set of dependencies from the specified
> and overriden central repositories. The, suddenly, during a running build it
> starts downloading dependencies from the default "central" repository (which
> is actually overridden). This behaviour is problematic for us.
> In these log-statements you can see that initial downloads are done from the
> overridden definition and that later the default central repository is used.
> {quote}
>
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";
> xmlns="http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> 4.0.0
> xxx
> yyy
> 5.0-SNAPSHOT
>
>
> org.glassfish.main.appclient.client
> gf-client
> 3.1.2.2
>
>
>
>
> central
> http://www.liermann.ws/maven/
>
> true
>
>
> true
> always
>
>
>
>
>
> central
> http://www.liermann.ws/maven/
>
> true
>
>
> true
> always
>
>
>
>
> {quote}
> Log file snippet
> {quote}
> Downloading:
> http://www.liermann.ws/maven/org/glassfish/metro/metro-project/2.2.0-1/metro-project-2.2.0-1.pom
> Downloaded:
> http://www.liermann.ws/maven/org/glassfish/metro/metro-project/2.2.0-1/metro-project-2.2.0-1.pom
> (31 KB at 532.0 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/com/sun/xml/ws/jaxws-ri/2.2.6-2/jaxws-ri-2.2.6-2.pom
> Downloaded:
> http://repo1.maven.org/maven2/com/sun/xml/ws/jaxws-ri/2.2.6-2/jaxws-ri-2.2.6-2.pom
> (6 KB at 101.3 KB/sec)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MNG-5846) Maven 3.3.3 ignores repository definition for "central"
[
https://issues.apache.org/jira/browse/MNG-5846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14599571#comment-14599571
]
Torsten Liermann commented on MNG-5846:
---
The example runs without a settings.xml. The result is the same with any
settings.xml file.
> Maven 3.3.3 ignores repository definition for "central"
> ---
>
> Key: MNG-5846
> URL: https://issues.apache.org/jira/browse/MNG-5846
> Project: Maven
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.3.1
> Environment: n/a
>Reporter: Torsten Liermann
>
> Hi,
> The sample pom.xml works fine with maven 3.0.5 but shows a big problem while
> using maven 3.3.3.
> It's starts correctly and downloads a set of dependencies from the specified
> and overriden central repositories. The, suddenly, during a running build it
> starts downloading dependencies from the default "central" repository (which
> is actually overridden). This behaviour is problematic for us.
> In these log-statements you can see that initial downloads are done from the
> overridden definition and that later the default central repository is used.
> {quote}
>
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";
> xmlns="http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
> 4.0.0
> xxx
> yyy
> 5.0-SNAPSHOT
>
>
> org.glassfish.main.appclient.client
> gf-client
> 3.1.2.2
>
>
>
>
> central
> http://www.liermann.ws/maven/
>
> true
>
>
> true
> always
>
>
>
>
>
> central
> http://www.liermann.ws/maven/
>
> true
>
>
> true
> always
>
>
>
>
> {quote}
> Log file snippet
> {quote}
> Downloading:
> http://www.liermann.ws/maven/org/glassfish/metro/metro-project/2.2.0-1/metro-project-2.2.0-1.pom
> Downloaded:
> http://www.liermann.ws/maven/org/glassfish/metro/metro-project/2.2.0-1/metro-project-2.2.0-1.pom
> (31 KB at 532.0 KB/sec)
> Downloading:
> http://repo1.maven.org/maven2/com/sun/xml/ws/jaxws-ri/2.2.6-2/jaxws-ri-2.2.6-2.pom
> Downloaded:
> http://repo1.maven.org/maven2/com/sun/xml/ws/jaxws-ri/2.2.6-2/jaxws-ri-2.2.6-2.pom
> (6 KB at 101.3 KB/sec)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MNG-5846) Maven 3.3.3 ignores repository definition for "central"
Torsten Liermann created MNG-5846:
-
Summary: Maven 3.3.3 ignores repository definition for "central"
Key: MNG-5846
URL: https://issues.apache.org/jira/browse/MNG-5846
Project: Maven
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.3.1
Environment: n/a
Reporter: Torsten Liermann
Hi,
The sample pom.xml works fine with maven 3.0.5 but shows a big problem while
using maven 3.3.3.
It's starts correctly and downloads a set of dependencies from the specified
and overriden central repositories. The, suddenly, during a running build it
starts downloading dependencies from the default "central" repository (which is
actually overridden). This behaviour is problematic for us.
In these log-statements you can see that initial downloads are done from the
overridden definition and that later the default central repository is used.
{quote}
http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";
xmlns="http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
4.0.0
xxx
yyy
5.0-SNAPSHOT
org.glassfish.main.appclient.client
gf-client
3.1.2.2
central
http://www.liermann.ws/maven/
true
true
always
central
http://www.liermann.ws/maven/
true
true
always
{quote}
Log file snippet
{quote}
Downloading:
http://www.liermann.ws/maven/org/glassfish/metro/metro-project/2.2.0-1/metro-project-2.2.0-1.pom
Downloaded:
http://www.liermann.ws/maven/org/glassfish/metro/metro-project/2.2.0-1/metro-project-2.2.0-1.pom
(31 KB at 532.0 KB/sec)
Downloading:
http://repo1.maven.org/maven2/com/sun/xml/ws/jaxws-ri/2.2.6-2/jaxws-ri-2.2.6-2.pom
Downloaded:
http://repo1.maven.org/maven2/com/sun/xml/ws/jaxws-ri/2.2.6-2/jaxws-ri-2.2.6-2.pom
(6 KB at 101.3 KB/sec)
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] (MNG-5678) second import within dependencyManagement is not taken from the correct repository
[ https://jira.codehaus.org/browse/MNG-5678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Torsten Liermann closed MNG-5678. - Resolution: Duplicate Fix Version/s: 3.2.3 Fixed for MNG-5663 > second import within dependencyManagement is not taken from the correct > repository > -- > > Key: MNG-5678 > URL: https://jira.codehaus.org/browse/MNG-5678 > Project: Maven > Issue Type: Bug > Components: Dependencies >Affects Versions: 3.2.2 > Environment: Windows 7, jdk 7 >Reporter: Torsten Liermann > Fix For: 3.2.3 > > Attachments: pom.xml > > > Resolving of the second import within dependency management goes always on > maven central (http://repo.maven.apache.org/maven2/) although the correct > repository is specified. > This bug is new in maven 3.2.2 The attacht sample works with maven 3.0.5 and > also with maven 3.1.1 > A similar error occurs when an imported dependency management contains an > import. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNG-5678) second import within dependencyManagement is not taken from the correct repository
Torsten Liermann created MNG-5678: - Summary: second import within dependencyManagement is not taken from the correct repository Key: MNG-5678 URL: https://jira.codehaus.org/browse/MNG-5678 Project: Maven Issue Type: Bug Components: Dependencies Affects Versions: 3.2.2 Environment: Windows 7, jdk 7 Reporter: Torsten Liermann Attachments: pom.xml Resolving of the second import within dependency management goes always on maven central (http://repo.maven.apache.org/maven2/) although the correct repository is specified. This bug is new in maven 3.2.2 The attacht sample works with maven 3.0.5 and also with maven 3.1.1 A similar error occurs when an imported dependency management contains an import. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRELEASE-784) SNAPSHOT version in Dependency in DependencyManagement with scope import and type pom is not replaced
[ https://jira.codehaus.org/browse/MRELEASE-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=350373#comment-350373 ] Torsten Liermann commented on MRELEASE-784: --- Please support the "import" feature of maven dependency management. This error also occurs in version 2.5. Thanks! > SNAPSHOT version in Dependency in DependencyManagement with scope import and > type pom is not replaced > - > > Key: MRELEASE-784 > URL: https://jira.codehaus.org/browse/MRELEASE-784 > Project: Maven Release Plugin > Issue Type: Bug >Affects Versions: 2.3.2 > Environment: Maven 3.0.4 >Reporter: Michael Niedermaier > Attachments: console.out, internal-managed-snapshot-dependency.zip, > remote-repository.zip > > > In the test case he asks for the external:artifactId version on console, but > it should only ask and change for the import dependencyManagement dependency > external:parent-artifactid-withimport-dm which's version is not changed by > the release plugin > I attached my sample repository, the project in tryed to release (including > the created pom for tag, which still contains the SNAPSHOT version) and the > console output -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (SUREFIRE-569) There should be a way to run unit tests from a dependency jar.
[ https://jira.codehaus.org/browse/SUREFIRE-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=330515#comment-330515 ] Torsten Liermann commented on SUREFIRE-569: --- The extension "dependenciesToScan" is not enough for jars of type test-jar. Please support classifier "tests". Thanks. > There should be a way to run unit tests from a dependency jar. > -- > > Key: SUREFIRE-569 > URL: https://jira.codehaus.org/browse/SUREFIRE-569 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Reporter: Paul Gier >Assignee: Kristian Rosenvold > Fix For: 2.15 > > Attachments: SUREFIRE-569.patch > > > In some cases it would be useful to have a set of tests that run with various > dependency configurations. One way to accomplish this would be to have a > single project that contains the unit tests and generates a test jar. > Several test configuration projects could then consume the unit tests and run > them with different dependency sets. The problem is that there is no easy > way to run tests in a dependency jar. The surefire plugin should have a > configuration to allow me to run all or a set of unit tests contained in a > dependency jar. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-454) The Release-Plugin does not rewrite dependencies in the DependencyManagement with scope "import"
[ https://jira.codehaus.org/browse/MRELEASE-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=323442#comment-323442 ] Torsten Liermann commented on MRELEASE-454: --- Please reopen the bug for release plugin version 2.4 and maven 3.0.4 Maven-release-plugin:prepare does not update the version of the imported dependency management. Thanks Torsten > The Release-Plugin does not rewrite dependencies in the DependencyManagement > with scope "import" > > > Key: MRELEASE-454 > URL: https://jira.codehaus.org/browse/MRELEASE-454 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: prepare >Affects Versions: 2.0-beta-9 >Reporter: Jens Mühlenhoff >Assignee: Benjamin Bentmann > Fix For: 2.2.2 > > Attachments: MRELEASE-412_and_MRELEASE-454.patch, MRELEASE-454.diff, > MRELEASE-454.patch > > > Add the following node to the pom. Then prepare the release and this section > will not be rewriten, because the "imported" entry will not appear in > project.getDependencyManagement().getDependencies(). This methode returns all > the resolved dependencies. In this situation the transformDocument method > from AbstractRewritePomsPhase could not change the given dependencies, > because it is not visible to the method. > > > > dist > deps > pom > 4.0.4-SNAPSHOT > import > > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-699) release:update-versions should support -DreleaseVersion too (not only -DdevelopmentVersion), so it also supports not suffixing the version with -SNAPSHOT
[
https://jira.codehaus.org/browse/MRELEASE-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=292172#comment-292172
]
Torsten Liermann commented on MRELEASE-699:
---
This is also true for the branch goal. Specifying a -DreleaseVersion=1.0 the
release plugin generate as release version 1.0-SNAPSHOT. But when the plugin
ask for the branch version, the created branch pom will be correct.
> release:update-versions should support -DreleaseVersion too (not only
> -DdevelopmentVersion), so it also supports not suffixing the version with
> -SNAPSHOT
> -
>
> Key: MRELEASE-699
> URL: https://jira.codehaus.org/browse/MRELEASE-699
> Project: Maven 2.x Release Plugin
> Issue Type: Improvement
> Components: update-versions
>Reporter: Geoffrey De Smet
> Attachments:
> 0001-MRELEASE-699-release-update-versions-should-support-.patch
>
>
> The documentation
>
> http://maven.apache.org/plugins/maven-release-plugin/examples/update-versions.html
> states "The update-versions goal can use the same properties used by the
> prepare goal for specifying the versions to be used."
> That's not true, as releaseVersion is not supported:
>
> http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#releaseVersion
> This means, that if you do this:
> {{mvn --batch-mode release:update-versions -DdevelopmentVersion=1.2.0}}
> that the set version is not 1.2.0, but in fact 1.2.0-SNAPSHOT.
--
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] (MEAR-76) This resolution resolves the Clover defect MCLOVER-77
[ https://jira.codehaus.org/browse/MEAR-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=287736#comment-287736 ] Torsten Liermann commented on MEAR-76: -- i have a similar when building with cobertura. "Cobertura" is the classifier. I must play with module excludes and extra step for removing duplicate entries from application.xml. > This resolution resolves the Clover defect MCLOVER-77 > - > > Key: MEAR-76 > URL: https://jira.codehaus.org/browse/MEAR-76 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3.1 > Environment: windows/jdk1.5/cloer plugin 2.3.1 and above >Reporter: Martin Franklin >Assignee: Stephane Nicoll > Attachments: cloverclassifier.diff > > > The clover plugin 'swizzles' the dependencies of an artifact when the > clover:instrument goal is executed. This adds the classifier 'clover' to > those dependencies of the ear which can be resolved as clovered artifacts. > However due to some assumptions made in constructing the ear the problem > detailed in http://jira.codehaus.org/browse/MCLOVER-77 can be created. > The cause turns out to be multiple problems - first after clover 'swizzles' > the dependencies the list gets new versions added during ear processing. I > suspect this is due to the classifier being different so the dependencies of > the dependencies are not found and so they get added again. Thus the same > dependency is listed in the project.getArtifacts() Set. Once with the clover > classifier and once with null. The second problem is the application.xml > generation which adds a second set of dependencies. This can be resolved by > specifying the classifier for the specific module listed in the Modules > section. However this is awkward to use if you wish to use the same pom for > both clovered and unclovered ear generation. This patch supports this. > This patch will always select an artifact with a classifier rather than one > with null set. The matching is only done at the groupid/artifactid level, but > I believe that should be sufficient. > Duplicate EarModules are also removed so that only the most specific > gorupid/artifactid/classifier is used for both inclusion in the ear and > inclusion in the application.xml > One last point about the patch - I could not get test 42 to run before I > started work on the patch, so this test is commented out in the patch. All > the other tests worked fine. > As creating a test would require creating a linkage with the clover plugin, > and the fact that the clover plugin itself needs a patch MCLOVER-82, in order > to fully display these effects easily, I haven't created a test case for it. > I have tested this with my own projects which show that MCLOVER-77 is now > resolved with this patch. -- 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
