[jira] Commented: (MRELEASE-481) prepare goal no longer errors on subversion files
[ http://jira.codehaus.org/browse/MRELEASE-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198810#action_198810 ] Stefan Seelmann commented on MRELEASE-481: -- This seems to be related with http://jira.codehaus.org/browse/SCM-480. > prepare goal no longer errors on subversion files > --- > > Key: MRELEASE-481 > URL: http://jira.codehaus.org/browse/MRELEASE-481 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-8 >Reporter: Paul Hammant > Fix For: 2.0-beta-10 > > > Snow Leopard / Maven 2.2.0 / Svn 1.6.3 (via macports) > release:prepare used to error telling you that you had files not checked in. > It no longer does, or no longer does by default :-( > -ph -- 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: (MRELEASE-504) Check if working copy is up-to-date
Check if working copy is up-to-date --- Key: MRELEASE-504 URL: http://jira.codehaus.org/browse/MRELEASE-504 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Affects Versions: 2.0-beta-9 Reporter: Stefan Seelmann It would be nice if the release:prepare goal could check if the working copy is up-to-date. For svn the local and the remote revision number could be compared. For git the it should also be possible to compare commit IDs. My current problem that release:prepare fails if there is a newer revision in the SVN repository: --- [INFO] Unable to commit files Provider message: The svn command failed. Command output: svn: Commit failed (details follow): svn: File '/firstmodule/trunk/pom.xml' is out of date --- -- 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: (MRELEASE-504) Check if working copy is up-to-date
[ http://jira.codehaus.org/browse/MRELEASE-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198813#action_198813 ] Stefan Seelmann commented on MRELEASE-504: -- As a pre-requirement I think SCM must support remote commands: http://jira.codehaus.org/browse/SCM-381 > Check if working copy is up-to-date > --- > > Key: MRELEASE-504 > URL: http://jira.codehaus.org/browse/MRELEASE-504 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare >Affects Versions: 2.0-beta-9 >Reporter: Stefan Seelmann > > It would be nice if the release:prepare goal could check if the working copy > is up-to-date. > For svn the local and the remote revision number could be compared. > For git the it should also be possible to compare commit IDs. > My current problem that release:prepare fails if there is a newer revision in > the SVN repository: > --- > [INFO] Unable to commit files > Provider message: > The svn command failed. > Command output: > svn: Commit failed (details follow): > svn: File '/firstmodule/trunk/pom.xml' is out of date > --- -- 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-4457) dependency:resolve decides to take older (incompatible) version for transitive dep
[ http://jira.codehaus.org/browse/MNG-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198817#action_198817 ] Paolo Compieta commented on MNG-4457: - 1) ok 2) ok 3) i added C only in the second example, to show a 'normal' (IMO) resolution to 1.3.0; in the first example there were only A and B, and Maven didn't pick the closest I still see this last case as a problem: - A resolves 1.3.0 via B via DepMgmt, 2 hops - B has 1.4.1, 1 hop So, should B win? (case: m2WrongTransitiveDepResolve.zip) If no, i agree to close this issue. > dependency:resolve decides to take older (incompatible) version for > transitive dep > -- > > Key: MNG-4457 > URL: http://jira.codehaus.org/browse/MNG-4457 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.2.1 > Environment: WinXp > Maven 2.0.9/2.2.1 >Reporter: Paolo Compieta >Assignee: Brian Fox > Attachments: m2FairTransitiveDepResolve.zip, > m2WrongTransitiveDepResolve.zip > > > I'll use modules Parent,ModuleA,ModuleB,ModuleEAR and dependency Commons-Net > to explain the case. > Parent specifies commons-net/1.3.0 in dependencyManagement > \- ModuleB declares commons-net/1.4.1 as dependency (overrides version), and > resolves correctly 1.4.1 > \- ModuleA declares ModuleB as dependency (obtaining transitive dep to > commons-net), and resolves *erroneously* 1.3.0 > \- ModuleC (ear) takes in 1.3.0 whilst no module is actually using or > declaring it > I'd expect this case to resolve 1.4.1 or at least to fail the build, because > in this example B is the only one using commons-net (maybe exploiting > 1.4.1-only features), while the final build resolves 1.3.0 (see ModuleA or > ModuleC). > I'm not 100% which is the best policy, but i've got problems (wrong jars, > different behaviours and runtime errors) with this kind silent > down-resolution of version. > Regards, > Paolo -- 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] Issue Comment Edited: (MNG-4457) dependency:resolve decides to take older (incompatible) version for transitive dep
[ http://jira.codehaus.org/browse/MNG-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198817#action_198817 ] Paolo Compieta edited comment on MNG-4457 at 11/20/09 5:14 AM: --- 1) ok 2) ok 3) i added C only in the second example, to show a 'normal' (IMO) resolution to 1.3.0; in the first example there were only A and B, and Maven didn't pick the closest I still see this last case as a problem: - A resolves 1.3.0 via B via DepMgmt, 2 hops - B has 1.4.1, 1 hop So, should B win? (case: m2WrongTransitiveDepResolve.zip) If no, i agree to close this issue. was (Author: paolo.compieta): 1) ok 2) ok 3) i added C only in the second example, to show a 'normal' (IMO) resolution to 1.3.0; in the first example there were only A and B, and Maven didn't pick the closest I still see this last case as a problem: - A resolves 1.3.0 via B via DepMgmt, 2 hops - B has 1.4.1, 1 hop So, should B win? (case: m2WrongTransitiveDepResolve.zip) If no, i agree to close this issue. > dependency:resolve decides to take older (incompatible) version for > transitive dep > -- > > Key: MNG-4457 > URL: http://jira.codehaus.org/browse/MNG-4457 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.2.1 > Environment: WinXp > Maven 2.0.9/2.2.1 >Reporter: Paolo Compieta >Assignee: Brian Fox > Attachments: m2FairTransitiveDepResolve.zip, > m2WrongTransitiveDepResolve.zip > > > I'll use modules Parent,ModuleA,ModuleB,ModuleEAR and dependency Commons-Net > to explain the case. > Parent specifies commons-net/1.3.0 in dependencyManagement > \- ModuleB declares commons-net/1.4.1 as dependency (overrides version), and > resolves correctly 1.4.1 > \- ModuleA declares ModuleB as dependency (obtaining transitive dep to > commons-net), and resolves *erroneously* 1.3.0 > \- ModuleC (ear) takes in 1.3.0 whilst no module is actually using or > declaring it > I'd expect this case to resolve 1.4.1 or at least to fail the build, because > in this example B is the only one using commons-net (maybe exploiting > 1.4.1-only features), while the final build resolves 1.3.0 (see ModuleA or > ModuleC). > I'm not 100% which is the best policy, but i've got problems (wrong jars, > different behaviours and runtime errors) with this kind silent > down-resolution of version. > Regards, > Paolo -- 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: (MENFORCER-86) Add a banRepositories rule
Add a banRepositories rule -- Key: MENFORCER-86 URL: http://jira.codehaus.org/browse/MENFORCER-86 Project: Maven 2.x Enforcer Plugin Issue Type: New Feature Components: Standard Rules Reporter: Stephen Connolly This rule is needed so that we can enforce the "no repositories" requirement of Maven Central Repository. I would see something like (these would be defaults> true false -- 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: (MNG-4459) [regression] Effective settings as visible to plugins contain plain text passwords
[regression] Effective settings as visible to plugins contain plain text
passwords
--
Key: MNG-4459
URL: http://jira.codehaus.org/browse/MNG-4459
Project: Maven 2
Issue Type: Bug
Components: Settings
Affects Versions: 3.0-alpha-4
Reporter: Benjamin Bentmann
When we introduced MNG-553, the passwords were only decrypted at the transport
layer and the {{Settings}} instance kept in memory was kept encrypted. E.g. to
save plugins from accidentally dumping the plain text passwords on the console
or such.
This does currently not hold for 3.0-alpha-4 as
{{org.apache.maven.plugin:maven-help-plugin:2.0:effective-settings}} shows.
--
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: (MSITE-435) Plugin running in batch mode fails to upload site via scp due to failure to resolve credentials from settings.xml
Plugin running in batch mode fails to upload site via scp due to failure to
resolve credentials from settings.xml
-
Key: MSITE-435
URL: http://jira.codehaus.org/browse/MSITE-435
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 2.0-beta-7
Environment: software platform
Reporter: Abraham Kiggundu
When the site:deploy plugin is ran in interactive mode it prompts you for your
username and password. On a Hudson build server we run maven in batch mode.
The command line below:
mvn site:deploy --batch-mode
will always fail the build due to the following error
Cannot connect. Reason: Auth cancel
the only temporary workaround to fix this at the moment is to have the user
credentials in your pom as below
docs
Release Documentation Website
scp://[USER]:[passwo...@[machine]/{location uri}/
In contradiction the distribution management works fine with the following pom
setup
id
the id
scp://[us...@[machine]/{location uri}/
and never prompts you for user credentials always grabing them from the
settings .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
[jira] Closed: (MNG-4459) [regression] Effective settings as visible to plugins contain plain text passwords
[
http://jira.codehaus.org/browse/MNG-4459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4459.
--
Resolution: Fixed
Fix Version/s: 3.0-alpha-5
Assignee: Benjamin Bentmann
Fixed in [r882580|http://svn.apache.org/viewvc?view=revision&revision=882580].
> [regression] Effective settings as visible to plugins contain plain text
> passwords
> --
>
> Key: MNG-4459
> URL: http://jira.codehaus.org/browse/MNG-4459
> Project: Maven 2
> Issue Type: Bug
> Components: Settings
>Affects Versions: 3.0-alpha-4
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-5
>
>
> When we introduced MNG-553, the passwords were only decrypted at the
> transport layer and the {{Settings}} instance kept in memory was kept
> encrypted. E.g. to save plugins from accidentally dumping the plain text
> passwords on the console or such.
> This does currently not hold for 3.0-alpha-4 as
> {{org.apache.maven.plugin:maven-help-plugin:2.0:effective-settings}} shows.
--
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: (MSITE-435) Plugin running in batch mode fails to upload site via scp due to failure to resolve credentials from settings.xml
[
http://jira.codehaus.org/browse/MSITE-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abraham Kiggundu closed MSITE-435.
--
Resolution: Not A Bug
Issue resolved by further investigation as per comments
> Plugin running in batch mode fails to upload site via scp due to failure to
> resolve credentials from settings.xml
> -
>
> Key: MSITE-435
> URL: http://jira.codehaus.org/browse/MSITE-435
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 2.0-beta-7
> Environment: software platform
>Reporter: Abraham Kiggundu
>
> When the site:deploy plugin is ran in interactive mode it prompts you for
> your username and password. On a Hudson build server we run maven in batch
> mode.
> The command line below:
> mvn site:deploy --batch-mode
> will always fail the build due to the following error
> Cannot connect. Reason: Auth cancel
> the only temporary workaround to fix this at the moment is to have the user
> credentials in your pom as below
>
> docs
> Release Documentation Website
> scp://[USER]:[passwo...@[machine]/{location uri}/
>
> In contradiction the distribution management works fine with the following
> pom setup
>
>
> id
> the id
> scp://[us...@[machine]/{location uri}/
>
>
> and never prompts you for user credentials always grabing them from the
> settings .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
[jira] Commented: (MSITE-435) Plugin running in batch mode fails to upload site via scp due to failure to resolve credentials from settings.xml
[
http://jira.codehaus.org/browse/MSITE-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198838#action_198838
]
Abraham Kiggundu commented on MSITE-435:
I took a deeper look into this and realised the server in my
settings.xml was not matching the site value. Once I corrected this
all was fine without placing the credentials in the url.
> Plugin running in batch mode fails to upload site via scp due to failure to
> resolve credentials from settings.xml
> -
>
> Key: MSITE-435
> URL: http://jira.codehaus.org/browse/MSITE-435
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 2.0-beta-7
> Environment: software platform
>Reporter: Abraham Kiggundu
>
> When the site:deploy plugin is ran in interactive mode it prompts you for
> your username and password. On a Hudson build server we run maven in batch
> mode.
> The command line below:
> mvn site:deploy --batch-mode
> will always fail the build due to the following error
> Cannot connect. Reason: Auth cancel
> the only temporary workaround to fix this at the moment is to have the user
> credentials in your pom as below
>
> docs
> Release Documentation Website
> scp://[USER]:[passwo...@[machine]/{location uri}/
>
> In contradiction the distribution management works fine with the following
> pom setup
>
>
> id
> the id
> scp://[us...@[machine]/{location uri}/
>
>
> and never prompts you for user credentials always grabing them from the
> settings .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
[jira] Created: (MNG-4460) NPE from the classworlds launcher while trying to use custom component.xml
NPE from the classworlds launcher while trying to use custom component.xml -- Key: MNG-4460 URL: http://jira.codehaus.org/browse/MNG-4460 Project: Maven 2 Issue Type: Bug Affects Versions: 2.2.1 Environment: Windows XP Reporter: Liz Sommers Attachments: build.log, components.xml, ProjectDateMojo.java All of this code works with Maven 2.0.8-2.0.9 I have included the components.xml file i am using and the first mojo it calls so that you can see that it is working correctly. Resources never gets executed. I am not sure if the problem is with the launcher or with the resource plugin, but it should be obvious to you if you look at the build.log I am putting the pom here because there isn't another attachement available http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 mil.disa.packages FAKE-PACKAGE package 4.2.0.2-RC03 FAKE-PACKAGE http://maven.apache.org mil.disa.ap.segments packageParent 1.8 4.2.0.2 FAKE FAKE scm:svn:http://svnsrv/svn/SEGS/PACKAGES/FAKE-package/trunk scm:svn:http://svnsrv/svn/SEGS/PACKAGES/FAKE-package/trunk http://svnsrv/svn/SEGS/PACKAGES/FAKE-package/trunk **/pkginfo **/ReleaseNotes FAKE **/pkginfo **/ReleaseNotes FAKE true -- 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-4460) NPE from the classworlds launcher while trying to use custom component.xml
[
http://jira.codehaus.org/browse/MNG-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4460.
--
Resolution: Not A Bug
Assignee: Benjamin Bentmann
>From the mojo:
{code:java}
Date now = new Date();
projectProperties.put("project.date",now);
{code}
Putting non-string objects into properties violates the contract of
[java.util.Properties|http://java.sun.com/javase/6/docs/api/java/util/Properties.html].
> NPE from the classworlds launcher while trying to use custom component.xml
> --
>
> Key: MNG-4460
> URL: http://jira.codehaus.org/browse/MNG-4460
> Project: Maven 2
> Issue Type: Bug
>Affects Versions: 2.2.1
> Environment: Windows XP
>Reporter: Liz Sommers
>Assignee: Benjamin Bentmann
> Attachments: build.log, components.xml, ProjectDateMojo.java
>
>
> All of this code works with Maven 2.0.8-2.0.9
> I have included the components.xml file i am using and the first mojo it
> calls so that you can see that it is working correctly. Resources never gets
> executed.
> I am not sure if the problem is with the launcher or with the resource
> plugin, but it should be obvious to you if you look at the build.log
> I am putting the pom here because there isn't another attachement available
>
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> 4.0.0
> mil.disa.packages
> FAKE-PACKAGE
> package
> 4.2.0.2-RC03
> FAKE-PACKAGE
> http://maven.apache.org
>
>
> mil.disa.ap.segments
> packageParent
> 1.8
>
>
>
>4.2.0.2
> FAKE
> FAKE
>
>
>
> scm:svn:http://svnsrv/svn/SEGS/PACKAGES/FAKE-package/trunk
>
> scm:svn:http://svnsrv/svn/SEGS/PACKAGES/FAKE-package/trunk
> http://svnsrv/svn/SEGS/PACKAGES/FAKE-package/trunk
>
>
>
>
>
>
> **/pkginfo
> **/ReleaseNotes
>
> FAKE
>
>
>
> **/pkginfo
> **/ReleaseNotes
>
> FAKE
> true
>
>
>
>
>
>
--
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: (MNG-4461) [regression] No transfer progress during artifact deployment
[regression] No transfer progress during artifact deployment
Key: MNG-4461
URL: http://jira.codehaus.org/browse/MNG-4461
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories, Logging
Affects Versions: 3.0-alpha-4
Reporter: Benjamin Bentmann
Priority: Minor
As reported by Juven, we get no transfer progress here:
{noformat}
[INFO] --- maven-deploy-plugin:2.4:deploy (default-deploy) @ test ---
[INFO] Retrieving previous metadata from maven-core-it
[INFO] Uploading repository metadata for: 'artifact
org.apache.maven.its.mng:test'
[INFO] Uploading project information for test 0.1
{noformat}
compared to Maven 2.x
{noformat}
[INFO] [deploy:deploy]
Uploading: file:///M:\z/repo/org/apache/maven/its/mng/test/0.1/test-0.1.jar
1K uploaded (test-0.1.jar)
[INFO] Retrieving previous metadata from maven-core-it
[INFO] Uploading repository metadata for: 'artifact
org.apache.maven.its.mng:test'
[INFO] Uploading project information for test 0.1
{noformat}
--
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-4461) [regression] No transfer progress during artifact deployment
[
http://jira.codehaus.org/browse/MNG-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4461.
--
Resolution: Fixed
Fix Version/s: 3.0-alpha-5
Assignee: Benjamin Bentmann
Fixed in [r882668|http://svn.apache.org/viewvc?view=revision&revision=882668].
> [regression] No transfer progress during artifact deployment
>
>
> Key: MNG-4461
> URL: http://jira.codehaus.org/browse/MNG-4461
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories, Logging
>Affects Versions: 3.0-alpha-4
>Reporter: Benjamin Bentmann
>Assignee: Benjamin Bentmann
>Priority: Minor
> Fix For: 3.0-alpha-5
>
>
> As reported by Juven, we get no transfer progress here:
> {noformat}
> [INFO] --- maven-deploy-plugin:2.4:deploy (default-deploy) @ test ---
> [INFO] Retrieving previous metadata from maven-core-it
> [INFO] Uploading repository metadata for: 'artifact
> org.apache.maven.its.mng:test'
> [INFO] Uploading project information for test 0.1
> {noformat}
> compared to Maven 2.x
> {noformat}
> [INFO] [deploy:deploy]
> Uploading: file:///M:\z/repo/org/apache/maven/its/mng/test/0.1/test-0.1.jar
> 1K uploaded (test-0.1.jar)
> [INFO] Retrieving previous metadata from maven-core-it
> [INFO] Uploading repository metadata for: 'artifact
> org.apache.maven.its.mng:test'
> [INFO] Uploading project information for test 0.1
> {noformat}
--
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: (MNG-4456) Deprecate fully qualified pathnames in system path
[
http://jira.codehaus.org/browse/MNG-4456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4456:
---
Affects Version/s: 2.2.1
> Deprecate fully qualified pathnames in system path
> --
>
> Key: MNG-4456
> URL: http://jira.codehaus.org/browse/MNG-4456
> Project: Maven 2
> Issue Type: Improvement
>Affects Versions: 2.2.1
> Environment: Any.
>Reporter: Jim Showalter
>Priority: Minor
>
> You could output a deprecation warning whenever a fully qualified path is
> specified, but not warn if the path starts with a variable.
> For example, this would generate no warning:
>
>com.sun
>tools
>1.6.0
>system
>${java.home}/../lib/tools.jar
>
> but this would:
>
>yuck
>ugh
>4.2.8
>system
>C:/dumb/way/to/set/up/maven/dependency
>
> That way at least users are warned when they're doing something dumb, and if
> they change to the variable-based form, they stand a fighting chance of
> having portable builds.
--
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-4456) Deprecate fully qualified pathnames in system path
[
http://jira.codehaus.org/browse/MNG-4456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4456.
--
Resolution: Fixed
Fix Version/s: 3.0-alpha-5
Assignee: Benjamin Bentmann
Added warning in
[r882677|http://svn.apache.org/viewvc?view=revision&revision=882677].
> Deprecate fully qualified pathnames in system path
> --
>
> Key: MNG-4456
> URL: http://jira.codehaus.org/browse/MNG-4456
> Project: Maven 2
> Issue Type: Improvement
>Affects Versions: 2.2.1
> Environment: Any.
>Reporter: Jim Showalter
>Assignee: Benjamin Bentmann
>Priority: Minor
> Fix For: 3.0-alpha-5
>
>
> You could output a deprecation warning whenever a fully qualified path is
> specified, but not warn if the path starts with a variable.
> For example, this would generate no warning:
>
>com.sun
>tools
>1.6.0
>system
>${java.home}/../lib/tools.jar
>
> but this would:
>
>yuck
>ugh
>4.2.8
>system
>C:/dumb/way/to/set/up/maven/dependency
>
> That way at least users are warned when they're doing something dumb, and if
> they change to the variable-based form, they stand a fighting chance of
> having portable builds.
--
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-180) Update to Maven Reporting Impl 2.0.4.3
[ http://jira.codehaus.org/browse/MCHANGES-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MCHANGES-180: - Summary: Update to Maven Reporting Impl 2.0.4.3 (was: Update to Maven Reporting Impl 2.0.4.2) > Update to Maven Reporting Impl 2.0.4.3 > -- > > Key: MCHANGES-180 > URL: http://jira.codehaus.org/browse/MCHANGES-180 > Project: Maven 2.x Changes Plugin > Issue Type: Task >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > Fix For: 2.2 > > > To keep the Doxia-related dependencies in sync Maven Reporting Impl should be > updated to version 2.0.4.2. That version uses Doxia 1.0. -- 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: (MCHANGES-180) Update to Maven Reporting Impl 2.0.4.2
[ http://jira.codehaus.org/browse/MCHANGES-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg reopened MCHANGES-180: -- > Update to Maven Reporting Impl 2.0.4.2 > -- > > Key: MCHANGES-180 > URL: http://jira.codehaus.org/browse/MCHANGES-180 > Project: Maven 2.x Changes Plugin > Issue Type: Task >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > Fix For: 2.2 > > > To keep the Doxia-related dependencies in sync Maven Reporting Impl should be > updated to version 2.0.4.2. That version uses Doxia 1.0. -- 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: (MCHANGES-180) Update to Maven Reporting Impl 2.0.4.3
[ http://jira.codehaus.org/browse/MCHANGES-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-180. Resolution: Fixed Updated to 2.0.4.3 in [r882720|http://svn.apache.org/viewvc?rev=882720&view=rev]. > Update to Maven Reporting Impl 2.0.4.3 > -- > > Key: MCHANGES-180 > URL: http://jira.codehaus.org/browse/MCHANGES-180 > Project: Maven 2.x Changes Plugin > Issue Type: Task >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > Fix For: 2.2 > > > To keep the Doxia-related dependencies in sync Maven Reporting Impl should be > updated to version 2.0.4.2. That version uses Doxia 1.0. -- 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: (MNG-4462) Forbid fully qualified pathnames in system path
Forbid fully qualified pathnames in system path --- Key: MNG-4462 URL: http://jira.codehaus.org/browse/MNG-4462 Project: Maven 2 Issue Type: Improvement Affects Versions: 3.0 Reporter: Paul Benedict This issue is the companion of MNG-4456 to be completed, if desired, sometime in future releases. -- 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
