[jira] (WAGON-388) remove wagon-http-shared4 dependency on httpclient
[ https://jira.codehaus.org/browse/WAGON-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319017#comment-319017 ] Olivier Lamy commented on WAGON-388: +1 for jsoup impl. > remove wagon-http-shared4 dependency on httpclient > -- > > Key: WAGON-388 > URL: https://jira.codehaus.org/browse/WAGON-388 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-http-lightweight >Affects Versions: 2.0, 2.4 >Reporter: Herve Boutemy > > AbstractHttpClientWagon uses classes from > [HttpClient|http://hc.apache.org/httpcomponents-client-ga/httpclient/index.html] > Lightweight wagon extends AbstractHttpClientWagon but uses JRE java.net > classes > AbstractHttpClientWagon should not depend on httpclient: it can depend on > [HttpCore|http://hc.apache.org/httpcomponents-core-ga/index.html], if useful > to share some utilities between wagon-http and wagon-http-lightweight, but > not HttpClient > Such separation, possible now that HttpComponents has 2 separate layers, will > ease maintenance -- 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] (WAGON-388) remove wagon-http-shared4 dependency on httpclient
[ https://jira.codehaus.org/browse/WAGON-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319016#comment-319016 ] Herve Boutemy commented on WAGON-388: - code removed from wagon-http-shared4 in [34e9c2a0|http://git-wip-us.apache.org/repos/asf/maven-wagon/commit/34e9c2a0] and wagon-http-shared in [24a54ebe|http://git-wip-us.apache.org/repos/asf/maven-wagon/commit/24a54ebe] now we need to choose one HtmlFileListParser implementation and drop one of the 2 libraries, then update [the dependency map|http://maven.apache.org/wagon-archives/wagon-2.2/] > remove wagon-http-shared4 dependency on httpclient > -- > > Key: WAGON-388 > URL: https://jira.codehaus.org/browse/WAGON-388 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-http-lightweight >Affects Versions: 2.0, 2.4 >Reporter: Herve Boutemy > > AbstractHttpClientWagon uses classes from > [HttpClient|http://hc.apache.org/httpcomponents-client-ga/httpclient/index.html] > Lightweight wagon extends AbstractHttpClientWagon but uses JRE java.net > classes > AbstractHttpClientWagon should not depend on httpclient: it can depend on > [HttpCore|http://hc.apache.org/httpcomponents-core-ga/index.html], if useful > to share some utilities between wagon-http and wagon-http-lightweight, but > not HttpClient > Such separation, possible now that HttpComponents has 2 separate layers, will > ease maintenance -- 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] (MNG-3959) Per-execution inherited flag ignored
[
https://jira.codehaus.org/browse/MNG-3959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319011#comment-319011
]
Michael Osipov commented on MNG-3959:
-
Sadly, I can confirm this on Maven 2.2.1. Maven 3.0.x works as expected.
> Per-execution inherited flag ignored
>
>
> Key: MNG-3959
> URL: https://jira.codehaus.org/browse/MNG-3959
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Reporter: Dave Syer
> Fix For: Issues to be reviewed for 3.x
>
>
> Per-execution inherited flag ignored. E.g.
> {code}
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> test
> initialize
> false
> ...
> {code}
> If you move the inherited element up to the plugin level it works, but then
> that applies to all executions, which isn't what is needed.
--
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] (MDEP-396) Add support to use the baseVersion of an artifact instead of version for the destFileName
[ https://jira.codehaus.org/browse/MDEP-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318913#comment-318913 ] Olivier Lamy commented on MDEP-396: --- the patch looks good. but the trouble I have is the lack of test. Could you provide a unit test or an integration ? > Add support to use the baseVersion of an artifact instead of version for the > destFileName > - > > Key: MDEP-396 > URL: https://jira.codehaus.org/browse/MDEP-396 > Project: Maven 2.x Dependency Plugin > Issue Type: Improvement > Components: copy >Affects Versions: 2.6 >Reporter: Andreas Kuhtz > Attachments: baseVersionPatch.diff > > > Add support to use the baseVersion of an artifact instead of version for the > destFileName via plugin configuration. The problem occurs with maven 3 and > SNAPSHOT artifacts where the name of the copied file contains the timestamped > (unique) version instead of '-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] (MSHARED-274) Missing license file
[ https://jira.codehaus.org/browse/MSHARED-274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318912#comment-318912 ] Olivier Lamy commented on MSHARED-274: -- all sources have license headers. What is your issue exactly ? > Missing license file > > > Key: MSHARED-274 > URL: https://jira.codehaus.org/browse/MSHARED-274 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-repository-builder >Reporter: tradej > > Maven-repository-builder is missing the license file. Apache Software License > though requires one to be present with code distribution. > Please, add the license file. Thank you. -- 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] (MGPG-42) property name references not resolved when copying pom to target directory prior to signing
Marshall Schor created MGPG-42:
--
Summary: property name references not resolved when copying pom to
target directory prior to signing
Key: MGPG-42
URL: https://jira.codehaus.org/browse/MGPG-42
Project: Maven 2.x and 3.x GPG Plugin
Issue Type: Bug
Affects Versions: 1.4
Reporter: Marshall Schor
Priority: Minor
We sometimes configure our with a which has a string where
the "version" part is a maven dynamically-set property. We do this so that
Jars we build that are Eclipse plugins can follow the Eclipse conventions of
using periods (e.g., in front of SNAPSHOT, rather than the maven convention of
a dash). We use the build-helper-maven-plugin parse-version goal to do this.
The maven-jar-plugin takes the finalName string and manages to substitute the
value that the build-helper-maven-plugin sets.
The gpg plugin copies the projects pom.xml file to the target before signing
it. It uses this bit of code:
File pomToSign = new File( project.getBuild().getDirectory(),
project.getBuild().getFinalName() + ".pom" );
FileUtils.copyFile( project.getFile(), pomToSign )
Unfortunately, the ...getFinalName() picks up the final name string without
substituting the value of the variable, so looking in the target directory, we
see things like:
org.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}.pom
and
org.apache.uima.textmarker.engine_${parsedVersion.osgiVersion}.pom.asc
This should be fixed to operate like the maven-jar-plugin works, with the
finalName value being processed to replace variables with their values.
Now, this may not be urgent. Here's why. When a subsequent Maven Install
runs, it puts the pom and signature into the repository. But to my surprise,
it copies the pom not from the target, but it does get the signature from the
target, and RENAMES it (surprise!) so in the repository, things look ok.
But anyone who works with signed files in the target directory would get the
wrong names (if dynamically set variables are used as part of the name), so
this should probably be fixed.
--
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] (MCOMPILER-178) can't specify -Xlint:-path option without violation of XML well-formness
[
https://jira.codehaus.org/browse/MCOMPILER-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MCOMPILER-178.
--
Resolution: Fixed
fixed http://svn.apache.org/r1444233
Thanks !
> can't specify -Xlint:-path option without violation of XML well-formness
>
>
> Key: MCOMPILER-178
> URL: https://jira.codehaus.org/browse/MCOMPILER-178
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Reporter: Yegor Bugayenko
>Assignee: Olivier Lamy
> Fix For: 3.1
>
>
> This XML document is not valid:
> {noformat}
>
>
>
> {noformat}
> because {{Xlint}} is interpreted as a namespace, which is absent in the
> document
--
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] (MCOMPILER-178) can't specify -Xlint:-path option without violation of XML well-formness
[
https://jira.codehaus.org/browse/MCOMPILER-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy updated MCOMPILER-178:
---
Fix Version/s: 3.1
Assignee: Olivier Lamy
> can't specify -Xlint:-path option without violation of XML well-formness
>
>
> Key: MCOMPILER-178
> URL: https://jira.codehaus.org/browse/MCOMPILER-178
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Reporter: Yegor Bugayenko
>Assignee: Olivier Lamy
> Fix For: 3.1
>
>
> This XML document is not valid:
> {noformat}
>
>
>
> {noformat}
> because {{Xlint}} is interpreted as a namespace, which is absent in the
> document
--
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] (MCOMPILER-178) can't specify -Xlint:-path option without violation of XML well-formness
[
https://jira.codehaus.org/browse/MCOMPILER-178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318901#comment-318901
]
Jan Sievers commented on MCOMPILER-178:
---
IMHO the existing mojo parameters String compilerArgument and Map
compilerArguments can't be modified in a backwards-compatible way to support
both multiple arguments and characters not allowed in XML element names.
At the same time there are all kinds of shortcomings with the current map-based
approach (":" in arguments being interpreted as XML namespace separators, "+"
not allowed in XML element names, fixed -key=value syntax, etc...) and these
are real-world problems with compiler arguments of the eclipse JDT compiler[1].
Another recent example which shows that the current approach doesn't scale is
the fix for MCOMPILER-135 : special handling had to be introduced for the
"-Akey=value" syntax.
I propose to fix this by introducing a new List mojo parameter e.g.
"compilerArgs" and deprecate the old Map compilerArguments.
Here is my pull request:
https://github.com/apache/maven-plugins/pull/4
BTW we fixed this for tycho in a similar way [2]
[1]
http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Ftasks%2Ftask-using_batch_compiler.htm
[2] https://git.eclipse.org/r/#/c/10254/
> can't specify -Xlint:-path option without violation of XML well-formness
>
>
> Key: MCOMPILER-178
> URL: https://jira.codehaus.org/browse/MCOMPILER-178
> Project: Maven 2.x Compiler Plugin
> Issue Type: Bug
>Reporter: Yegor Bugayenko
>
> This XML document is not valid:
> {noformat}
>
>
>
> {noformat}
> because {{Xlint}} is interpreted as a namespace, which is absent in the
> document
--
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] (WAGON-388) remove wagon-http-shared4 dependency on httpclient
[ https://jira.codehaus.org/browse/WAGON-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318897#comment-318897 ] Herve Boutemy commented on WAGON-388: - ok, so the solution is even simpler than expected: the abstract class is to move to wagon-http, and removed from wagon-http-shared4 (notice that previously, httpclient was excluded but not httpcore, which caused a useless dependency: see [dependency report|http://maven.apache.org/wagon-archives/wagon-2.2/wagon-providers/wagon-http-lightweight/dependencies.html]) > remove wagon-http-shared4 dependency on httpclient > -- > > Key: WAGON-388 > URL: https://jira.codehaus.org/browse/WAGON-388 > Project: Maven Wagon > Issue Type: Improvement > Components: wagon-http, wagon-http-lightweight >Affects Versions: 2.0, 2.4 >Reporter: Herve Boutemy > > AbstractHttpClientWagon uses classes from > [HttpClient|http://hc.apache.org/httpcomponents-client-ga/httpclient/index.html] > Lightweight wagon extends AbstractHttpClientWagon but uses JRE java.net > classes > AbstractHttpClientWagon should not depend on httpclient: it can depend on > [HttpCore|http://hc.apache.org/httpcomponents-core-ga/index.html], if useful > to share some utilities between wagon-http and wagon-http-lightweight, but > not HttpClient > Such separation, possible now that HttpComponents has 2 separate layers, will > ease maintenance -- 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] (MJAR-162) skipIfEmpty not work for test-jar goal and empty directories
[ https://jira.codehaus.org/browse/MJAR-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed MJAR-162. - Resolution: Fixed fixed http://svn.apache.org/r1444045 > skipIfEmpty not work for test-jar goal and empty directories > - > > Key: MJAR-162 > URL: https://jira.codehaus.org/browse/MJAR-162 > Project: Maven 2.x JAR Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Lefebvre JF >Assignee: Olivier Lamy > Fix For: 2.5 > > Attachments: wsTestMaven.zip > > > skipIfEmpty not work for test-jar goal -- 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] (MJAR-162) skipIfEmpty not work for test-jar goal and empty directories
[ https://jira.codehaus.org/browse/MJAR-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MJAR-162: -- Summary: skipIfEmpty not work for test-jar goal and empty directories (was: skipIfEmpty not work for test-jar goal) > skipIfEmpty not work for test-jar goal and empty directories > - > > Key: MJAR-162 > URL: https://jira.codehaus.org/browse/MJAR-162 > Project: Maven 2.x JAR Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Lefebvre JF >Assignee: Olivier Lamy > Fix For: 2.5 > > Attachments: wsTestMaven.zip > > > skipIfEmpty not work for test-jar goal -- 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] (MJAR-162) skipIfEmpty not work for test-jar goal
[ https://jira.codehaus.org/browse/MJAR-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318891#comment-318891 ] Lefebvre JF commented on MJAR-162: -- Thanks a lot. > skipIfEmpty not work for test-jar goal > -- > > Key: MJAR-162 > URL: https://jira.codehaus.org/browse/MJAR-162 > Project: Maven 2.x JAR Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Lefebvre JF >Assignee: Olivier Lamy > Fix For: 2.5 > > Attachments: wsTestMaven.zip > > > skipIfEmpty not work for test-jar goal -- 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] (MJAR-162) skipIfEmpty not work for test-jar goal
[ https://jira.codehaus.org/browse/MJAR-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MJAR-162: -- Fix Version/s: 2.5 Assignee: Olivier Lamy > skipIfEmpty not work for test-jar goal > -- > > Key: MJAR-162 > URL: https://jira.codehaus.org/browse/MJAR-162 > Project: Maven 2.x JAR Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Lefebvre JF >Assignee: Olivier Lamy > Fix For: 2.5 > > Attachments: wsTestMaven.zip > > > skipIfEmpty not work for test-jar goal -- 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] (MJAR-162) skipIfEmpty not work for test-jar goal
[ https://jira.codehaus.org/browse/MJAR-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318889#comment-318889 ] Olivier Lamy commented on MJAR-162: --- you are correct. I will fix that . > skipIfEmpty not work for test-jar goal > -- > > Key: MJAR-162 > URL: https://jira.codehaus.org/browse/MJAR-162 > Project: Maven 2.x JAR Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Lefebvre JF > Fix For: 2.5 > > Attachments: wsTestMaven.zip > > > skipIfEmpty not work for test-jar goal -- 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] (MJAR-162) skipIfEmpty not work for test-jar goal
[ https://jira.codehaus.org/browse/MJAR-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=31#comment-31 ] Lefebvre JF commented on MJAR-162: -- I know this workaround but if you take the source plugin, it does not create jar even if src/test/java and src/test/resouces are present but empty. > skipIfEmpty not work for test-jar goal > -- > > Key: MJAR-162 > URL: https://jira.codehaus.org/browse/MJAR-162 > Project: Maven 2.x JAR Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Lefebvre JF > Attachments: wsTestMaven.zip > > > skipIfEmpty not work for test-jar goal -- 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] (MJAR-162) skipIfEmpty not work for test-jar goal
[ https://jira.codehaus.org/browse/MJAR-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318884#comment-318884 ] Olivier Lamy commented on MJAR-162: --- you child project contains directories src/test/java and src/test/resources so that create target/test-classes that's why the test jar is created. Remove those directories and not test jar will be created. > skipIfEmpty not work for test-jar goal > -- > > Key: MJAR-162 > URL: https://jira.codehaus.org/browse/MJAR-162 > Project: Maven 2.x JAR Plugin > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Lefebvre JF > Attachments: wsTestMaven.zip > > > skipIfEmpty not work for test-jar goal -- 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] (MSHARED-274) Missing license file
tradej created MSHARED-274: -- Summary: Missing license file Key: MSHARED-274 URL: https://jira.codehaus.org/browse/MSHARED-274 Project: Maven Shared Components Issue Type: Bug Components: maven-repository-builder Reporter: tradej Maven-repository-builder is missing the license file. Apache Software License though requires one to be present with code distribution. Please, add the license file. Thank you. -- 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-168) Use build final name as default context root
[
https://jira.codehaus.org/browse/MEAR-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stéphane Nicoll updated MEAR-168:
-
Affects Version/s: (was: 2.8.1)
(was: 2.9)
2.8
2.8.1 and 2.9 are not even released so you can be affected by those.
> Use build final name as default context root
>
>
> Key: MEAR-168
> URL: https://jira.codehaus.org/browse/MEAR-168
> Project: Maven 2.x Ear Plugin
> Issue Type: Bug
>Affects Versions: 2.8
> Environment: all
>Reporter: José Volmei Dal Prá Junior
>
> Sometimes we need to make some conventions when dealing with several modules.
> We need to use the "${project.build.finalName}" as the default "contextRoot"
> mapping.
> The suggestion is: make a global configuration parameter with name
> "mustUseBuildFinalNameAsDefaultWebContextRoot". If this is set to true then
> the "WebModule.getDefaultContextRoot" method must use the build final name as
> context root.
> The global configuration parameter should have false as default value.
> Thanks.
--
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] (MANTTASKS-236) Dependencies task picks POM from releases but JAR from snapshots
[
https://jira.codehaus.org/browse/MANTTASKS-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Clemens Ballarin closed MANTTASKS-236.
--
Resolution: Not A Bug
Defective repository configuration in settings.xml, see MNG-2631.
> Dependencies task picks POM from releases but JAR from snapshots
>
>
> Key: MANTTASKS-236
> URL: https://jira.codehaus.org/browse/MANTTASKS-236
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Components: dependencies task
>Affects Versions: 2.1.3
> Environment: Apache Ant version 1.7.1
> Artifactory 2.6.6
>Reporter: Clemens Ballarin
>
> This issue manifests when using a version range.
> {code:xml}
>
>
>
> {code}
> produces this failure:
> {noformat}
> [artifact:dependencies] Downloading: xyz/remoteexec/1.3/remoteexec-1.3.pom
> from repository central at http://localhost:8081/artifactory/libs-release
> [artifact:dependencies] Transferring 3K from central
> [artifact:dependencies] Downloading: xyz/remoteexec/1.3/remoteexec-1.3.jar
> from repository snapshots at http://localhost:8081/artifactory/libs-snapshot
> [artifact:dependencies] Unable to locate resource in repository
> {noformat}
> While the POM is correctly retrieved from lib-release-local, getting the JAR
> from libs-snapshot-local obviously must fail.
> When setting the version to "1.3" the dependency is resolved correctly.
--
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] (WAGON-388) remove wagon-http-shared4 dependency on httpclient
[
https://jira.codehaus.org/browse/WAGON-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318871#comment-318871
]
Olivier Lamy commented on WAGON-388:
Euh I miss you Hervé
{code}
public class LightweightHttpWagon
extends StreamWagon
{code}
see
https://git-wip-us.apache.org/repos/asf?p=maven-wagon.git;a=blob;f=wagon-providers/wagon-http-lightweight/src/main/java/org/apache/maven/wagon/providers/http/LightweightHttpWagon.java;h=b15d059dbfd50d30af057be6ed17ec03f24963ef;hb=HEAD
wagon-http-lightweight depends on shared4 only for an utility class called
HtmlFileListParser (maybe could be moved somewhere really a module with only
this class ?)
And dependency on shared4 exclude httpclient deps
{code}
${project.groupId}
wagon-http-shared4
${project.version}
org.apache.httpcomponents
httpclient
commons-logging
commons-logging
{code}
> remove wagon-http-shared4 dependency on httpclient
> --
>
> Key: WAGON-388
> URL: https://jira.codehaus.org/browse/WAGON-388
> Project: Maven Wagon
> Issue Type: Improvement
> Components: wagon-http, wagon-http-lightweight
>Affects Versions: 2.0, 2.4
>Reporter: Herve Boutemy
>
> AbstractHttpClientWagon uses classes from
> [HttpClient|http://hc.apache.org/httpcomponents-client-ga/httpclient/index.html]
> Lightweight wagon extends AbstractHttpClientWagon but uses JRE java.net
> classes
> AbstractHttpClientWagon should not depend on httpclient: it can depend on
> [HttpCore|http://hc.apache.org/httpcomponents-core-ga/index.html], if useful
> to share some utilities between wagon-http and wagon-http-lightweight, but
> not HttpClient
> Such separation, possible now that HttpComponents has 2 separate layers, will
> ease maintenance
--
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] (MSKINS-74) Upgrade jQuery to v1.9.1
Simone Tripodi created MSKINS-74: Summary: Upgrade jQuery to v1.9.1 Key: MSKINS-74 URL: https://jira.codehaus.org/browse/MSKINS-74 Project: Maven Skins Issue Type: Task Components: Fluido Skin Affects Versions: fluido-1.3.1 Reporter: Simone Tripodi MSKINS-73 introduces Bootstrap 2.3.0 which is jQuery 1.9.X compatible, it would worth to update jQuery to the latest version available -- 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] (MSKINS-73) Upgrade Bootstrap to Version 2.3.0
[ https://jira.codehaus.org/browse/MSKINS-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simone Tripodi closed MSKINS-73. Resolution: Fixed Fix Version/s: fluido-1.3.1 Assignee: Simone Tripodi Bootstrap upgraded at r 1443862 > Upgrade Bootstrap to Version 2.3.0 > -- > > Key: MSKINS-73 > URL: https://jira.codehaus.org/browse/MSKINS-73 > Project: Maven Skins > Issue Type: Task > Components: Fluido Skin >Affects Versions: fluido-1.3.1 >Reporter: Simone Tripodi >Assignee: Simone Tripodi > Fix For: fluido-1.3.1 > > > They just announced the immediate availability of Twitter Bootstrap Version > 2.3.0, it must be included in next fluido-skin release -- 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] (MNG-5432) Range [1.3, 1.4) cannot get resolved, but [1.3],[1.4] is working.
Markus KARG created MNG-5432: Summary: Range [1.3, 1.4) cannot get resolved, but [1.3],[1.4] is working. Key: MNG-5432 URL: https://jira.codehaus.org/browse/MNG-5432 Project: Maven 2 & 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0.4 Environment: Win 7 Pro 64 Bit, JDK 1.7.0_13, Nexus 1.9.2.4, MVN 3.0.4 Reporter: Markus KARG Priority: Critical My project contains the following dependency: xmlunit xmlunit [1.3, 1.4) test This worked well until today, as on Maven Central the latest artifact was 1.3. Today in Maven Central a version 1.4 was published, and now my project does not build anymore! "mvn compile" says that it cannot find an xmlunit artifact in the range [1.3, 1.4). This is strange, as 1.3 is still found in my local repo, in my Nexus instance, and on Maven Central! I was able to workaround it by using xmlunit xmlunit [1.3] test instead, which is some kind of weird. Seems like a bug in the range resolver? -- 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
