[continuum build - FAILED - update] Tue Dec 6 09:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051206.09.txt
[continuum build - FAILED - update] Tue Dec 6 09:30:01 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051206.093001.txt
[continuum build - FAILED - update] Tue Dec 6 15:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051206.153000.txt
[continuum build - SUCCESS - update] Tue Dec 6 17:00:00 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20051206.17.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051206.17.txt
[continuum build - FAILED - update] Wed Dec 7 02:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051207.023000.txt
[continuum build - FAILED - update] Wed Dec 7 03:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051207.030001.txt
[continuum build - FAILED - update] Wed Dec 7 04:00:01 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051207.040001.txt
[continuum build - FAILED - update] Wed Dec 7 04:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051207.043000.txt
[continuum build - FAILED - update] Wed Dec 7 05:00:01 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051207.050001.txt
[continuum build - FAILED - update] Wed Dec 7 06:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051207.063001.txt
[continuum build - FAILED - update] Wed Dec 7 07:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051207.07.txt
[continuum build - FAILED - update] Wed Dec 7 07:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051207.073000.txt
Re: [vote] Release SCM 1.0-beta-2
Wim,
I think you can safely assume that on
windows: viewstore is at \\${hostname}\viewstore
unix viewstore is at /viewstore
Those should be the default value if view store value are not found any where.
-D
On 12/5/05, Wim Deblauwe [EMAIL PROTECTED] wrote:
Yes, it is quite simple:clearcase-settings viewstore\\mycomputer\viewstore/viewstore
/clearcase-settingsI would read this from ~/.scm/clearcase-settings.xmlIf you could help me underway, it would be very much appriciated. regards,Wim
2005/12/5, Emmanuel Venisse [EMAIL PROTECTED]:
Do you have a sample of a xml file you want to read?EmmanuelWim Deblauwe a écrit :
ClearCase support is ok for maven-release-plugin, but not for Continuum. I can make it work tomorrow for Continuum by making the viewstore a plugin parameter and not being read from a settings xml file (I will
need to learn Modello first). regards, Wim 2005/12/5, John Casey
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1 Hi everyone, I'd like to release 1.0-beta-2 of Maven SCM. It looks like we've got ClearCase and Perforce support now, and IIRC there is some fixes for
update URL formatting, etc. At any rate, it'd be nice to be able to include this in the next Maven and Continuum releases, which we're hoping to push out this week. I know it's sort of short notice, but I'd like to get a vote finalized
in the next 48 hours, to make the cut for Maven/Continuum releases. Here's my +1. Thanks, John -BEGIN PGP SIGNATURE- Version: GnuPG
v1.2.6 (GNU/Linux) iD4DBQFDlIW8K3h2CZwO/4URAmHPAJjIjw0hRHsH4M1vh4pIdVNvOkX5AJ9dvp+C QIs9+8agaMZcs+uqXaacjQ== =qiPO -END PGP SIGNATURE-
Re: [vote] Release SCM 1.0-beta-2
Dan,I'm afraid not, with us, it is at \\${hostname}\cc_vws1 :(regards,Wim2005/12/6, dan tran [EMAIL PROTECTED]:
Wim,
I think you can safely assume that on
windows: viewstore is at \\${hostname}\viewstore
unix viewstore is at /viewstore
Those should be the default value if view store value are not found any where.
-D
On 12/5/05, Wim Deblauwe [EMAIL PROTECTED]
wrote:
Yes, it is quite simple:clearcase-settings viewstore\\mycomputer\viewstore/viewstore
/clearcase-settingsI would read this from ~/.scm/clearcase-settings.xmlIf you could help me underway, it would be very much appriciated. regards,Wim
2005/12/5, Emmanuel Venisse [EMAIL PROTECTED]
:
Do you have a sample of a xml file you want to read?EmmanuelWim Deblauwe a écrit :
ClearCase support is ok for maven-release-plugin, but not for Continuum. I can make it work tomorrow for Continuum by making the viewstore a plugin parameter and not being read from a settings xml file (I will
need to learn Modello first). regards, Wim 2005/12/5, John Casey
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
: -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1 Hi everyone, I'd like to release 1.0-beta-2 of Maven SCM. It looks like we've got ClearCase and Perforce support now, and IIRC there is some fixes for
update URL formatting, etc. At any rate, it'd be nice to be able to include this in the next Maven and Continuum releases, which we're hoping to push out this week. I know it's sort of short notice, but I'd like to get a vote finalized
in the next 48 hours, to make the cut for Maven/Continuum releases. Here's my +1. Thanks, John -BEGIN PGP SIGNATURE- Version: GnuPG
v1.2.6 (GNU/Linux) iD4DBQFDlIW8K3h2CZwO/4URAmHPAJjIjw0hRHsH4M1vh4pIdVNvOkX5AJ9dvp+C QIs9+8agaMZcs+uqXaacjQ== =qiPO -END PGP SIGNATURE-
Re: [vote] Release SCM 1.0-beta-2
Is it possible in windows to share the same folder as 2 different names? Because currently my viewstore is at c:\viewstore1, but is shared as cc_vws1. I cannot change this, because this is how ClearCase is installed on our machines, but if there would be a way to also share this folder as viewstore, then that would solve the problem.
Wim2005/12/6, Wim Deblauwe [EMAIL PROTECTED]:
Dan,I'm afraid not, with us, it is at \\${hostname}\cc_vws1 :(regards,Wim2005/12/6, dan tran
[EMAIL PROTECTED]
:
Wim,
I think you can safely assume that on
windows: viewstore is at \\${hostname}\viewstore
unix viewstore is at /viewstore
Those should be the default value if view store value are not found any where.
-D
On 12/5/05, Wim Deblauwe [EMAIL PROTECTED]
wrote:
Yes, it is quite simple:clearcase-settings viewstore\\mycomputer\viewstore/viewstore
/clearcase-settingsI would read this from ~/.scm/clearcase-settings.xmlIf you could help me underway, it would be very much appriciated. regards,Wim
2005/12/5, Emmanuel Venisse [EMAIL PROTECTED]
:
Do you have a sample of a xml file you want to read?EmmanuelWim Deblauwe a écrit :
ClearCase support is ok for maven-release-plugin, but not for Continuum. I can make it work tomorrow for Continuum by making the viewstore a plugin parameter and not being read from a settings xml file (I will
need to learn Modello first). regards, Wim 2005/12/5, John Casey
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
: -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1 Hi everyone, I'd like to release 1.0-beta-2 of Maven SCM. It looks like we've got ClearCase and Perforce support now, and IIRC there is some fixes for
update URL formatting, etc. At any rate, it'd be nice to be able to include this in the next Maven and Continuum releases, which we're hoping to push out this week. I know it's sort of short notice, but I'd like to get a vote finalized
in the next 48 hours, to make the cut for Maven/Continuum releases. Here's my +1. Thanks, John -BEGIN PGP SIGNATURE- Version: GnuPG
v1.2.6 (GNU/Linux) iD4DBQFDlIW8K3h2CZwO/4URAmHPAJjIjw0hRHsH4M1vh4pIdVNvOkX5AJ9dvp+C QIs9+8agaMZcs+uqXaacjQ== =qiPO -END PGP SIGNATURE-
Re: [vote] Release SCM 1.0-beta-2
I committed the generator. Source files are generated in target/generated-sources when you run mvn clean install Emmanuel Wim Deblauwe a écrit : Yes, it is quite simple: clearcase-settings viewstore\\mycomputer\viewstore/viewstore /clearcase-settings I would read this from ~/.scm/clearcase-settings.xml If you could help me underway, it would be very much appriciated. regards, Wim 2005/12/5, Emmanuel Venisse [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Do you have a sample of a xml file you want to read? Emmanuel Wim Deblauwe a écrit : ClearCase support is ok for maven-release-plugin, but not for Continuum. I can make it work tomorrow for Continuum by making the viewstore a plugin parameter and not being read from a settings xml file (I will need to learn Modello first). regards, Wim 2005/12/5, John Casey [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, I'd like to release 1.0-beta-2 of Maven SCM. It looks like we've got ClearCase and Perforce support now, and IIRC there is some fixes for update URL formatting, etc. At any rate, it'd be nice to be able to include this in the next Maven and Continuum releases, which we're hoping to push out this week. I know it's sort of short notice, but I'd like to get a vote finalized in the next 48 hours, to make the cut for Maven/Continuum releases. Here's my +1. Thanks, John -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD4DBQFDlIW8K3h2CZwO/4URAmHPAJjIjw0hRHsH4M1vh4pIdVNvOkX5AJ9dvp+C QIs9+8agaMZcs+uqXaacjQ== =qiPO -END PGP SIGNATURE-
Re: [vote] Release SCM 1.0-beta-2
in your case, you'll use clearcase-settings.xml, and if this file doesn't exist and you don't find
info in scm url, you can use dan proposal as default value.
Emmanuel
Wim Deblauwe a écrit :
Dan,
I'm afraid not, with us, it is at \\${hostname}\cc_vws1 :(
regards,
Wim
2005/12/6, dan tran [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:
Wim,
I think you can safely assume that on
windows: viewstore is at \\${hostname}\viewstore
unix viewstore is at /viewstore
Those should be the default value if view store value are not found
any where.
-D
On 12/5/05, *Wim Deblauwe* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Yes, it is quite simple:
clearcase-settings
viewstore\\mycomputer\viewstore/viewstore
/clearcase-settings
I would read this from ~/.scm/clearcase-settings.xml
If you could help me underway, it would be very much appriciated.
regards,
Wim
2005/12/5, Emmanuel Venisse [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Do you have a sample of a xml file you want to read?
Emmanuel
Wim Deblauwe a écrit :
ClearCase support is ok for maven-release-plugin, but not
for Continuum.
I can make it work tomorrow for Continuum by making the
viewstore a
plugin parameter and not being read from a settings xml
file (I will
need to learn Modello first).
regards,
Wim
2005/12/5, John Casey [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
I'd like to release 1.0-beta-2 of Maven SCM. It looks
like we've got
ClearCase and Perforce support now, and IIRC there is
some fixes for
update URL formatting, etc. At any rate, it'd be nice
to be able to
include this in the next Maven and Continuum releases,
which we're
hoping to push out this week.
I know it's sort of short notice, but I'd like to get a
vote finalized
in the next 48 hours, to make the cut for
Maven/Continuum releases.
Here's my +1.
Thanks,
John
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD4DBQFDlIW8K3h2CZwO/4URAmHPAJjIjw0hRHsH4M1vh4pIdVNvOkX5AJ9dvp+C
QIs9+8agaMZcs+uqXaacjQ==
=qiPO
-END PGP SIGNATURE-
Re: [vote] Release SCM 1.0-beta-2
I don't think.
Emmanuel
Wim Deblauwe a écrit :
Is it possible in windows to share the same folder as 2 different names?
Because currently my viewstore is at c:\viewstore1, but is shared as
cc_vws1. I cannot change this, because this is how ClearCase is
installed on our machines, but if there would be a way to also share
this folder as viewstore, then that would solve the problem.
Wim
2005/12/6, Wim Deblauwe [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Dan,
I'm afraid not, with us, it is at \\${hostname}\cc_vws1 :(
regards,
Wim
2005/12/6, dan tran [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]:
Wim,
I think you can safely assume that on
windows: viewstore is at \\${hostname}\viewstore
unix viewstore is at /viewstore
Those should be the default value if view store value are not
found any where.
-D
On 12/5/05, *Wim Deblauwe* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Yes, it is quite simple:
clearcase-settings
viewstore\\mycomputer\viewstore/viewstore
/clearcase-settings
I would read this from ~/.scm/clearcase-settings.xml
If you could help me underway, it would be very much
appriciated.
regards,
Wim
2005/12/5, Emmanuel Venisse [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Do you have a sample of a xml file you want to read?
Emmanuel
Wim Deblauwe a écrit :
ClearCase support is ok for maven-release-plugin, but
not for Continuum.
I can make it work tomorrow for Continuum by making
the viewstore a
plugin parameter and not being read from a settings
xml file (I will
need to learn Modello first).
regards,
Wim
2005/12/5, John Casey [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi everyone,
I'd like to release 1.0-beta-2 of Maven SCM. It
looks like we've got
ClearCase and Perforce support now, and IIRC there
is some fixes for
update URL formatting, etc. At any rate, it'd be
nice to be able to
include this in the next Maven and Continuum
releases, which we're
hoping to push out this week.
I know it's sort of short notice, but I'd like to
get a vote finalized
in the next 48 hours, to make the cut for
Maven/Continuum releases.
Here's my +1.
Thanks,
John
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
iD4DBQFDlIW8K3h2CZwO/4URAmHPAJjIjw0hRHsH4M1vh4pIdVNvOkX5AJ9dvp+C
QIs9+8agaMZcs+uqXaacjQ==
=qiPO
-END PGP SIGNATURE-
Re: [vote] Release SCM 1.0-beta-2
2005/12/6, Emmanuel Venisse [EMAIL PROTECTED]: I committed the generator.Source files are generated in target/generated-sources when you run mvn clean installEmmanuelThanks! I tried that and I get the generated source files. How should I proceed? Do I copy the generated source files under the source tree and use them from there? Or is the idea to regenerate them every time and how do I use them then? Do I need to include the generated-sources directory then in my compilationpath somehow? regards,Wim
Re: [vote] Release SCM 1.0-beta-2
It's done: http://jira.codehaus.org/browse/SCM-100I hope we can have some beta-testers to test this out.regards,Wim 2005/12/6, Wim Deblauwe [EMAIL PROTECTED]: 2005/12/6, Emmanuel Venisse [EMAIL PROTECTED] : I committed the generator.Source files are generated in target/generated-sources when you run mvn clean installEmmanuelThanks! I tried that and I get the generated source files. How should I proceed? Do I copy the generated source files under the source tree and use them from there? Or is the idea to regenerate them every time and how do I use them then? Do I need to include the generated-sources directory then in my compilationpath somehow? regards,Wim
[jira] Created: (SCM-97) Implement executable changelog command
Implement executable changelog command -- Key: SCM-97 URL: http://jira.codehaus.org/browse/SCM-97 Project: Maven SCM Type: Bug Components: maven-scm-provider-perforce Versions: 1.0-beta-2 Reporter: mike perham Fix For: 1.0-beta-2 Attachments: changelog.txt The changelog command is more of a stub than I realized. This patch adds code to: 1) Execute the actual command (!) 2) Handle non-standard directory structure better by relying on the working directory rather than the repositoryPath -- 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: (SCM-99) changelog is emtpy when using startDate is assigned
[ http://jira.codehaus.org/browse/SCM-99?page=all ]
Dan Tran updated SCM-99:
Attachment: SCM-99.patch
patch + test
changelog is emtpy when using startDate is assigned
---
Key: SCM-99
URL: http://jira.codehaus.org/browse/SCM-99
Project: Maven SCM
Type: Bug
Components: maven-scm-provider-starteam
Environment: starteam, xp
Reporter: Dan Tran
Attachments: SCM-99.patch
Current implementation uses -cfgd ${startDate} option to retreive changelog
from startDate to latest change log.
However, -cfgd is not intended to be used this way. It acutally returns the
reverse which are the changelogs from the current view creation date to the
date assigned to -cfgd.
Therefore, the only solution is to retreive all changelogs and filter by
start and end dates.
--
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: (SCM-98) Add scm:changelog goal
[ http://jira.codehaus.org/browse/SCM-98?page=all ] Dan Tran updated SCM-98: Attachment: SCM-98.patch patch, manually tested with svn and starteam providers Add scm:changelog goal -- Key: SCM-98 URL: http://jira.codehaus.org/browse/SCM-98 Project: Maven SCM Type: New Feature Components: maven-plugin Versions: 1.0-beta-1 Environment: starteam, svn, xp Reporter: Dan Tran Fix For: 1.0-beta-2 Attachments: SCM-98.patch This additional mojo dumps the contents of changelog command ( ChangeSet) to stdout. It is for testing changelog command only. -- 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-98) Add scm:changelog goal
Add scm:changelog goal -- Key: SCM-98 URL: http://jira.codehaus.org/browse/SCM-98 Project: Maven SCM Type: New Feature Components: maven-plugin Versions: 1.0-beta-1 Environment: starteam, svn, xp Reporter: Dan Tran Fix For: 1.0-beta-2 Attachments: SCM-98.patch This additional mojo dumps the contents of changelog command ( ChangeSet) to stdout. It is for testing changelog command only. -- 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-99) changelog is emtpy when using startDate is assigned
changelog is emtpy when using startDate is assigned
---
Key: SCM-99
URL: http://jira.codehaus.org/browse/SCM-99
Project: Maven SCM
Type: Bug
Components: maven-scm-provider-starteam
Environment: starteam, xp
Reporter: Dan Tran
Attachments: SCM-99.patch
Current implementation uses -cfgd ${startDate} option to retreive changelog
from startDate to latest change log.
However, -cfgd is not intended to be used this way. It acutally returns the
reverse which are the changelogs from the current view creation date to the
date assigned to -cfgd.
Therefore, the only solution is to retreive all changelogs and filter by start
and end dates.
--
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-100) [patch] ClearCase checkout and update commands
[patch] ClearCase checkout and update commands -- Key: SCM-100 URL: http://jira.codehaus.org/browse/SCM-100 Project: Maven SCM Type: Improvement Components: maven-scm-provider-clearcase Reporter: Wim Deblauwe Fix For: 1.0-beta-2 Attachments: clearcase-checkout.patch This patch implements the checkout and update commands for ClearCase. Note that currently checkout from a label is not supported (as done by the maven-release-plugin), but the checkout should work in combination with Continuum. The patch misses 1 unit test for a consumer and also an update to the site, but I will add this later. -- 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-100) [patch] ClearCase checkout and update commands
[ http://jira.codehaus.org/browse/SCM-100?page=all ] Emmanuel Venisse closed SCM-100: Assign To: Emmanuel Venisse Resolution: Fixed Fix Version: 1.0-beta-2 Applied. [patch] ClearCase checkout and update commands -- Key: SCM-100 URL: http://jira.codehaus.org/browse/SCM-100 Project: Maven SCM Type: Improvement Components: maven-scm-provider-clearcase Reporter: Wim Deblauwe Assignee: Emmanuel Venisse Fix For: 1.0-beta-2 Attachments: clearcase-checkout.patch This patch implements the checkout and update commands for ClearCase. Note that currently checkout from a label is not supported (as done by the maven-release-plugin), but the checkout should work in combination with Continuum. The patch misses 1 unit test for a consumer and also an update to the site, but I will add this later. -- 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: [vote] Release SCM 1.0-beta-2
yes2005/12/6, Emmanuel Venisse [EMAIL PROTECTED]: update command works too with continuum?EmmanuelWim Deblauwe a écrit : It's done: http://jira.codehaus.org/browse/SCM-100 I hope we can have some beta-testers to test this out. regards, Wim 2005/12/6, Wim Deblauwe [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] : 2005/12/6, Emmanuel Venisse [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] : I committed the generator. Source files are generated in target/generated-sources when you run mvn clean install Emmanuel Thanks! I tried that and I get the generated source files. How should I proceed? Do I copy the generated source files under the source tree and use them from there? Or is the idea to regenerate them every time and how do I use them then? Do I need to include the generated-sources directory then in my compilationpath somehow? regards, Wim
site update
Hi,my patch http://jira.codehaus.org/browse/SCM-95 has not been applied yet. Is there a specific reason?regards,Wim
[jira] Closed: (SCM-98) Add scm:changelog goal
[ http://jira.codehaus.org/browse/SCM-98?page=all ] Emmanuel Venisse closed SCM-98: --- Assign To: Emmanuel Venisse Resolution: Fixed Applied. Add scm:changelog goal -- Key: SCM-98 URL: http://jira.codehaus.org/browse/SCM-98 Project: Maven SCM Type: New Feature Components: maven-plugin Versions: 1.0-beta-1 Environment: starteam, svn, xp Reporter: Dan Tran Assignee: Emmanuel Venisse Fix For: 1.0-beta-2 Attachments: SCM-98.patch This additional mojo dumps the contents of changelog command ( ChangeSet) to stdout. It is for testing changelog command only. -- 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-97) Implement executable changelog command
[ http://jira.codehaus.org/browse/SCM-97?page=all ] Emmanuel Venisse closed SCM-97: --- Assign To: Emmanuel Venisse Resolution: Fixed Applied Implement executable changelog command -- Key: SCM-97 URL: http://jira.codehaus.org/browse/SCM-97 Project: Maven SCM Type: Bug Components: maven-scm-provider-perforce Versions: 1.0-beta-2 Reporter: mike perham Assignee: Emmanuel Venisse Fix For: 1.0-beta-2 Attachments: changelog.txt The changelog command is more of a stub than I realized. This patch adds code to: 1) Execute the actual command (!) 2) Handle non-standard directory structure better by relying on the working directory rather than the repositoryPath -- 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-99) changelog is emtpy when using startDate is assigned
[ http://jira.codehaus.org/browse/SCM-99?page=all ]
Emmanuel Venisse closed SCM-99:
---
Assign To: Emmanuel Venisse
Resolution: Fixed
Fix Version: 1.0-beta-2
applied.
changelog is emtpy when using startDate is assigned
---
Key: SCM-99
URL: http://jira.codehaus.org/browse/SCM-99
Project: Maven SCM
Type: Bug
Components: maven-scm-provider-starteam
Environment: starteam, xp
Reporter: Dan Tran
Assignee: Emmanuel Venisse
Fix For: 1.0-beta-2
Attachments: SCM-99.patch
Current implementation uses -cfgd ${startDate} option to retreive changelog
from startDate to latest change log.
However, -cfgd is not intended to be used this way. It acutally returns the
reverse which are the changelogs from the current view creation date to the
date assigned to -cfgd.
Therefore, the only solution is to retreive all changelogs and filter by
start and end dates.
--
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: site update
ah, ok, thanks.2005/12/6, Emmanuel Venisse [EMAIL PROTECTED]: I didn't have time, it will be update before the releaseEmmanuelWim Deblauwe a écrit : Hi, my patch http://jira.codehaus.org/browse/SCM-95 has not been applied yet. Is there a specific reason? regards, Wim
[jira] Moved: (MNG-1757) classpath error
[ http://jira.codehaus.org/browse/MNG-1757?page=all ] Vincent Massol moved MPCLOVER-51 to MNG-1757: - Complexity: Intermediate Workflow: Maven (was: jira) Key: MNG-1757 (was: MPCLOVER-51) Project: Maven 2 (was: maven-clover-plugin) classpath error --- Key: MNG-1757 URL: http://jira.codehaus.org/browse/MNG-1757 Project: Maven 2 Type: Bug Components: maven-clover-plugin Versions: 2.0 Environment: Windows XP, JDK 5.0 update 6, Maven 2.0, maven-clover-plugin-2.0-alpha-1 Reporter: YueNi I used maven clover plugin to generate test report but got FileNotFoundException. I employ spring in my project, so I use ClassPathXmlApplicationContext in my JUnit test case to get the application context. When the clover:report goal is executed, I got the error message Caused by: java.io.FileNotFoundException: class path resource [net/sf/psm4j/applicationContext.xml] cannot be opened because it does not exist(Actually, the file exists in the right path) . When I executed the mvn test goal, the unit test can be run without exception. In the same time, I can also run the test case in Eclipse without exception(The Eclipse .classpath file is generated by maven eclipse:eclipse goal). Therefore, I think there's something wrong in the maven clover plugin dealing with the classpath. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1757) classpath error
[ http://jira.codehaus.org/browse/MNG-1757?page=all ] Vincent Massol updated MNG-1757: Version: 2.0 Component: maven-clover-plugin classpath error --- Key: MNG-1757 URL: http://jira.codehaus.org/browse/MNG-1757 Project: Maven 2 Type: Bug Components: maven-clover-plugin Versions: 2.0 Environment: Windows XP, JDK 5.0 update 6, Maven 2.0, maven-clover-plugin-2.0-alpha-1 Reporter: YueNi I used maven clover plugin to generate test report but got FileNotFoundException. I employ spring in my project, so I use ClassPathXmlApplicationContext in my JUnit test case to get the application context. When the clover:report goal is executed, I got the error message Caused by: java.io.FileNotFoundException: class path resource [net/sf/psm4j/applicationContext.xml] cannot be opened because it does not exist(Actually, the file exists in the right path) . When I executed the mvn test goal, the unit test can be run without exception. In the same time, I can also run the test case in Eclipse without exception(The Eclipse .classpath file is generated by maven eclipse:eclipse goal). Therefore, I think there's something wrong in the maven clover plugin dealing with the classpath. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPARTIFACT-63) Cannot deploy artifacts with own ArtifactTypeHandler.
[ http://jira.codehaus.org/browse/MPARTIFACT-63?page=all ] Lukas Theussl updated MPARTIFACT-63: Fix Version: 1.7 Cannot deploy artifacts with own ArtifactTypeHandler. - Key: MPARTIFACT-63 URL: http://jira.codehaus.org/browse/MPARTIFACT-63 Project: maven-artifact-plugin Type: Bug Versions: 1.7 Reporter: Shinobu Kawai Yoshida Priority: Critical Fix For: 1.7 Attachments: MPARTIFACT-63.patch As of MPARTIFACT-35, DeployBean#typeHandler became a NamedArtifactTypeHandler (was ArtifactTypeHandler in 1.6). As a result, any artifact which uses it's own ArtifactTypeHandler and does not extend NamedArtifactTypeHandler fails. eg. maven ejb:deploy results in: BUILD FAILED File.. C:\Documents and Settings\shinobu\.maven\cache\maven-artifact-plugin-1.7-SNAPSHOT\plugin.jelly Element... artifact:artifact-deploy Line.. 103 Column 9 Property 'typeHandler' has no write method Total time : 2 minutes 7 seconds Finished at : Monday, December 5, 2005 12:26:38 PM PST -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1743) Surefire plugin reports error without explanation
[ http://jira.codehaus.org/browse/MNG-1743?page=comments#action_52814 ] Brett Porter commented on MNG-1743: --- what version of the surefire plugin do you have? worth checking it is the latest as I had some similar issues with the first snapshot jason deployed, but its fine now. Surefire plugin reports error without explanation - Key: MNG-1743 URL: http://jira.codehaus.org/browse/MNG-1743 Project: Maven 2 Type: Bug Components: maven-surefire-plugin Versions: 2.0.1 Reporter: Vincent Massol Assignee: Jason van Zyl I think this is due to some recent changes in the surefire plugin. I have the maven2 snapshot repo defined and this morning when I tried the tests I got the following error (yesterday I was also getting an error but that an error from my project and the explanation was printed as a stak trace): [...] [INFO] [surefire:test] [INFO] Setting reports dir: C:\dev\cargo\trunk\samples\java\target/surefire-reports [DEBUG] Setting system property [cargo.tomcat3x.port]=[8280] [DEBUG] Setting system property [cargo.containers.timeout]=[6] [DEBUG] Setting system property [cargo.tomcat5x.url]=[http://www.apache.org/dist/jakarta/tomcat-5/v5.0.30/bin/jakarta-tomcat-5.0.3 0.zip] [DEBUG] Setting system property [cargo.orion2x.url]=[http://www.orionserver.com/distributions/orion2.0.5.zip] [DEBUG] Setting system property [cargo.resin3x.port]=[8280] [DEBUG] Setting system property [cargo.target.dir]=[C:\dev\cargo\trunk\samples\java/target] [DEBUG] Setting system property [cargo.testdata.expanded-war]=[org/codehaus/cargo/samples/testdata/expanded-war/0.7-SNAPSHOT/expan ded-war-0.7-SNAPSHOT.war] [DEBUG] Setting system property [cargo.resin2x.url]=[http://www.caucho.com/download/resin-2.1.16.zip] [DEBUG] Setting system property [cargo.resin3x.url]=[http://www.caucho.com/download/resin-3.0.15.zip] [DEBUG] Setting system property [cargo.version]=[0.7-SNAPSHOT] [DEBUG] Setting system property [cargo.tomcat5x.port]=[8280] [DEBUG] Setting system property [cargo.orion2x.port]=[8280] [DEBUG] Setting system property [cargo.install.dir]=[C:\dev\cargo\trunk\samples\java/../../target/installs] [DEBUG] Setting system property [cargo.testdata.authentication-war]=[org/codehaus/cargo/samples/testdata/authentication-war/0.7-SN APSHOT/authentication-war-0.7-SNAPSHOT.war] [DEBUG] Setting system property [cargo.orion1x.port]=[8280] [DEBUG] Setting system property [cargo.oc4j9x.port]=[8280] [DEBUG] Setting system property [cargo.containers]=[resin3x, orion2x, tomcat5x, jetty4xEmbedded] [DEBUG] Setting system property [cargo.jo1x.url]=[http://www.tagtraum.com/download/jo1.1beta1.zip] [DEBUG] Setting system property [cargo.weblogic8x.port]=[8280] [DEBUG] Setting system property [cargo.testdata.empty-ear]=[org/codehaus/cargo/samples/testdata/empty-ear/0.7-SNAPSHOT/empty-ear-0 .7-SNAPSHOT.ear] [DEBUG] Setting system property [cargo.resin2x.port]=[8280] [DEBUG] Setting system property [cargo.tomcat3x.url]=[http://www.apache.org/dist/jakarta/tomcat-3/v3.3.2/bin/jakarta-tomcat-3.3.2. zip] [DEBUG] Setting system property [cargo.testdata.simple-war]=[org/codehaus/cargo/samples/testdata/simple-war/0.7-SNAPSHOT/simple-wa r-0.7-SNAPSHOT.war] [DEBUG] Setting system property [cargo.testdata.tomcatcontext-war]=[org/codehaus/cargo/samples/testdata/tomcatcontext-war/0.7-SNAP SHOT/tomcatcontext-war-0.7-SNAPSHOT.war] [DEBUG] Setting system property [cargo.jetty4xEmbedded.port]=[8280] [DEBUG] Setting system property [cargo.jo1x.port]=[8280] [DEBUG] Setting system property [cargo.testdata.simple-ear]=[org/codehaus/cargo/samples/testdata/simple-ear/0.7-SNAPSHOT/simple-ea r-0.7-SNAPSHOT.ear] [DEBUG] Setting system property [cargo.jboss4x.port]=[8280] [DEBUG] Setting system property [cargo.tomcat4x.url]=[http://www.apache.org/dist/jakarta/tomcat-4/v4.1.31/bin/jakarta-tomcat-4.1.3 1.zip] [DEBUG] Setting system property [cargo.jboss4x.url]=[http://ovh.dl.sourceforge.net/sourceforge/jboss/jboss-4.0.2.zip] [DEBUG] Setting system property [cargo.orion1x.url]=[http://www.orionserver.com/distributions/orion1.6.0b.zip] [DEBUG] Setting system property [cargo.tomcat4x.port]=[8280] [DEBUG] Test Classpath : [DEBUG] C:\dev\cargo\trunk\samples\java\target\test-classes [DEBUG] C:\dev\cargo\trunk\samples\java\target\classes [DEBUG] C:\dev\cargo\trunk\samples\java\target\classes [DEBUG] C:\dev\cargo\trunk\samples\java\target\test-classes [DEBUG] C:\Documents and Settings\Vincent Massol\.m2\repository\junit\junit\3.8.1\junit-3.8.1.jar [DEBUG] C:\Documents and Settings\Vincent Massol\.m2\repository\javax\servlet\jsp-api\2.0\jsp-api-2.0.jar [DEBUG] C:\Documents and Settings\Vincent Massol\.m2\repository\javax\servlet\servlet-api\2.4\servlet-api-2.4.jar [DEBUG] C:\Documents and Settings\Vincent
[jira] Commented: (MPARTIFACT-63) Cannot deploy artifacts with own ArtifactTypeHandler.
[ http://jira.codehaus.org/browse/MPARTIFACT-63?page=comments#action_52817 ] Lukas Theussl commented on MPARTIFACT-63: - Thanks for the patch! The problem is that it breaks exactly the feature that was introduced with the fix for MPARTIFACT-57: you cannot deploy custom named artifacts anymore. We'll have to find a more general solution... Cannot deploy artifacts with own ArtifactTypeHandler. - Key: MPARTIFACT-63 URL: http://jira.codehaus.org/browse/MPARTIFACT-63 Project: maven-artifact-plugin Type: Bug Versions: 1.7 Reporter: Shinobu Kawai Yoshida Priority: Critical Fix For: 1.7 Attachments: MPARTIFACT-63.patch As of MPARTIFACT-35, DeployBean#typeHandler became a NamedArtifactTypeHandler (was ArtifactTypeHandler in 1.6). As a result, any artifact which uses it's own ArtifactTypeHandler and does not extend NamedArtifactTypeHandler fails. eg. maven ejb:deploy results in: BUILD FAILED File.. C:\Documents and Settings\shinobu\.maven\cache\maven-artifact-plugin-1.7-SNAPSHOT\plugin.jelly Element... artifact:artifact-deploy Line.. 103 Column 9 Property 'typeHandler' has no write method Total time : 2 minutes 7 seconds Finished at : Monday, December 5, 2005 12:26:38 PM PST -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (SUREFIRE-21) Use plexus-utils and get rid of the copied util files
[ http://jira.codehaus.org/browse/SUREFIRE-21?page=all ] Brett Porter moved MNG-1747 to SUREFIRE-21: --- Version: (was: 2.0.2) Workflow: jira (was: Maven) Key: SUREFIRE-21 (was: MNG-1747) Project: surefire (was: Maven 2) Use plexus-utils and get rid of the copied util files -- Key: SUREFIRE-21 URL: http://jira.codehaus.org/browse/SUREFIRE-21 Project: surefire Type: Improvement Reporter: Jason van Zyl Assignee: Jason van Zyl Might also need to push TeeStream into plexus utils. -- 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-1743) Surefire plugin reports error without explanation
[ http://jira.codehaus.org/browse/MNG-1743?page=all ] Vincent Massol closed MNG-1743: --- Assign To: Vincent Massol (was: Jason van Zyl) Resolution: Won't Fix It seems there was a problem with the publishing of the plugin. I have built it from sources and it's no longer causing this problem. Surefire plugin reports error without explanation - Key: MNG-1743 URL: http://jira.codehaus.org/browse/MNG-1743 Project: Maven 2 Type: Bug Components: maven-surefire-plugin Versions: 2.0.1 Reporter: Vincent Massol Assignee: Vincent Massol I think this is due to some recent changes in the surefire plugin. I have the maven2 snapshot repo defined and this morning when I tried the tests I got the following error (yesterday I was also getting an error but that an error from my project and the explanation was printed as a stak trace): [...] [INFO] [surefire:test] [INFO] Setting reports dir: C:\dev\cargo\trunk\samples\java\target/surefire-reports [DEBUG] Setting system property [cargo.tomcat3x.port]=[8280] [DEBUG] Setting system property [cargo.containers.timeout]=[6] [DEBUG] Setting system property [cargo.tomcat5x.url]=[http://www.apache.org/dist/jakarta/tomcat-5/v5.0.30/bin/jakarta-tomcat-5.0.3 0.zip] [DEBUG] Setting system property [cargo.orion2x.url]=[http://www.orionserver.com/distributions/orion2.0.5.zip] [DEBUG] Setting system property [cargo.resin3x.port]=[8280] [DEBUG] Setting system property [cargo.target.dir]=[C:\dev\cargo\trunk\samples\java/target] [DEBUG] Setting system property [cargo.testdata.expanded-war]=[org/codehaus/cargo/samples/testdata/expanded-war/0.7-SNAPSHOT/expan ded-war-0.7-SNAPSHOT.war] [DEBUG] Setting system property [cargo.resin2x.url]=[http://www.caucho.com/download/resin-2.1.16.zip] [DEBUG] Setting system property [cargo.resin3x.url]=[http://www.caucho.com/download/resin-3.0.15.zip] [DEBUG] Setting system property [cargo.version]=[0.7-SNAPSHOT] [DEBUG] Setting system property [cargo.tomcat5x.port]=[8280] [DEBUG] Setting system property [cargo.orion2x.port]=[8280] [DEBUG] Setting system property [cargo.install.dir]=[C:\dev\cargo\trunk\samples\java/../../target/installs] [DEBUG] Setting system property [cargo.testdata.authentication-war]=[org/codehaus/cargo/samples/testdata/authentication-war/0.7-SN APSHOT/authentication-war-0.7-SNAPSHOT.war] [DEBUG] Setting system property [cargo.orion1x.port]=[8280] [DEBUG] Setting system property [cargo.oc4j9x.port]=[8280] [DEBUG] Setting system property [cargo.containers]=[resin3x, orion2x, tomcat5x, jetty4xEmbedded] [DEBUG] Setting system property [cargo.jo1x.url]=[http://www.tagtraum.com/download/jo1.1beta1.zip] [DEBUG] Setting system property [cargo.weblogic8x.port]=[8280] [DEBUG] Setting system property [cargo.testdata.empty-ear]=[org/codehaus/cargo/samples/testdata/empty-ear/0.7-SNAPSHOT/empty-ear-0 .7-SNAPSHOT.ear] [DEBUG] Setting system property [cargo.resin2x.port]=[8280] [DEBUG] Setting system property [cargo.tomcat3x.url]=[http://www.apache.org/dist/jakarta/tomcat-3/v3.3.2/bin/jakarta-tomcat-3.3.2. zip] [DEBUG] Setting system property [cargo.testdata.simple-war]=[org/codehaus/cargo/samples/testdata/simple-war/0.7-SNAPSHOT/simple-wa r-0.7-SNAPSHOT.war] [DEBUG] Setting system property [cargo.testdata.tomcatcontext-war]=[org/codehaus/cargo/samples/testdata/tomcatcontext-war/0.7-SNAP SHOT/tomcatcontext-war-0.7-SNAPSHOT.war] [DEBUG] Setting system property [cargo.jetty4xEmbedded.port]=[8280] [DEBUG] Setting system property [cargo.jo1x.port]=[8280] [DEBUG] Setting system property [cargo.testdata.simple-ear]=[org/codehaus/cargo/samples/testdata/simple-ear/0.7-SNAPSHOT/simple-ea r-0.7-SNAPSHOT.ear] [DEBUG] Setting system property [cargo.jboss4x.port]=[8280] [DEBUG] Setting system property [cargo.tomcat4x.url]=[http://www.apache.org/dist/jakarta/tomcat-4/v4.1.31/bin/jakarta-tomcat-4.1.3 1.zip] [DEBUG] Setting system property [cargo.jboss4x.url]=[http://ovh.dl.sourceforge.net/sourceforge/jboss/jboss-4.0.2.zip] [DEBUG] Setting system property [cargo.orion1x.url]=[http://www.orionserver.com/distributions/orion1.6.0b.zip] [DEBUG] Setting system property [cargo.tomcat4x.port]=[8280] [DEBUG] Test Classpath : [DEBUG] C:\dev\cargo\trunk\samples\java\target\test-classes [DEBUG] C:\dev\cargo\trunk\samples\java\target\classes [DEBUG] C:\dev\cargo\trunk\samples\java\target\classes [DEBUG] C:\dev\cargo\trunk\samples\java\target\test-classes [DEBUG] C:\Documents and Settings\Vincent Massol\.m2\repository\junit\junit\3.8.1\junit-3.8.1.jar [DEBUG] C:\Documents and Settings\Vincent Massol\.m2\repository\javax\servlet\jsp-api\2.0\jsp-api-2.0.jar [DEBUG] C:\Documents and Settings\Vincent Massol\.m2\repository\javax\servlet\servlet-api\2.4\servlet-api-2.4.jar [DEBUG] C:\Documents and Settings\Vincent
[jira] Updated: (MPARTIFACT-63) Cannot deploy artifacts with own ArtifactTypeHandler.
[ http://jira.codehaus.org/browse/MPARTIFACT-63?page=all ] Shinobu Kawai Yoshida updated MPARTIFACT-63: Attachment: MPARTIFACT-63.patch A quick fix. Cannot deploy artifacts with own ArtifactTypeHandler. - Key: MPARTIFACT-63 URL: http://jira.codehaus.org/browse/MPARTIFACT-63 Project: maven-artifact-plugin Type: Bug Versions: 1.7 Reporter: Shinobu Kawai Yoshida Priority: Critical Fix For: 1.7 Attachments: MPARTIFACT-63.patch As of MPARTIFACT-35, DeployBean#typeHandler became a NamedArtifactTypeHandler (was ArtifactTypeHandler in 1.6). As a result, any artifact which uses it's own ArtifactTypeHandler and does not extend NamedArtifactTypeHandler fails. eg. maven ejb:deploy results in: BUILD FAILED File.. C:\Documents and Settings\shinobu\.maven\cache\maven-artifact-plugin-1.7-SNAPSHOT\plugin.jelly Element... artifact:artifact-deploy Line.. 103 Column 9 Property 'typeHandler' has no write method Total time : 2 minutes 7 seconds Finished at : Monday, December 5, 2005 12:26:38 PM PST -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1758) Tests failing when specifying forkmode=pertest on windows
Tests failing when specifying forkmode=pertest on windows - Key: MNG-1758 URL: http://jira.codehaus.org/browse/MNG-1758 Project: Maven 2 Type: Bug Components: maven-surefire-plugin Environment: Windows XP Reporter: Vincent Massol C:\dev\cargo\trunk\samples\javamvn install [INFO] Scanning for projects... [INFO] [INFO] Building Cargo Sample for Java [INFO]task-segment: [install] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [surefire:test] [INFO] forkMode: pertest [INFO] Setting reports dir: C:\dev\cargo\trunk\samples\java\target/surefire-reports '-classpath' is not recognized as an internal or external command, operable program or batch file. '-classpath' is not recognized as an internal or external command, operable program or batch file. '-classpath' is not recognized as an internal or external command, operable program or batch file. '-classpath' is not recognized as an internal or external command, operable program or batch file. '-classpath' is not recognized as an internal or external command, operable program or batch file. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] There are some test failure. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 7 seconds [INFO] Finished at: Mon Dec 05 22:54:09 CET 2005 [INFO] Final Memory: 4M/8M [INFO] -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (CONTINUUM-499) Update for README.txt with an hands on chapter for including the Sun jars into the m2 repository
[ http://jira.codehaus.org/browse/CONTINUUM-499?page=all ] Emmanuel Venisse closed CONTINUUM-499: -- Assign To: Emmanuel Venisse Resolution: Fixed Fix Version: 1.0.2 Applied. Thanks. Update for README.txt with an hands on chapter for including the Sun jars into the m2 repository Key: CONTINUUM-499 URL: http://jira.codehaus.org/browse/CONTINUUM-499 Project: Continuum Type: Improvement Components: Core system Reporter: Andreas Hoheneder Assignee: Emmanuel Venisse Priority: Trivial Fix For: 1.0.2 Attachments: sun_jars.patch If an user tries to build continuum the first time he has the unpleasant experience that the build fails because of the missing sun jars (and oracles ojdbc14.jar). This Patch adds a short description how to download and inject the jar files from the various homepages to give newcomers a little help for their first build. -- 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-701) extract pom conversion code to create a standalone tool
[ http://jira.codehaus.org/browse/MNG-701?page=all ] Brett Porter closed MNG-701: Assign To: Brett Porter Resolution: Won't Fix Fix Version: (was: 2.0.1) extract pom conversion code to create a standalone tool --- Key: MNG-701 URL: http://jira.codehaus.org/browse/MNG-701 Project: Maven 2 Type: New Feature Reporter: Brett Porter Assignee: Brett Porter Priority: Minor useful for getting started on an m1 to m2 conversion tool -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-678) scp intermittently failing deploying artifact
[ http://jira.codehaus.org/browse/MNG-678?page=comments#action_52821 ] Grégory Joseph commented on MNG-678: Oh gosh, in my case, the distant repo's disk was full. However, it'd be nice if this kind of meaningful information was reported in the buid failure message :) scp intermittently failing deploying artifact - Key: MNG-678 URL: http://jira.codehaus.org/browse/MNG-678 Project: Maven 2 Type: Bug Components: Artifacts and Repositories Versions: 2.0-alpha-3 Environment: JDK 1.5, Red Hat 9 Reporter: Joe Futrelle Fix For: 2.0.2 Some of the time, deploying artifacts fails during the scp transfer. The bottom of the stack trace is reproduced below. If I run the m2 deploy enough times, it succeeds; not sure why. This is not an unknown issue with Jsch; apparently client code can cause behavior like this if it doesn't dispose of connections properly. Possibly a plugin that's runs before the deploy phase is messing up the connection state somehow? Caused by: org.apache.maven.wagon.TransferFailedException: Error occured while deploying 'ncsa/gsbt/1.0-SNAPSHOT/gsbt-1.0-20050728.190330-38.pom.sha1' to remote repository: scp://chasm.ncsa.uiuc.edu//home/futrelle/m2/repository at org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:331) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:167) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:91) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:73) ... 17 more Caused by: com.jcraft.jsch.JSchException: session is down at com.jcraft.jsch.Channel.connect(Unknown Source) at org.apache.maven.wagon.providers.ssh.ScpWagon.put(ScpWagon.java:271) ... 20 more -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPTEST-59) test:single should override maven.test.skip=true
test:single should override maven.test.skip=true Key: MPTEST-59 URL: http://jira.codehaus.org/browse/MPTEST-59 Project: maven-test-plugin Type: Improvement Versions: 1.7 Reporter: Jeff Black If I have a properties file with maven.test.skip=true, but I want to run a single unit test. A maven test:single with the -D switch should ignore the skip property, as it is clear that I always want to run this single test. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Reopened: (MNG-441) surefire plugin needs to be able to fork tests
[ http://jira.codehaus.org/browse/MNG-441?page=all ] Jason van Zyl reopened MNG-441: --- Forking is not working on Windows. surefire plugin needs to be able to fork tests -- Key: MNG-441 URL: http://jira.codehaus.org/browse/MNG-441 Project: Maven 2 Type: Improvement Components: maven-surefire-plugin Reporter: Brett Porter Assignee: Jason van Zyl Fix For: 2.0.1 Attachments: SurefirePlugin.java, pom.xml they can leak memory, so a fork once for all option would be good. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPARTIFACT-63) Cannot deploy artifacts with own ArtifactTypeHandler.
[ http://jira.codehaus.org/browse/MPARTIFACT-63?page=comments#action_52824 ] Lukas Theussl commented on MPARTIFACT-63: - I just committed a slightly modified version of your patch, can you confirm that this still works for you? Thanks! Cannot deploy artifacts with own ArtifactTypeHandler. - Key: MPARTIFACT-63 URL: http://jira.codehaus.org/browse/MPARTIFACT-63 Project: maven-artifact-plugin Type: Bug Versions: 1.7 Reporter: Shinobu Kawai Yoshida Priority: Critical Fix For: 1.7 Attachments: MPARTIFACT-63.patch As of MPARTIFACT-35, DeployBean#typeHandler became a NamedArtifactTypeHandler (was ArtifactTypeHandler in 1.6). As a result, any artifact which uses it's own ArtifactTypeHandler and does not extend NamedArtifactTypeHandler fails. eg. maven ejb:deploy results in: BUILD FAILED File.. C:\Documents and Settings\shinobu\.maven\cache\maven-artifact-plugin-1.7-SNAPSHOT\plugin.jelly Element... artifact:artifact-deploy Line.. 103 Column 9 Property 'typeHandler' has no write method Total time : 2 minutes 7 seconds Finished at : Monday, December 5, 2005 12:26:38 PM PST -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1754) Antrun plugin defaults to using jre classpath instead of jdk
[ http://jira.codehaus.org/browse/MNG-1754?page=all ]
Brett Porter closed MNG-1754:
-
Assign To: Brett Porter
Resolution: Won't Fix
afaik this is normal - we always reference it as: ${java.home}/../lib/tools.jar
I don't quite understand why this wouldn't work in subprojects?
Antrun plugin defaults to using jre classpath instead of jdk
Key: MNG-1754
URL: http://jira.codehaus.org/browse/MNG-1754
Project: Maven 2
Type: Bug
Components: maven-antrun-plugin
Versions: 2.0
Reporter: ruel loehr
Assignee: Brett Porter
When executing ant tasks via the antrun plugin, maven reconciles them with a
jre classpath. You can verify this by running the antrun plugin with the
following task:
echo message={java.home/
The solution I can see is to add a plugin dependency on the antrun plugin
which resolves to the tools.jar, however another bug prevents this from
working in anything but top level projects. Hence, the antrun plugin cannot
be used for any compilation purposes (javac, rmic) for child projects.
--
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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1471) Module paths for system scope are relative to parent pom instead of its own
[ http://jira.codehaus.org/browse/MNG-1471?page=comments#action_52827 ] John Casey commented on MNG-1471: - The whole point of maven is to have your project declaratively specified, and then use that information to build the project artifact, project documentation, etc., etc. Why would you want to remove that safety net? Aside from this discussion, there *is* an SCM wagon provider (not sure of what quality it currently is), which can retrieve your dependencies from CVS/SVN/etc. if your scm repository is structured as a normal maven repository. Then, it's just a matter of specifying the correct repositories/ configuration, and adding a build extension/ for the scm wagon. Would this work? It seems as if you've been using Maven 1 as a shell around Ant for some time now, if you're still adding lib/*.jar. System dependencies are broken, in that they don't support transitivity, and can *very* easily become non-portable (like, if lib/ exists outside your project directory...it doesn't, does it??). For things like tools.jar, we're planning to support the notion of specification dependencies, where tools.jar might implement some javac POM or something. For native builds, where the dependency is actually installed on the system somewhere, alternative artifact resolver implementations are more appropriate, since specifying the path of these deps on the user-POM side isn't very efficient. Module paths for system scope are relative to parent pom instead of its own --- Key: MNG-1471 URL: http://jira.codehaus.org/browse/MNG-1471 Project: Maven 2 Type: Bug Components: maven-compiler-plugin Versions: 2.0 Environment: Win XP, Maven 2.0 Reporter: Jeff Jensen Assignee: John Casey Priority: Critical Fix For: 2.0.1 Attachments: MNG-1471-maven-project.patch Original Estimate: 30 minutes Remaining: 30 minutes When building from the parent POM dir, all paths are relative to it. A problem occurs when its modules have dependencies of scopesystem/scope - the module's corresponding systemPath is relative to the parent POM dir, instead of the module's POM dir. With a module's systemPath set to compile correctly it on its own, compiling from its parent POM dir gives this error: [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: thegrp ArtifactId: subsystem Version: 2.1-SNAPSHOT Reason: System artifact: thegrp:subsystem:jar:2.1-SNAPSHOT not found in path: src\lib\subsystem.jar thegrp:subsystem:2.1-SNAPSHOT:jar (would be nice to have the fully qualified path name listed there, instead of the relative one so users would know where it is really looking for it from) Expected behavior is that Maven treats system scope paths relative to the module POM, not the parent's POM. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1471) Module paths for system scope are relative to parent pom instead of its own
[ http://jira.codehaus.org/browse/MNG-1471?page=comments#action_52828 ] Brett Porter commented on MNG-1471: --- it will just be discouraged, not removed (at least not without a reasonable deprecation period and plenty of discussion of alternatives). We might need some other resolvers, but the dependenchy mechanism in m2 relies on the repository information to perform. I guess what you are asking for here is to turn off the dependency mechanism and just use local jars - that's a possibility, and a separate feature request. Module paths for system scope are relative to parent pom instead of its own --- Key: MNG-1471 URL: http://jira.codehaus.org/browse/MNG-1471 Project: Maven 2 Type: Bug Components: maven-compiler-plugin Versions: 2.0 Environment: Win XP, Maven 2.0 Reporter: Jeff Jensen Assignee: John Casey Priority: Critical Fix For: 2.0.1 Attachments: MNG-1471-maven-project.patch Original Estimate: 30 minutes Remaining: 30 minutes When building from the parent POM dir, all paths are relative to it. A problem occurs when its modules have dependencies of scopesystem/scope - the module's corresponding systemPath is relative to the parent POM dir, instead of the module's POM dir. With a module's systemPath set to compile correctly it on its own, compiling from its parent POM dir gives this error: [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: thegrp ArtifactId: subsystem Version: 2.1-SNAPSHOT Reason: System artifact: thegrp:subsystem:jar:2.1-SNAPSHOT not found in path: src\lib\subsystem.jar thegrp:subsystem:2.1-SNAPSHOT:jar (would be nice to have the fully qualified path name listed there, instead of the relative one so users would know where it is really looking for it from) Expected behavior is that Maven treats system scope paths relative to the module POM, not the parent's POM. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1749) [PATCH] Bring maven-checkstyle-plugin up to date with maven1 counterpart.
[ http://jira.codehaus.org/browse/MNG-1749?page=all ] Joakim Erdfelt updated MNG-1749: Attachment: MNG-1749-checkstyle-up-to-date-with-m1.patch Attached: MNG-1749-checkstyle-up-to-date-with-m1.patch This patch is created using the following technique. [EMAIL PROTECTED] maven-checkstyle-plugin]$ svn --version svn, version 1.2.3 (r15833) compiled Aug 26 2005, 03:42:45 [EMAIL PROTECTED] maven-checkstyle-plugin/]$ svn diff MNG-1749-checkstyle-up-to-date-with-m1.patch [PATCH] Bring maven-checkstyle-plugin up to date with maven1 counterpart. - Key: MNG-1749 URL: http://jira.codehaus.org/browse/MNG-1749 Project: Maven 2 Type: Improvement Components: maven-checkstyle-plugin Versions: 2.0 Reporter: Joakim Erdfelt Fix For: 2.0 Attachments: MNG-1749-checkstyle-up-to-date-with-m1.patch, m2-checkstyle-up-to-date-with-m1.patch Bring Maven 2 Checkstyle plugin up to date with regards to its maven 1 counterpart. See http://joakim.erdfelt.net/checkstyle/ for example site gen for the checkstyle plugin. Attached patch includes: * Upgraded to checkstyle v4.0 (from maven1 version) * Added RSS feed for rule violations. (from maven1 version) * Rules summary added as report section. (new functionality) * Refactoring of Map of AuditEvents into CheckstyleResult. (needed to share logic between RSS and original report) * Added report output parameters enableFilesSummary, enableRulesSummary, enableSeveritySummary, enableRSS. (to allow the individual sections to be turned on/off) * Added checkstyle:check goal. (requested by vmassol to allow build failure on a found checkstyle violation/error) * Updated parameters to have expressions. (so that checkstyle:checkstyle can be effectively configured via the command line) * Updated parameter documentation with regards to *Location parameters. (to properly represent nature of location copying) -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-245) Tomcat 4.1.31 missing
[ http://jira.codehaus.org/browse/MEV-245?page=comments#action_52833 ] Edwin Punzalan commented on MEV-245: H... this should be in maven-upload-requests and the procedure on doing it is here: http://maven.apache.org/guides/mini/guide-ibiblio-upload.html. Tomcat 4.1.31 missing - Key: MEV-245 URL: http://jira.codehaus.org/browse/MEV-245 Project: Maven Evangelism Type: Bug Reporter: Tomislav Stojcevich Not sure if this is the correct place to ask this becase the instructions on the maven2 site are not specific. Let me know what the correct procedures are if this is not the right place. I asked the Tomcat team to add Tomcat 4.1.31 to the Apache repository. They did that. See: http://www.apache.org/dist/java-repository/tomcat/jars/ It looks like the directories got created for maven2 but no jars or poms. What needs to be done now to get the jars and poms in the central repository for maven2? Specifically I need jasper-compiler and jasper-runtime. I know somebody else asked about catalina in the mailing list a while back. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1509) Profile activation by os doesn't work
[ http://jira.codehaus.org/browse/MNG-1509?page=all ] Bernd Bohmann updated MNG-1509: --- Attachment: OperatingSystemProfileActivator.java.patch First patch for OperatingSystemProfileActivator was not really correct. Profile activation by os doesn't work - Key: MNG-1509 URL: http://jira.codehaus.org/browse/MNG-1509 Project: Maven 2 Type: Bug Components: Inheritence and Interpolation Versions: 2.0 Environment: Ubuntu 5.10 maven 2.0 Reporter: Bernd Bohmann Attachments: DefaultProfileManagerTest.java.patch, OperatingSystemProfileActivator.java.patch, OperatingSystemProfileActivator.java.patch, components.xml.patch Profile activation by os doesn't work. OperatingSystemProfileActivator is missing in components.xml. Implementation of OperatingSystemProfileActivator.isActive is wrong. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-244) WebWork 2.1.5 has incorrect groupId for com.servlets
[ http://jira.codehaus.org/browse/MEV-244?page=all ] Edwin Punzalan closed MEV-244: -- Assign To: Edwin Punzalan Resolution: Fixed Sorry about that. I preferred on using servlets.com as the pom has more info... didn't notice that servlets.com don't have the version. Fixed and may take up to 4 hours to reach central repo. WebWork 2.1.5 has incorrect groupId for com.servlets Key: MEV-244 URL: http://jira.codehaus.org/browse/MEV-244 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Matt Raible Assignee: Edwin Punzalan Currently has: dependency groupIdservlets.com/groupId artifactIdcos/artifactId version09May2002/version /dependency Should be: dependency groupIdcom.servlets/groupId artifactIdcos/artifactId version09May2002/version /dependency -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPASPECTJ-23) Report for the plugin
Report for the plugin - Key: MPASPECTJ-23 URL: http://jira.codehaus.org/browse/MPASPECTJ-23 Project: maven-aspectj-plugin Type: Wish Reporter: Shinobu Kawai Yoshida Priority: Trivial It would be great if there was a report feature to the plugin. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPASPECTJ-22) bootclasspath support
bootclasspath support - Key: MPASPECTJ-22 URL: http://jira.codehaus.org/browse/MPASPECTJ-22 Project: maven-aspectj-plugin Type: Wish Versions: 3.2 Reporter: Shinobu Kawai Yoshida Priority: Minor It would be great if the plugin supported the bootclasspath attribute. cf. http://www.eclipse.org/aspectj/doc/released/devguide/antTasks-iajc.html -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1759) URLs only link if they are FQDNs
URLs only link if they are FQDNs Key: MNG-1759 URL: http://jira.codehaus.org/browse/MNG-1759 Project: Maven 2 Type: Bug Versions: 2.0 Reporter: mike perham Fix For: 2.0.2 We are trying to create internal site documentation for our projects with links to our Confluence user home pages: developer idmperham/id urlhttp://wiki:9090/display/~mperham/url /developer But the project info report does not link this URL. If I add .com or .org to the end of it, it does link so I suspect the validation is just a little over-zealous. It should just link whatever the user puts in there. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPECLIPSE-71) Better support for multiproject with eclipse plugin
[ http://jira.codehaus.org/browse/MPECLIPSE-71?page=comments#action_52840 ]
Max Rudman commented on MPECLIPSE-71:
-
I had the same need and created my own version. Submitted patch is actually
more robust than what I did so I am not submitting mine. However, I have a
couple of suggestions:
1) Generated sources dir for nested projects should be obtained with something
like this:
j:set var=nestedContext value=${reactorProject.context}/
j:invoke var=genSrc on=${nestedContext} method=getVariable
j:arg value=maven.gen.src/
/j:invoke
This way nested project's potentially different setting is respected. Same
should be done for maven.build.dir
2) I put multiproject handling into a separate multiclasspath.jelly file and
included it in the main classpath.jelly. I like smaller files as I feel they
are easier to work with/find things in.
Better support for multiproject with eclipse plugin
---
Key: MPECLIPSE-71
URL: http://jira.codehaus.org/browse/MPECLIPSE-71
Project: maven-eclipse-plugin
Type: New Feature
Reporter: Yujin Kim
Priority: Minor
Attachments: classpath.jelly.MPECLIPSE-71.zip, classpath.jelly.patch,
maven-eclipse-plugin-test.zip
Currently when eclipse generates .classpath file, the subprojects' target
paths default to the parent project's target path.
for example if you have a POM A which is a parent project, and POM B and C
that are subprojects of A, generated classpath will have :
src/java - target/classes
src/test - target/test-classes
B/src/java - target/classes
B/src/test - target/test-classes
C/src/java - target/classes
C/src/test - target/test-classes
If I get a chance, I'll post a 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
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JXR-5) JXR report html malformed
[ http://jira.codehaus.org/browse/JXR-5?page=comments#action_52841 ] mike perham commented on JXR-5: --- Where is the maven-jxr source code? I'll fix this and submit a patch if only I knew where it was... JXR report html malformed - Key: JXR-5 URL: http://jira.codehaus.org/browse/JXR-5 Project: Maven JXR Type: Bug Versions: 1.0-beta-1 Reporter: mike perham Fix For: 1.0-beta-1 Here's a sample of the HTML generated. Note the invalid links and the unresolved $name variable: html xml:lang=en lang=en head meta http-equiv=content-type content=text/html; charset=ISO-8859-1 / titleWSF TripleStore SPI 2.2.0-SNAPSHOT Reference Package $name/title link rel=stylesheet type=text/css href=\.\./\.\./\.\./\.\./\.\./stylesheet.css title=style / /head body div class=overview ul li a href=\.\./\.\./\.\./\.\./\.\./overview-summary.htmlOverview/a /li li class=selectedPackage/li /ul /div div class=framenoframe ul li a href=\.\./\.\./\.\./\.\./\.\./index.html target=_topFRAMES/a /li -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (JXR-5) JXR report html malformed
JXR report html malformed - Key: JXR-5 URL: http://jira.codehaus.org/browse/JXR-5 Project: Maven JXR Type: Bug Versions: 1.0-beta-1 Reporter: mike perham Fix For: 1.0-beta-1 Here's a sample of the HTML generated. Note the invalid links and the unresolved $name variable: html xml:lang=en lang=en head meta http-equiv=content-type content=text/html; charset=ISO-8859-1 / titleWSF TripleStore SPI 2.2.0-SNAPSHOT Reference Package $name/title link rel=stylesheet type=text/css href=\.\./\.\./\.\./\.\./\.\./stylesheet.css title=style / /head body div class=overview ul li a href=\.\./\.\./\.\./\.\./\.\./overview-summary.htmlOverview/a /li li class=selectedPackage/li /ul /div div class=framenoframe ul li a href=\.\./\.\./\.\./\.\./\.\./index.html target=_topFRAMES/a /li -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPDIST-28) Allow to configure to which files should use CRLF line endings in Zip archives
[ http://jira.codehaus.org/browse/MPDIST-28?page=comments#action_52844 ] Lukas Theussl commented on MPDIST-28: - Thanks Phil! Just to clarify: you get the NPE with the plugin-plugin-1.7-SNAPSHOT installed? Running maven 1.0 or 1.1? It shouldn't be necessary to comment the assert out in any case. Allow to configure to which files should use CRLF line endings in Zip archives -- Key: MPDIST-28 URL: http://jira.codehaus.org/browse/MPDIST-28 Project: maven-dist-plugin Type: Improvement Versions: 1.7 Environment: 1.7 Reporter: Arnaud Heritier Fix For: 1.7 Attachments: dist.patch Add a new property to replace the hardcoded filter **/*.txt used in fixcrlf tasks. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1761) Better Archetype template processing support
Better Archetype template processing support Key: MNG-1761 URL: http://jira.codehaus.org/browse/MNG-1761 Project: Maven 2 Type: Improvement Versions: 2.2 Reporter: Aaron Anderson Priority: Trivial Attachments: new-archetype.zip I really love the maven 2 archetype concept and have developed an enhanced version that utilizes the velocity templating engine to a greater degree. While the code is fully functionality it needs to be cleaned up and the documentation enhanced. Please feel to incorporate any part of this back into maven 2 if any of it is appealing. If desired I could also enhance the code to make it a better contribution as well. To test out the archetype functionallity, run mvn install in both archetype (new plugin) and jbi-component (sample archetype) to execute the new archetype, run C:\temp\maventest mvn com.javaforge.bobber:bobber-archetype:1.0-SNAPSHOT:create -DarchetypeGroupId=com.javaforge.bobber -DarchetypeArtifactId=maven-archetype-jbi-component -DarchetypeVersion=1.0-SNAPSHOT -DgroupId=com.newarchetype -DartifactId=test in the same way the default archeype functionality works. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1760) Custom packaging type ignored when POM contains modules entry
Custom packaging type ignored when POM contains modules entry -- Key: MNG-1760 URL: http://jira.codehaus.org/browse/MNG-1760 Project: Maven 2 Type: Bug Reporter: Aaron Anderson First I have not come across any information stating that only POM's with package type POM may have a modules section. If this is so then the following is not a bug. I created an extension plugin that has a custom artifact type and lifecycle following the directions at http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html The POM that has the custom packaging type declares the plugin as an extension in it's build section and has a dependency on two modules in two different subdirectories, i.e modules moduleruntime/module moduleboot/module /modules If I go into the modules directory and run mvn install and then go up to the project directory and run mvn install without the above module statement the dependencies are found and the custom lifecyle is invoked and everything is fine. However, if I add the above module declaration back in and run mvn install expecting that all three projects will be built only the sub modules are built correctly by the reactor but for the top level project the custom packaging type is ignored and the project is treated as a POM package type and is installed in the repository as such. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1762) Exclude files svn from archive.
Exclude files svn from archive. --- Key: MNG-1762 URL: http://jira.codehaus.org/browse/MNG-1762 Project: Maven 2 Type: New Feature Components: maven-ear-plugin Reporter: Dmitrij Khayretdinov Priority: Minor At assembly of archive in it files svn from src/main/application get. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1558) Manifest generation problems caused by valid POM information
[ http://jira.codehaus.org/browse/MNG-1558?page=all ] Edwin Punzalan updated MNG-1558: Attachment: (was: MNG-1558-plexus-archiver.patch) Manifest generation problems caused by valid POM information Key: MNG-1558 URL: http://jira.codehaus.org/browse/MNG-1558 Project: Maven 2 Type: Bug Components: maven-jar-plugin Versions: 2.0 Reporter: Bob Allison Assignee: Edwin Punzalan Fix For: 2.0.1 Attachments: MNG-1558-plexus-archiver.patch It looks like we have some problems with the contents of manifests in jar files. According to Sun's documentation (http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html), there are three basic formatting rules which are not always being enforced: 1) All text must be UTF-8 2) Lines are limited to 72 characters; longer lines must be continued 3) Sections are divided by blank lines Where are these rules being violated? The first rule can be violated by any POM which is in a character set other than UTF-8. The last two rules can be violated by any POM value which spans multiple lines. Both of these are potential problems since a number of POM values go directly into the manifest without sufficient checking. Example: The plugin I have been working on suddenly stopped working. It stopped when I added a two-line description to the POM. I have been able to determine that converting the second line of the description into a proper manifest continuation line fixed the problem. As it turns out, the class loader was ignoring the jar; this created an error where the name of the Mojo class was found but the class could not be loaded. Workarounds for the present: -- Any POM fields which end up in a jar manifest needs to be limited to UTF-8 characters. -- Multi-line values should be constructed so that all lines start with a space character (not strictly required for the first line but it doesn't hurt). -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1558) Manifest generation problems caused by valid POM information
[ http://jira.codehaus.org/browse/MNG-1558?page=all ] Edwin Punzalan updated MNG-1558: Attachment: MNG-1558-plexus-archiver.patch Attached patch with updated test cases for the problem. Manifest generation problems caused by valid POM information Key: MNG-1558 URL: http://jira.codehaus.org/browse/MNG-1558 Project: Maven 2 Type: Bug Components: maven-jar-plugin Versions: 2.0 Reporter: Bob Allison Assignee: Edwin Punzalan Fix For: 2.0.1 Attachments: MNG-1558-plexus-archiver.patch It looks like we have some problems with the contents of manifests in jar files. According to Sun's documentation (http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html), there are three basic formatting rules which are not always being enforced: 1) All text must be UTF-8 2) Lines are limited to 72 characters; longer lines must be continued 3) Sections are divided by blank lines Where are these rules being violated? The first rule can be violated by any POM which is in a character set other than UTF-8. The last two rules can be violated by any POM value which spans multiple lines. Both of these are potential problems since a number of POM values go directly into the manifest without sufficient checking. Example: The plugin I have been working on suddenly stopped working. It stopped when I added a two-line description to the POM. I have been able to determine that converting the second line of the description into a proper manifest continuation line fixed the problem. As it turns out, the class loader was ignoring the jar; this created an error where the name of the Mojo class was found but the class could not be loaded. Workarounds for the present: -- Any POM fields which end up in a jar manifest needs to be limited to UTF-8 characters. -- Multi-line values should be constructed so that all lines start with a space character (not strictly required for the first line but it doesn't hurt). -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1558) Manifest generation problems caused by valid POM information
[ http://jira.codehaus.org/browse/MNG-1558?page=all ] Edwin Punzalan updated MNG-1558: Attachment: MNG-1558-plexus-archiver.patch Manifest generation problems caused by valid POM information Key: MNG-1558 URL: http://jira.codehaus.org/browse/MNG-1558 Project: Maven 2 Type: Bug Components: maven-jar-plugin Versions: 2.0 Reporter: Bob Allison Assignee: Edwin Punzalan Fix For: 2.0.1 Attachments: MNG-1558-plexus-archiver.patch It looks like we have some problems with the contents of manifests in jar files. According to Sun's documentation (http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html), there are three basic formatting rules which are not always being enforced: 1) All text must be UTF-8 2) Lines are limited to 72 characters; longer lines must be continued 3) Sections are divided by blank lines Where are these rules being violated? The first rule can be violated by any POM which is in a character set other than UTF-8. The last two rules can be violated by any POM value which spans multiple lines. Both of these are potential problems since a number of POM values go directly into the manifest without sufficient checking. Example: The plugin I have been working on suddenly stopped working. It stopped when I added a two-line description to the POM. I have been able to determine that converting the second line of the description into a proper manifest continuation line fixed the problem. As it turns out, the class loader was ignoring the jar; this created an error where the name of the Mojo class was found but the class could not be loaded. Workarounds for the present: -- Any POM fields which end up in a jar manifest needs to be limited to UTF-8 characters. -- Multi-line values should be constructed so that all lines start with a space character (not strictly required for the first line but it doesn't hurt). -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1558) Manifest generation problems caused by valid POM information
[ http://jira.codehaus.org/browse/MNG-1558?page=all ] Edwin Punzalan updated MNG-1558: Attachment: MNG-1558-plexus-archiver.patch Sorry about that the multiple attach/delete... was cleaning the unit test output. Manifest generation problems caused by valid POM information Key: MNG-1558 URL: http://jira.codehaus.org/browse/MNG-1558 Project: Maven 2 Type: Bug Components: maven-jar-plugin Versions: 2.0 Reporter: Bob Allison Assignee: Edwin Punzalan Fix For: 2.0.1 Attachments: MNG-1558-plexus-archiver.patch It looks like we have some problems with the contents of manifests in jar files. According to Sun's documentation (http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html), there are three basic formatting rules which are not always being enforced: 1) All text must be UTF-8 2) Lines are limited to 72 characters; longer lines must be continued 3) Sections are divided by blank lines Where are these rules being violated? The first rule can be violated by any POM which is in a character set other than UTF-8. The last two rules can be violated by any POM value which spans multiple lines. Both of these are potential problems since a number of POM values go directly into the manifest without sufficient checking. Example: The plugin I have been working on suddenly stopped working. It stopped when I added a two-line description to the POM. I have been able to determine that converting the second line of the description into a proper manifest continuation line fixed the problem. As it turns out, the class loader was ignoring the jar; this created an error where the name of the Mojo class was found but the class could not be loaded. Workarounds for the present: -- Any POM fields which end up in a jar manifest needs to be limited to UTF-8 characters. -- Multi-line values should be constructed so that all lines start with a space character (not strictly required for the first line but it doesn't hurt). -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1763) Suport sources generator in eclipse plugin
Suport sources generator in eclipse plugin --- Key: MNG-1763 URL: http://jira.codehaus.org/browse/MNG-1763 Project: Maven 2 Type: Bug Components: maven-eclipse-plugin Versions: 2.0 Reporter: Gilles Scokart The current eclipse plugin doesn't have suport for code generation like Maven 1 (see http://maven.apache.org/maven-1.x/reference/plugins/eclipse/). In maven 2, its probably simpler. The eclipse plugin in should only launch the build cycle up to process-test-resources. If any plugin is executed in the source generation or test source generation phase, those plugins will automatically add the directory to the list of source directory (as described in http://maven.apache.org/guides/mini/guide-generating-sources.html). -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1558) Manifest generation problems caused by valid POM information
[ http://jira.codehaus.org/browse/MNG-1558?page=all ] Edwin Punzalan updated MNG-1558: Attachment: (was: MNG-1558-plexus-archiver.patch) Manifest generation problems caused by valid POM information Key: MNG-1558 URL: http://jira.codehaus.org/browse/MNG-1558 Project: Maven 2 Type: Bug Components: maven-jar-plugin Versions: 2.0 Reporter: Bob Allison Assignee: Edwin Punzalan Fix For: 2.0.1 Attachments: MNG-1558-plexus-archiver.patch It looks like we have some problems with the contents of manifests in jar files. According to Sun's documentation (http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html), there are three basic formatting rules which are not always being enforced: 1) All text must be UTF-8 2) Lines are limited to 72 characters; longer lines must be continued 3) Sections are divided by blank lines Where are these rules being violated? The first rule can be violated by any POM which is in a character set other than UTF-8. The last two rules can be violated by any POM value which spans multiple lines. Both of these are potential problems since a number of POM values go directly into the manifest without sufficient checking. Example: The plugin I have been working on suddenly stopped working. It stopped when I added a two-line description to the POM. I have been able to determine that converting the second line of the description into a proper manifest continuation line fixed the problem. As it turns out, the class loader was ignoring the jar; this created an error where the name of the Mojo class was found but the class could not be loaded. Workarounds for the present: -- Any POM fields which end up in a jar manifest needs to be limited to UTF-8 characters. -- Multi-line values should be constructed so that all lines start with a space character (not strictly required for the first line but it doesn't hurt). -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MRM-2) repository: transitive dependency report
[ http://jira.codehaus.org/browse/MRM-2?page=all ] John Tolentino updated MRM-2: - Attachment: MRM-2-maven-repository-reports-standard.diff Additional implementations, new classes and unit tests. repository: transitive dependency report Key: MRM-2 URL: http://jira.codehaus.org/browse/MRM-2 Project: Maven Repository Manager Type: New Feature Components: reporting Reporter: Brett Porter Assignee: John Tolentino Fix For: 1.0-alpha-1 Attachments: MRM-2-maven-repository-reports-standard.diff, MRM-2-maven-repository-reports-standard.diff, MRM-2-maven-repository-reports-standard.diff Original Estimate: 2 days Time Spent: 4 hours Remaining: 1 day, 20 hours repository tool to ensure that transitive dependencies will work. we basically need to know that every artifact that is referenced in one POM is actually in the repository along with its POM. We need to know that the dependency relationships among all artifacts in the repository form a closed set. otherwise the transitive dependency mechanism in m2 will break and we need to be wary of this. eventually i would like to create graphical representations of the dependencies amongst projects but this can come later. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (CONTINUUM-485) Add a default build definition for ant project
[ http://jira.codehaus.org/browse/CONTINUUM-485?page=all ] nick gonzalez updated CONTINUUM-485: Attachment: CONTINUUM-485-continuum-core.patch Add a default build definition for ant project -- Key: CONTINUUM-485 URL: http://jira.codehaus.org/browse/CONTINUUM-485 Project: Continuum Type: Improvement Reporter: Emmanuel Venisse Fix For: 1.0.2 Attachments: CONTINUUM-485-continuum-core.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] Updated: (MRM-2) repository: transitive dependency report
[ http://jira.codehaus.org/browse/MRM-2?page=all ] John Tolentino updated MRM-2: - Attachment: MRM-2-maven-repository-reports-standard.diff More unit tests. repository: transitive dependency report Key: MRM-2 URL: http://jira.codehaus.org/browse/MRM-2 Project: Maven Repository Manager Type: New Feature Components: reporting Reporter: Brett Porter Assignee: John Tolentino Fix For: 1.0-alpha-1 Attachments: MRM-2-maven-repository-reports-standard.diff, MRM-2-maven-repository-reports-standard.diff, MRM-2-maven-repository-reports-standard.diff Original Estimate: 2 days Time Spent: 4 hours Remaining: 1 day, 20 hours repository tool to ensure that transitive dependencies will work. we basically need to know that every artifact that is referenced in one POM is actually in the repository along with its POM. We need to know that the dependency relationships among all artifacts in the repository form a closed set. otherwise the transitive dependency mechanism in m2 will break and we need to be wary of this. eventually i would like to create graphical representations of the dependencies amongst projects but this can come later. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPARTIFACT-61) scpexe is a noop
[ http://jira.codehaus.org/browse/MPARTIFACT-61?page=comments#action_52862 ] Joerg Schaible commented on MPARTIFACT-61: -- Well, as already said, exec for Linux Windows is quite different. For scp I have always an AuthenticationException for my privatekey and passphrase. I can use ssh -i id_file without problems though ... = % jar:deploy: [echo] Deploying... Using userBuildPropertiesFile: C:\Dokumente und Einstellungen\jos\build.properties Using projectPropertiesFile: C:\Work\Projects\commons\test\project.properties Using projectBuildPropertiesFile: C:\Work\Projects\commons\test\build.properties Will deploy to 1 repository(ies): elsag Deploying to repository: elsag Failed to deploy to: elsag Reason: org.apache.maven.wagon.authentication.AuthenticationException: Cannot connect. Reason: Auth fail org.apache.maven.wagon.authentication.AuthenticationException: Cannot connect. Reason: Auth fail at org.apache.maven.wagon.providers.ssh.ScpWagon.openConnection(ScpWagon.java:164) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:123) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:90) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deployFiles(DefaultArtifactDeployer.java:376) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.doDeploy(DefaultArtifactDeployer.java:324) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.handleDeploy(DefaultArtifactDeployer.java:131) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:102) at org.apache.maven.artifact.deployer.DeployBean.deploy(DeployBean.java:142) 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.apache.commons.jelly.impl.DynamicBeanTag.doTag(DynamicBeanTag.java:230) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135) at org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79) at org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110) at com.werken.werkz.Goal.fire(Goal.java:639) at com.werken.werkz.Goal.attain(Goal.java:575) at org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:671) at org.apache.maven.MavenSession.attainGoals(MavenSession.java:263) at org.apache.maven.cli.App.doMain(App.java:488) at org.apache.maven.cli.App.main(App.java:1239) 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 com.werken.forehead.Forehead.run(Forehead.java:551) at com.werken.forehead.Forehead.main(Forehead.java:581) Caused by: com.jcraft.jsch.JSchException: Auth fail at com.jcraft.jsch.Session.connect(Unknown Source) at org.apache.maven.wagon.providers.ssh.ScpWagon.openConnection(ScpWagon.java:158) ... 31 more scpexe is a noop Key: MPARTIFACT-61 URL: http://jira.codehaus.org/browse/MPARTIFACT-61 Project: maven-artifact-plugin Type: Bug Versions: 1.5.2 Environment: Windows / Cygwin / Maven 1.0.2 / JDK 1.4.2 Reporter: Joerg Schaible Priority: Blocker Fix For: 1.5.3 Unfortunatel scpexe protocoll seems a noop in version 1.5.2. The executable is not called, but Maven is reporting happily that it has deployed: jar:deploy: [echo] Deploying... Using userBuildPropertiesFile: C:\Dokumente und Einstellungen\jos\build.properties Using projectPropertiesFile: C:\Work\Projects\commons\lang\project.properties Using projectBuildPropertiesFile: C:\Work\Projects\commons\lang\build.properties Will deploy to 1 repository(ies): elsag Deploying to repository: elsag Uploading to elsag-commons/poms/elsag-lang-1.2-SNAPSHOT.pom: (7K) Uploading to elsag-commons/poms/elsag-lang-snapshot-version: (0K) Uploading to elsag-commons/poms/elsag-lang-1.2-20051011.091919.pom: (7K) Will deploy to 1 repository(ies):
[jira] Updated: (MNG-804) maven.jar.override usage in m2
[ http://jira.codehaus.org/browse/MNG-804?page=all ] Allan Ramirez updated MNG-804: -- Attachment: m1-m2-changes.apt For review maven.jar.override usage in m2 -- Key: MNG-804 URL: http://jira.codehaus.org/browse/MNG-804 Project: Maven 2 Type: Sub-task Components: documentation - general Reporter: Natalie Burdick Assignee: Allan Ramirez Priority: Minor Fix For: 2.0.2 Attachments: m1-m2-changes.apt refer to: http://mail-archives.apache.org/mod_mbox/maven-users/200508.mbox/[EMAIL PROTECTED] to document that unlike m1, m2 no longer allow jar overrides via the maven.jar.override property -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JXR-5) JXR report html malformed
[ http://jira.codehaus.org/browse/JXR-5?page=comments#action_52865 ] Emmanuel Venisse commented on JXR-5: https://svn.apache.org/repos/asf/maven/jxr/trunk JXR report html malformed - Key: JXR-5 URL: http://jira.codehaus.org/browse/JXR-5 Project: Maven JXR Type: Bug Versions: 1.0-beta-1 Reporter: mike perham Fix For: 1.0-beta-1 Here's a sample of the HTML generated. Note the invalid links and the unresolved $name variable: html xml:lang=en lang=en head meta http-equiv=content-type content=text/html; charset=ISO-8859-1 / titleWSF TripleStore SPI 2.2.0-SNAPSHOT Reference Package $name/title link rel=stylesheet type=text/css href=\.\./\.\./\.\./\.\./\.\./stylesheet.css title=style / /head body div class=overview ul li a href=\.\./\.\./\.\./\.\./\.\./overview-summary.htmlOverview/a /li li class=selectedPackage/li /ul /div div class=framenoframe ul li a href=\.\./\.\./\.\./\.\./\.\./index.html target=_topFRAMES/a /li -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1643) Provide installer support like NSIS or InnoSetup
[ http://jira.codehaus.org/browse/MNG-1643?page=all ] Vincent Siveton updated MNG-1643: - Attachment: MNG-1643.diff plexus-installer.diff Brett, I created a new plexus component, called plexus-installer. Out of box installers are NSIS and IIS. I also modified the assembly plugin. WDYT? Provide installer support like NSIS or InnoSetup Key: MNG-1643 URL: http://jira.codehaus.org/browse/MNG-1643 Project: Maven 2 Type: New Feature Components: maven-assembly-plugin Reporter: Vincent Siveton Attachments: MNG-1643.diff, MNG-1643.diff, maven-assembly-plugin.zip, plexus-installer.diff Add the support of installer compiler like NSIS or InnoSetup. See the thread: http://www.nabble.com/m2-developers-rfc%3A-The-assembly-plugin-ans-thirdparty-installation-builders-%28REPOST%29-t57.html#a1546470 -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[REPOCLEAN] Error(s) occurred while converting repository
Errors occurred while performing maven-1 to maven-2 repository conversion. For more details, see: http://test.maven.codehaus.org/reports/repoclean/06-Dec-2005_08.32.31/repository.report.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: site update
I didn't have time, it will be update before the release Emmanuel Wim Deblauwe a écrit : Hi, my patch http://jira.codehaus.org/browse/SCM-95 has not been applied yet. Is there a specific reason? regards, Wim
Please Reopen - Re: [jira] Closed: (MEV-136) MyFaces requires commons-digester and commons-el
On 11/24/05, Edwin Punzalan (JIRA) [EMAIL PROTECTED] wrote: [ http://jira.codehaus.org/browse/MEV-136?page=all ] Edwin Punzalan closed MEV-136: -- Resolution: Fixed Matt's comment on 23/Nov/05 seems not to be resolved. The 1.1.0 and 1.1.1 myfaces-parent poms still have the extra '' after 'provided' in the ibiblio repository: http://www.ibiblio.org/maven2/myfaces/myfaces-parent/1.1.1/myfaces-parent-1.1.1.pom http://www.ibiblio.org/maven2/myfaces/myfaces-parent/1.1.0/myfaces-parent-1.1.0.pom Thanks, Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-136) MyFaces requires commons-digester and commons-el
[ http://jira.codehaus.org/browse/MEV-136?page=comments#action_52873 ] Wendy Smoak commented on MEV-136: - Both the 1.1.1 and 1.1.0 POMs on ibiblio still have the extra '' after 'provided' for the JSP api artifact. (See Matt's 23/Nov/05 comment.) http://ibiblio.org/maven2/myfaces/myfaces-parent/1.1.1/myfaces-parent-1.1.1.pom http://ibiblio.org/maven2/myfaces/myfaces-parent/1.1.0/myfaces-parent-1.1.0.pom Thanks! MyFaces requires commons-digester and commons-el Key: MEV-136 URL: http://jira.codehaus.org/browse/MEV-136 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Matt Raible Assignee: Edwin Punzalan Here's a revised version: project modelVersion4.0.0/modelVersion groupIdmyfaces/groupId artifactIdmyfaces-all/artifactId version1.1.0/version dependencies dependency groupIdcommons-digester/groupId artifactIdcommons-digester/artifactId version1.5/version /dependency dependency groupIdcommons-el/groupId artifactIdcommons-el/artifactId version1.0/version /dependency /dependencies /project -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[maven2 build - SUCCESS - update] Tue Dec 6 14:15:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051206.141500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051206.141500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MEV-245) Tomcat 4.1.31 missing
[ http://jira.codehaus.org/browse/MEV-245?page=comments#action_52875 ] Tomislav Stojcevich commented on MEV-245: - Shouldn't the sync take care of it? It looks like the jars made it into the maven1 repository. http://www.ibiblio.org/maven/tomcat/jars/ The bottom of the page you referenced states that there is automatic syncronization between apache and ibiblio. Tomcat 4.1.31 missing - Key: MEV-245 URL: http://jira.codehaus.org/browse/MEV-245 Project: Maven Evangelism Type: Bug Reporter: Tomislav Stojcevich Not sure if this is the correct place to ask this becase the instructions on the maven2 site are not specific. Let me know what the correct procedures are if this is not the right place. I asked the Tomcat team to add Tomcat 4.1.31 to the Apache repository. They did that. See: http://www.apache.org/dist/java-repository/tomcat/jars/ It looks like the directories got created for maven2 but no jars or poms. What needs to be done now to get the jars and poms in the central repository for maven2? Specifically I need jasper-compiler and jasper-runtime. I know somebody else asked about catalina in the mailing list a while back. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1471) Module paths for system scope are relative to parent pom instead of its own
[ http://jira.codehaus.org/browse/MNG-1471?page=comments#action_52874 ] Matthew Wheaton commented on MNG-1471: -- Hi John, I think your assessment is correct in that I think my usage model of Maven is a convenience wrapper around ANT, and using the event driven model around compilation, etc. I'm going to stick with Maven 2 and see if there's any other issues that crop up, but I'm going to try and adopt the Maven 2 usage model as closely as possible. thx all, mw Module paths for system scope are relative to parent pom instead of its own --- Key: MNG-1471 URL: http://jira.codehaus.org/browse/MNG-1471 Project: Maven 2 Type: Bug Components: maven-compiler-plugin Versions: 2.0 Environment: Win XP, Maven 2.0 Reporter: Jeff Jensen Assignee: John Casey Priority: Critical Fix For: 2.0.1 Attachments: MNG-1471-maven-project.patch Original Estimate: 30 minutes Remaining: 30 minutes When building from the parent POM dir, all paths are relative to it. A problem occurs when its modules have dependencies of scopesystem/scope - the module's corresponding systemPath is relative to the parent POM dir, instead of the module's POM dir. With a module's systemPath set to compile correctly it on its own, compiling from its parent POM dir gives this error: [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: thegrp ArtifactId: subsystem Version: 2.1-SNAPSHOT Reason: System artifact: thegrp:subsystem:jar:2.1-SNAPSHOT not found in path: src\lib\subsystem.jar thegrp:subsystem:2.1-SNAPSHOT:jar (would be nice to have the fully qualified path name listed there, instead of the relative one so users would know where it is really looking for it from) Expected behavior is that Maven treats system scope paths relative to the module POM, not the parent's POM. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-661) In parent site, automatically create link to modules sites and vice-versa
[ http://jira.codehaus.org/browse/MNG-661?page=all ] Vincent Siveton closed MNG-661: --- Resolution: Fixed Applied. Thanks John! In parent site, automatically create link to modules sites and vice-versa - Key: MNG-661 URL: http://jira.codehaus.org/browse/MNG-661 Project: Maven 2 Type: Improvement Components: maven-site-plugin Versions: 2.0-alpha-3 Reporter: Yann Le Du Assignee: Vincent Siveton Priority: Minor Fix For: 2.0.2 Attachments: MNG-661.diff, MNG-661.diff, SiteMojoPatch.txt, SiteMojoPatch.txt, SiteMojoPatch.txt, site-plugin-multiproject.zip Say we have the following project structure : A +-- B +-- C +-- D It would be nice to have the following links in the left menu of the generated sites : A : Modules : B, D B : Parent : A Modules : C C : Parent : B D : Parent : A -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1764) Failed to deploy to a remote repository
Failed to deploy to a remote repository --- Key: MNG-1764 URL: http://jira.codehaus.org/browse/MNG-1764 Project: Maven 2 Type: Bug Components: maven-deploy-plugin Versions: 2.0 Environment: Linux Fedora, 32bit, Maven2 Reporter: Nic It seems that 'mvn deploy' doesn't work when deploying to a remoty repository using scp/scpexe protocol pom.xml: ... distributionManagement repository idcorp-repository/id urlscpexe://[EMAIL PROTECTED]/var/maven2/repos/url /repository site idwebsite/id urlscpexe://[EMAIL PROTECTED]/usr/local/apache2/htdocs/projects/proj1//url /site /distributionManagement ... settings.xml: servers server idwebserver/id usernameuser/username privateKey~/.ssh/id_rsa/privateKey /server server idcorp-repository/id usernameuser/username privateKey~/.ssh/id_rsa/privateKey /server /servers When I issue the command 'mvn site:deploy' - it works When I issue the command 'mvn deploy' - it doesn't work. The reason is: Exit code 255 - Permission denied (publickey,password). When I issue the command 'scp a.file [EMAIL PROTECTED]:/var/maven2/repos' - it works I have no idea how to make 'mvn deploy' work. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-983) add staging site capabilities
[ http://jira.codehaus.org/browse/MNG-983?page=all ] Vincent Siveton closed MNG-983: --- Resolution: Fixed Created a new SiteStageMojo add staging site capabilities - Key: MNG-983 URL: http://jira.codehaus.org/browse/MNG-983 Project: Maven 2 Type: Improvement Components: maven-site-plugin Reporter: Brett Porter -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (CONTINUUM-485) Add a default build definition for ant project
[ http://jira.codehaus.org/browse/CONTINUUM-485?page=all ] Emmanuel Venisse closed CONTINUUM-485: -- Assign To: Emmanuel Venisse Resolution: Fixed Applied with some modifications. Add a default build definition for ant project -- Key: CONTINUUM-485 URL: http://jira.codehaus.org/browse/CONTINUUM-485 Project: Continuum Type: Improvement Reporter: Emmanuel Venisse Assignee: Emmanuel Venisse Fix For: 1.0.2 Attachments: CONTINUUM-485-continuum-core.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
[continuum build - FAILED - update] Tue Dec 6 14:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051206.143000.txt
[maven2 build - SUCCESS - update] Tue Dec 6 14:30:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20051206.143000.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051206.143000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1762) Exclude files svn from archive.
[ http://jira.codehaus.org/browse/MNG-1762?page=all ] Stephane Nicoll closed MNG-1762: Resolution: Duplicate I hope I fully understand your problem. This is already fixed and will be available as of maven-ear-plugin 2.1 See linked issue for more details. Exclude files svn from archive. --- Key: MNG-1762 URL: http://jira.codehaus.org/browse/MNG-1762 Project: Maven 2 Type: New Feature Components: maven-ear-plugin Reporter: Dmitrij Khayretdinov Assignee: Stephane Nicoll Priority: Minor At assembly of archive in it files svn from src/main/application get. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1471) Module paths for system scope are relative to parent pom instead of its own
[ http://jira.codehaus.org/browse/MNG-1471?page=comments#action_52882 ] Jeff Jensen commented on MNG-1471: -- John, Matt's may be what you describe, but ours is not. I gleefully shed anything Ant-ish when I began using Maven. My situation is described in my comment on 10/Nov/05 11:48 AM]. Brett's comment on 05/Dec/05 04:45 PM sounds right on for our situation. Module paths for system scope are relative to parent pom instead of its own --- Key: MNG-1471 URL: http://jira.codehaus.org/browse/MNG-1471 Project: Maven 2 Type: Bug Components: maven-compiler-plugin Versions: 2.0 Environment: Win XP, Maven 2.0 Reporter: Jeff Jensen Assignee: John Casey Priority: Critical Fix For: 2.0.1 Attachments: MNG-1471-maven-project.patch Original Estimate: 30 minutes Remaining: 30 minutes When building from the parent POM dir, all paths are relative to it. A problem occurs when its modules have dependencies of scopesystem/scope - the module's corresponding systemPath is relative to the parent POM dir, instead of the module's POM dir. With a module's systemPath set to compile correctly it on its own, compiling from its parent POM dir gives this error: [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: thegrp ArtifactId: subsystem Version: 2.1-SNAPSHOT Reason: System artifact: thegrp:subsystem:jar:2.1-SNAPSHOT not found in path: src\lib\subsystem.jar thegrp:subsystem:2.1-SNAPSHOT:jar (would be nice to have the fully qualified path name listed there, instead of the relative one so users would know where it is really looking for it from) Expected behavior is that Maven treats system scope paths relative to the module POM, not the parent's POM. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (SCM-101) Clean scm url in AbstractScmManager when scmurl contains ../
Clean scm url in AbstractScmManager when scmurl contains ../ -- Key: SCM-101 URL: http://jira.codehaus.org/browse/SCM-101 Project: Maven SCM Type: Improvement Components: maven-scm-api Versions: 1.0-beta-1 Reporter: Emmanuel Venisse Fix For: 1.0-beta-2 scm url like this scm:provider:path_to_repository/directory1/../directory2 must be clean to scm:provider:path_to_repository/directory2 before to run scm commands -- 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
[continuum build - FAILED - update] Tue Dec 6 15:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051206.15.txt
[maven2 build - FAILED - update] Tue Dec 6 16:30:00 GMT 2005
Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20051206.163000.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1696) war includes and excludes don't handle comma separated tokens (patch included)
[ http://jira.codehaus.org/browse/MNG-1696?page=comments#action_52886 ] Marcel Schutte commented on MNG-1696: - Please take a look at EarMojo from maven-ear-plugin as well. This one has similar getExcludes() and getIncludes() methods. war includes and excludes don't handle comma separated tokens (patch included) -- Key: MNG-1696 URL: http://jira.codehaus.org/browse/MNG-1696 Project: Maven 2 Type: Bug Components: maven-war-plugin Reporter: David Hawkins Attachments: MNG-1696-maven-war-plugin.patch The documentation for warSourceIncludes, warSourceExcludes, dependantWarIncludes, and dependantWarExcludes all state something that they support comma delimited tokens but it simply doesn't work when a comma is specified. This patch makes all four parameters properly process comma delimited values. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (JXR-5) JXR report html malformed
[ http://jira.codehaus.org/browse/JXR-5?page=comments#action_52887 ] mike perham commented on JXR-5: --- Here's an ugly but working patch: Index: src/main/java/org/apache/maven/jxr/DirectoryIndexer.java === --- src/main/java/org/apache/maven/jxr/DirectoryIndexer.java(revision 354452) +++ src/main/java/org/apache/maven/jxr/DirectoryIndexer.java(working copy) @@ -347,6 +347,8 @@ String pkgName = pkg.getName(); String pkgDir = perl.substitute( s/\\./\\//g, pkgName ); String rootRef = perl.substitute( s/[^\\.]*(\\.|$)/\\.\\.\\//g, pkgName ); + // TODO Ugly hack to remove spurious backslashes, see JXR-5 + rootRef = perl.substitute( s///g, rootRef ); // special case for the default package // javadoc doesn't deal with it, but it's easy for us JXR report html malformed - Key: JXR-5 URL: http://jira.codehaus.org/browse/JXR-5 Project: Maven JXR Type: Bug Versions: 1.0-beta-1 Reporter: mike perham Fix For: 1.0-beta-1 Here's a sample of the HTML generated. Note the invalid links and the unresolved $name variable: html xml:lang=en lang=en head meta http-equiv=content-type content=text/html; charset=ISO-8859-1 / titleWSF TripleStore SPI 2.2.0-SNAPSHOT Reference Package $name/title link rel=stylesheet type=text/css href=\.\./\.\./\.\./\.\./\.\./stylesheet.css title=style / /head body div class=overview ul li a href=\.\./\.\./\.\./\.\./\.\./overview-summary.htmlOverview/a /li li class=selectedPackage/li /ul /div div class=framenoframe ul li a href=\.\./\.\./\.\./\.\./\.\./index.html target=_topFRAMES/a /li -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1764) Failed to deploy to a remote repository
[ http://jira.codehaus.org/browse/MNG-1764?page=comments#action_52889 ] John Casey commented on MNG-1764: - it may be failing to create the directories needed to support the artifact inside that repository's layout...for example, if you have: org.apache.maven.test:test-project:1.0 you'd need permission to issue: mkdir -p org/apache/maven/test/test-project/1.0 inside your chosen repository location, rather than simply uploading the file to the repository's root dir. Can you verify that you're able to do this manually? Also, could you add another comment with the relevant output from the build? This *should* include the command lines that are running...(cleaned up to remove user/passwords, and protect the innocent, of course ;) Failed to deploy to a remote repository --- Key: MNG-1764 URL: http://jira.codehaus.org/browse/MNG-1764 Project: Maven 2 Type: Bug Components: maven-deploy-plugin Versions: 2.0 Environment: Linux Fedora, 32bit, Maven2 Reporter: Nic It seems that 'mvn deploy' doesn't work when deploying to a remoty repository using scp/scpexe protocol pom.xml: ... distributionManagement repository idcorp-repository/id urlscpexe://[EMAIL PROTECTED]/var/maven2/repos/url /repository site idwebsite/id urlscpexe://[EMAIL PROTECTED]/usr/local/apache2/htdocs/projects/proj1//url /site /distributionManagement ... settings.xml: servers server idwebserver/id usernameuser/username privateKey~/.ssh/id_rsa/privateKey /server server idcorp-repository/id usernameuser/username privateKey~/.ssh/id_rsa/privateKey /server /servers When I issue the command 'mvn site:deploy' - it works When I issue the command 'mvn deploy' - it doesn't work. The reason is: Exit code 255 - Permission denied (publickey,password). When I issue the command 'scp a.file [EMAIL PROTECTED]:/var/maven2/repos' - it works I have no idea how to make 'mvn deploy' work. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1471) Module paths for system scope are relative to parent pom instead of its own
[ http://jira.codehaus.org/browse/MNG-1471?page=comments#action_52888 ] John Casey commented on MNG-1471: - You have your third party libraries in SCM, and it's been decided that this should remain the case...how would this preclude your using an SCM-based Maven repository? As I mentioned in my comment to Matthew on 05-Dec, the Maven-Wagon project does have an SCM provider (not sure what the status of it is, though). This, along with a custom artifact repository layout (to adapt to non-m2-ish layout of your /lib), should enable you to resolve those libraries without any custom design on the part of Maven. While this practice has not been fully realized yet, there is nothing tying users to the default Maven 2.x repository layout for their own repository instances; you only need to have an appropriate ArtifactRepositoryLayout and the right wagon provider in place. These two tasks are still non-trivial, but possible with the current implementation. Would this solve your problem? Would there be any problem with checking in POMs for those third party libraries, to help make transitive dependencies possible for those? If not, it's still possible to use them. Module paths for system scope are relative to parent pom instead of its own --- Key: MNG-1471 URL: http://jira.codehaus.org/browse/MNG-1471 Project: Maven 2 Type: Bug Components: maven-compiler-plugin Versions: 2.0 Environment: Win XP, Maven 2.0 Reporter: Jeff Jensen Assignee: John Casey Priority: Critical Fix For: 2.0.1 Attachments: MNG-1471-maven-project.patch Original Estimate: 30 minutes Remaining: 30 minutes When building from the parent POM dir, all paths are relative to it. A problem occurs when its modules have dependencies of scopesystem/scope - the module's corresponding systemPath is relative to the parent POM dir, instead of the module's POM dir. With a module's systemPath set to compile correctly it on its own, compiling from its parent POM dir gives this error: [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. GroupId: thegrp ArtifactId: subsystem Version: 2.1-SNAPSHOT Reason: System artifact: thegrp:subsystem:jar:2.1-SNAPSHOT not found in path: src\lib\subsystem.jar thegrp:subsystem:2.1-SNAPSHOT:jar (would be nice to have the fully qualified path name listed there, instead of the relative one so users would know where it is really looking for it from) Expected behavior is that Maven treats system scope paths relative to the module POM, not the parent's POM. -- 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
