[jira] Commented: (MARTIFACT-32) Maven does not expand expressions while installing artifacts locally
[
http://jira.codehaus.org/browse/MARTIFACT-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145527#action_145527
]
Henrik Brautaset Aronsen commented on MARTIFACT-32:
---
There is a simple patch in MNG-3057 which solves this issue.
> Maven does not expand expressions while installing artifacts locally
> -
>
> Key: MARTIFACT-32
> URL: http://jira.codehaus.org/browse/MARTIFACT-32
> Project: Maven Artifact
> Issue Type: Bug
>Reporter: Harsha Rai
>
> When a pom uses expressions like: grizzly.version in the following pom.xml
> >
> >
>...
> > grizzly-module
> > jar
> > ${grizzly.version}
> Everything works well when the project.version above is defined as a
> property as 'grizzly.version'
> The local repository layout also seems to be correct, for a given property
> value for, grizzly.version.
> What's going wrong is, maven just copies the same pom.xml to the local repo
> directory and from there to the remote repo while deploying the
> artifacts of the same project, whose version is parameterized.
> In the strict sense, while parsing the pom and resolving the artifacts,
> maven got the right version for the project.version for the project; the
> same should have been used inside the pom file while installing locally. By
> doing this, the expanded pom files will have right artifact information.
> Users should be given a choice if they want maven to expand expressions in
> the pom.xml or leave them as it is.
> I don't know the right category of the project and component. Please reassign
> / redirect as appropriate.
> This belongs somewhere pom parsing, artifact resolver and mvn install.
> thanks..
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145526#action_145526 ] Henrik Brautaset Aronsen commented on MNG-624: -- Harsha: There is a simple patch in MNG-3057 which solves this issue. > automatic parent versioning > --- > > Key: MNG-624 > URL: http://jira.codehaus.org/browse/MNG-624 > Project: Maven 2 > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Brett Porter >Assignee: Ralph Goers >Priority: Blocker > Fix For: 3.0 > > Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2182) infinitest 4.0.1 upload
infinitest 4.0.1 upload --- Key: MAVENUPLOAD-2182 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2182 Project: Maven Upload Requests Issue Type: Wish Reporter: Rod Coffin I am a developer on the infintest project and this can be verified at http://code.google.com/p/infinitest/ where I (username rfciii) am listed as one of the project owners. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145524#action_145524 ] Harsha Rai commented on MNG-624: Hello: I filed the following: http://jira.codehaus.org/browse/MARTIFACT-32 The issue is almost the same. I didn't know which maven component the issue belonged to? Is there a workaround for this? thanks.. > automatic parent versioning > --- > > Key: MNG-624 > URL: http://jira.codehaus.org/browse/MNG-624 > Project: Maven 2 > Issue Type: Improvement > Components: Inheritance and Interpolation >Reporter: Brett Porter >Assignee: Ralph Goers >Priority: Blocker > Fix For: 3.0 > > Attachments: MNG-624-maven-2.0.x-r507648.patch, MNG-624-tests.tar.gz > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see > MNG-521) > currently, you have to specify the parent version when extending which makes > a project stand alone very easily, but has the drawback of being a > maintainance problem when you start development on a new version. Tools can > help, but it would be nice not to have to rely on them. > One alternative is to allow the parent version to be omitted, and when it is > it is assumed you want the latest. The parent is used from the reactor or the > universal source directory. IT may also be read from a LATEST in the > repository though this is contentious - it may be better to simply fail in > that environment and require builds be in a known checkout structure for > building individual projects. > This also introduces the need for tool support to populate the version on > release and deployment for reproducibility. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3720) Documentation of properties (pom variables) available (in mojo)
[
http://jira.codehaus.org/browse/MNG-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145523#action_145523
]
Alfonsas Stonis commented on MNG-3720:
--
Thanks Dennis. The only one way that I found to solve this problem is to hard
code path to the file
${basedir}/src/site/databasedoc/IFS.xml
I know that it will mean that configuration of the project will be ignored, but
I found no better way. Also I assume that what most users would like is to have
a documentation of all available properties, that are not listed in the project
reference (the one you mentioned).
> Documentation of properties (pom variables) available (in mojo)
> ---
>
> Key: MNG-3720
> URL: http://jira.codehaus.org/browse/MNG-3720
> Project: Maven 2
> Issue Type: Improvement
> Components: Documentation: General
> Environment: All
>Reporter: Alfonsas Stonis
>
> There is no list of properties available to Mojo expressions or within pom
> files. I spend whole day trying to find anything in Maven site or somewhere
> on internet. The best I was able to find was this link.
> http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide
> I doubt that it is complete. I found somewhere in maven site @parameter
> expression="${project.resources}" but there is no documentation about it. I
> do not know the type. I need resources directory and can not find the way how
> to find it. The only solution seems to work is to write whole path to
> property, but it is really bad way.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (SUREFIRE-516) Definition of multiple Suite-Files not working
Hi, After updating my pom to TestNG 5.7, works for me now. http://jira.codehaus.org/browse/SUREFIRE-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel JIRA [EMAIL PROTECTED] wrote: > > Definition of multiple Suite-Files not working > -- > > Key: SUREFIRE-516 > URL: http://jira.codehaus.org/browse/SUREFIRE-516 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support > Affects Versions: 2.4.2 > Environment: maven 2.0.9 > > Reporter: Andreas Höhmann > > > > > maven-surefire-plugin > > > > /src/test/resources/Testsuite1.xml > > /src/test/resources/Testsuite2.xml > > /src/test/resources/Testsuite3.xml > > > > > > Will raise the error > > [INFO] Surefire report directory: > d:\ws_sid\spice-sid\sid-base\sid-base-knowledgebase\target\surefire-reports > org.apache.maven.surefire.booter.SurefireExecutionException: Suite file > d:\ws_sid\spice-sid\sid-base\sid-base-knowledgeb > ase\src\test\resources\Testsuite1.xmld:\ws_sid\spice-sid\sid-base\sid-base-knowledgebase\src\test\resources\Testsuite2.xml > > is not a valid file; nested exception is > org.apache.maven.surefire.testset.TestSetFailedException: Suite file d: > \ws_sid\spice-sid\sid-base\sid-base-knowledgebase\src\test\resources\Testsuite1.xmld:\ws_sid\spice-sid\sid-base\sid-ba > se-knowledgebase\src\test\resources\Testsuite2.xml is not a valid file > org.apache.maven.surefire.testset.TestSetFailedException: Suite file > d:\ws_sid\spice-sid\sid-base\sid-base-knowledgebase > \src\test\resources\Testsuite1.xmld:\ws_sid\spice-sid\sid-base\sid-base-knowledgebase\src\test\resources\Testsuite2.xml > is not a valid file > at > org.apache.maven.surefire.testng.TestNGXmlTestSuite.locateTestSets(TestNGXmlTestSuite.java:129) > at > org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) > at org.apache.maven.surefire.Surefire.run(Surefire.java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) > > Workaround (put a ',' behind every suiteXmlFile): > > > maven-surefire-plugin > > > > /src/test/resources/Testsuite1.xml, > > /src/test/resources/Testsuite2.xml, > > /src/test/resources/Testsuite3.xml, > > > > > > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: > http://jira.codehaus.org/secure/Administrators.jspa > - > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > > -- View this message in context: http://www.nabble.com/-jira--Created%3A-%28SUREFIRE-516%29-Definition-of-multiple-Suite-Files-not-working-tp19031598p19060344.html Sent from the Maven - Issues mailing list archive at Nabble.com.
[jira] Commented: (SCM-396) git provider implements scm update
[ http://jira.codehaus.org/browse/SCM-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145520#action_145520 ] Olivier Lamy commented on SCM-396: -- Mark, I use cygwin. But the consummer handle the character | too and this should work with your format too. IMHO, you can open an other issue with the fix for tck update test and we can close it ? WDYT ? > git provider implements scm update > --- > > Key: SCM-396 > URL: http://jira.codehaus.org/browse/SCM-396 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-git >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 1.1 > > Attachments: GitExeUpdateTck.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
maven-javadoc-plugin and custom stylesheet
I am having difficulties getting the maven-javadoc-plugin to utilize my
custom stylesheet.
(I am new to Maven)
In pom.xml, I have:
...
org.apache.maven.plugins
maven-javadoc-plugin
html
${basedir}/src/main/javadoc/stylesheet.css
${basedir}/src/main/javadoc/overview.html
...
...
--
If I invoke
mvn clean site
my stylesheet file is utilized:
Building tree for all the packages and classes...
Generating
c:/ws/SofaCommonsMvn/target/site/apidocs\com/fsb/commons/configuration/\SofaConfiguration.html...
...
Copying file c:\ws\SofaCommonsMvn\src\main\javadoc\stylesheet.css to
file c:\ws\SofaCommonsMvn\target\site\apidocs\stylesheet.css...
...
Building index for all the packages and classes...
Generating
c:/ws/SofaCommonsMvn/target/site/apidocs\overview-tree.html...
Generating c:/ws/SofaCommonsMvn/target/site/apidocs\index-all.html...
Generating
c:/ws/SofaCommonsMvn/target/site/apidocs\deprecated-list.html...
Building index for all classes...
Generating
c:/ws/SofaCommonsMvn/target/site/apidocs\allclasses-frame.html...
Generating
c:/ws/SofaCommonsMvn/target/site/apidocs\allclasses-noframe.html...
Generating c:/ws/SofaCommonsMvn/target/site/apidocs\index.html...
Generating
c:/ws/SofaCommonsMvn/target/site/apidocs\overview-summary.html...
Generating c:/ws/SofaCommonsMvn/target/site/apidocs\help-doc.html...
--
If I then invoke:
rm -rf target/site/apidocs ; mvn javadoc:javadoc
my stylesheet is NOT utilized:
Building tree for all the packages and classes...
...
Building index for all the packages and classes...
Generating
c:/ws/SofaCommonsMvn/target/site/apidocs\overview-tree.html...
Generating c:/ws/SofaCommonsMvn/target/site/apidocs\index-all.html...
Generating
c:/ws/SofaCommonsMvn/target/site/apidocs\deprecated-list.html...
Building index for all classes...
Generating
c:/ws/SofaCommonsMvn/target/site/apidocs\allclasses-frame.html...
Generating
c:/ws/SofaCommonsMvn/target/site/apidocs\allclasses-noframe.html...
Generating c:/ws/SofaCommonsMvn/target/site/apidocs\index.html...
Generating
c:/ws/SofaCommonsMvn/target/site/apidocs\overview-summary.html...
Generating c:/ws/SofaCommonsMvn/target/site/apidocs\help-doc.html...
Generating c:/ws/SofaCommonsMvn/target/site/apidocs\stylesheet.css...
Thoughts? Am I using these goals incorrectly?
J. Thomas Halliley
IT Architecture & Infrastructure Team
Flagstar Bank
This e-mail may contain data that is confidential, proprietary or
non-public personal information, as that term is defined in the
Gramm-Leach-Bliley Act (collectively, Confidential Information).
The Confidential Information is disclosed conditioned upon your
agreement that you will treat it confidentially and in accordance
with applicable law, ensure that such data isn't used or disclosed
except for the limited purpose for which it's being provided and
will notify and cooperate with us regarding any requested or
unauthorized disclosure or use of any Confidential Information.
By accepting and reviewing the Confidential information, you agree
to indemnify us against any losses or expenses, including
attorney's fees that we may incur as a result of any unauthorized
use or disclosure of this data due to your acts or omissions. If a
party other than the intended recipient receives this e-mail, he or
she is requested to instantly notify us of the erroneous delivery
and return to us all data so delivered.
[jira] Commented: (MANTTASKS-73) miss RemoteRepository sub-element for tasks pom and install-provider
[
http://jira.codehaus.org/browse/MANTTASKS-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145515#action_145515
]
Dennis Lundberg commented on MANTTASKS-73:
--
Documentation has already been updated, but not yet published. This is being
tracked in MANTTASKS-114.
> miss RemoteRepository sub-element for tasks pom and install-provider
>
>
> Key: MANTTASKS-73
> URL: http://jira.codehaus.org/browse/MANTTASKS-73
> Project: Maven 2.x Ant Tasks
> Issue Type: Wish
> Components: install-provider task, POM Integration
>Affects Versions: 2.0.6
> Environment: Ant 1.6.5 / Maven Ant Task 2.0.6
>Reporter: David N'DIAYE
> Fix For: 2.0.7
>
> Attachments: MANTTASKS-73.diff, MANTTASKS-73.tgz
>
>
> My pom have parent pom which is not in the {{repo1.maven.org}}. And i can't
> initialize it because maven task ant {{pom}} doesn't find parent pom.
> I need to have possibility to specify the remote repository like in the
> dependencies task
> {code:xml}
>
> **
>
>
> {code}
> I have the same problem with the {{install-provider}} to download my
> dependencies. I can't specify the remote repository, so i can't download all
> dependencies which is not in {{repo1.maven.org}}.
> {code:xml}
>
> **
>
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3720) Documentation of properties (pom variables) available (in mojo)
[
http://jira.codehaus.org/browse/MNG-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145514#action_145514
]
Dennis Lundberg commented on MNG-3720:
--
The possible values are many. One good way to find out what is available is
this:
${project.anything}
will refer to the element "anything" in the current Maven Project. For
documentation on Maven Project see the reference at
http://maven.apache.org/ref/current/maven-model/maven.html
Your specific request is difficult to get, because there can be more than one
resource directory.
> Documentation of properties (pom variables) available (in mojo)
> ---
>
> Key: MNG-3720
> URL: http://jira.codehaus.org/browse/MNG-3720
> Project: Maven 2
> Issue Type: Improvement
> Components: Documentation: General
> Environment: All
>Reporter: Alfonsas Stonis
>
> There is no list of properties available to Mojo expressions or within pom
> files. I spend whole day trying to find anything in Maven site or somewhere
> on internet. The best I was able to find was this link.
> http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide
> I doubt that it is complete. I found somewhere in maven site @parameter
> expression="${project.resources}" but there is no documentation about it. I
> do not know the type. I need resources directory and can not find the way how
> to find it. The only solution seems to work is to write whole path to
> property, but it is really bad way.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-402) scm:checkin doesn't work on OS X 10.5 Leopard
scm:checkin doesn't work on OS X 10.5 Leopard - Key: SCM-402 URL: http://jira.codehaus.org/browse/SCM-402 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-svn Affects Versions: 1.0 Reporter: Dan Fabulich Priority: Blocker Run "mvn scm:checkin -Dmessage=test" on OS X 10.5 Leopard. You'll see: [INFO] Executing: svn --non-interactive commit --file /tmp/maven-scm-1856881168.commit But --non-interactive is broken on OS X 10.5 Leopard. http://subversion.tigris.org/issues/show_bug.cgi?id=3059 Brett Porter has a hacky workaround for it here: http://blogs.exist.com/bporter/2008/02/25/working-around-non-interactive-problems-in-leopards-subversion/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2923) Having any active profiles causes the build to fail
[ http://jira.codehaus.org/browse/MNG-2923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145507#action_145507 ] David Greenberg commented on MNG-2923: -- I am a beginner with Maven, and am getting this issue with Maven 2.0.9. What's weird is that I didn't have this issue for the few months that I have been using this configuration, and suddenly it broke today. Is there an easy way to tell which dependency it is breaking on? I have a lot of dependencies in my pom. > Having any active profiles causes the build to fail > --- > > Key: MNG-2923 > URL: http://jira.codehaus.org/browse/MNG-2923 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.6 >Reporter: Matthew Beermann > Fix For: 2.0.7 > > Attachments: MNG-2923-maven-artifact.patch, pom.xml > > > (This seems to be a regression in 2.0.6, and does not occur in 2.0.5.) If I > have any active profiles when building certain projects in Maven 2.0.6, the > build will fail. For example, adding something as simple as: > > > foo > > true > > > > ...to my ~/.m2/settings.xml file will cause the stack trace below, but the > build will succeed once I remove it. I'm attaching my POM for reference. > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:164) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:334) > at > org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:75) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:284) > at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:272) > at > org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1238) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:397) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2181) Please upload
Please upload -- Key: MAVENUPLOAD-2181 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2181 Project: Maven Upload Requests Issue Type: Task Reporter: Andres Rodriguez "net.sf.lucis","[EMAIL PROTECTED]:/home/groups/l/lu/lucis/htdocs/maven2","rsync_ssh","Andres Rodriguez","[EMAIL PROTECTED]",, Sourceforge project Thank you very much. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2486) ${project.version} evaluated to timestamped version if referring to SNAPSHOT
[
http://jira.codehaus.org/browse/MNG-2486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145497#action_145497
]
Bo Conroy commented on MNG-2486:
Are there any known workarounds for this? We have a pretty large project that
is running into this issue often. We are using maven-2.0.9.
> ${project.version} evaluated to timestamped version if referring to SNAPSHOT
>
>
> Key: MNG-2486
> URL: http://jira.codehaus.org/browse/MNG-2486
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies, Inheritance and Interpolation, POM
>Affects Versions: 2.0.4, 2.0.5, 2.0.6, 2.0.7, 3.0-alpha-1
>Reporter: John Casey
>Priority: Critical
> Fix For: 3.0
>
>
> when projects specify dependencyManagement sections with a shorthand version
> notation using the current project version (using ${project.version}) the
> version resolved will be that of the POM in which the dependencyManagement
> section is specified. If this POM is a snapshot, these dependency
> specifications will get the timestamp/buildnumber of that POM, instead of the
> actual one used when the dependency it references gets deployed.
> We should look at strategies for limiting or eliminating this practice, or
> else (somehow) pulling the real timestamp/buildnumber for that artifact from
> the reactor...in order to make these deps transitively resolvable for users.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MARTIFACT-32) Maven does not expand expressions while installing artifacts locally
Maven does not expand expressions while installing artifacts locally
-
Key: MARTIFACT-32
URL: http://jira.codehaus.org/browse/MARTIFACT-32
Project: Maven Artifact
Issue Type: Bug
Reporter: Harsha Rai
When a pom uses expressions like: grizzly.version in the following pom.xml
>
>
...
> grizzly-module
> jar
> ${grizzly.version}
Everything works well when the project.version above is defined as a property
as 'grizzly.version'
The local repository layout also seems to be correct, for a given property
value for, grizzly.version.
What's going wrong is, maven just copies the same pom.xml to the local repo
directory and from there to the remote repo while deploying the
artifacts of the same project, whose version is parameterized.
In the strict sense, while parsing the pom and resolving the artifacts, maven
got the right version for the project.version for the project; the same should
have been used inside the pom file while installing locally. By doing this,
the expanded pom files will have right artifact information.
Users should be given a choice if they want maven to expand expressions in the
pom.xml or leave them as it is.
I don't know the right category of the project and component. Please reassign /
redirect as appropriate.
This belongs somewhere pom parsing, artifact resolver and mvn install.
thanks..
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3706) Multi-module project with intermodule dependencies fails to package
[ http://jira.codehaus.org/browse/MNG-3706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stevo Slavic closed MNG-3706. - Resolution: Not A Bug Issue was in wrong use of maven assembly plugin where instead of "attached" goal, "assembly" goal was used, breaking multimodule project build. > Multi-module project with intermodule dependencies fails to package > --- > > Key: MNG-3706 > URL: http://jira.codehaus.org/browse/MNG-3706 > Project: Maven 2 > Issue Type: Bug > Components: Reactor and workspace >Affects Versions: 2.0.9 >Reporter: Stevo Slavic > > Say we have a maven project with following module structure: > mainproject (packaging: pom) > module 1 (packaging: jar) > module 2 (packaging: pom) > module 2.1 (packing: jar, depends on module 1) > module 2.2 (packagin: jar, depends on module 2.1) > module 3 (packaging: pom) > module 3.1 (packaing: jar, depends on module 1) > module 3.2 (packaging: jar, depends on module 2.2) > If using command line one issues "mvn clean package" on a main project a > build error gets reported that while building module 3.1 maven "failed to > resolve artifact", reporting module 1 as missing. If using command line one > issues "mvn clean install", again on a main project, a similar build error > gets reported but now while building module 3.2 maven failed to resolve > artifact, reporting as missing module 3.1 and module 2.2. > Before issuing either of the commands I've cleaned up local repository from > all of these modules artifacts, expecting that maven will resolve > dependencies between modules while building them without using local or > remote repositories. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (SCM-396) git provider implements scm update
[ http://jira.codehaus.org/browse/SCM-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy reopened SCM-396: -- reopen due to Mark comments. > git provider implements scm update > --- > > Key: SCM-396 > URL: http://jira.codehaus.org/browse/SCM-396 > Project: Maven SCM > Issue Type: New Feature > Components: maven-scm-provider-git >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 1.1 > > Attachments: GitExeUpdateTck.patch > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MRELEASE-373) Unable to do a release with release plug-in
[ http://jira.codehaus.org/browse/MRELEASE-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton moved SCM-373 to MRELEASE-373: -- Key: MRELEASE-373 (was: SCM-373) Project: Maven 2.x Release Plugin (was: Maven SCM) > Unable to do a release with release plug-in > --- > > Key: MRELEASE-373 > URL: http://jira.codehaus.org/browse/MRELEASE-373 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Environment: Windows XP SP2, Maven 2.0.7, JDK 1.5.0_10 >Reporter: Pascal ST LAURENT > > When I try to do a release, I call the following statement : mvn > release:prepare. I received this exception, maybe caused by path too long in > the project... > [ERROR] FATAL ERROR > [INFO] > > [INFO] 60 > [INFO] > > [INFO] Trace > java.lang.ArrayIndexOutOfBoundsException: 60 > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateUrlPath(RewritePomsForReleasePhase.java:249) > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateScm(RewritePomsForReleasePhase.java:124) > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.transformScm(RewritePomsForReleasePhase.java:61) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:271) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:180) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:116) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:99) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) > at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-379) SCM URL with query transformed incorrectly on release:prepare
[ http://jira.codehaus.org/browse/SCM-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed SCM-379. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 1.1 Fixed in [r687028|http://svn.apache.org/viewvc?rev=687028&view=rev] without your patch. > SCM URL with query transformed incorrectly on release:prepare > - > > Key: SCM-379 > URL: http://jira.codehaus.org/browse/SCM-379 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Affects Versions: 1.0 >Reporter: Doron Solomon >Assignee: Vincent Siveton > Fix For: 1.1 > > Attachments: SvnTagBranchUtils.java > > > Given the following scm definition: > > scm:svn:https://myserver/svn/myproj/pom/trunk > > scm:svn:https://myserver/svn/myproj/pom/trunk > https://myserver/plugins/scmsvn/viewcvs.php/pom/trunk?root=myproj > > Running the release:prepare goal transforms this to the following (in the POM > associated to the tag): > > > scm:svn:https://myserver/svn/myproj/pom/tags/mytag-1 > > scm:svn:https://myserver/svn/myproj/pom/tags/mytag-1 > > https://myserver/plugins/scmsvn/viewcvs.php/pom/trunk?root=myproj/tags/mytag-1?root=myproj > > The element is incorrect, as it is adding the query "?root=myproj" > twice. The desired url tag is: > > https://myserver/plugins/scmsvn/viewcvs.php/pom/tags/mytag-1?root=myproj > The problem is in the class > org.apache.maven.scm.provider.svn.SvnTagBranchUtils (in artifact > org.apache.maven.scm:maven-scm-providers-svn). The method resolveUrl is > considering the case where the URL contains a query string, but is not > removing the query part of the URL before transforming it. The attached java > file contains the patched version of this class that I have tested. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-380) CvsStatusConsumer cannot be used for CvsJavaListCommand and CvsExeListCommand
[ http://jira.codehaus.org/browse/SCM-380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed SCM-380. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 1.1 Patch applied in [r687025|http://svn.apache.org/viewvc?rev=687025&view=rev]. Thanks! > CvsStatusConsumer cannot be used for CvsJavaListCommand and CvsExeListCommand > - > > Key: SCM-380 > URL: http://jira.codehaus.org/browse/SCM-380 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-cvs >Affects Versions: 1.1 > Environment: C:\>cvs --version > Concurrent Versions System (CVS) 1.12.13a (client) > Copyright (C) 2005 Free Software Foundation, Inc. > Senior active maintainers include Larry Jones, Derek R. Price, > and Mark D. Baushke. Please see the AUTHORS and README files from the CVS > distribution kit for a complete list of contributors and copyrights. > CVS may be copied only under the terms of the GNU General Public License, > a copy of which can be found with the CVS distribution kit. > Specify the --help option for further information about CVS > C:\>cvs -H rls > Usage: cvs rls [-e | -l] [-RP] [-r rev] [-D date] [path...] > -d Show dead revisions (with tag when specified). > -e Display in CVS/Entries format. > -l Display all details. > -P Prune empty directories. > -R List recursively. > -r rev Show files with revision or tag. > -D date Show files from date. > (Specify the --help global option for a list of other help options) >Reporter: Sergey Zakusov >Assignee: Vincent Siveton >Priority: Blocker > Fix For: 1.1 > > Attachments: AbstractCvsListCommand.patch, > maven-scm-providers-cvs.patch > > > http://mail-archives.apache.org/mod_mbox/maven-scm-dev/200805.mbox/[EMAIL > PROTECTED] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-382) cleanup dependencies in maven-scm-provider-accurev
[
http://jira.codehaus.org/browse/SCM-382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed SCM-382.
---
Assignee: Jason van Zyl
Resolution: Fixed
Fix Version/s: 1.1
Fixed in [r662629|http://svn.apache.org/viewvc?rev=662629&view=rev]
> cleanup dependencies in maven-scm-provider-accurev
> --
>
> Key: SCM-382
> URL: http://jira.codehaus.org/browse/SCM-382
> Project: Maven SCM
> Issue Type: Bug
>Reporter: Eugene Kuleshov
>Assignee: Jason van Zyl
> Fix For: 1.1
>
> Attachments: accurev.patch
>
>
> scm provider for Accurew has some dependencies unusual for scm providers.
> Those need to be replaced with plexus-utils
> {code}
>
> org.codehaus.plexus
> plexus-cli
> 1.4
>
>
> commons-lang
> commons-lang
> 2.4
>
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-385) AbstractCvsChangeLogCommand create a wrong command for case when startVersion == endVersion
[ http://jira.codehaus.org/browse/SCM-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed SCM-385. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 1.1 Fixed in [r687020|http://svn.apache.org/viewvc?rev=687020&view=rev] > AbstractCvsChangeLogCommand create a wrong command for case when startVersion > == endVersion > --- > > Key: SCM-385 > URL: http://jira.codehaus.org/browse/SCM-385 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-cvs >Affects Versions: 1.1 > Environment: C:\>cvs --version > Concurrent Versions System (CVS) 1.12.13a (client) > Copyright (C) 2005 Free Software Foundation, Inc. > Senior active maintainers include Larry Jones, Derek R. Price, > and Mark D. Baushke. Please see the AUTHORS and README files from the CVS > distribution kit for a complete list of contributors and copyrights. > CVS may be copied only under the terms of the GNU General Public License, > a copy of which can be found with the CVS distribution kit. > Specify the --help option for further information about CVS > C:\>cvs -H rlog > Usage: cvs rlog [-lRhtNb] [-r[revisions]] [-d dates] [-s states] > [-w[logins]] [files...] > -l Local directory only, no recursion. > -b Only list revisions on the default branch. > -h Only print header. > -R Only print name of RCS file. > -t Only print header and descriptive text. > -N Do not list tags. > -S Do not print name/header if no revisions selected. -d, -r, > -s, & -w have little effect in conjunction with -b, -h, -R, > and > -t without this option. > -r[revisions] A comma-separated list of revisions to print: >rev1:rev2 Between rev1 and rev2, including rev1 and rev2. >rev1::rev2 Between rev1 and rev2, excluding rev1. >rev:rev and following revisions on the same branch. >rev:: After rev on the same branch. >:revrev and previous revisions on the same branch. >::rev rev and previous revisions on the same branch. >rev Just rev. >branch All revisions on the branch. >branch. The last revision on the branch. > -d datesA semicolon-separated list of dates > (D1 -s states Only list revisions with specified states. > -w[logins] Only list revisions checked in by specified logins. > (Specify the --help global option for a list of other help options) >Reporter: Sergey Zakusov >Assignee: Vincent Siveton > Fix For: 1.1 > > > If we want to get one changelog, then we call ScmManager.changeLog( > ScmRepository repository, ScmFileSet fileSet, ScmVersion startVersion, > ScmVersion endVersion ) where startVersion = endVersion. Is it true? > For Subversion it works fine, for example: > svn log -r3240:3240 http://svn.emforge.org/svn/emforge/maven-scm > it just returns one revision named 3240 > But the same algorithm does not work with CVS providers - the problem is in > that > AbstractCvsChangeLogCommand uses duplicated colon "::" to specify revisions, > but it means that rev1 will be excluded from result: > -r[revisions] A comma-separated list of revisions to print: >rev1:rev2 Between rev1 and rev2, including rev1 and rev2. >rev1::rev2 Between rev1 and rev2, excluding rev1. > So AbstractCvsChangeLogCommand should use first variant "rev1:rev2" to > specify revisions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-387) CvsScmProviderRepository returns wrong CVSROOT for local repository
[
http://jira.codehaus.org/browse/SCM-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Siveton closed SCM-387.
---
Assignee: Vincent Siveton
Resolution: Fixed
Fix Version/s: 1.1
Patch applied in [r687016|http://svn.apache.org/viewvc?rev=687016&view=rev]
> CvsScmProviderRepository returns wrong CVSROOT for local repository
> ---
>
> Key: SCM-387
> URL: http://jira.codehaus.org/browse/SCM-387
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-cvs
>Affects Versions: 1.1
>Reporter: Sergey Zakusov
>Assignee: Vincent Siveton
>Priority: Blocker
> Fix For: 1.1
>
>
> For local repository getCvsRoot() returns just the root path without
> transport type - see getCvsRootForCvsPass:
> {code:title=CvsScmProviderRepository.java|borderStyle=solid}
> /**
> * @return The cvs root
> */
> public String getCvsRoot()
> {
> String root = getCvsRootForCvsPass();
> return removeDefaultPortFromCvsRoot( root );
> }
> private String removeDefaultPortFromCvsRoot( String root )
> {
> if ( root != null && root.indexOf( ":2401" ) > 0 )
> {
> root = root.substring( 0, root.indexOf( ":2401" ) ) + ":" +
> root.substring( root.indexOf( ":2401" ) + 5 );
> }
> return root;
> }
> /**
> * @return The cvs root stored in .cvspass
> */
> public String getCvsRootForCvsPass()
> {
> if ( getUser() != null )
> {
> return getCvsRootWithCorrectUser( getUser() );
> }
> else
> {
> if ( AbstractCvsScmProvider.TRANSPORT_LOCAL.equals(
> getTransport() ) )
> {
> return cvsroot;
> }
> else
> {
> throw new IllegalArgumentException( "Username isn't defined."
> );
> }
> }
> }
> /**
> * @param user user name
> * @return
> */
> private String getCvsRootWithCorrectUser( String user )
> {
> //:transport:rest_of_cvsroot
> int indexOfUsername = getTransport().length() + 2;
> int indexOfAt = cvsroot.indexOf( "@" );
> String userString = user == null ? "" : ":" + user;
> if ( indexOfAt > 0 )
> {
> cvsroot = ":" + getTransport() + userString + cvsroot.substring(
> indexOfAt );
> }
> else
> {
> cvsroot = ":" + getTransport() + userString + "@" +
> cvsroot.substring( indexOfUsername );
> }
> return cvsroot;
> }
> {code}
> And if user was set directly, then the getCvsRootWithCorrectUser logic will
> be wrong.
> So the method should be changed like:
> {code:title=CvsScmProviderRepository.java|borderStyle=solid}
> /**
> * @return The cvs root stored in .cvspass
> */
> public String getCvsRootForCvsPass()
> {
> String result;
> String transport = getTransport();
> if ( AbstractCvsScmProvider.TRANSPORT_LOCAL.equals( transport ) )
> {
> result = ":" + transport + ":" + cvsroot;
> }
> else if ( getUser() != null )
> {
> result = getCvsRootWithCorrectUser( getUser() );
> }
> else
> {
> throw new IllegalArgumentException( "Username isn't defined." );
> }
> return result;
> }
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-480) System-scoped dependencies are added to the manifest, whilst provided ones are not.
System-scoped dependencies are added to the manifest, whilst provided ones are not. --- Key: MECLIPSE-480 URL: http://jira.codehaus.org/browse/MECLIPSE-480 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: OSGi, Manifest Affects Versions: 2.5.1 Reporter: Benjamin Voigt Attachments: exclude_system_scoped_deps_from_manifest.patch System scoped dependencies should not be added to the manifest file, like provided scoped ones. It's just a small change in the EclipseOSGiManifestWriter. Patch is included. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2305) only first active proxy considered/used
[ http://jira.codehaus.org/browse/MNG-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145420#action_145420 ] Brett Porter commented on MNG-2305: --- this is worth reviewing against 2.0.10 (current RC is in testing) since some related fixes were made > only first active proxy considered/used > --- > > Key: MNG-2305 > URL: http://jira.codehaus.org/browse/MNG-2305 > Project: Maven 2 > Issue Type: Bug > Components: General >Affects Versions: 2.0.4 > Environment: WIN2K JDK 1.5.0_06 > proxy:81 for both http and https >Reporter: Franz Fehringer > Fix For: Reviewed Pending Version Assignment > > Attachments: settings.xml > > > With the attached settings.xml > all https connects fail (doing mvn -U). > If i reverse the order (https first http second) all http connects fail. > Questions: > Does https tunneling over http proxies work at all with Maven2 (sending HTTP > CONNECT to the proxy is needed)? > Why is the Java system configuration (in Application > Data\Sun\Java\Deployment\deployment.properties) not used to detect proxies? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2305) only first active proxy considered/used
[ http://jira.codehaus.org/browse/MNG-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145419#action_145419 ] Niels Bertram commented on MNG-2305: Still seems broken in 2.0.9 ... is there a workaround? > only first active proxy considered/used > --- > > Key: MNG-2305 > URL: http://jira.codehaus.org/browse/MNG-2305 > Project: Maven 2 > Issue Type: Bug > Components: General >Affects Versions: 2.0.4 > Environment: WIN2K JDK 1.5.0_06 > proxy:81 for both http and https >Reporter: Franz Fehringer > Fix For: Reviewed Pending Version Assignment > > Attachments: settings.xml > > > With the attached settings.xml > all https connects fail (doing mvn -U). > If i reverse the order (https first http second) all http connects fail. > Questions: > Does https tunneling over http proxies work at all with Maven2 (sending HTTP > CONNECT to the proxy is needed)? > Why is the Java system configuration (in Application > Data\Sun\Java\Deployment\deployment.properties) not used to detect proxies? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-142) PDE provided scope dependencies should be linked to in .project, but should not be present in MANIFEST.MF
[ http://jira.codehaus.org/browse/MECLIPSE-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145418#action_145418 ] Benjamin Voigt commented on MECLIPSE-142: - I think the same goes for system dependencies. > PDE provided scope dependencies should be linked to in .project, but should > not be present in MANIFEST.MF > - > > Key: MECLIPSE-142 > URL: http://jira.codehaus.org/browse/MECLIPSE-142 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: PDE support >Affects Versions: 2.3 >Reporter: David Boden > > At the moment, provided dependencies are not included at all. Instead, they > should be put as links in .project just like compile scope dependencies. > However, they should not be listed in MANIFEST.MF as they won't end up > getting packaged in the plugin bundle. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPIR-134) SCM report generator should adhere to maven.scm.provider.cvs.implementation property
SCM report generator should adhere to maven.scm.provider.cvs.implementation property Key: MPIR-134 URL: http://jira.codehaus.org/browse/MPIR-134 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Components: scm Affects Versions: 2.0.1 Environment: Windows 2000 SP4, Maven 2.0.9 Reporter: Ringo De Smet I have a number of projects correctly building with Maven 2.0.9. I now came to the point that I wanted to tackle the site generation. Everything works, except the SCM report because it seems to insist on using the Java based CVS library. I already had to revert to scm_native for the release plugin, so I would have assumed that this would have worked for the project-info-reports also. The command-line I use: mvn site -Dmaven.scm.provider.cvs.implementation=cvs_native -Dusername=rdesmet1 The error I get: ... [INFO] Generating "Source Xref" report. [INFO] Generating "Continuous Integration" report. [INFO] Generating "Dependencies" report. [INFO] Generating "Issue Tracking" report. [INFO] Generating "Project License" report. [INFO] Generating "Mailing Lists" report. [INFO] Generating "Project Summary" report. [INFO] Generating "Source Repository" report. [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Username isn't defined. [INFO] [INFO] Trace java.lang.IllegalArgumentException: Username isn't defined. at org.apache.maven.scm.provider.cvslib.repository.CvsScmProviderRepository.getCvsRootForCvsPass(CvsScmProviderRepository.java:105) at org.apache.maven.scm.provider.cvslib.repository.CvsScmProviderRepository.getCvsRoot(CvsScmProviderRepository.java:73) at org.apache.maven.report.projectinfo.ScmReport$ScmRenderer.anonymousAccessCVS(ScmReport.java:457) at org.apache.maven.report.projectinfo.ScmReport$ScmRenderer.renderAnonymousAccessSection(ScmReport.java:276) at org.apache.maven.report.projectinfo.ScmReport$ScmRenderer.renderBody(ScmReport.java:183) at org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65) at org.apache.maven.report.projectinfo.ScmReport.executeReport(ScmReport.java:87) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:101) at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 28 seconds [INFO] Finished at: Mon Aug 18 16:32:28 CEST 2008 [INFO] Final Memory: 54M/347M [INFO] -
[jira] Commented: (ARCHETYPE-199) Archetype plugin depends on missing SNAPSHOTs of Struts 2 Archetypes
[ http://jira.codehaus.org/browse/ARCHETYPE-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145416#action_145416 ] Lukasz Lenart commented on ARCHETYPE-199: - What version of maven-archetype-plugin you have? I saw the same behavior with older version than 2.0-alpha-3 Regards - Lukasz http://www.lenart.org.pl/ > Archetype plugin depends on missing SNAPSHOTs of Struts 2 Archetypes > > > Key: ARCHETYPE-199 > URL: http://jira.codehaus.org/browse/ARCHETYPE-199 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes >Affects Versions: 2.0-alpha-1 > Environment: Maven version: 2.0.9 > Java version: 1.6.0_03 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Lukasz Lenart > > All archetypes to generate Struts2 application are missing from repo > http://people.apache.org/repo/m2-snapshot-repository/ but are still listed > when you launch mvn archetype:create > I think, they should be temporally removed from list till there be final > release. > Regards > -- > Lukasz > http://www.lenart.org.pl/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHANGES-60) The jira report should handle the nonProxyHosts specified in settings.xml
[ http://jira.codehaus.org/browse/MCHANGES-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Geach updated MCHANGES-60: --- Attachment: MNG-MCHANGES-60-MCHANGES-123-maven-changes-plugin.patch This patch fixes the issue - if JIRA is hosted on a non-proxy host as specified in settings.xml, then the request is not routed via the proxy. The helper method that matches the JIRA host with non-proxy hosts is copied from org.apache.maven.wagon.proxy.ProxyUtils (which is in project wagon-provider-api version 1.0-beta-4). In the future, when maven-changes-plugin updates its dependency on maven-project to a more recent version, then the method can be removed. Note that this patch also fixes issue MCHANGES-123 > The jira report should handle the nonProxyHosts specified in settings.xml > - > > Key: MCHANGES-60 > URL: http://jira.codehaus.org/browse/MCHANGES-60 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: jira-report >Affects Versions: 2.0-beta-2 > Environment: A network with a proxy to access the outside, and a JIRA > inside the network. >Reporter: Pierre-Antoine Grégoire > Attachments: MNG-MCHANGES-60-MCHANGES-123-maven-changes-plugin.patch > > > These nonProxyHosts can be retrieved with the > settings.getActiveProxy().getNonProxyHosts(); > This returns a String containing a (usually?)comma-separated list of > nonProxyHosts. > If the jira URL matches one of these hosts, it should not use any proxy of > course ;). > I haven't found a nonProxyHosts concept in commons-httpclient, so it should > be checked in the determineProxy Method of AbstractJiraDownloader. > This is quickly fixed and would be very useful ;) > Thanks in advance -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHANGES-123) Login to remote JIRA with username and password is broken with JIRA version 3.12.3
[ http://jira.codehaus.org/browse/MCHANGES-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Geach updated MCHANGES-123: Attachment: MNG-MCHANGES-60-MCHANGES-123-maven-changes-plugin.patch This patch fixes the authentication test for JIRA version 3.12.3. Tested with 3.11 and 3.12.3 only so there may be further work - I don't know when the format of the Login Screen changed. Note that this patch fixes this issue and MCHANGES-60 > Login to remote JIRA with username and password is broken with JIRA version > 3.12.3 > -- > > Key: MCHANGES-123 > URL: http://jira.codehaus.org/browse/MCHANGES-123 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: jira-report >Affects Versions: 2.0 >Reporter: Andy Geach >Priority: Minor > Attachments: jira3.12.3_logout.html, > MNG-MCHANGES-60-MCHANGES-123-maven-changes-plugin.patch > > > The current test is for the response to be parsed for the String "your > username and password are incorrect". > In version 3.12.3 that phrase no longer appears -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MINSTALL-50) provide property filtering on .pom files placed in local repo
[
http://jira.codehaus.org/browse/MINSTALL-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=145413#action_145413
]
Henrik Brautaset Aronsen commented on MINSTALL-50:
--
MNG-3057 also has a patch for this issue. And it's being worked on in MNG-624.
> provide property filtering on .pom files placed in local repo
> -
>
> Key: MINSTALL-50
> URL: http://jira.codehaus.org/browse/MINSTALL-50
> Project: Maven 2.x Install Plugin
> Issue Type: New Feature
>Affects Versions: 2.3
> Environment: independent
>Reporter: Stefan Armbruster
> Attachments: MNG-maven-install.patch, MNG-maven-install.patch
>
>
> When maven installs an artifact, it's pom is also copied into the artifact's
> directory. Unfortunately, if the pom contains a property reference (e.g.
> ${myprop}), this will not be replaced upon copying the pom file.
> I've created a patch for the install plugin that switches on property
> filtering by setting a mojo parameter "filteringEnabled". Since this defaults
> to "false", backward compatibility is kept 100%.
> Some implementation notes:
> * the dirty work is done in FilteredProjectArtifactMetadata.java, the
> property resolution code has been inspired by ResourcesMojo.
> * I've added a unit test, that replaces ${basedir} with the value of a system
> property.
> * since "svn diff" does not handle binary files,
> src/test/resources/unit/basic-install-test-with-filtering/target/maven-install-test-1.0-SNAPSHOT.jar
> is not included in the patch. This file is the same as
> src/test/resources/unit/basic-install-test/target/maven-install-test-1.0-SNAPSHOT.jar
> Since my knowledge of Maven API is more than limited, there might be a more
> elegant way to provide this feature ... but it works! I'd be happy to see
> this in a future release of maven.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
