The following comment has been added to this issue:
Author: Marc Portier
Created: Tue, 14 Oct 2003 5:04 PM
Body:
Some additional comments after some more investigation.
The cause of the problem seems to be that if no ${maven.build.dir} is set, that it
then gets set to the ABSOLUTE PATH pointing to ${basedir}/target
However if people _are_ setting the maven.build.dir then they typically do so by
providing a relative path: -Dmaven.build.dir=build
(or by setting it into project.properties which should work regardless of in which
directory location people have checked out the project --> ie relative!)
Asserting the above: things just work if the absolute path for the property is
provided: -Dmaven.build.dir=c:/.../myproject/build
I haven't read any documents stating that the property needs to be absolute though and
I would consider it very unlogic if that requirement would be formalised. (see use
case above)
Equally I would find it unlogic that the contract of the <deploy:artifact> is such
that its @artifact is required to be a relative path.
A similar reasoning is also suggested by the other comments in this bug which advocate
the removal of the path-stringmanipulating code in the jar:deploy* goals
Trying that out however on my w2k with cygwin the system exec to scp breaks on the
fact that scp looks at the c:/path as a location /path on the host named 'c'
(So it seems that portion of the code is kinda welcome after all :-))
At this stage it looks to me as if the fix should be inside the deploy:artifact
however:
- it should not assume that its @artifact was made a relative path IMHO
- since it is calling the 'scp' it should be the one covering up for the limitations
of its delegate
- only then indeed the fix will be there also for war:deploy (and others)
If time allows I'll read up on how the deploy:artifact works and report back with more
suggestions. (but don't wait for it if you can beat me to it since all my
understanding of maven is pretty new)
---------------------------------------------------------------------
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-373
Here is an overview of the issue:
---------------------------------------------------------------------
Key: MAVEN-373
Summary: Incorrect arguments in jar:deploy and jar:deploy-snapshot
Type: Bug
Status: Unassigned
Priority: Major
Time Spent: Unknown
Remaining: Unknown
Project: maven
Components:
plugin-java
Fix Fors:
1.1
Versions:
1.0-beta-9
Assignee:
Reporter: Aslak Hellesoy
Created: Fri, 4 Apr 2003 6:31 AM
Updated: Mon, 4 Aug 2003 11:26 AM
Description:
The jar:deploy and jar:deploy-snapshot goals are doing some fancy and unnecessary
string manipulations to find the relative file name of the jar file to deploy.
This is unnecessary (the file name of the jars can be absolute), and furhter, it
doesn't work when ${maven.build.dir} is overridden to point outside the project.
Further, the jar:deploy-snapshot could just call the jar:deploy goal (and avoid
copy-paste of identical logic).
The mentioned goals should be simplified as follows:
<!-- ================================================================== -->
<!-- D E P L O Y S N A P S H O T -->
<!-- ================================================================== -->
<goal
name="jar:deploy-snapshot"
description="Deploy a snapshot jar to the remote repository">
<m:user-check user="${maven.username}"/>
<attainGoal name="jar:snapshot"/>
<attainGoal name="jar:deploy"/>
</goal>
<!-- ================================================================== -->
<!-- D E P L O Y J A R -->
<!-- ================================================================== -->
<goal
name="jar:deploy"
description="Deploy a jar to the remote repository">
<m:user-check user="${maven.username}"/>
<attainGoal name="java:jar"/>
<ant:property name="maven.jar.to.deploy" value="${maven.final.name}.jar"/>
<deploy:artifact
artifact="${maven.final.name}.jar"
type="jars"
assureDirectoryCommand="mkdir -p"
siteCommand="cd @deployDirectory@; chmod g+w ${maven.jar.to.deploy}; chgrp maven
${maven.jar.to.deploy}"
/>
</goal>
---------------------------------------------------------------------
JIRA INFORMATION:
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
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
