[jira] Commented: (MNG-4869) Warn when relativePath points at parent POM with different version
[
http://jira.codehaus.org/browse/MNG-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=240135#action_240135
]
Joern Huxhorn commented on MNG-4869:
I just read at http://www.developer.com/open/article.php/3908561/article.htm
"3. Automatic Parent Versioning" that the version of the parent pom will soon
(i.e. in Maven 3.1) be optional.
In that case an explicit version would already resemble an "I really mean it"
marker, making this whole suggestion/issue mostly unnecessary.
My suggestion of printing a warning message was based on the assumption that
the parent version would still be required.
> Warn when relativePath points at parent POM with different version
> --
>
> Key: MNG-4869
> URL: http://jira.codehaus.org/browse/MNG-4869
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.0
> Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
>Reporter: Joern Huxhorn
>Priority: Trivial
> Attachments: MNG-4869.zip
>
>
> We have the following situation in our project:
> A parent pom containing the following infos:
> {code:xml}
>
> 6.1.9
>
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
> ${jettyVersion}
>
>
>
> {code}
> A child module with the following configuration:
> {code:xml}
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
>
>
> org.mortbay.jetty
> jetty-plus
> ${jettyVersion}
>
>
> org.mortbay.jetty
> jetty-naming
> ${jettyVersion}
>
>
>
>
>
> {code}
> The property jettyVersion was added during the latest. The parent pom is the
> first sub-module in the master pom, followed by the other sub-modules
> including the child-module above. All definitions include correct
> entries.
> Previously, it worked perfectly well to simply build the master pom, which in
> turn built the parent followed by all other sub-modules.
> Since Maven 3, however, this didn't work anymore. Right after the addition of
> the jettyVersion property, Maven 3 complained with the following error:
> {noformat}
> [ERROR] The build could not read 24 projects -> [Help 1]
> [ERROR]
> [ERROR] The project xyz:2.0.0-SNAPSHOT (/path/to/child/pom.xml) has 2 errors
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-plus:jar must be a valid version but is
> '${jettyVersion}'. @ line 28, column 28
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-naming:jar must be a valid version but is
> '${jettyVersion}'. @ line 33, column 28
> {noformat}
> Building the parent manually fixed this issue.
> To be precise, our actual project involved another parent level, i.e. the
> parent described above was the parent of parent2 while parent2 was the parent
> of the child module - but I don't think that this is relevant. I'm just
> mentioning it just in case. Again, all definitions include correct
> entries.
> This worked in Maven 2 so I think it's a regression.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4869) Warn when relativePath points at parent POM with different version
[
http://jira.codehaus.org/browse/MNG-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=240024#action_240024
]
Joern Huxhorn commented on MNG-4869:
I didn't mean to imply you were wrong.
Instead I obviously had the wrong impression all the time. If my last comment
sounded offensive it definitely wasn't meant to do so. I was merely surprised.
Thanks for taking the time to analyze this.
> Warn when relativePath points at parent POM with different version
> --
>
> Key: MNG-4869
> URL: http://jira.codehaus.org/browse/MNG-4869
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.0
> Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
>Reporter: Joern Huxhorn
>Priority: Trivial
> Attachments: MNG-4869.zip
>
>
> We have the following situation in our project:
> A parent pom containing the following infos:
> {code:xml}
>
> 6.1.9
>
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
> ${jettyVersion}
>
>
>
> {code}
> A child module with the following configuration:
> {code:xml}
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
>
>
> org.mortbay.jetty
> jetty-plus
> ${jettyVersion}
>
>
> org.mortbay.jetty
> jetty-naming
> ${jettyVersion}
>
>
>
>
>
> {code}
> The property jettyVersion was added during the latest. The parent pom is the
> first sub-module in the master pom, followed by the other sub-modules
> including the child-module above. All definitions include correct
> entries.
> Previously, it worked perfectly well to simply build the master pom, which in
> turn built the parent followed by all other sub-modules.
> Since Maven 3, however, this didn't work anymore. Right after the addition of
> the jettyVersion property, Maven 3 complained with the following error:
> {noformat}
> [ERROR] The build could not read 24 projects -> [Help 1]
> [ERROR]
> [ERROR] The project xyz:2.0.0-SNAPSHOT (/path/to/child/pom.xml) has 2 errors
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-plus:jar must be a valid version but is
> '${jettyVersion}'. @ line 28, column 28
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-naming:jar must be a valid version but is
> '${jettyVersion}'. @ line 33, column 28
> {noformat}
> Building the parent manually fixed this issue.
> To be precise, our actual project involved another parent level, i.e. the
> parent described above was the parent of parent2 while parent2 was the parent
> of the child module - but I don't think that this is relevant. I'm just
> mentioning it just in case. Again, all definitions include correct
> entries.
> This worked in Maven 2 so I think it's a regression.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4869) Warn when relativePath points at parent POM with different version
[
http://jira.codehaus.org/browse/MNG-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=240018#action_240018
]
Joern Huxhorn commented on MNG-4869:
I just read that the behavior didn't change in Maven 3. Sure? I had the
impression that the parent pom at the relative path was always taking
precedence over poms from the local repository.
> Warn when relativePath points at parent POM with different version
> --
>
> Key: MNG-4869
> URL: http://jira.codehaus.org/browse/MNG-4869
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.0
> Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
>Reporter: Joern Huxhorn
>Priority: Trivial
> Attachments: MNG-4869.zip
>
>
> We have the following situation in our project:
> A parent pom containing the following infos:
> {code:xml}
>
> 6.1.9
>
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
> ${jettyVersion}
>
>
>
> {code}
> A child module with the following configuration:
> {code:xml}
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
>
>
> org.mortbay.jetty
> jetty-plus
> ${jettyVersion}
>
>
> org.mortbay.jetty
> jetty-naming
> ${jettyVersion}
>
>
>
>
>
> {code}
> The property jettyVersion was added during the latest. The parent pom is the
> first sub-module in the master pom, followed by the other sub-modules
> including the child-module above. All definitions include correct
> entries.
> Previously, it worked perfectly well to simply build the master pom, which in
> turn built the parent followed by all other sub-modules.
> Since Maven 3, however, this didn't work anymore. Right after the addition of
> the jettyVersion property, Maven 3 complained with the following error:
> {noformat}
> [ERROR] The build could not read 24 projects -> [Help 1]
> [ERROR]
> [ERROR] The project xyz:2.0.0-SNAPSHOT (/path/to/child/pom.xml) has 2 errors
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-plus:jar must be a valid version but is
> '${jettyVersion}'. @ line 28, column 28
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-naming:jar must be a valid version but is
> '${jettyVersion}'. @ line 33, column 28
> {noformat}
> Building the parent manually fixed this issue.
> To be precise, our actual project involved another parent level, i.e. the
> parent described above was the parent of parent2 while parent2 was the parent
> of the child module - but I don't think that this is relevant. I'm just
> mentioning it just in case. Again, all definitions include correct
> entries.
> This worked in Maven 2 so I think it's a regression.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4869) Warn when relativePath points at parent POM with different version
[
http://jira.codehaus.org/browse/MNG-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=240017#action_240017
]
Joern Huxhorn commented on MNG-4869:
Ok, I see.
The MNG-4619 feature did actually help me already while migrating from Maven 2
to Maven 3. I liked it a lot. The enhanced diagnostic messages are the main
Maven 3 feature for me, at least for now.
I think, but that's of course only my opinion, that a version mismatch in the
presence of a relative path is at least somewhat strange. It would probably be
a case for some "I really mean it" marker for the parent version or an option
to disable such a check.
In our 360 module project such a situation would always be a mistake. But
others might use Maven differently.
Otherwise an issue like the one that bit me is pretty hard to diagnose,
especially since the behavior changed from Maven 2. I double- and
triple-checked the relative path but overlooked the version issue repeatedly.
> Warn when relativePath points at parent POM with different version
> --
>
> Key: MNG-4869
> URL: http://jira.codehaus.org/browse/MNG-4869
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: POM
>Affects Versions: 3.0
> Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
>Reporter: Joern Huxhorn
>Priority: Trivial
> Attachments: MNG-4869.zip
>
>
> We have the following situation in our project:
> A parent pom containing the following infos:
> {code:xml}
>
> 6.1.9
>
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
> ${jettyVersion}
>
>
>
> {code}
> A child module with the following configuration:
> {code:xml}
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
>
>
> org.mortbay.jetty
> jetty-plus
> ${jettyVersion}
>
>
> org.mortbay.jetty
> jetty-naming
> ${jettyVersion}
>
>
>
>
>
> {code}
> The property jettyVersion was added during the latest. The parent pom is the
> first sub-module in the master pom, followed by the other sub-modules
> including the child-module above. All definitions include correct
> entries.
> Previously, it worked perfectly well to simply build the master pom, which in
> turn built the parent followed by all other sub-modules.
> Since Maven 3, however, this didn't work anymore. Right after the addition of
> the jettyVersion property, Maven 3 complained with the following error:
> {noformat}
> [ERROR] The build could not read 24 projects -> [Help 1]
> [ERROR]
> [ERROR] The project xyz:2.0.0-SNAPSHOT (/path/to/child/pom.xml) has 2 errors
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-plus:jar must be a valid version but is
> '${jettyVersion}'. @ line 28, column 28
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-naming:jar must be a valid version but is
> '${jettyVersion}'. @ line 33, column 28
> {noformat}
> Building the parent manually fixed this issue.
> To be precise, our actual project involved another parent level, i.e. the
> parent described above was the parent of parent2 while parent2 was the parent
> of the child module - but I don't think that this is relevant. I'm just
> mentioning it just in case. Again, all definitions include correct
> entries.
> This worked in Maven 2 so I think it's a regression.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MNG-4869) Parent POM is not evaluated as expected, regression in Maven 3
[
http://jira.codehaus.org/browse/MNG-4869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joern Huxhorn reopened MNG-4869:
You are right, the original description missed a crucial piece of information
that I just discovered:
The parent-version requested in the child pom was different from the version as
defined in the parent pom itself, i.e. the parent had
1.0-SNAPSHOT while the child requested
2.0-SNAPSHOT.
This mistake didn't hurt in Maven 2 since (I guess) the parent version was
ignored in the presence of a valid relativePath. This seems to have changed in
Maven 3, which is actually ok/correct.
I tentatively reopened this issue anyway since I think that Maven 3 should
warn/fail in such a situation. This obviously isn't a critical issue anymore,
though.
Please let me know how we should handle this. Should I file a new issue
(feature request) or will you change this one accordingly?
Interestingly, the title isn't that incorrect after all...
> Parent POM is not evaluated as expected, regression in Maven 3
> --
>
> Key: MNG-4869
> URL: http://jira.codehaus.org/browse/MNG-4869
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0
> Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
> Java version: 1.6.0_20
> Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
> Default locale: en_US, platform encoding: MacRoman
> OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
>Reporter: Joern Huxhorn
>Assignee: Benjamin Bentmann
>Priority: Critical
> Attachments: MNG-4869.zip
>
>
> We have the following situation in our project:
> A parent pom containing the following infos:
>
> 6.1.9
>
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
> ${jettyVersion}
>
>
>
> A child module with the following configuration:
>
>
>
> org.mortbay.jetty
> maven-jetty-plugin
>
>
> org.mortbay.jetty
> jetty-plus
> ${jettyVersion}
>
>
> org.mortbay.jetty
> jetty-naming
> ${jettyVersion}
>
>
>
>
>
> The property jettyVersion was added during the latest. The parent pom is the
> first sub-module in the master pom, followed by the other sub-modules
> including the child-module above. All definitions include correct
> entries.
> Previously, it worked perfectly well to simply build the master pom, which in
> turn built the parent followed by all other sub-modules.
> Since Maven 3, however, this didn't work anymore. Right after the addition of
> the jettyVersion property, Maven 3 complained with the following error:
> [ERROR] The build could not read 24 projects -> [Help 1]
> [ERROR]
> [ERROR] The project xyz:2.0.0-SNAPSHOT (/path/to/child/pom.xml) has 2 errors
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-plus:jar must be a valid version but is
> '${jettyVersion}'. @ line 28, column 28
> [ERROR]
> 'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
> for org.mortbay.jetty:jetty-naming:jar must be a valid version but is
> '${jettyVersion}'. @ line 33, column 28
> Building the parent manually fixed this issue.
> To be precise, our actual project involved another parent level, i.e. the
> parent described above was the parent of parent2 while parent2 was the parent
> of the child module - but I don't think that this is relevant. I'm just
> mentioning it just in case. Again, all definitions include correct
> entries.
> This worked in Maven 2 so I think it's a regression.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4869) Parent POM is not evaluated as expected, regression in Maven 3
Parent POM is not evaluated as expected, regression in Maven 3
--
Key: MNG-4869
URL: http://jira.codehaus.org/browse/MNG-4869
Project: Maven 2 & 3
Issue Type: Bug
Affects Versions: 3.0
Environment: Apache Maven 3.0 (r1004208; 2010-10-04 13:50:56+0200)
Java version: 1.6.0_20
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x" version: "10.6.4" arch: "x86_64" Family: "mac"
Reporter: Joern Huxhorn
Priority: Critical
We have the following situation in our project:
A parent pom containing the following infos:
6.1.9
org.mortbay.jetty
maven-jetty-plugin
${jettyVersion}
A child module with the following configuration:
org.mortbay.jetty
maven-jetty-plugin
org.mortbay.jetty
jetty-plus
${jettyVersion}
org.mortbay.jetty
jetty-naming
${jettyVersion}
The property jettyVersion was added during the latest. The parent pom is the
first sub-module in the master pom, followed by the other sub-modules including
the child-module above. All definitions include correct
entries.
Previously, it worked perfectly well to simply build the master pom, which in
turn built the parent followed by all other sub-modules.
Since Maven 3, however, this didn't work anymore. Right after the addition of
the jettyVersion property, Maven 3 complained with the following error:
[ERROR] The build could not read 24 projects -> [Help 1]
[ERROR]
[ERROR] The project xyz:2.0.0-SNAPSHOT (/path/to/child/pom.xml) has 2 errors
[ERROR]
'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
for org.mortbay.jetty:jetty-plus:jar must be a valid version but is
'${jettyVersion}'. @ line 28, column 28
[ERROR]
'build.plugins.plugin[org.mortbay.jetty:maven-jetty-plugin].dependencies.dependency.version'
for org.mortbay.jetty:jetty-naming:jar must be a valid version but is
'${jettyVersion}'. @ line 33, column 28
Building the parent manually fixed this issue.
To be precise, our actual project involved another parent level, i.e. the
parent described above was the parent of parent2 while parent2 was the parent
of the child module - but I don't think that this is relevant. I'm just
mentioning it just in case. Again, all definitions include correct
entries.
This worked in Maven 2 so I think it's a regression.
--
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: (MAVENUPLOAD-2164) Upload request for groupId's de.huxhorn.sulky and de.huxhorn.lilith
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joern Huxhorn closed MAVENUPLOAD-2164. -- Resolution: Not A Bug Argh, sorry... The artifacts have obviously arrived at http://repo1.maven.org/maven2/de/huxhorn/ They are simply not showing up at http://mirrors.ibiblio.org/pub/mirrors/maven2/de/huxhorn/ I always checked against that mirror... Who should be contacted because of this issue? > Upload request for groupId's de.huxhorn.sulky and de.huxhorn.lilith > --- > > Key: MAVENUPLOAD-2164 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2164 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Joern Huxhorn >Assignee: Carlos Sanchez > > "de.huxhorn.sulky","mavens...@shell.sourceforge.net:/home/groups/s/su/sulky/htdocs/repository",,"rsync_ssh","Joern > Huxhorn","huxh...@sf.net",, > "de.huxhorn.lilith","mavens...@shell.sourceforge.net:/home/groups/l/li/lilith/htdocs/repository",,"rsync_ssh","Joern > Huxhorn","huxh...@sf.net",, > This request is actually about two projects, sulky and lilith. > I added both URLs - as project and contributor URL. > I sincerely hope that I've done everything correctly since this is my very > first submission to the central maven repository. > I own the domain huxhorn.de as you can verify on http://www.denic.de > Therefore I also own sulky.huxhorn.de as well as lilith.huxhorn.de > I'm also the sole developer registered in the respective sourceforge projects > http://sf.net/projects/sulky > and > http://sf.net/projects/lilith > Since this form *requires* an upload bundle URL I entered a URL to the comma > separated sync file... > Please let me know if everything is OK or if somethings still wrong/missing. > Thank you. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MAVENUPLOAD-2164) Upload request for groupId's de.huxhorn.sulky and de.huxhorn.lilith
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=200307#action_200307 ] Joern Huxhorn edited comment on MAVENUPLOAD-2164 at 12/2/09 9:20 AM: - Didn't help at all, my artifacts are still missing from the central repository... Any idea what's wrong? groupId: de.huxhorn.lilith Error: Command line executed: /bin/sh -c 'rsync --include=*/ --include=**/maven-metadata.xml* --exclude=* --exclude-from=/home/maven/bin/synchronize/syncopate/exclusions.txt -Lrtivz "--rsh=ssh " [EMAIL PROTECTED]:/home/groups/l/li/lilith/htdocs/repository/de/huxhorn/lilith/ /home/maven/repository-staging/to-ibiblio/maven2/de/huxhorn/lilith/'org.codehaus.plexus.util.cli.CommandLineException: Error while executing external command, process killed.Error while executing external command, process killed.Process timeout out after 900 seconds groupId: de.huxhorn.sulky Error: Command line executed: /bin/sh -c 'rsync --include=*/ --include=**/maven-metadata.xml* --exclude=* --exclude-from=/home/maven/bin/synchronize/syncopate/exclusions.txt -Lrtivz "--rsh=ssh " [EMAIL PROTECTED]:/home/groups/s/su/sulky/htdocs/repository/de/huxhorn/sulky/ /home/maven/repository-staging/to-ibiblio/maven2/de/huxhorn/sulky/'org.codehaus.plexus.util.cli.CommandLineException: Error while executing external command, process killed.Error while executing external command, process killed.Process timeout out after 900 seconds was (Author: jhuxhorn): Didn't help at all, my artifacts are still missing from the central repository... Any idea what's wrong? > Upload request for groupId's de.huxhorn.sulky and de.huxhorn.lilith > --- > > Key: MAVENUPLOAD-2164 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2164 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Joern Huxhorn >Assignee: Carlos Sanchez > > "de.huxhorn.sulky","mavens...@shell.sourceforge.net:/home/groups/s/su/sulky/htdocs/repository",,"rsync_ssh","Joern > Huxhorn","huxh...@sf.net",, > "de.huxhorn.lilith","mavens...@shell.sourceforge.net:/home/groups/l/li/lilith/htdocs/repository",,"rsync_ssh","Joern > Huxhorn","huxh...@sf.net",, > This request is actually about two projects, sulky and lilith. > I added both URLs - as project and contributor URL. > I sincerely hope that I've done everything correctly since this is my very > first submission to the central maven repository. > I own the domain huxhorn.de as you can verify on http://www.denic.de > Therefore I also own sulky.huxhorn.de as well as lilith.huxhorn.de > I'm also the sole developer registered in the respective sourceforge projects > http://sf.net/projects/sulky > and > http://sf.net/projects/lilith > Since this form *requires* an upload bundle URL I entered a URL to the comma > separated sync file... > Please let me know if everything is OK or if somethings still wrong/missing. > Thank you. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2164) Upload request for groupId's de.huxhorn.sulky and de.huxhorn.lilith
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=200307#action_200307 ] Joern Huxhorn commented on MAVENUPLOAD-2164: Didn't help at all, my artifacts are still missing from the central repository... Any idea what's wrong? > Upload request for groupId's de.huxhorn.sulky and de.huxhorn.lilith > --- > > Key: MAVENUPLOAD-2164 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2164 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Joern Huxhorn >Assignee: Carlos Sanchez > > "de.huxhorn.sulky","mavens...@shell.sourceforge.net:/home/groups/s/su/sulky/htdocs/repository",,"rsync_ssh","Joern > Huxhorn","huxh...@sf.net",, > "de.huxhorn.lilith","mavens...@shell.sourceforge.net:/home/groups/l/li/lilith/htdocs/repository",,"rsync_ssh","Joern > Huxhorn","huxh...@sf.net",, > This request is actually about two projects, sulky and lilith. > I added both URLs - as project and contributor URL. > I sincerely hope that I've done everything correctly since this is my very > first submission to the central maven repository. > I own the domain huxhorn.de as you can verify on http://www.denic.de > Therefore I also own sulky.huxhorn.de as well as lilith.huxhorn.de > I'm also the sole developer registered in the respective sourceforge projects > http://sf.net/projects/sulky > and > http://sf.net/projects/lilith > Since this form *requires* an upload bundle URL I entered a URL to the comma > separated sync file... > Please let me know if everything is OK or if somethings still wrong/missing. > Thank you. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2164) Upload request for groupId's de.huxhorn.sulky and de.huxhorn.lilith
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199159#action_199159 ] Joern Huxhorn commented on MAVENUPLOAD-2164: Well, I've found this here: http://www.mail-archive.com/repo-maintain...@maven.apache.org/msg01599.html groupId: de.huxhorn.lilith Error: Command line executed: /bin/sh -c 'rsync --include=*/ --include=**/maven-metadata.xml* --exclude=* --exclude-from=/home/maven/bin/synchronize/syncopate/exclusions.txt -Lrtivz "--rsh=ssh " [EMAIL PROTECTED]:/home/groups/l/li/lilith/htdocs/repository/de/huxhorn/lilith/ /home/maven/repository-staging/to-ibiblio/maven2/de/huxhorn/lilith/'org.codehaus.plexus.util.cli.CommandLineException: Error while executing external command, process killed.Error while executing external command, process killed.Process timeout out after 900 seconds groupId: de.huxhorn.sulky Error: Command line executed: /bin/sh -c 'rsync --include=*/ --include=**/maven-metadata.xml* --exclude=* --exclude-from=/home/maven/bin/synchronize/syncopate/exclusions.txt -Lrtivz "--rsh=ssh " [EMAIL PROTECTED]:/home/groups/s/su/sulky/htdocs/repository/de/huxhorn/sulky/ /home/maven/repository-staging/to-ibiblio/maven2/de/huxhorn/sulky/'org.codehaus.plexus.util.cli.CommandLineException: Error while executing external command, process killed.Error while executing external command, process killed.Process timeout out after 900 seconds And I guessed that it was my fault because of the problem is described above. Anyway, my artifacts won't show up in the central repository. This is my repository: http://lilith.sourceforge.net/repository/de/huxhorn/lilith/de.huxhorn.lilith/ The 0.9.37 artifacts of Lilith are there since 2009-11-12, the same is the case for sulky 0.9.9. If the above isn't the problem then I really don't understand why the artifacts are not syncing. Beside all this, please remove one of the syncs (or direct them both to the lilith repo) and change my email to the one I provided above. I mistakenly left out the "users" - it should have been huxh...@users.sf.net - and the contact address is better suited anyway. I assume that I would receive an email if sync fails, right? Is it possible that my artifacts are not showing up because the old sulky repos does not contain the new versions and the new lilith versions depend on the new sulky versions? I'll rsync to the sulky repo as well right now, just to be sure. > Upload request for groupId's de.huxhorn.sulky and de.huxhorn.lilith > --- > > Key: MAVENUPLOAD-2164 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2164 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Joern Huxhorn >Assignee: Carlos Sanchez > > "de.huxhorn.sulky","mavens...@shell.sourceforge.net:/home/groups/s/su/sulky/htdocs/repository",,"rsync_ssh","Joern > Huxhorn","huxh...@sf.net",, > "de.huxhorn.lilith","mavens...@shell.sourceforge.net:/home/groups/l/li/lilith/htdocs/repository",,"rsync_ssh","Joern > Huxhorn","huxh...@sf.net",, > This request is actually about two projects, sulky and lilith. > I added both URLs - as project and contributor URL. > I sincerely hope that I've done everything correctly since this is my very > first submission to the central maven repository. > I own the domain huxhorn.de as you can verify on http://www.denic.de > Therefore I also own sulky.huxhorn.de as well as lilith.huxhorn.de > I'm also the sole developer registered in the respective sourceforge projects > http://sf.net/projects/sulky > and > http://sf.net/projects/lilith > Since this form *requires* an upload bundle URL I entered a URL to the comma > separated sync file... > Please let me know if everything is OK or if somethings still wrong/missing. > Thank you. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MAVENUPLOAD-2164) Upload request for groupId's de.huxhorn.sulky and de.huxhorn.lilith
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=198496#action_198496 ] Joern Huxhorn edited comment on MAVENUPLOAD-2164 at 11/17/09 1:51 AM: -- There was some change at Sourceforge so the previous settings aren't valid anymore. Supposedly, they should look like this now: "de.huxhorn.lilith","mavens...@web.sourceforge.net:/home/groups/l/li/lilith/htdocs/repository",,"rsync_ssh","Joern Huxhorn","cont...@lilith.huxhorn.de",, I've also changed the email - which was wrong, previously. And I only require a single sync, now. Please let me know if the above works as expected. I've simply changed my previous settings according to http://maven.apache.org/guides/mini/guide-central-repository-upload.html was (Author: jhuxhorn): There was some change at Sourceforge so the previous settings aren't valid anymore. Supposedly, they should look like this now: "de.huxhorn.sulky","mavens...@web.sourceforge.net:/home/groups/s/su/sulky/htdocs/repository",,"rsync_ssh","Joern Huxhorn","cont...@lilith.huxhorn.de",, "de.huxhorn.lilith","mavens...@web.sourceforge.net:/home/groups/l/li/lilith/htdocs/repository",,"rsync_ssh","Joern Huxhorn","cont...@lilith.huxhorn.de",, I've also changed the email - which was wrong, previously. Please let me know if the above works as expected. I've simply changed my previous settings according to http://maven.apache.org/guides/mini/guide-central-repository-upload.html > Upload request for groupId's de.huxhorn.sulky and de.huxhorn.lilith > --- > > Key: MAVENUPLOAD-2164 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2164 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Joern Huxhorn >Assignee: Carlos Sanchez > > "de.huxhorn.sulky","mavens...@shell.sourceforge.net:/home/groups/s/su/sulky/htdocs/repository",,"rsync_ssh","Joern > Huxhorn","huxh...@sf.net",, > "de.huxhorn.lilith","mavens...@shell.sourceforge.net:/home/groups/l/li/lilith/htdocs/repository",,"rsync_ssh","Joern > Huxhorn","huxh...@sf.net",, > This request is actually about two projects, sulky and lilith. > I added both URLs - as project and contributor URL. > I sincerely hope that I've done everything correctly since this is my very > first submission to the central maven repository. > I own the domain huxhorn.de as you can verify on http://www.denic.de > Therefore I also own sulky.huxhorn.de as well as lilith.huxhorn.de > I'm also the sole developer registered in the respective sourceforge projects > http://sf.net/projects/sulky > and > http://sf.net/projects/lilith > Since this form *requires* an upload bundle URL I entered a URL to the comma > separated sync file... > Please let me know if everything is OK or if somethings still wrong/missing. > Thank you. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MAVENUPLOAD-2164) Upload request for groupId's de.huxhorn.sulky and de.huxhorn.lilith
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joern Huxhorn reopened MAVENUPLOAD-2164: There was some change at Sourceforge so the previous settings aren't valid anymore. Supposedly, they should look like this now: "de.huxhorn.sulky","mavens...@web.sourceforge.net:/home/groups/s/su/sulky/htdocs/repository",,"rsync_ssh","Joern Huxhorn","cont...@lilith.huxhorn.de",, "de.huxhorn.lilith","mavens...@web.sourceforge.net:/home/groups/l/li/lilith/htdocs/repository",,"rsync_ssh","Joern Huxhorn","cont...@lilith.huxhorn.de",, I've also changed the email - which was wrong, previously. Please let me know if the above works as expected. I've simply changed my previous settings according to http://maven.apache.org/guides/mini/guide-central-repository-upload.html > Upload request for groupId's de.huxhorn.sulky and de.huxhorn.lilith > --- > > Key: MAVENUPLOAD-2164 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2164 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Joern Huxhorn >Assignee: Carlos Sanchez > > "de.huxhorn.sulky","mavens...@shell.sourceforge.net:/home/groups/s/su/sulky/htdocs/repository",,"rsync_ssh","Joern > Huxhorn","huxh...@sf.net",, > "de.huxhorn.lilith","mavens...@shell.sourceforge.net:/home/groups/l/li/lilith/htdocs/repository",,"rsync_ssh","Joern > Huxhorn","huxh...@sf.net",, > This request is actually about two projects, sulky and lilith. > I added both URLs - as project and contributor URL. > I sincerely hope that I've done everything correctly since this is my very > first submission to the central maven repository. > I own the domain huxhorn.de as you can verify on http://www.denic.de > Therefore I also own sulky.huxhorn.de as well as lilith.huxhorn.de > I'm also the sole developer registered in the respective sourceforge projects > http://sf.net/projects/sulky > and > http://sf.net/projects/lilith > Since this form *requires* an upload bundle URL I entered a URL to the comma > separated sync file... > Please let me know if everything is OK or if somethings still wrong/missing. > Thank you. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2164) Upload request for groupId's de.huxhorn.sulky and de.huxhorn.lilith
Upload request for groupId's de.huxhorn.sulky and de.huxhorn.lilith --- Key: MAVENUPLOAD-2164 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2164 Project: Maven Upload Requests Issue Type: Wish Reporter: Joern Huxhorn "de.huxhorn.sulky","[EMAIL PROTECTED]:/home/groups/s/su/sulky/htdocs/repository",,"rsync_ssh","Joern Huxhorn","[EMAIL PROTECTED]",, "de.huxhorn.lilith","[EMAIL PROTECTED]:/home/groups/l/li/lilith/htdocs/repository",,"rsync_ssh","Joern Huxhorn","[EMAIL PROTECTED]",, This request is actually about two projects, sulky and lilith. I added both URLs - as project and contributor URL. I sincerely hope that I've done everything correctly since this is my very first submission to the central maven repository. I own the domain huxhorn.de as you can verify on http://www.denic.de Therefore I also own sulky.huxhorn.de as well as lilith.huxhorn.de I'm also the sole developer registered in the respective sourceforge projects http://sf.net/projects/sulky and http://sf.net/projects/lilith Since this form *requires* an upload bundle URL I entered a URL to the comma separated sync file... Please let me know if everything is OK or if somethings still wrong/missing. Thank you. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-102) Module filepath is generated incorrectly for sibling parent
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126692 ] Joern Huxhorn commented on MIDEA-102: - I had to build using mvn clean install -Dmaven.test.skip=true because otherwise the build would fail with the following messages: Running org.apache.maven.plugin.idea.IdeaModuleTest [WARNING] An error occurred during dependency resolution of the following artifact: org.apache.maven.plugin.test:plugin-test-1919 Caused by: required artifacts missing: javax.sql:jdbc-stdext:jar:2.0 for the artifact: org.apache.maven.plugin.test:plugin-test-19:jar:19 from the specified remote repositories: test-repo (file://P:\misc\maven-idea-plugin\src\test\remote-repo) [WARNING] An error occurred during dependency resolution of the following artifact: org.apache.maven.plugin.test:plugin-test- Caused by: required artifacts missing: javax.sql:jdbc-stdext:jar:2.0 for the artifact: org.apache.maven.plugin.test:plugin-test-22:jar:22 from the specified remote repositories: test-repo (file://P:\misc\maven-idea-plugin\src\test\remote-repo) [WARNING] Unable to get resource from repository test-repo (file://P:\misc\maven-idea-plugin\src\test\remote-repo) [INFO] artifact junit:junit: checking for updates from test-repo Tests run: 15, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.484 sec <<< FAILURE! Running org.apache.maven.plugin.idea.LibraryTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec Running org.apache.maven.plugin.idea.IdeaMojoTestCase Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec Results : Failed tests: testEjbProjectWithModulesConfigurations(org.apache.maven.plugin.idea.IdeaModuleTest) Tests run: 37, Failures: 1, Errors: 0, Skipped: 0 But beside that, the current version works as expected for me. > Module filepath is generated incorrectly for sibling parent > --- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- 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: (MCOMPILER-64) "mvn clean install" crashes with java.lang.OutOfMemoryError: PermGen space after update to java 1.6.0_04
"mvn clean install" crashes with java.lang.OutOfMemoryError: PermGen space after update to java 1.6.0_04 Key: MCOMPILER-64 URL: http://jira.codehaus.org/browse/MCOMPILER-64 Project: Maven 2.x Compiler Plugin Issue Type: Bug Environment: Maven version: 2.0.8 Java version: 1.6.0_04 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" Reporter: Joern Huxhorn Priority: Critical After upgrading to java 1.6.0_04 i can't build a big multi-module project anymore. java.exe keeps allocating more and more memory (ca. 260MB) until it crashes with an error like the following: Failure executing javac, but could not parse the error: The system is out of resources. Consult the following stack trace for details. java.lang.OutOfMemoryError: PermGen space at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:620) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124) at java.net.URLClassLoader.defineClass(URLClassLoader.java:260) at java.net.URLClassLoader.access$000(URLClassLoader.java:56) at java.net.URLClassLoader$1.run(URLClassLoader.java:195) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at org.codehaus.plexus.compiler.javac.IsolatedClassLoader.loadClass(IsolatedClassLoader.java:56) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at com.sun.tools.javac.comp.Annotate.(Annotate.java:52) at com.sun.tools.javac.comp.Annotate.instance(Annotate.java:36) at com.sun.tools.javac.jvm.ClassReader.(ClassReader.java:215) at com.sun.tools.javac.jvm.ClassReader.instance(ClassReader.java:168) at com.sun.tools.javac.main.JavaCompiler.(JavaCompiler.java:293) at com.sun.tools.javac.main.JavaCompiler.instance(JavaCompiler.java:72) at com.sun.tools.javac.main.Main.compile(Main.java:340) at com.sun.tools.javac.main.Main.compile(Main.java:279) at com.sun.tools.javac.main.Main.compile(Main.java:270) at com.sun.tools.javac.Main.compile(Main.java:87) 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:597) at org.codehaus.plexus.compiler.javac.JavacCompiler.compileInProcess(JavacCompiler.java:420) at org.codehaus.plexus.compiler.javac.JavacCompiler.compile(JavacCompiler.java:141) at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:493) at org.apache.maven.plugin.TestCompilerMojo.execute(TestCompilerMojo.java:102) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459) Executing the same command with this setup Maven version: 2.0.8 Java version: 1.5.0_13 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" works perfectly. java.exe allocates at most 110MB. Increasing the PermGen space using -XX:MaxPermSize=512M didn't help, either... This is probably a java regression introduced with j6u4 but it could also be a problem in org.codehaus.plexus.compiler.javac.IsolatedClassLoader. I didn't experience any other problems with the new java version, so far. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCLEAN-25) Optionally don't delete the 'target ' directory
[ http://jira.codehaus.org/browse/MCLEAN-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113832 ] Joern Huxhorn commented on MCLEAN-25: - Very nice, thank you! This does not solve the problem of vanishing explorer-windows but it does solve our main problem of failed builds. Can we expect a 2.2 release in the near future? > Optionally don't delete the 'target ' directory > > > Key: MCLEAN-25 > URL: http://jira.codehaus.org/browse/MCLEAN-25 > Project: Maven 2.x Clean Plugin > Issue Type: New Feature >Reporter: Joern Huxhorn >Assignee: Vincent Siveton > Fix For: 2.2 > > Attachments: clean-patch.patch > > > Would it be possible to add an option to the clean-plugin so only the content > of the target folder(s) are deleted but not the directory itself? > This would help developers using windoze quite a lot since: > - clean fails if you happen to have opened a command line with target as the > current dir. > - windoze closes explorer windows pointing to deleted directories, so you > have to reopen the windows after a clean install > Those problems would both be solved by an option like deleteRoot=false or > something. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCLEAN-25) Optionally don't delete the 'target ' directory
[ http://jira.codehaus.org/browse/MCLEAN-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113815 ] Joern Huxhorn commented on MCLEAN-25: - This isn't a windows handler problem but a windows "feature". You can't delete a directory that is the current directory of a cmd-console. The real problem is that clean fails if it can't delete a root directory. I don't know about any other handler problems that this patch doesn't fix but I just can't see whats so bad about my suggestion. > Optionally don't delete the 'target ' directory > > > Key: MCLEAN-25 > URL: http://jira.codehaus.org/browse/MCLEAN-25 > Project: Maven 2.x Clean Plugin > Issue Type: New Feature >Reporter: Joern Huxhorn >Assignee: Vincent Siveton > Fix For: 2.2 > > Attachments: clean-patch.patch > > > Would it be possible to add an option to the clean-plugin so only the content > of the target folder(s) are deleted but not the directory itself? > This would help developers using windoze quite a lot since: > - clean fails if you happen to have opened a command line with target as the > current dir. > - windoze closes explorer windows pointing to deleted directories, so you > have to reopen the windows after a clean install > Those problems would both be solved by an option like deleteRoot=false or > something. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly
[
http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103430
]
Joern Huxhorn commented on MIDEA-102:
-
To clarify my point a little more: calling toRelative("C:\Foo\bar1",
"C:\Foo\bar2") must return "../bar2" but currently returns "C:/Foo/bar2".
> CLONE -still broken - Module filepath is generated incorrectly
> --
>
> Key: MIDEA-102
> URL: http://jira.codehaus.org/browse/MIDEA-102
> Project: Maven 2.x IDEA Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: $ mvn -v
> Maven version: 2.0.7
> Java version: 1.5.0_11
> OS name: "windows xp" version: "5.1" arch: "x86"
> cygwin
>Reporter: Joern Huxhorn
>Assignee: Dennis Lundberg
> Fix For: 2.2
>
> Attachments: maven-idea-plugin-MIDEA-102.patch
>
>
> I have a multi-module mvn project.
> When I do an mvn idea:clean idea:idea, the following ProjectModuleManager
> snippet in the top level .ipr is generated:
>
>
>
>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/>
>filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/>
>
>
> The $PROJECT_DIR in this case is C:/dev/voca/gateway/.
> But this path is being appended in a hard-coded fashion after the
> $PROJECT_DIR entry.
> The symptom in Intellij is the following error message:
> Cannot load module: File
> C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not
> exist
> Would you like to remove the module from the project?
> The workaround is to delete the extra appended file path from each module
> entry in the above mentioned snippet.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joern Huxhorn reopened MIDEA-102: - My patch is against r559855 of 2.2-SNAPSHOT (trunk). I tried the 2.2-SNAPSHOT and the same problem still exists if the master-pom is at the same level as the child-poms. C:\Foo\parent\pom.xml The master-pom containing a section ../child C:\Foo\child\pom.xml The sub-module referenced from the master-module In cases like that, i.e. if the path of the submodule must contain ".." the behavior is still like in the original bug-report. That's why I cloned it instead of creating a new one which was probably wrong on my side. I thought this would be wise since the previous fix only fixed a special-case of the problem. > CLONE -still broken - Module filepath is generated incorrectly > -- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103413 ] Joern Huxhorn commented on MIDEA-102: - I'd also suggest to change protected String toRelative( File basedir, String absolutePath ) to static String toRelative( File basedir, String absolutePath ) and write some tests. I didn't want to change too much, though. > CLONE -still broken - Module filepath is generated incorrectly > -- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- 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: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joern Huxhorn updated MIDEA-102: Attachment: maven-idea-plugin-MIDEA-102.patch the problem still exists if the master-module is at the same level as the child module, e.g. C:\foo\master and C:\foo\child. The attached patch fixes this problem. > CLONE -still broken - Module filepath is generated incorrectly > -- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- 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: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly
CLONE -still broken - Module filepath is generated incorrectly -- Key: MIDEA-102 URL: http://jira.codehaus.org/browse/MIDEA-102 Project: Maven 2.x IDEA Plugin Issue Type: Bug Affects Versions: 2.1 Environment: $ mvn -v Maven version: 2.0.7 Java version: 1.5.0_11 OS name: "windows xp" version: "5.1" arch: "x86" cygwin Reporter: Joern Huxhorn Assignee: Dennis Lundberg Fix For: 2.2 I have a multi-module mvn project. When I do an mvn idea:clean idea:idea, the following ProjectModuleManager snippet in the top level .ipr is generated: The $PROJECT_DIR in this case is C:/dev/voca/gateway/. But this path is being appended in a hard-coded fashion after the $PROJECT_DIR entry. The symptom in Intellij is the following error message: Cannot load module: File C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not exist Would you like to remove the module from the project? The workaround is to delete the extra appended file path from each module entry in the above mentioned snippet. -- 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: (MCLEAN-25) Optionally don't delete the 'target ' directory
[ http://jira.codehaus.org/browse/MCLEAN-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joern Huxhorn updated MCLEAN-25: Attachment: clean-patch.patch A patch that implements the desired functionality. > Optionally don't delete the 'target ' directory > > > Key: MCLEAN-25 > URL: http://jira.codehaus.org/browse/MCLEAN-25 > Project: Maven 2.x Clean Plugin > Issue Type: New Feature >Reporter: Joern Huxhorn > Attachments: clean-patch.patch > > > Would it be possible to add an option to the clean-plugin so only the content > of the target folder(s) are deleted but not the directory itself? > This would help developers using windoze quite a lot since: > - clean fails if you happen to have opened a command line with target as the > current dir. > - windoze closes explorer windows pointing to deleted directories, so you > have to reopen the windows after a clean install > Those problems would both be solved by an option like deleteRoot=false or > something. -- 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: (MCLEAN-25) Optionally don't delete the 'target ' directory
Optionally don't delete the 'target ' directory Key: MCLEAN-25 URL: http://jira.codehaus.org/browse/MCLEAN-25 Project: Maven 2.x Clean Plugin Issue Type: New Feature Reporter: Joern Huxhorn Would it be possible to add an option to the clean-plugin so only the content of the target folder(s) are deleted but not the directory itself? This would help developers using windoze quite a lot since: - clean fails if you happen to have opened a command line with target as the current dir. - windoze closes explorer windows pointing to deleted directories, so you have to reopen the windows after a clean install Those problems would both be solved by an option like deleteRoot=false or something. -- 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
