[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158696#comment-17158696 ] Aaron Digulla commented on MRESOURCES-171: -- Another idea: Can we use the actual Properties class to load properties files? > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://issues.apache.org/jira/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Priority: Minor > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158539#comment-17158539 ] Aaron Digulla commented on MRESOURCES-171: -- [~afloom] Thanks for the update. (screaming and cursing in the background). Ahem. Seems like a bad situation got worse. One way to attack this: Determine Java version and set the default accordingly (ISO for < Java 9, UTF-8 for everything later). Log the setting to the console so developers notice that something is happening. But a better approach would be to add a new property and print a warning when it's not set (that's what happening when source encoding is missing, IIRC). That would allow us to print a link to a web page with instructions. I think the last option is best: It makes the problem obvious (especially for those so far oblivious to it), it will help those who have installed workarounds and we can explain what's going on AND give suggestions for common cases. > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://issues.apache.org/jira/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Priority: Minor > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158128#comment-17158128 ] Aaron Digulla commented on MRESOURCES-171: -- Short discussion regarding the default value: project.build.sourceEncoding: Pro: It's not a breaking change. Con: 99% of all Java developers are not aware that the problem even exists. Many are US developers who don't care about characters outside the ASCII charset, so they're not affected. This would mean that most builds will stay broken without anyone noticing. Only when translations into other languages are added, weird things will happen and people will be confused. ISO-8859-1: Pro: That's what it should have been all along. ISO-8859-1 can process UTF-8 unchanged since the encoding is binary stable (every byte of input maps to the same byte of output). So while a human would see those UTF-8 sequences for umlauts and special characters, the computer doesn't care. This can only fail when people use resource filtering and try to replace a variable with a System property with special characters. Pure ASCII replacements still work. That's the only corner case where we get the dreaded UTF-8 sequence unrolling (where you start to see those à characters). Con: There is a chance that builds will break if people added the wrong workaround to fix the issue. One fix would be the complex config above. As far as I can tell, the fix above is compatible with ISO-8859-1 as default. It can get messy when people have changed the loading code to use UTF-8. That being said, if you would chose the default to stay UTF-8, projects would silently fail for a long time without anyone noticing. I think this is bad. When something is broken, it should blow up in a way that people can see and do something about it. So as I see it, using the correct default (as Java defines it) will break a small number of builds but the fix is easy: Remove all workarounds. What I would like is a warning or error when you're affected. Maybe we should check for characters with codePoint >= 128 && check whether resource filtering is enabled and print a warning? > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://issues.apache.org/jira/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Priority: Minor > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158128#comment-17158128 ] Aaron Digulla edited comment on MRESOURCES-171 at 7/15/20, 12:40 PM: - Short discussion regarding the default value: project.build.sourceEncoding: Pro: It's not a breaking change. Con: 99% of all Java developers are not aware that the problem even exists. Many are US developers who don't care about characters outside the ASCII charset, so they're not affected. This would mean that most builds will stay broken without anyone noticing. Only when translations into other languages are added, weird things will happen and people will be confused. Frankly, even many developers in Europe don't understand the problem (just look at the comments here where people argue UFT-8 is good/better/valid when it's clearly not). ISO-8859-1: Pro: That's what it should have been all along. ISO-8859-1 can process UTF-8 unchanged since the encoding is binary stable (every byte of input maps to the same byte of output). So while a human would see those UTF-8 sequences for umlauts and special characters, the computer doesn't care. This can only fail when people use resource filtering and try to replace a variable with a System property with special characters. Pure ASCII replacements still work. That's the only corner case where we get the dreaded UTF-8 sequence unrolling (where you start to see those à characters). Con: There is a chance that builds will break if people added the wrong workaround to fix the issue. One fix would be the complex config above. As far as I can tell, the fix above is compatible with ISO-8859-1 as default. It can get messy when people have changed the loading code to use UTF-8. That being said, if you would chose the default to stay UTF-8, projects would silently fail for a long time without anyone noticing. I think this is bad. When something is broken, it should blow up in a way that people can see and do something about it. So as I see it, using the correct default (as Java defines it) will break a small number of builds but the fix is easy: Remove all workarounds. If people really don't like it, they can stay with the old version of the plugin. That's just a two minute change in the POM. What I would like is a warning or error when you're affected. Maybe we should check for characters with codePoint >= 128 && check whether resource filtering is enabled and print a warning? was (Author: digulla): Short discussion regarding the default value: project.build.sourceEncoding: Pro: It's not a breaking change. Con: 99% of all Java developers are not aware that the problem even exists. Many are US developers who don't care about characters outside the ASCII charset, so they're not affected. This would mean that most builds will stay broken without anyone noticing. Only when translations into other languages are added, weird things will happen and people will be confused. ISO-8859-1: Pro: That's what it should have been all along. ISO-8859-1 can process UTF-8 unchanged since the encoding is binary stable (every byte of input maps to the same byte of output). So while a human would see those UTF-8 sequences for umlauts and special characters, the computer doesn't care. This can only fail when people use resource filtering and try to replace a variable with a System property with special characters. Pure ASCII replacements still work. That's the only corner case where we get the dreaded UTF-8 sequence unrolling (where you start to see those à characters). Con: There is a chance that builds will break if people added the wrong workaround to fix the issue. One fix would be the complex config above. As far as I can tell, the fix above is compatible with ISO-8859-1 as default. It can get messy when people have changed the loading code to use UTF-8. That being said, if you would chose the default to stay UTF-8, projects would silently fail for a long time without anyone noticing. I think this is bad. When something is broken, it should blow up in a way that people can see and do something about it. So as I see it, using the correct default (as Java defines it) will break a small number of builds but the fix is easy: Remove all workarounds. What I would like is a warning or error when you're affected. Maybe we should check for characters with codePoint >= 128 && check whether resource filtering is enabled and print a warning? > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://issues.apache.org/jira/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >
[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[
https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17158106#comment-17158106
]
Aaron Digulla commented on MRESOURCES-171:
--
[~afloom] and others: The encoding of property files is defined by the Java TCK
and the default *MUST BE ISO-8859-1.* UTF-8 or anything else IS NOT VALID.
That's what this bug is about: *The Java standard* *says ISO-8859-1* (which is
a bad choice IMHO but that's what it is). This is true for ALL JAVA versions
from 1.0 to 11. A lot of people are suprised by this but there is really no way
around it.
[From the docs
(again)|https://docs.oracle.com/javase/8/docs/api/java/util/Properties.html]:
{quote}the input/output stream is encoded in ISO 8859-1 character encoding.
{quote}
Note: this is not true when you use XML to serialize the properties, only for
the old *.properties files. If you want UTF-8, I suggest you load/save as XML,
that avoids a whole load of trouble plus has some nice features like nesting
paths and comments everywhere.
> ISO8859-1 properties files get changed into UTF-8 when filtered
> ---
>
> Key: MRESOURCES-171
> URL: https://issues.apache.org/jira/browse/MRESOURCES-171
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: filtering
>Reporter: Alex Collins
>Priority: Minor
> Attachments: filtering-bug.zip
>
>
> Create:
> src/main/resources/test.properties
> And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u
> formatting.
> When adding this line:
> src/main/resourcestrue
> Expected:
> ISO8859-1 encoded file in jar.
> Actual:
> UTF-8 encoded file in jar.
> ---
> If there are any property files (which can only be ISO8859-1) they appear to
> be converted into UTF-8 in the jar.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ on Windows10 and MinTTY(Cygwin) console
[ https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975017#comment-16975017 ] Aaron Digulla commented on SUREFIRE-1631: - Things will be easier to understand if you used "Maven parent process" instead of "Maven" and "Surefire subprocess" / "Surefire child process" instead of "self fork JVM" in the error messages. [https://gitbox.apache.org/repos/asf?p=maven-surefire.git;a=blob;f=surefire-booter/src/main/java/org/apache/maven/surefire/booter/ForkedBooter.java;h=9da6d9b50d54ba84206e90a9fe3a5d23c55735b9;hb=08ff28f17ad251bcbe9440b00cc445ce69405efc#l237] When I read the code, I was under the impression that SurefireBooter is the parent (which creates the forked VM) and that the parent controls everything. When I look at the code now, I see that the child wants to know whether the parent is still there. That said, just checking the stdin for EOF in the child process should be enough to find out whether the parent died / went away; why this complex magic with PINGs and the like? > Forked VM terminated without properly saying goodbye with AciveMQ on > Windows10 and MinTTY(Cygwin) console > - > > Key: SUREFIRE-1631 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1631 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1 >Reporter: Aaron Digulla >Assignee: Tibor Digana >Priority: Major > Attachments: cmd.PNG, cmd2.PNG, shurefire-shutdownhook-bug-0.0.1.zip > > > I'm seeing spurious "The forked VM terminated without properly saying > goodbye. VM crash or System.exit called?" messages when running unit tests in > a big multi-module project. > OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of > Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191. > I'm running Maven from the command line using MinTTY (Cygwin). > Things I tried which have no effect: > * Reboot / Cold boot (happens first thing on Monday morning when I come into > the office and turn on my PC). > * More free memory (happens when I only have a single window open). I have > 16GB of RAM. > * Different terminal. I tried CMD prompt and urxvt (Cygwin/X). > * Different versions of the Surefire plugin or Maven > * Different JDK 8 builds > Things that affect the bug: > * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log > * Redirecting all log output to a file using logback-test.xml > * Running Surefire with forkCount=0 > * Running a subset of the tests (-Dtest=...) > * Pending Windows updates (I think, not sure about this one). > Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never > seen it with redirecting log output (~ 10 builds). Redirecting sometimes > helps but not always. > One thing which I notice is that one of the tests creates an ActiveMQ broker > and uses a shutdown hook to stop it. So I created a small test project which > demonstrates that Surefire will sometimes cut off stdout. I think that > happens because the main process kills the child after a timeout (correct?). > So my guess would be that shutdown hooks can mess with the pipeline between > the surefire child VM and main Maven process. ActiveMQ might be worse since > it stops threads and execution pools (so the output comes slowly with a > couple of exceptions sprinkled in when one component loses connection because > another is shutting down). > But now, it gets weird. When the build succeeds, it takes about ~5 minutes to > run 1028 tests. The log is 25 MB. > When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) > and the log stops in the middle of a test but is also 25 MB. > Some of the time discrepancy is probably because writing to a file is faster > than printing on a terminal. The strange part is that the log file is about > the same size but 30% of the tests haven't run. Most tests log a lot, do I > would expect to see a difference of at least a few MB. The Maven part (which > contains escape sequences, etc). is just 60 KB. > Maybe the parent takes some part of the log output as "child terminated". > I'm running out of ideas what to try next. I think a way to log the > communication between parent and child would help. Also the parent should > terminate the child and then read stdout until EOF to we can see anything > that happens afterwards. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ on Windows10 and MinTTY(Cygwin) console
[ https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975005#comment-16975005 ] Aaron Digulla commented on SUREFIRE-1631: - I'm still unsure what happens. When it happened for me, no JVM dumps or errors were written. From the thread dumps provided by [~adolfo.cia] , it seems the child process was killed in the middle by something. Does the Maven parent process kill the Surefire child? If so, why doesn't the parent print the reason anywhere? As it is, it looks as if someone suddenly killed the JVM and Maven has no clue. If my description is correct, please add big fat warnings into the parent output: "Killed Surefire child process because XXX. See [https://maven.org/...] for details" > Forked VM terminated without properly saying goodbye with AciveMQ on > Windows10 and MinTTY(Cygwin) console > - > > Key: SUREFIRE-1631 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1631 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1 >Reporter: Aaron Digulla >Assignee: Tibor Digana >Priority: Major > Attachments: cmd.PNG, cmd2.PNG, shurefire-shutdownhook-bug-0.0.1.zip > > > I'm seeing spurious "The forked VM terminated without properly saying > goodbye. VM crash or System.exit called?" messages when running unit tests in > a big multi-module project. > OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of > Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191. > I'm running Maven from the command line using MinTTY (Cygwin). > Things I tried which have no effect: > * Reboot / Cold boot (happens first thing on Monday morning when I come into > the office and turn on my PC). > * More free memory (happens when I only have a single window open). I have > 16GB of RAM. > * Different terminal. I tried CMD prompt and urxvt (Cygwin/X). > * Different versions of the Surefire plugin or Maven > * Different JDK 8 builds > Things that affect the bug: > * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log > * Redirecting all log output to a file using logback-test.xml > * Running Surefire with forkCount=0 > * Running a subset of the tests (-Dtest=...) > * Pending Windows updates (I think, not sure about this one). > Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never > seen it with redirecting log output (~ 10 builds). Redirecting sometimes > helps but not always. > One thing which I notice is that one of the tests creates an ActiveMQ broker > and uses a shutdown hook to stop it. So I created a small test project which > demonstrates that Surefire will sometimes cut off stdout. I think that > happens because the main process kills the child after a timeout (correct?). > So my guess would be that shutdown hooks can mess with the pipeline between > the surefire child VM and main Maven process. ActiveMQ might be worse since > it stops threads and execution pools (so the output comes slowly with a > couple of exceptions sprinkled in when one component loses connection because > another is shutting down). > But now, it gets weird. When the build succeeds, it takes about ~5 minutes to > run 1028 tests. The log is 25 MB. > When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) > and the log stops in the middle of a test but is also 25 MB. > Some of the time discrepancy is probably because writing to a file is faster > than printing on a terminal. The strange part is that the log file is about > the same size but 30% of the tests haven't run. Most tests log a lot, do I > would expect to see a difference of at least a few MB. The Maven part (which > contains escape sequences, etc). is just 60 KB. > Maybe the parent takes some part of the log output as "child terminated". > I'm running out of ideas what to try next. I think a way to log the > communication between parent and child would help. Also the parent should > terminate the child and then read stdout until EOF to we can see anything > that happens afterwards. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ
[ https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16963370#comment-16963370 ] Aaron Digulla commented on SUREFIRE-1631: - Just some notes: # My test doesn't call exit() at any time. I've set a breakpoint at Runtime.exit() which was never hit. # It happens often on Windows (I was using 10). I've seen it on Jenkins but I don't remember if the slave was running Linux or Windows. # I've only seen it with recent versions of Java 8 (after u81, I *think*) # It's a brittle error. Sometimes, you don't get it for weeks. Then every build fails. Sometimes reboot helps, sometimes not. I understand that you closed the bug but I doubt it's fixed. It's probably a weird bug that happens with a combination of Oracle Java 8, Windows and IPC which makes the VM crash/terminate *without* writing any crash logs. It's not related to Spring or Docker and I'm not using either in my project (well, I'm using the Spring JMS template but no application context). I've sunk about a week's worth of time into the bug and I still have no idea what happens. Might be a JIT bug or I don't know. Very frustrating. > Forked VM terminated without properly saying goodbye with AciveMQ > - > > Key: SUREFIRE-1631 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1631 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20.1, 2.22.0, 3.0.0-M2, 3.0.0-M1 >Reporter: Aaron Digulla >Assignee: Tibor Digana >Priority: Major > Attachments: shurefire-shutdownhook-bug-0.0.1.zip > > > I'm seeing spurious "The forked VM terminated without properly saying > goodbye. VM crash or System.exit called?" messages when running unit tests in > a big multi-module project. > OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of > Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191. > I'm running Maven from the command line using MinTTY (Cygwin). > Things I tried which have no effect: > * Reboot / Cold boot (happens first thing on Monday morning when I come into > the office and turn on my PC). > * More free memory (happens when I only have a single window open). I have > 16GB of RAM. > * Different terminal. I tried CMD prompt and urxvt (Cygwin/X). > * Different versions of the Surefire plugin or Maven > * Different JDK 8 builds > Things that affect the bug: > * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log > * Redirecting all log output to a file using logback-test.xml > * Running Surefire with forkCount=0 > * Running a subset of the tests (-Dtest=...) > * Pending Windows updates (I think, not sure about this one). > Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never > seen it with redirecting log output (~ 10 builds). Redirecting sometimes > helps but not always. > One thing which I notice is that one of the tests creates an ActiveMQ broker > and uses a shutdown hook to stop it. So I created a small test project which > demonstrates that Surefire will sometimes cut off stdout. I think that > happens because the main process kills the child after a timeout (correct?). > So my guess would be that shutdown hooks can mess with the pipeline between > the surefire child VM and main Maven process. ActiveMQ might be worse since > it stops threads and execution pools (so the output comes slowly with a > couple of exceptions sprinkled in when one component loses connection because > another is shutting down). > But now, it gets weird. When the build succeeds, it takes about ~5 minutes to > run 1028 tests. The log is 25 MB. > When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) > and the log stops in the middle of a test but is also 25 MB. > Some of the time discrepancy is probably because writing to a file is faster > than printing on a terminal. The strange part is that the log file is about > the same size but 30% of the tests haven't run. Most tests log a lot, do I > would expect to see a difference of at least a few MB. The Maven part (which > contains escape sequences, etc). is just 60 KB. > Maybe the parent takes some part of the log output as "child terminated". > I'm running out of ideas what to try next. I think a way to log the > communication between parent and child would help. Also the parent should > terminate the child and then read stdout until EOF to we can see anything > that happens afterwards. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[
https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801493#comment-16801493
]
Aaron Digulla edited comment on MRESOURCES-171 at 3/26/19 9:03 AM:
---
My preferred solution is: The plugin uses ISO-8859-1 when reading and writing
.properties files by default and this encoding can be overridden with a config
option. So when people have found a way to work around the encoding in their
code (like creating their own {{Reader}}), they can configure the plugin to use
${project.build.sourceEncoding}.
was (Author: digulla):
My preferred solution is: The plugin uses ISO-8859-1 when reading and writing
.properties files by default and this encoding can be overridden with a config
option. So when people have found a way to work around the encoding in their
code (like creating their own {{Reader}}), they can configure the plugin to use
${{{project.build.sourceEncoding}}}.
> ISO8859-1 properties files get changed into UTF-8 when filtered
> ---
>
> Key: MRESOURCES-171
> URL: https://issues.apache.org/jira/browse/MRESOURCES-171
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: filtering
>Reporter: Alex Collins
>Priority: Minor
> Attachments: filtering-bug.zip
>
>
> Create:
> src/main/resources/test.properties
> And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u
> formatting.
> When adding this line:
> src/main/resourcestrue
> Expected:
> ISO8859-1 encoded file in jar.
> Actual:
> UTF-8 encoded file in jar.
> ---
> If there are any property files (which can only be ISO8859-1) they appear to
> be converted into UTF-8 in the jar.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[
https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801493#comment-16801493
]
Aaron Digulla commented on MRESOURCES-171:
--
My preferred solution is: The plugin uses ISO-8859-1 when reading and writing
.properties files by default and this encoding can be overridden with a config
option. So when people have found a way to work around the encoding in their
code (like creating their own {{Reader}}), they can configure the plugin to use
${{{project.build.sourceEncoding}}}.
> ISO8859-1 properties files get changed into UTF-8 when filtered
> ---
>
> Key: MRESOURCES-171
> URL: https://issues.apache.org/jira/browse/MRESOURCES-171
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: filtering
>Reporter: Alex Collins
>Priority: Minor
> Attachments: filtering-bug.zip
>
>
> Create:
> src/main/resources/test.properties
> And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u
> formatting.
> When adding this line:
> src/main/resourcestrue
> Expected:
> ISO8859-1 encoded file in jar.
> Actual:
> UTF-8 encoded file in jar.
> ---
> If there are any property files (which can only be ISO8859-1) they appear to
> be converted into UTF-8 in the jar.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (MASSEMBLY-811) Document possible values for handlerName in containerDescriptorHandler plus their configuration
[ https://issues.apache.org/jira/browse/MASSEMBLY-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801485#comment-16801485 ] Aaron Digulla edited comment on MASSEMBLY-811 at 3/26/19 8:52 AM: -- Fixed with [https://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-container-descriptor-handlers.html] Please close the issue. was (Author: digulla): Seems to be fixed now with [https://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-container-descriptor-handlers.html] > Document possible values for handlerName in containerDescriptorHandler plus > their configuration > --- > > Key: MASSEMBLY-811 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-811 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: component descriptor >Affects Versions: 2.6 >Reporter: Aaron Digulla >Priority: Major > > There is no documentation that I could find on the official site > (https://maven.apache.org/plugins/maven-assembly-plugin/) which explains > which handlers exist and how to configure them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (MASSEMBLY-811) Document possible values for handlerName in containerDescriptorHandler plus their configuration
[ https://issues.apache.org/jira/browse/MASSEMBLY-811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16801485#comment-16801485 ] Aaron Digulla commented on MASSEMBLY-811: - Seems to be fixed now with [https://maven.apache.org/plugins/maven-assembly-plugin/examples/single/using-container-descriptor-handlers.html] > Document possible values for handlerName in containerDescriptorHandler plus > their configuration > --- > > Key: MASSEMBLY-811 > URL: https://issues.apache.org/jira/browse/MASSEMBLY-811 > Project: Maven Assembly Plugin > Issue Type: Bug > Components: component descriptor >Affects Versions: 2.6 >Reporter: Aaron Digulla >Priority: Major > > There is no documentation that I could find on the official site > (https://maven.apache.org/plugins/maven-assembly-plugin/) which explains > which handlers exist and how to configure them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MNG-6617) Please improve
Aaron Digulla created MNG-6617:
--
Summary: Please improve
Key: MNG-6617
URL: https://issues.apache.org/jira/browse/MNG-6617
Project: Maven
Issue Type: Improvement
Components: Documentation: Guides
Reporter: Aaron Digulla
Please improve the page at [https://maven.apache.org/maven-ci-friendly.html]
I think the document explains an important feature but I find it confusing.
* Why would someone want to use this feature? Which problems does it solve and
which are created?
* How will Maven determine the values for ${sha1} and ${changelist}?
* You mention
1.0.0-${buildNumber}-SNAPSHOT"will _not work as expected_". Why not? Explain
why the build number doesn't make as much sense as the other variables.
* In the section "Dependencies" why not use {{dependencyManagement}}?
* Under "Install / Deploy", you say "will not be consumable by Maven anymore".
Why?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ
[ https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757468#comment-16757468 ] Aaron Digulla commented on SUREFIRE-1631: - *sigh* This is really driving me insane. Now, I can't repeat it myself... it failed only once (see stack trace above). So my current statistics with the attached test case: 1 failure in 21 builds... > Forked VM terminated without properly saying goodbye with AciveMQ > - > > Key: SUREFIRE-1631 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1631 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20.1, 3.0.0-M1, 2.22.0, 3.0.0-M2 >Reporter: Aaron Digulla >Priority: Major > Attachments: shurefire-shutdownhook-bug-0.0.1.zip > > > I'm seeing spurious "The forked VM terminated without properly saying > goodbye. VM crash or System.exit called?" messages when running unit tests in > a big multi-module project. > OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of > Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191. > I'm running Maven from the command line using MinTTY (Cygwin). > Things I tried which have no effect: > * Reboot / Cold boot (happens first thing on Monday morning when I come into > the office and turn on my PC). > * More free memory (happens when I only have a single window open). I have > 16GB of RAM. > * Different terminal. I tried CMD prompt and urxvt (Cygwin/X). > * Different versions of the Surefire plugin or Maven > * Different JDK 8 builds > Things that affect the bug: > * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log > * Redirecting all log output to a file using logback-test.xml > * Running Surefire with forkCount=0 > * Running a subset of the tests (-Dtest=...) > * Pending Windows updates (I think, not sure about this one). > Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never > seen it with redirecting log output (~ 10 builds). Redirecting sometimes > helps but not always. > One thing which I notice is that one of the tests creates an ActiveMQ broker > and uses a shutdown hook to stop it. So I created a small test project which > demonstrates that Surefire will sometimes cut off stdout. I think that > happens because the main process kills the child after a timeout (correct?). > So my guess would be that shutdown hooks can mess with the pipeline between > the surefire child VM and main Maven process. ActiveMQ might be worse since > it stops threads and execution pools (so the output comes slowly with a > couple of exceptions sprinkled in when one component loses connection because > another is shutting down). > But now, it gets weird. When the build succeeds, it takes about ~5 minutes to > run 1028 tests. The log is 25 MB. > When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) > and the log stops in the middle of a test but is also 25 MB. > Some of the time discrepancy is probably because writing to a file is faster > than printing on a terminal. The strange part is that the log file is about > the same size but 30% of the tests haven't run. Most tests log a lot, do I > would expect to see a difference of at least a few MB. The Maven part (which > contains escape sequences, etc). is just 60 KB. > Maybe the parent takes some part of the log output as "child terminated". > I'm running out of ideas what to try next. I think a way to log the > communication between parent and child would help. Also the parent should > terminate the child and then read stdout until EOF to we can see anything > that happens afterwards. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ
[
https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757106#comment-16757106
]
Aaron Digulla commented on SUREFIRE-1631:
-
Updates. I've made some changes to the logger configuration (I'm using slf4j
with logback) and then built the system 10 times.
The first change was adding color to the log by changing the pattern
{code}
{code}
to
{code}
{code}
Now the build fails 10 out of 11 times (the first build succeeded ...).
Then, I've disabled AMQ logging. This avoids log output in a shutdown hook.
{code}
{code}
Now 6 out of 10 builds fail.
If I also disable {{org.springframework.core.env}} (which creates a few 80KB
lines of log), then only 2 out of 20 builds fail.
Weird fact: The first two of 20 builds failed. It's as if the problem "heals"
itself.
It seems the amount of logging has an effect on the bug but I can't see why. In
the code of Surefire, you're using {{readLine()}} in
{{org.apache.maven.shared.utils.cli.StreamPumper.run()}} to read the test
output which has no length limitation. Non-printables are escaped in
{{ForkingRunListener.writeTestOutput()}}. It seems that the length of the line
shouldn't have an effect but it does.
So I wrote a small test project which just writes a 100K log and ... it crashes
for me with:
{code}
11:01:25.347 [main] DEBUG o.a.m.s.b.s.SomethingWhichInstallShutdownHook - This
is a short log message 96420
11:01:25.347 [main] DEBUG o.a.m.s.b.s.SomethingWhichInstallShutdownHook - This
is a short log message 96421
11:01:25.347 [main] DEBUG o.a.m.s.b.s.SomethingWhichInstallShutdownHook - This
is a short log message 96422
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 04:23 min
[INFO] Finished at: 2019-01-31T11:02:22+01:00
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M2:test (default-test) on
project surefire-shutdownhook-bug: There are test failures.
[ERROR]
[ERROR] Please refer to
C:\dev\workspace\surefire-shutdownhook-bug\target\surefire-reports for the
individual test results.
[ERROR] Please refer to dump files (if any exist) [date].dump,
[date]-jvmRun[N].dump and [date].dumpstream.
[ERROR] The forked VM terminated without properly saying goodbye. VM crash or
System.exit called?
[ERROR] Command was cmd.exe /X /C "C:\tools\java\jdk1.8.0_191\jre\bin\java -jar
C:\tools\cygwin\tmp\surefire2097056449345541265\surefirebooter7815058800200549210.jar
C:\tools\cygwin\tmp\surefire2097056449345541265
2019-01-31T10-58-05_362-jvmRun1 surefire7801676233715227954tmp
surefire_06053953062955035510tmp"
[ERROR] Process Exit Code: 0
[ERROR] Crashed tests:
[ERROR]
org.apache.maven.surefire.bugs.shutdownhook.SomethingWhichInstallShutdownHookTest
[ERROR] org.apache.maven.surefire.booter.SurefireBooterForkException: The
forked VM terminated without properly saying goodbye. VM crash or System.exit
called?
[ERROR] Command was cmd.exe /X /C "C:\tools\java\jdk1.8.0_191\jre\bin\java -jar
C:\tools\cygwin\tmp\surefire2097056449345541265\surefirebooter7815058800200549210.jar
C:\tools\cygwin\tmp\surefire2097056449345541265
2019-01-31T10-58-05_362-jvmRun1 surefire7801676233715227954tmp
surefire_06053953062955035510tmp"
[ERROR] Process Exit Code: 0
[ERROR] Crashed tests:
[ERROR]
org.apache.maven.surefire.bugs.shutdownhook.SomethingWhichInstallShutdownHookTest
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:670)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:283)
[ERROR] at
org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:246)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:1159)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1000)
[ERROR] at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:846)
[ERROR] at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
[ERROR] at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
[ERROR] at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR] at
[jira] [Comment Edited] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ
[
https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757109#comment-16757109
]
Aaron Digulla edited comment on SUREFIRE-1631 at 1/31/19 10:29 AM:
---
I've attached a project which demonstrates the bug. Just compile it with
{code}mvn clean install{code}
Can someone please confirm this bug?
was (Author: digulla):
I've attached the test case. Can someone please confirm this bug?
> Forked VM terminated without properly saying goodbye with AciveMQ
> -
>
> Key: SUREFIRE-1631
> URL: https://issues.apache.org/jira/browse/SUREFIRE-1631
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Surefire Plugin
>Affects Versions: 2.20.1, 3.0.0-M1, 2.22.0, 3.0.0-M2
>Reporter: Aaron Digulla
>Priority: Major
> Attachments: shurefire-shutdownhook-bug-0.0.1.zip
>
>
> I'm seeing spurious "The forked VM terminated without properly saying
> goodbye. VM crash or System.exit called?" messages when running unit tests in
> a big multi-module project.
> OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of
> Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191.
> I'm running Maven from the command line using MinTTY (Cygwin).
> Things I tried which have no effect:
> * Reboot / Cold boot (happens first thing on Monday morning when I come into
> the office and turn on my PC).
> * More free memory (happens when I only have a single window open). I have
> 16GB of RAM.
> * Different terminal. I tried CMD prompt and urxvt (Cygwin/X).
> * Different versions of the Surefire plugin or Maven
> * Different JDK 8 builds
> Things that affect the bug:
> * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log
> * Redirecting all log output to a file using logback-test.xml
> * Running Surefire with forkCount=0
> * Running a subset of the tests (-Dtest=...)
> * Pending Windows updates (I think, not sure about this one).
> Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never
> seen it with redirecting log output (~ 10 builds). Redirecting sometimes
> helps but not always.
> One thing which I notice is that one of the tests creates an ActiveMQ broker
> and uses a shutdown hook to stop it. So I created a small test project which
> demonstrates that Surefire will sometimes cut off stdout. I think that
> happens because the main process kills the child after a timeout (correct?).
> So my guess would be that shutdown hooks can mess with the pipeline between
> the surefire child VM and main Maven process. ActiveMQ might be worse since
> it stops threads and execution pools (so the output comes slowly with a
> couple of exceptions sprinkled in when one component loses connection because
> another is shutting down).
> But now, it gets weird. When the build succeeds, it takes about ~5 minutes to
> run 1028 tests. The log is 25 MB.
> When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies)
> and the log stops in the middle of a test but is also 25 MB.
> Some of the time discrepancy is probably because writing to a file is faster
> than printing on a terminal. The strange part is that the log file is about
> the same size but 30% of the tests haven't run. Most tests log a lot, do I
> would expect to see a difference of at least a few MB. The Maven part (which
> contains escape sequences, etc). is just 60 KB.
> Maybe the parent takes some part of the log output as "child terminated".
> I'm running out of ideas what to try next. I think a way to log the
> communication between parent and child would help. Also the parent should
> terminate the child and then read stdout until EOF to we can see anything
> that happens afterwards.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ
[ https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16757109#comment-16757109 ] Aaron Digulla commented on SUREFIRE-1631: - I've attached the test case. Can someone please confirm this bug? > Forked VM terminated without properly saying goodbye with AciveMQ > - > > Key: SUREFIRE-1631 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1631 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20.1, 3.0.0-M1, 2.22.0, 3.0.0-M2 >Reporter: Aaron Digulla >Priority: Major > Attachments: shurefire-shutdownhook-bug-0.0.1.zip > > > I'm seeing spurious "The forked VM terminated without properly saying > goodbye. VM crash or System.exit called?" messages when running unit tests in > a big multi-module project. > OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of > Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191. > I'm running Maven from the command line using MinTTY (Cygwin). > Things I tried which have no effect: > * Reboot / Cold boot (happens first thing on Monday morning when I come into > the office and turn on my PC). > * More free memory (happens when I only have a single window open). I have > 16GB of RAM. > * Different terminal. I tried CMD prompt and urxvt (Cygwin/X). > * Different versions of the Surefire plugin or Maven > * Different JDK 8 builds > Things that affect the bug: > * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log > * Redirecting all log output to a file using logback-test.xml > * Running Surefire with forkCount=0 > * Running a subset of the tests (-Dtest=...) > * Pending Windows updates (I think, not sure about this one). > Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never > seen it with redirecting log output (~ 10 builds). Redirecting sometimes > helps but not always. > One thing which I notice is that one of the tests creates an ActiveMQ broker > and uses a shutdown hook to stop it. So I created a small test project which > demonstrates that Surefire will sometimes cut off stdout. I think that > happens because the main process kills the child after a timeout (correct?). > So my guess would be that shutdown hooks can mess with the pipeline between > the surefire child VM and main Maven process. ActiveMQ might be worse since > it stops threads and execution pools (so the output comes slowly with a > couple of exceptions sprinkled in when one component loses connection because > another is shutting down). > But now, it gets weird. When the build succeeds, it takes about ~5 minutes to > run 1028 tests. The log is 25 MB. > When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) > and the log stops in the middle of a test but is also 25 MB. > Some of the time discrepancy is probably because writing to a file is faster > than printing on a terminal. The strange part is that the log file is about > the same size but 30% of the tests haven't run. Most tests log a lot, do I > would expect to see a difference of at least a few MB. The Maven part (which > contains escape sequences, etc). is just 60 KB. > Maybe the parent takes some part of the log output as "child terminated". > I'm running out of ideas what to try next. I think a way to log the > communication between parent and child would help. Also the parent should > terminate the child and then read stdout until EOF to we can see anything > that happens afterwards. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ
[ https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Digulla updated SUREFIRE-1631: Attachment: shurefire-shutdownhook-bug-0.0.1.zip > Forked VM terminated without properly saying goodbye with AciveMQ > - > > Key: SUREFIRE-1631 > URL: https://issues.apache.org/jira/browse/SUREFIRE-1631 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.20.1, 3.0.0-M1, 2.22.0, 3.0.0-M2 >Reporter: Aaron Digulla >Priority: Major > Attachments: shurefire-shutdownhook-bug-0.0.1.zip > > > I'm seeing spurious "The forked VM terminated without properly saying > goodbye. VM crash or System.exit called?" messages when running unit tests in > a big multi-module project. > OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of > Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191. > I'm running Maven from the command line using MinTTY (Cygwin). > Things I tried which have no effect: > * Reboot / Cold boot (happens first thing on Monday morning when I come into > the office and turn on my PC). > * More free memory (happens when I only have a single window open). I have > 16GB of RAM. > * Different terminal. I tried CMD prompt and urxvt (Cygwin/X). > * Different versions of the Surefire plugin or Maven > * Different JDK 8 builds > Things that affect the bug: > * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log > * Redirecting all log output to a file using logback-test.xml > * Running Surefire with forkCount=0 > * Running a subset of the tests (-Dtest=...) > * Pending Windows updates (I think, not sure about this one). > Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never > seen it with redirecting log output (~ 10 builds). Redirecting sometimes > helps but not always. > One thing which I notice is that one of the tests creates an ActiveMQ broker > and uses a shutdown hook to stop it. So I created a small test project which > demonstrates that Surefire will sometimes cut off stdout. I think that > happens because the main process kills the child after a timeout (correct?). > So my guess would be that shutdown hooks can mess with the pipeline between > the surefire child VM and main Maven process. ActiveMQ might be worse since > it stops threads and execution pools (so the output comes slowly with a > couple of exceptions sprinkled in when one component loses connection because > another is shutting down). > But now, it gets weird. When the build succeeds, it takes about ~5 minutes to > run 1028 tests. The log is 25 MB. > When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) > and the log stops in the middle of a test but is also 25 MB. > Some of the time discrepancy is probably because writing to a file is faster > than printing on a terminal. The strange part is that the log file is about > the same size but 30% of the tests haven't run. Most tests log a lot, do I > would expect to see a difference of at least a few MB. The Maven part (which > contains escape sequences, etc). is just 60 KB. > Maybe the parent takes some part of the log output as "child terminated". > I'm running out of ideas what to try next. I think a way to log the > communication between parent and child would help. Also the parent should > terminate the child and then read stdout until EOF to we can see anything > that happens afterwards. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ
[ https://issues.apache.org/jira/browse/SUREFIRE-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Digulla updated SUREFIRE-1631: Description: I'm seeing spurious "The forked VM terminated without properly saying goodbye. VM crash or System.exit called?" messages when running unit tests in a big multi-module project. OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191. I'm running Maven from the command line using MinTTY (Cygwin). Things I tried which have no effect: * Reboot / Cold boot (happens first thing on Monday morning when I come into the office and turn on my PC). * More free memory (happens when I only have a single window open). I have 16GB of RAM. * Different terminal. I tried CMD prompt and urxvt (Cygwin/X). * Different versions of the Surefire plugin or Maven * Different JDK 8 builds Things that affect the bug: * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log * Redirecting all log output to a file using logback-test.xml * Running Surefire with forkCount=0 * Running a subset of the tests (-Dtest=...) * Pending Windows updates (I think, not sure about this one). Counts: I've never seen it with forkCount=0 (~ 20 test builds). I've never seen it with redirecting log output (~ 10 builds). Redirecting sometimes helps but not always. One thing which I notice is that one of the tests creates an ActiveMQ broker and uses a shutdown hook to stop it. So I created a small test project which demonstrates that Surefire will sometimes cut off stdout. I think that happens because the main process kills the child after a timeout (correct?). So my guess would be that shutdown hooks can mess with the pipeline between the surefire child VM and main Maven process. ActiveMQ might be worse since it stops threads and execution pools (so the output comes slowly with a couple of exceptions sprinkled in when one component loses connection because another is shutting down). But now, it gets weird. When the build succeeds, it takes about ~5 minutes to run 1028 tests. The log is 25 MB. When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) and the log stops in the middle of a test but is also 25 MB. Some of the time discrepancy is probably because writing to a file is faster than printing on a terminal. The strange part is that the log file is about the same size but 30% of the tests haven't run. Most tests log a lot, do I would expect to see a difference of at least a few MB. The Maven part (which contains escape sequences, etc). is just 60 KB. Maybe the parent takes some part of the log output as "child terminated". I'm running out of ideas what to try next. I think a way to log the communication between parent and child would help. Also the parent should terminate the child and then read stdout until EOF to we can see anything that happens afterwards. was: I'm seeing spurious "The forked VM terminated without properly saying goodbye. VM crash or System.exit called?" messages when running unit tests in a big multi-module project. OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191. I'm running Maven from the command line using MinTTY (Cygwin). Things I tried which have no effect: * Reboot / Cold boot (happens first thing on Monday morning when I come into the office and turn on my PC). * More free memory (happens when I only have a single window open). I have 16GB of RAM. * Different terminal. I tried CMD prompt and urxvt (Cygwin/X). * Different versions of the Surefire plugin or Maven * Different JDK 8 builds Things that affect the bug: * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log * Redirecting all log output to a file using logback-test.xml * Running Surefire with forkCount=0 * Running a subset of the tests (-Dtest=...) * Pending Windows updates (I think, not sure about this one). Counts: I've never seen it with forkCount=0 (~20 test builds). I've never seen it with redirecting log output (~ 10 builds). Redirecting sometimes helps but not always. One thing which I notice is that one of the tests creates an ActiveMQ broker and uses a shutdown hook to stop it. So I created a small test project which demonstrates that Surefire will sometimes cut off stdout. I think that happens because the main process kills the child after a timeout (correct?). So my guess would be that shutdown hooks can mess with the pipeline between the surefire child VM and main Maven process. But now, it gets weird. When the build succeeds, it takes about ~5 minutes to run 1028 tests. The log is 25 MB. When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) and the log stops in the middle of a test but is also 25 MB. Some of the time discrepancy is probably because writing to
[jira] [Created] (SUREFIRE-1631) Forked VM terminated without properly saying goodbye with AciveMQ
Aaron Digulla created SUREFIRE-1631: --- Summary: Forked VM terminated without properly saying goodbye with AciveMQ Key: SUREFIRE-1631 URL: https://issues.apache.org/jira/browse/SUREFIRE-1631 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 3.0.0-M2, 2.22.0, 3.0.0-M1, 2.20.1 Reporter: Aaron Digulla I'm seeing spurious "The forked VM terminated without properly saying goodbye. VM crash or System.exit called?" messages when running unit tests in a big multi-module project. OS: Windows 10, running Maven 3.5.0 to 3.6.0 and different versions of Surefire (2.20.1 to 3.0.0.-M2), Java 8u171 to 8u191. I'm running Maven from the command line using MinTTY (Cygwin). Things I tried which have no effect: * Reboot / Cold boot (happens first thing on Monday morning when I come into the office and turn on my PC). * More free memory (happens when I only have a single window open). I have 16GB of RAM. * Different terminal. I tried CMD prompt and urxvt (Cygwin/X). * Different versions of the Surefire plugin or Maven * Different JDK 8 builds Things that affect the bug: * Redirecting Maven's stdout to a file: mvn ... | tee mvn.log * Redirecting all log output to a file using logback-test.xml * Running Surefire with forkCount=0 * Running a subset of the tests (-Dtest=...) * Pending Windows updates (I think, not sure about this one). Counts: I've never seen it with forkCount=0 (~20 test builds). I've never seen it with redirecting log output (~ 10 builds). Redirecting sometimes helps but not always. One thing which I notice is that one of the tests creates an ActiveMQ broker and uses a shutdown hook to stop it. So I created a small test project which demonstrates that Surefire will sometimes cut off stdout. I think that happens because the main process kills the child after a timeout (correct?). So my guess would be that shutdown hooks can mess with the pipeline between the surefire child VM and main Maven process. But now, it gets weird. When the build succeeds, it takes about ~5 minutes to run 1028 tests. The log is 25 MB. When it fails, it takes ~8 minutes to run ~700-800 tests (this number varies) and the log stops in the middle of a test but is also 25 MB. Some of the time discrepancy is probably because writing to a file is faster than printing on a terminal. The strange part is that the log file is about the same size but 30% of the tests haven't run. Most tests log a lot, do I would expect to see a difference of at least a few MB. The Maven part (which contains escape sequences, etc). is just 60 KB. Maybe the parent takes some part of the log output as "child terminated". I'm running out of ideas what to try next. I think a way to log the communication between parent and child would help. Also the parent should terminate the child and then read stdout until EOF to we can see anything that happens afterwards. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (MASSEMBLY-812) containerDescriptorHandler metaInf-services breaks services in sub-folders of META-INF/services
Aaron Digulla created MASSEMBLY-812:
---
Summary: containerDescriptorHandler metaInf-services breaks
services in sub-folders of META-INF/services
Key: MASSEMBLY-812
URL: https://issues.apache.org/jira/browse/MASSEMBLY-812
Project: Maven Assembly Plugin
Issue Type: Bug
Components: component descriptor
Reporter: Aaron Digulla
ActiveMQ has an odd structure to define Java services. Instead of putting them
into {{META-INF/services/}}__, they put them into sub-folders:
{code}
1008 2016-04-28 12:30
META-INF/services/org/apache/activemq/wireformat/default
1013 2016-04-28 12:30
META-INF/services/org/apache/activemq/transport/mock
1011 2016-04-28 12:30
META-INF/services/org/apache/activemq/transport/ssl
1011 2016-04-28 12:30
META-INF/services/org/apache/activemq/transport/nio+ssl
1011 2016-04-28 12:30
META-INF/services/org/apache/activemq/transport/udp
1023 2016-04-28 12:30
META-INF/services/org/apache/activemq/transport/multicast
1011 2016-04-28 12:30
META-INF/services/org/apache/activemq/transport/tcp
{code}
After merging services with the metaInf-services, the folder looks like so:
{code}
1008 2016-04-28 12:30 META-INF/services/default
1013 2016-04-28 12:30 META-INF/services/mock
1011 2016-04-28 12:30 META-INF/services/ssl
1011 2016-04-28 12:30 META-INF/services/nio+ssl
1011 2016-04-28 12:30 META-INF/services/udp
1023 2016-04-28 12:30 META-INF/services/multicast
1011 2016-04-28 12:30 META-INF/services/tcp
{code}
which renders the JAR useless.
You can test with this JAR:
http://search.maven.org/#artifactdetails%7Corg.apache.activemq%7Cactivemq-client%7C5.13.3%7Cjar
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (MASSEMBLY-811) Document possible values for handlerName in containerDescriptorHandler plus their configuration
Aaron Digulla created MASSEMBLY-811: --- Summary: Document possible values for handlerName in containerDescriptorHandler plus their configuration Key: MASSEMBLY-811 URL: https://issues.apache.org/jira/browse/MASSEMBLY-811 Project: Maven Assembly Plugin Issue Type: Documentation Components: component descriptor Affects Versions: 2.6 Reporter: Aaron Digulla There is no documentation that I could find on the official site (https://maven.apache.org/plugins/maven-assembly-plugin/) which explains which handlers exist and how to configure them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[
https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15081867#comment-15081867
]
Aaron Digulla commented on MRESOURCES-171:
--
[~afloom] Well, he can't use Maven and expect properties files to work, then.
It's as simple as that: You have place A where you can't change anything and
place B, where you can, so B has to give. That means if you load all your
resources via {{ResourceBundles}} and you don't use any libraries, this might
work. Or maybe the code above is a workaround for the broken Maven resource
plugin - which would give this bug even more priority.
[~khmarbaise] Please reopen the bug. As you quoted: *Characters not in Latin1
... are represented ... using Unicode escapes* That means you can never use
anything but Latin 1 in plain properties files and expect them to work. Which
is why Java comes with
[native2ascii|http://docs.oracle.com/javase/7/docs/technotes/tools/windows/native2ascii.html]
> ISO8859-1 properties files get changed into UTF-8 when filtered
> ---
>
> Key: MRESOURCES-171
> URL: https://issues.apache.org/jira/browse/MRESOURCES-171
> Project: Maven Resources Plugin
> Issue Type: Bug
> Components: filtering
>Reporter: Alex Collins
>Priority: Minor
> Attachments: filtering-bug.zip
>
>
> Create:
> src/main/resources/test.properties
> And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u
> formatting.
> When adding this line:
> src/main/resourcestrue
> Expected:
> ISO8859-1 encoded file in jar.
> Actual:
> UTF-8 encoded file in jar.
> ---
> If there are any property files (which can only be ISO8859-1) they appear to
> be converted into UTF-8 in the jar.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076468#comment-15076468 ] Aaron Digulla commented on MRESOURCES-171: -- We have all been in your place and thought "this can't be, can it? How is that supposed to work?" Well, it may be a bug or a feature but the fact is: The Java VM *always* uses ISO-8859-1 to read and write properties files. Unless you get Oracle and all the other JVMs to change the source code, that's the way it is. And all the IDEs and all the other tools and ... you get the idea. You want Chinese in a properties file? You need to use escape sequences. I don't like it either but no amount of dislike is going to change the facts. > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://issues.apache.org/jira/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Priority: Minor > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076468#comment-15076468 ] Aaron Digulla edited comment on MRESOURCES-171 at 1/2/16 9:19 AM: -- We have all been in your place and thought "this can't be, can it? How is that supposed to work?" Well, it may be a bug or a feature but the fact is: The Java VM *always* uses ISO-8859-1 to read and write properties files. It's hard coded in Properties.java. There is no system property; it's a string constant. Unless you get Oracle and all the other JVMs to change the source code, that's the way it is. And all the IDEs and all the other tools and ... you get the idea. You want Chinese in a properties file? You need to use escape sequences. I don't like it either but no amount of dislike is going to change the facts. was (Author: digulla): We have all been in your place and thought "this can't be, can it? How is that supposed to work?" Well, it may be a bug or a feature but the fact is: The Java VM *always* uses ISO-8859-1 to read and write properties files. Unless you get Oracle and all the other JVMs to change the source code, that's the way it is. And all the IDEs and all the other tools and ... you get the idea. You want Chinese in a properties file? You need to use escape sequences. I don't like it either but no amount of dislike is going to change the facts. > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://issues.apache.org/jira/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Priority: Minor > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076375#comment-15076375 ] Aaron Digulla commented on MRESOURCES-171: -- [~khmarbaise] You obviously didn't understand the bug. In a nutshell: UTF-8 encoding is *illegal* for properties files. GIF files have a defined layout, properties files have one. They *look* like text files but they are text files with ISO-8859-1 encoding *everywhere*. No exceptions, not even for Maven. If you don't like that or you think that is wrong, please get in contact with Oracle and have the file format changed. So please reopen the bug, it's a real, serious, and causes data corruption. > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://issues.apache.org/jira/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Priority: Minor > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://issues.apache.org/jira/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076375#comment-15076375 ] Aaron Digulla edited comment on MRESOURCES-171 at 1/1/16 9:15 PM: -- [~khmarbaise] You obviously didn't understand the bug. In a nutshell: UTF-8 encoding is *illegal* for properties files. GIF files have a defined layout, properties files have one. They *look* like text files but they are text files with ISO-8859-1 encoding *everywhere*. No exceptions, not even for Maven. If you don't like that or you think that is wrong, please get in contact with Oracle and have the file format changed. So please reopen the bug, it's real, serious, and causes data corruption. was (Author: digulla): [~khmarbaise] You obviously didn't understand the bug. In a nutshell: UTF-8 encoding is *illegal* for properties files. GIF files have a defined layout, properties files have one. They *look* like text files but they are text files with ISO-8859-1 encoding *everywhere*. No exceptions, not even for Maven. If you don't like that or you think that is wrong, please get in contact with Oracle and have the file format changed. So please reopen the bug, it's a real, serious, and causes data corruption. > ISO8859-1 properties files get changed into UTF-8 when filtered > --- > > Key: MRESOURCES-171 > URL: https://issues.apache.org/jira/browse/MRESOURCES-171 > Project: Maven Resources Plugin > Issue Type: Bug > Components: filtering >Reporter: Alex Collins >Priority: Minor > Attachments: filtering-bug.zip > > > Create: > src/main/resources/test.properties > And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u > formatting. > When adding this line: > src/main/resourcestrue > Expected: > ISO8859-1 encoded file in jar. > Actual: > UTF-8 encoded file in jar. > --- > If there are any property files (which can only be ISO8859-1) they appear to > be converted into UTF-8 in the jar. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[ https://jira.codehaus.org/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=354160#comment-354160 ] Aaron Digulla commented on MRESOURCES-171: -- @Karl-Heinz Marbaise: What would be a correct/working POM which just applied this encoding to property files and use the default encoding for everything else? I'd suggest to use the encoding iso-8859-1 for copying and resource filtering since it's a 1:1 encoding (each byte just passes through) but that doesn't work when the resource plugin expands a variable with a value that contains Unicode characters (code point 256) since those can't be mapped to iso-8859-1 anymore. So we would have a situation where most parts of a file would make it into the target folder unscathed but in some corner cases, it would fail. ISO8859-1 properties files get changed into UTF-8 when filtered --- Key: MRESOURCES-171 URL: https://jira.codehaus.org/browse/MRESOURCES-171 Project: Maven Resources Plugin Issue Type: Bug Components: filtering Reporter: Alex Collins Priority: Minor Fix For: backlog Attachments: filtering-bug.zip Create: src/main/resources/test.properties And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u formatting. When adding this line: resourcedirectorysrc/main/resources/directoryfilteringtrue/filtering/resource Expected: ISO8859-1 encoded file in jar. Actual: UTF-8 encoded file in jar. --- If there are any property files (which can only be ISO8859-1) they appear to be converted into UTF-8 in the jar. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MRESOURCES-171) ISO8859-1 properties files get changed into UTF-8 when filtered
[
https://jira.codehaus.org/browse/MRESOURCES-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=345029#comment-345029
]
Aaron Digulla commented on MRESOURCES-171:
--
I just stumbled over the same issue.
Background: Property files need to use ISO-8859-1 as encoding as per [the
docs|http://docs.oracle.com/javase/7/docs/api/java/util/Properties.html]:
{quote}
except the input/output stream is encoded in ISO 8859-1 character encoding
{quote}
Note: This is only true for the simple line-oriented properties file format,
not the XML version!
This becomes a problem when the default encoding
{{project.build.sourceEncoding}} is set to something else because the resource
plugin will try to load the files with this encoding (ignoring the Java
standard) which garbles the input when it contains non-ASCII characters like
öäü.
IDE usually get this right by ignoring the project's defaults for these files
and enforcing ISO-8859-1 for {{*.properties}} files.
I see two solutions:
# Configure the resource plugin to ignore those files (which is bad since then,
we can't replace variables in them anymore)
# Offer a per-file-type encoding
That way, one could say:
{code}
configuration
filetypes
filetype
encodingiso-8859-1/encoding
pattern*.properties/pattern
/filetype
/filetypes
/configuration
{code}
I'd even opt for this to be the default.
ISO8859-1 properties files get changed into UTF-8 when filtered
---
Key: MRESOURCES-171
URL: https://jira.codehaus.org/browse/MRESOURCES-171
Project: Maven Resources Plugin
Issue Type: Bug
Components: filtering
Reporter: Alex Collins
Priority: Minor
Attachments: filtering-bug.zip
Create:
src/main/resources/test.properties
And add a ISO8859-1 character that is not ASCII or UTF-8, do not use \u
formatting.
When adding this line:
resourcedirectorysrc/main/resources/directoryfilteringtrue/filtering/resource
Expected:
ISO8859-1 encoded file in jar.
Actual:
UTF-8 encoded file in jar.
---
If there are any property files (which can only be ISO8859-1) they appear to
be converted into UTF-8 in the jar.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MRESOURCES-99) ${project.baseUri} and ${maven.build.timestamp} are not expanded by resource filtering
[
https://jira.codehaus.org/browse/MRESOURCES-99?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=307337#comment-307337
]
Aaron Digulla commented on MRESOURCES-99:
-
I agree; it worries me that some properties are visible in the POM but not in
the resource plugin. What is causing this? Are there two types of properties?
${project.baseUri} and ${maven.build.timestamp} are not expanded by resource
filtering
---
Key: MRESOURCES-99
URL: https://jira.codehaus.org/browse/MRESOURCES-99
Project: Maven 2.x Resources Plugin
Issue Type: Improvement
Components: interpolation
Affects Versions: 2.3, 2.4
Reporter: Thomas Champagne
When filtering resources, ${project.baseUri} and ${maven.build.timestamp} are
not expanded (remains unchanged in the output file).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2553) Maven Local Settings Model should allow configuration of distributions (distributionManagement)
[ https://jira.codehaus.org/browse/MNG-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=302919#comment-302919 ] Aaron Digulla commented on MNG-2553: I have a different use case: I often need to deploy existing third party projects to our internal repository. Not all of them have distributionManagement elements and not all of them use your properties-scheme. Currently, I have to find the parent POM (and possibly check out another project), add the distributionManagement there, deploy it and only then I can deploy the project. It would be really useful to be able to create a profile which just contains a distributionManagement for my internal repo so I can deploy anything into it without having to edit the original POM. Because that either gives me a file that I must not check in (so the project is always in a needs commit state) or, even worse, I might accidentally commit it and ruin the day for other people. Please reconsider. Maven Local Settings Model should allow configuration of distributions (distributionManagement) --- Key: MNG-2553 URL: https://jira.codehaus.org/browse/MNG-2553 Project: Maven 2 3 Issue Type: Improvement Components: Settings Affects Versions: 2.0.4 Reporter: Jimisola Laursen There is a good use case where this would be very useful. E.g. I develop a plugin in mojo-sandbox and want to test it in an environment other than the one that I developed it on (e.g. a computer at work). I check out the plugin to this, build and then want to deploy to another repository (e..g a company's internal repository). I don't want to fiddle with the pom.xml of the plugin, just refer to a profile in settings.xml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-2553) Maven Local Settings Model should allow configuration of distributions (distributionManagement)
[ https://jira.codehaus.org/browse/MNG-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=302920#comment-302920 ] Aaron Digulla commented on MNG-2553: Oh, and the official documentation says, distributionManagement is support in settings.xml: https://maven.apache.org/pom.html#Profiles Maven Local Settings Model should allow configuration of distributions (distributionManagement) --- Key: MNG-2553 URL: https://jira.codehaus.org/browse/MNG-2553 Project: Maven 2 3 Issue Type: Improvement Components: Settings Affects Versions: 2.0.4 Reporter: Jimisola Laursen There is a good use case where this would be very useful. E.g. I develop a plugin in mojo-sandbox and want to test it in an environment other than the one that I developed it on (e.g. a computer at work). I check out the plugin to this, build and then want to deploy to another repository (e..g a company's internal repository). I don't want to fiddle with the pom.xml of the plugin, just refer to a profile in settings.xml. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5134) Standard documentation for build-in properties
[ https://jira.codehaus.org/browse/MNG-5134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=295435#comment-295435 ] Aaron Digulla commented on MNG-5134: I can't find this document. Where is it? You added it to the site index of maven-model-builder but that plugin has no index page (404 when trying to load https://maven.apache.org/maven-model-builder) This should go into https://maven.apache.org/pom.html or at least in a place close to it or you should add a link to the properties section in the POM documentation plus a link in the site menu to the left. Standard documentation for build-in properties -- Key: MNG-5134 URL: https://jira.codehaus.org/browse/MNG-5134 Project: Maven 2 3 Issue Type: Improvement Components: Documentation: General Reporter: Paul Gier Assignee: Paul Gier Priority: Minor Fix For: 3.0.4 The Maven site documentation should include a reference to all the available properties. There are a couple of existing locations of property documentation, but nothing on the official Maven site from what I can tell. http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide http://www.sonatype.com/books/mvnref-book/reference/resource-filtering-sect-properties.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-5268) Check the version of the parent POM, too
Aaron Digulla created MNG-5268:
--
Summary: Check the version of the parent POM, too
Key: MNG-5268
URL: https://jira.codehaus.org/browse/MNG-5268
Project: Maven 2 3
Issue Type: Improvement
Components: POM
Affects Versions: 3.0.4, 3.0.3
Reporter: Aaron Digulla
When doing a multi-module build, Maven checks that the coordinates of the
parent POM matches what you'd get by reading the POM via {{relativePath}} but
it doesn't check the version.
This can cause subtle bugs if the coordinates are correct but one forgets to
update the version of all modules after the parent version changes.
Please print a warning if the version in the {{parent}} element doesn't match
the version of the POM read via {{relativePath}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-134) Update to PMD 4.3 -- allow target to java 7
[ https://jira.codehaus.org/browse/MPMD-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=287403#comment-287403 ] Aaron Digulla commented on MPMD-134: +1 to have this in 2.7. Update to PMD 4.3 -- allow target to java 7 --- Key: MPMD-134 URL: https://jira.codehaus.org/browse/MPMD-134 Project: Maven 2.x PMD Plugin Issue Type: Wish Components: PMD Reporter: Eric Barboni Attachments: CpdReportGenerator.java After patching some source file with new Java 7 diamond operator (i.e. new HashMap()) all reports on this files are broken due to parsing error. It would be nice to patch the next 2.7 plug-in with 4.3 PMD to support all Java version grammar. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-126) PMD fails to parse source code in a specific case
[
https://jira.codehaus.org/browse/MPMD-126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=287404#comment-287404
]
Aaron Digulla commented on MPMD-126:
Does your code contain annotations? Can you post line 99?
If it contains annotations, did you set {{targetJdk}} to 1.5 or 1.6?
Also try version 2.6 of the plugin.
PMD fails to parse source code in a specific case
-
Key: MPMD-126
URL: https://jira.codehaus.org/browse/MPMD-126
Project: Maven 2.x PMD Plugin
Issue Type: Bug
Components: PMD
Affects Versions: 2.5
Environment: Gentoo Linux 64bit
Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_20
OS name: linux version: 2.6.34-gentoo-r12 arch: amd64 Family: unix
Reporter: Robin Vobruba
Priority: Minor
Attachments: PmdTest.java
i appended a test .java file, which is as minimal as i was able to get it.
when having it in my project, with the pmd plugin defined under reporting,
and then using mvn site,
PMD fails to parse the source code.
Output:
#
[INFO] Generating PMD Report report.
[WARNING] Error while parsing PmdTest.java: Encountered ( ( at line
99, column 22.
Was expecting one of:
. ...
. ...
. ...
#
(there are more of these last 3 lines)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPMD-125) net.sourceforge.pmd.ast.ASTCompilationUnit cannot be cast to net.sourceforge.pmd.jsp.ast.SimpleNode warning..
[
https://jira.codehaus.org/browse/MPMD-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=287405#comment-287405
]
Aaron Digulla commented on MPMD-125:
Probably related to this PMD bug:
https://sourceforge.net/tracker/?func=detailatid=479921aid=1763025group_id=56262#
net.sourceforge.pmd.ast.ASTCompilationUnit cannot be cast to
net.sourceforge.pmd.jsp.ast.SimpleNode warning..
---
Key: MPMD-125
URL: https://jira.codehaus.org/browse/MPMD-125
Project: Maven 2.x PMD Plugin
Issue Type: Bug
Components: PMD
Affects Versions: 2.5
Environment: maven 3.0, jdk 1.6
Reporter: Yegor Bugayenko
I keep seeing this message for every project I run:
{noformat}
[WARNING] Error while processing
[...]/src/main/java/com/woquo/wid/package-info.java:
net.sourceforge.pmd.ast.ASTCompilationUnit cannot be cast to
net.sourceforge.pmd.jsp.ast.SimpleNode
{noformat}
Would be nice to fix this. Thanks.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MDEP-233) dependency:copy goal should accept copyPom and useRepositoryLayout properties
[
https://jira.codehaus.org/browse/MDEP-233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=284622#comment-284622
]
Aaron Digulla commented on MDEP-233:
The bug is that the copy task will put the JAR and the POM in different folders
(see MDEP-312), that is the code which implements {{copyPom}} doesn't honor the
value of {{useRepositoryLayout}}. All POMs will end up in the
{{outputDirectory}} and the JARs will be in subfolders.
dependency:copy goal should accept copyPom and useRepositoryLayout properties
-
Key: MDEP-233
URL: https://jira.codehaus.org/browse/MDEP-233
Project: Maven 2.x Dependency Plugin
Issue Type: Improvement
Components: copy
Affects Versions: 2.2
Reporter: Antonio Manuel Muñiz Martín
Assignee: Brian Fox
Priority: Minor
dependency:copy goal should accept copyPom and useRepositoryLayout properties:
{code}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-dependency-plugin/artifactId
version2.1/version
configuration
/artifactItems
artifactItem
groupIdjavax.transaction/groupId
artifactIdjta/artifactId
version1.0.1B/version
outputDirectorytarget/lib/jta/outputDirectory
/artifactItem
/artifactItems
copyPomtrue/copyPom
useRepositoryLayouttrue/useRepositoryLayout
/configuration
/plugin
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MINSTALL-85) Please create JARs with temporary name and rename them
Please create JARs with temporary name and rename them -- Key: MINSTALL-85 URL: https://jira.codehaus.org/browse/MINSTALL-85 Project: Maven 2.x Install Plugin Issue Type: Improvement Components: install:install Affects Versions: 2.3.1 Reporter: Aaron Digulla If you have Eclipse running and do a Maven install, the VM can crash if Eclipse tries to read a JAR file while maven install writes it (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7074879). Please create JARs with a temporary name and then rename them after the copy operation has finished. Rename is an atomic operation on all file systems and prevents the issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MVERIFIER-10) Print the absolute path to the input file when verification fails
[
https://jira.codehaus.org/browse/MVERIFIER-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=273154#comment-273154
]
Aaron Digulla commented on MVERIFIER-10:
Here is the complete stack trace:
{code}
org.apache.maven.it.VerificationException: org.xml.sax.SAXException: Invalid
mavenProfile entry. Missing one or more fields: {localRepository}.
at
org.apache.maven.it.Verifier$UserModelReader.parse(Verifier.java:1917)
at org.apache.maven.it.Verifier.retrieveLocalRepo(Verifier.java:781)
at org.apache.maven.it.Verifier.findLocalRepo(Verifier.java:1822)
at org.apache.maven.it.Verifier.init(Verifier.java:150)
at org.apache.maven.it.Verifier.init(Verifier.java:127)
at org.apache.maven.it.Verifier.init(Verifier.java:121)
at org.apache.maven.it.Verifier.init(Verifier.java:176)
at
org.eclipse.tycho.test.AbstractTychoIntegrationTest.getVerifier(AbstractTychoIntegrationTest.java:81)
at
org.eclipse.tycho.test.AbstractTychoIntegrationTest.getVerifier(AbstractTychoIntegrationTest.java:51)
at
org.eclipse.tycho.test.AbstractTychoIntegrationTest.getVerifier(AbstractTychoIntegrationTest.java:109)
{code}
Print the absolute path to the input file when verification fails
-
Key: MVERIFIER-10
URL: https://jira.codehaus.org/browse/MVERIFIER-10
Project: Maven 2.x Verifier Plugin
Issue Type: New Feature
Reporter: Aaron Digulla
While building Tycho, I had this exception:
{{org.apache.maven.it.VerificationException: org.xml.sax.SAXException: Invalid
mavenProfile entry. Missing one or more fields: {localRepository}.}}
The error message was useless for me because I have no idea which file caused
the error.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MVERIFIER-10) Print the absolute path to the input file when verification fails
Print the absolute path to the input file when verification fails
-
Key: MVERIFIER-10
URL: https://jira.codehaus.org/browse/MVERIFIER-10
Project: Maven 2.x Verifier Plugin
Issue Type: New Feature
Reporter: Aaron Digulla
While building Tycho, I had this exception:
{{org.apache.maven.it.VerificationException: org.xml.sax.SAXException: Invalid
mavenProfile entry. Missing one or more fields: {localRepository}.}}
The error message was useless for me because I have no idea which file caused
the error.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DOXIASITETOOLS-60) Useless error message error in opening zip file in DefaultSiteRenderer.createContextForSkin()
[
http://jira.codehaus.org/browse/DOXIASITETOOLS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268447#action_268447
]
Aaron Digulla commented on DOXIASITETOOLS-60:
-
Yes. The debug output doesn't list the resources which the plugin loads. That
might be a valuable addition.
Useless error message error in opening zip file in
DefaultSiteRenderer.createContextForSkin()
---
Key: DOXIASITETOOLS-60
URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-60
Project: Maven Doxia Sitetools
Issue Type: Improvement
Components: Site renderer
Affects Versions: 1.2
Reporter: Aaron Digulla
Assignee: Lukas Theussl
Fix For: 1.2.1
When I run {{mvn site}} on my project, I get an exception in
DefaultSiteRenderer.createContextForSkin(): error in opening zip file
Which zip file?
--
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: (DOXIASITETOOLS-60) Useless error message error in opening zip file in DefaultSiteRenderer.createContextForSkin()
[
http://jira.codehaus.org/browse/DOXIASITETOOLS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268281#action_268281
]
Aaron Digulla commented on DOXIASITETOOLS-60:
-
The JAR file seems OK so the problem must be that Maven is pulling something in
that I don't expect/see.
How can I get this version of Doxia to test?
Useless error message error in opening zip file in
DefaultSiteRenderer.createContextForSkin()
---
Key: DOXIASITETOOLS-60
URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-60
Project: Maven Doxia Sitetools
Issue Type: Improvement
Components: Site renderer
Affects Versions: 1.2
Reporter: Aaron Digulla
Assignee: Lukas Theussl
Fix For: 1.3
When I run {{mvn site}} on my project, I get an exception in
DefaultSiteRenderer.createContextForSkin(): error in opening zip file
Which zip file?
--
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: (DOXIA-431) Doxia creates illegal URLs from local paths
[
http://jira.codehaus.org/browse/DOXIA-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268284#action_268284
]
Aaron Digulla commented on DOXIA-431:
-
Doxia 1.2 is not used...
I had problems with the site plugin 3.0-beta-3, so I tried beta-4-SNAPSHOT.
Is this a regression?
Probably. My guess is that recent code changes unveiled a whole set of errors.
where does this image come from...
The image comes from the folder {{src/site/resources/images/}}
I'm not the maintainer of the project, so I have no idea how Doxia includes the
image. All I have is the error message and the filename. I can't see any
reference to the image in site.xml, so it must be included from somewhere else,
probably the skin.
Is it documented somewhere that image/file references...?
A URL can contain only some characters. See
http://www.blooberry.com/indexdot/html/topics/urlencoding.htm for a pretty good
explanation.
File names on Unix can contain anything except / (slash) and 0-bytes.
So if you accept Unix file names anywhere in Doxia, you must escape them as
soon as they are converted to URLs and you must unescape them when they are
converted back to file names.
My suggestion is a new type which can be both and which has accessor methods to
get a OS-specific path or a RFC-compliant URL and to get rid of the type String
as soon as you can to make sure you don't have any gaps in the chain.
Doxia creates illegal URLs from local paths
---
Key: DOXIA-431
URL: http://jira.codehaus.org/browse/DOXIA-431
Project: Maven Doxia
Issue Type: Bug
Components: Core
Affects Versions: 1.2
Reporter: Aaron Digulla
If a local resource contains characters which are illegal in a URL, Doxia
creates illegal code or crashes.
--
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: (DOXIA-431) Doxia creates illegal URLs from local paths
[ http://jira.codehaus.org/browse/DOXIA-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268325#action_268325 ] Aaron Digulla commented on DOXIA-431: - I have no idea. But from my experience, I'd say that those URLs should already be encoded. I mean Image[1].png is a valid Unix filename. If you want to use that as a caption, you need escaping. So maybe the solution is to reject strings which contain invalid characters close to the input side. But I saw that you have sanitize methods in some URL helper class in Doxia. That led me to think that you want to do it there and I don't believe this will work. Data must be sanitized and validated in the outside interface, not deep in the code. Doxia creates illegal URLs from local paths --- Key: DOXIA-431 URL: http://jira.codehaus.org/browse/DOXIA-431 Project: Maven Doxia Issue Type: Bug Components: Core Affects Versions: 1.2 Reporter: Aaron Digulla If a local resource contains characters which are illegal in a URL, Doxia creates illegal code or crashes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-584) Useless error message error in opening zip file in DefaultSiteRenderer.createContextForSkin()
Useless error message error in opening zip file in
DefaultSiteRenderer.createContextForSkin()
---
Key: MSITE-584
URL: http://jira.codehaus.org/browse/MSITE-584
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:run
Affects Versions: 3.0-beta-3
Reporter: Aaron Digulla
When I run {{mvn site}} on my project, I get an exception in
DefaultSiteRenderer.createContextForSkin(): error in opening zip file
Which zip file?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-584) Useless error message error in opening zip file in DefaultSiteRenderer.createContextForSkin()
[
http://jira.codehaus.org/browse/MSITE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268172#action_268172
]
Aaron Digulla commented on MSITE-584:
-
Here is the full stack trace:
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site (default-site) on
project ExBib: Error during site generation: error in opening zip file - [Help
1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site (default-site) on
project ExBib: Error during site generation
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
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.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Error during site
generation
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:131)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.init(ZipFile.java:127)
at java.util.zip.ZipFile.init(ZipFile.java:144)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.createContextForSkin(DefaultSiteRenderer.java:616)
at
org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:312)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:138)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:122)
... 21 more
{code}
Useless error message error in opening zip file in
DefaultSiteRenderer.createContextForSkin()
---
Key: MSITE-584
URL: http://jira.codehaus.org/browse/MSITE-584
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:run
Affects Versions: 3.0-beta-3
Reporter: Aaron Digulla
When I run {{mvn site}} on my project, I get an exception in
DefaultSiteRenderer.createContextForSkin(): error in opening zip file
Which zip file?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-584) Useless error message error in opening zip file in DefaultSiteRenderer.createContextForSkin()
[
http://jira.codehaus.org/browse/MSITE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268173#action_268173
]
Aaron Digulla commented on MSITE-584:
-
Please add a {{try/catch}} in {{createContextForSkin()}} that adds the file
name to the error message (with absolute path).
Useless error message error in opening zip file in
DefaultSiteRenderer.createContextForSkin()
---
Key: MSITE-584
URL: http://jira.codehaus.org/browse/MSITE-584
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:run
Affects Versions: 3.0-beta-3
Reporter: Aaron Digulla
When I run {{mvn site}} on my project, I get an exception in
DefaultSiteRenderer.createContextForSkin(): error in opening zip file
Which zip file?
--
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: (DOXIA-431) Doxia creates illegal URLs from local paths
Doxia creates illegal URLs from local paths --- Key: DOXIA-431 URL: http://jira.codehaus.org/browse/DOXIA-431 Project: Maven Doxia Issue Type: Bug Components: Core Affects Versions: 1.2 Reporter: Aaron Digulla If a local resource contains characters which are illegal in a URL, Doxia creates illegal code or crashes. -- 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: (DOXIA-431) Doxia creates illegal URLs from local paths
[
http://jira.codehaus.org/browse/DOXIA-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=268177#action_268177
]
Aaron Digulla commented on DOXIA-431:
-
In an external project, there are image files which contain spaces. Instead of
replacing the spaces with %20 or calling {{java.net.URLEncoder.encode()}},
Doxia tries to call {{new java.net.URL(images/The ExTeX Project.png}} which
fails.
I tried a fix but couldn't get it to work in a couple of hours. The problem is
that you use a lot of Strings when you should be using URLs (or at least a
URL-like type). Without such a type, it's impossible to know when a URL must be
encoded/decoded.
Example stacktrace:
{code}
Caused by: java.lang.IllegalArgumentException
at java.net.URI.create(URI.java:842)
at
org.apache.maven.doxia.site.decoration.inheritance.URIPathDescriptor.init(URIPathDescriptor.java:69)
at
org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.rebaseLink(DefaultDecorationModelInheritanceAssembler.java:361)
at
org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.rebaseBannerPaths(DefaultDecorationModelInheritanceAssembler.java:162)
at
org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleModelInheritance(DefaultDecorationModelInheritanceAssembler.java:61)
at
org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:1221)
at
org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:458)
at
org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:285)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:140)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:124)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
... 20 more
Caused by: java.net.URISyntaxException: Illegal character in path at index 10:
images/The ExTeX Project.png
at java.net.URI$Parser.fail(URI.java:2809)
at java.net.URI$Parser.checkChars(URI.java:2982)
at java.net.URI$Parser.parseHierarchical(URI.java:3066)
at java.net.URI$Parser.parse(URI.java:3024)
at java.net.URI.init(URI.java:578)
at java.net.URI.create(URI.java:840)
... 30 more
{code}
Doxia creates illegal URLs from local paths
---
Key: DOXIA-431
URL: http://jira.codehaus.org/browse/DOXIA-431
Project: Maven Doxia
Issue Type: Bug
Components: Core
Affects Versions: 1.2
Reporter: Aaron Digulla
If a local resource contains characters which are illegal in a URL, Doxia
creates illegal code or crashes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-492) publishDate position=bottom doesn't work
[ http://jira.codehaus.org/browse/MSITE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=230330#action_230330 ] Aaron Digulla commented on MSITE-492: - Sorry, PEBKAC. Thanks. :-) publishDate position=bottom doesn't work -- Key: MSITE-492 URL: http://jira.codehaus.org/browse/MSITE-492 Project: Maven 2.x Site Plugin Issue Type: Bug Components: site descriptor Affects Versions: 2.1.1 Reporter: Aaron Digulla In the file default-site.vm is a call for the macro #publishDate with the parameter buttom but this value isn't used in the macro code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-492) publishDate position=bottom doesn't work
[ http://jira.codehaus.org/browse/MSITE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Digulla closed MSITE-492. --- Resolution: Not A Bug Fix Version/s: 2.1.1 There was an additional head element around the publishDate element. publishDate position=bottom doesn't work -- Key: MSITE-492 URL: http://jira.codehaus.org/browse/MSITE-492 Project: Maven 2.x Site Plugin Issue Type: Bug Components: site descriptor Affects Versions: 2.1.1 Reporter: Aaron Digulla Fix For: 2.1.1 In the file default-site.vm is a call for the macro #publishDate with the parameter buttom but this value isn't used in the macro code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-492) publishDate position=bottom doesn't work
publishDate position=bottom doesn't work -- Key: MSITE-492 URL: http://jira.codehaus.org/browse/MSITE-492 Project: Maven 2.x Site Plugin Issue Type: Bug Components: site descriptor Affects Versions: 2.1.1 Reporter: Aaron Digulla In the file default-site.vm is a call for the macro #publishDate with the parameter buttom but this value isn't used in the macro code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3614) settings.xml active profiles executed AFTER project profiles have been loaded and activated/not activated
[ http://jira.codehaus.org/browse/MNG-3614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=143332#action_143332 ] Aaron Digulla commented on MNG-3614: I have a similar issue: I have defined a property in the settings.xml with the version of the parent POM. Unfortunately, maven tries to validate the POM before loading the settings, so this doesn't work. I would also expect that maven reads the settings file first, activate all profiles in there which should be active and then check again if the POM of the project defines more properties which influence the active profiles. settings.xml active profiles executed AFTER project profiles have been loaded and activated/not activated - Key: MNG-3614 URL: http://jira.codehaus.org/browse/MNG-3614 Project: Maven 2 Issue Type: Bug Components: Inheritance and Interpolation, Profiles, Settings Affects Versions: 2.0.9 Environment: Solaris 5.10, ubuntu hardy x64 Reporter: Donald Abrams Priority: Minor Fix For: 2.0.x If you have the following settings.xml in ~/.m2: ?xml version=1.0 encoding=UTF-8? settings profiles profile iduserSettings/id activation activeByDefault/ /activation properties somepropertytrue/someproperty /properties /profile /profiles activeProfiles activeProfileuserSettings/activeProfile /activeProfiles /settings and another child pom.xml somewhere down the line has a profile with an activation like this: project xmlns=http://maven.apache.org/POM/4.0.0; modelVersion4.0.0/modelVersion profiles profile idwith-something/id activation activeByDefaultfalse/activeByDefault property namesomeproperty/name valuetrue/value /property /activation /profile /profiles /project During run-time, the profile with-something will load before userSettings. This causes with-something to be incorrectly not activated (as the property someproperty does not exist). This can be seen with mvn help:active-profiles. I know why this is true, but it is non-intuitive and one would expect settings.xml profiles to be loaded before anything else. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-3523) Bad error message if plugin.xml is missing/corrupt
[ http://jira.codehaus.org/browse/MNG-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=130755#action_130755 ] digulla edited comment on MNG-3523 at 4/15/08 2:54 AM: - Thanks for the fix in 2.0.10. This one really cost me a lot of nerves :) was (Author: digulla): Sweet. How did you fix it? Bad error message if plugin.xml is missing/corrupt -- Key: MNG-3523 URL: http://jira.codehaus.org/browse/MNG-3523 Project: Maven 2 Issue Type: Bug Components: Plugin API Affects Versions: 2.0.9 Reporter: Aaron Digulla Fix For: 2.0.10 Take the JAR of the maven-resources-plugin, delete the file META-INF/maven/plugin.xml and run maven. You'll get this error: java.lang.IllegalStateException: The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-resources-plugin] was not found. -- 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-3523) Bad error message if plugin.xml is missing/corrupt
Bad error message if plugin.xml is missing/corrupt -- Key: MNG-3523 URL: http://jira.codehaus.org/browse/MNG-3523 Project: Maven 2 Issue Type: Bug Components: Plugin API Affects Versions: 2.0.9 Reporter: Aaron Digulla Take the JAR of the maven-resources-plugin, delete the file META-INF/maven/plugin.xml and run maven. You'll get this error: java.lang.IllegalStateException: The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-resources-plugin] was not found. -- 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-3523) Bad error message if plugin.xml is missing/corrupt
[ http://jira.codehaus.org/browse/MNG-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=130742#action_130742 ] Aaron Digulla commented on MNG-3523: Technically, this is correct but doesn't really help to locate the root cause of the problem. If maven can't read the plugin.xml file of a plugin, it should abort with an error during the XML parsing step instead of trying to use the plugin anyway. Real world case: The plugin is downloaded via a proxy and the download aborts before the full file is transferred or the proxy returns a HTML file (A virus was detected blahblah) instead of the JAR. This can lead to corrupt JARs in the repository which leads to the error above. PS: Not sure if this is Plugin API or Plugins and Lifecycle. Please feel free to move the error report to the right place. Bad error message if plugin.xml is missing/corrupt -- Key: MNG-3523 URL: http://jira.codehaus.org/browse/MNG-3523 Project: Maven 2 Issue Type: Bug Components: Plugin API Affects Versions: 2.0.9 Reporter: Aaron Digulla Take the JAR of the maven-resources-plugin, delete the file META-INF/maven/plugin.xml and run maven. You'll get this error: java.lang.IllegalStateException: The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-resources-plugin] was not found. -- 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-3523) Bad error message if plugin.xml is missing/corrupt
[ http://jira.codehaus.org/browse/MNG-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=130755#action_130755 ] Aaron Digulla commented on MNG-3523: Sweet. How did you fix it? Bad error message if plugin.xml is missing/corrupt -- Key: MNG-3523 URL: http://jira.codehaus.org/browse/MNG-3523 Project: Maven 2 Issue Type: Bug Components: Plugin API Affects Versions: 2.0.9 Reporter: Aaron Digulla Fix For: 2.0.10 Take the JAR of the maven-resources-plugin, delete the file META-INF/maven/plugin.xml and run maven. You'll get this error: java.lang.IllegalStateException: The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-resources-plugin] was not found. -- 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-2691) DefaultPluginManager.addPlugin() doesn't tell which plugin is broken
[ http://jira.codehaus.org/browse/MNG-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=129787#action_129787 ] Aaron Digulla commented on MNG-2691: I think this bug is fixed in 2.0.8 but there is a new issue: I get this error with the maven-site-plugin 2.0-beta-6: [code] [DEBUG] maven-site-plugin: resolved to version 2.0-beta-6 from repository central [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::10 for project: null:maven-site-plugin:maven-plugin:2.0-beta-6 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::7 for project: org.apache.maven.plugins:maven-plugins:pom:10 from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache::4 for project: org.apache.maven:maven-parent:pom:7 from the repository. [INFO] [ERROR] FATAL ERROR [INFO] [INFO] The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-site-plugin] was not found. [INFO] [DEBUG] Trace java.lang.IllegalStateException: The PluginDescriptor for the plugin Plugin [org.apache.maven.plugins:maven-site-plugin] was not found. at org.apache.maven.plugin.DefaultPluginManager.addPlugin(DefaultPluginManager.java:321) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:208) [code] As you can see, the plugin exists and the POM could be loaded. So what is wrong in this case? DefaultPluginManager.addPlugin() doesn't tell which plugin is broken Key: MNG-2691 URL: http://jira.codehaus.org/browse/MNG-2691 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.5 Reporter: Aaron Digulla Fix For: Reviewed Pending Version Assignment In DefaultPluginManager.addPlugin() is code like this: throw new IllegalStateException( The PluginDescriptor for the plugin + plugin + was not found. ); Unfortunately, plugin has no toString(), so you just see the Java classname and the object id. Replace all three places with plugin.getKey() or, even better, add a new method to Plugin which also includes the version string if there is one. Also the error message of the IllegalStateException should be: The PluginDescriptor for the plugin + plugin.getKey() + was not found. Are you sure this is a Maven plugin and not a normal 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
[jira] Commented: (MWAR-120) Option containerConfigXML doesn't work
[ http://jira.codehaus.org/browse/MWAR-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_77 ] Aaron Digulla commented on MWAR-120: I think I found it: In the code, you check whether the option is set. If so, you add an ignore pattern for any context.xml which might be in the META-INF directory of the project (i.e. src\main\webapp\META-INF\context.xml). In my case, that's the file I tried to add with the option, so it gets mysteriously ignored. As a fix, I suggest that you check whether the value of the option matches the ignore pattern and if so, don't add the pattern. Option containerConfigXML doesn't work -- Key: MWAR-120 URL: http://jira.codehaus.org/browse/MWAR-120 Project: Maven 2.x War Plugin Issue Type: Bug Reporter: Aaron Digulla Fix For: 2.1-alpha-2 Attachments: context-bug.zip The file specified with containerConfigXML is copied to the exploded WAR directory but it will not end up in the final WAR. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-174) Plugin doesn't cache source not available status
[ http://jira.codehaus.org/browse/MECLIPSE-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108589 ] Aaron Digulla commented on MECLIPSE-174: I can confirm that. It seems the list of downloaded files which you get back from resolveArtifacts() (from memory; I'm not at my work PC right now) is empty. Plugin doesn't cache source not available status -- Key: MECLIPSE-174 URL: http://jira.codehaus.org/browse/MECLIPSE-174 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Affects Versions: 2.2 Reporter: Aaron Digulla Assignee: fabrizio giustina Priority: Minor Fix For: 2.3 When the m2 plugin reads the POM files and Download sources is set in the Eclipse preferences, it tries to download the source every time. Instead, it should cache the source not available status somewhere (just like Maven itself does) and not print thousands of error messages (Unable to download the artifact from any repository). This also delays the build considerably (opening network connections) and real errors are drowned. -- 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: (MWAR-120) Option containerConfigXML doesn't work
[ http://jira.codehaus.org/browse/MWAR-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108362 ] Aaron Digulla commented on MWAR-120: Maybe this is a regression because of an update of plexus? I tried to plexus-utils 1.1 and 1.2 (just replaced the version in the pom of the war plugin) but it works with neither version. If you could give me some pointers where the file ought to be included, I can try to debug this if you can't reproduce it. Option containerConfigXML doesn't work -- Key: MWAR-120 URL: http://jira.codehaus.org/browse/MWAR-120 Project: Maven 2.x War Plugin Issue Type: Bug Reporter: Aaron Digulla Attachments: context-bug.zip The file specified with containerConfigXML is copied to the exploded WAR directory but it will not end up in the final WAR. -- 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: (MWAR-119) Update plexus-utils to 1.2
[ http://jira.codehaus.org/browse/MWAR-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108363 ] Aaron Digulla commented on MWAR-119: If you use the plugin with maven 2.0.6+, it will throw funny error messages if plexus-utils is out of date, so I can't see how you can avoid this (except maybe by patching plexus to work with all versions of maven 2.0.x). Update plexus-utils to 1.2 -- Key: MWAR-119 URL: http://jira.codehaus.org/browse/MWAR-119 Project: Maven 2.x War Plugin Issue Type: Improvement Affects Versions: 2.0.2 Reporter: Aaron Digulla Assignee: Stephane Nicoll Please update plexus-utils to 1.2 (see [http://jira.codehaus.org/browse/MRESOURCES-10]). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-327) Improve documentation for options
Improve documentation for options
-
Key: MECLIPSE-327
URL: http://jira.codehaus.org/browse/MECLIPSE-327
Project: Maven 2.x Eclipse Plugin
Issue Type: Improvement
Affects Versions: 2.4
Reporter: Aaron Digulla
Priority: Minor
The option skip on [this
page|http://maven.apache.org/plugins/maven-eclipse-plugin/eclipse-mojo.html]
should be eclipse.skip (-Dskip has no effect).
In the explanation of downloadSources, you should mention where this file can
be found:
{quote}
... delete the file codemvn-eclipse-cache.properties/code in the target
directory in order to reset this cache.
{quote}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-328) Options in the user settings.xml influence the tests
Options in the user settings.xml influence the tests Key: MECLIPSE-328 URL: http://jira.codehaus.org/browse/MECLIPSE-328 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Reporter: Aaron Digulla I set outputDirectory to bin in my settings.xml which breaks the tests. As a workaround, I suggest to copy the file, strip all plugin options from it, write it to a temporary place and use that in the tests. This way, proxy settings will still 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
[jira] Created: (MECLIPSE-329) Skip should just skip the writing of project files
Skip should just skip the writing of project files -- Key: MECLIPSE-329 URL: http://jira.codehaus.org/browse/MECLIPSE-329 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Affects Versions: 2.4 Reporter: Aaron Digulla Attachments: meclipse-skip.patch Here is a small patch to modify the eclipse.skip option. Instead of completely disabling the plugin, it will just skip the writing of the updated project files. This way, you still have a simple way to download source artifacts without messing with your .classpath/.project files. -- 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: (MWAR-119) Update plexus-utils to 1.2
Update plexus-utils to 1.2 -- Key: MWAR-119 URL: http://jira.codehaus.org/browse/MWAR-119 Project: Maven 2.x War Plugin Issue Type: Improvement Affects Versions: 2.0.2 Reporter: Aaron Digulla Please update plexus-utils to 1.2 (see [http://jira.codehaus.org/browse/MRESOURCES-10]). -- 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: (MWAR-119) Update plexus-utils to 1.2
[ http://jira.codehaus.org/browse/MWAR-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108225 ] Aaron Digulla commented on MWAR-119: Note that I've patched the pom in my local repository to use plexus-utils 1.2 and I had no problems, so far. Update plexus-utils to 1.2 -- Key: MWAR-119 URL: http://jira.codehaus.org/browse/MWAR-119 Project: Maven 2.x War Plugin Issue Type: Improvement Affects Versions: 2.0.2 Reporter: Aaron Digulla Please update plexus-utils to 1.2 (see [http://jira.codehaus.org/browse/MRESOURCES-10]). -- 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: (MWAR-120) Option containerConfigXML doesn't work
Option containerConfigXML doesn't work -- Key: MWAR-120 URL: http://jira.codehaus.org/browse/MWAR-120 Project: Maven 2.x War Plugin Issue Type: Bug Reporter: Aaron Digulla Attachments: context-bug.zip The file specified with containerConfigXML is copied to the exploded WAR directory but it will not end up in the final WAR. -- 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: (MWAR-120) Option containerConfigXML doesn't work
[
http://jira.codehaus.org/browse/MWAR-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108226
]
Aaron Digulla commented on MWAR-120:
The affected version is 2.0.2.
What puzzles me is the log output of maven:
{code}
mvn war:war -X
...
[DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-war-plugin:2.0.2:war' -
-
[DEBUG] (f) archiveClasses = false
[DEBUG] (s) classesDirectory = D:\workspace-3.3\context-bug\target\classes
[DEBUG] (s) containerConfigXML = D:\workspace-3.3\context-bug\src\main\webapp\
META-INF\context.xml
[DEBUG] (f) filters = []
[DEBUG] (f) outputDirectory = D:\workspace-3.3\context-bug\target
[DEBUG] (f) primaryArtifact = true
[DEBUG] (s) project = [EMAIL PROTECTED]
[DEBUG] (f) warName = dummy
[DEBUG] (s) warSourceDirectory = D:\workspace-3.3\context-bug\src\main\webapp
[DEBUG] (f) warSourceExcludes = WEB-INF/platform/configuration/org.eclipse.osg
i/**,WEB-INF/platform/configuration/org.eclipse.core.runtime/**,WEB-INF/platform
/configuration/org.eclipse.update/**
[DEBUG] (s) directory = D:\workspace-3.3\context-bug/src/main/webapp
[DEBUG] (s) filtering = true
[DEBUG] (s) includes = [*.html, **/*.xml]
[DEBUG] (s) excludes = [**/alreportbuild.xml, **/tevbuild.xml, **/web.xml, **/
*.jsp, **/org.eclipse.update/**]
[DEBUG] (f) webResources = [Lorg.apache.maven.model.Resource;@cf66b
[DEBUG] (s) webappDirectory = D:\workspace-3.3\context-bug\target\context-bug-
0.0.1
[DEBUG] (f) workDirectory = D:\workspace-3.3\context-bug\target\war\work
[DEBUG] -- end configuration --
[INFO] [war:war]
[INFO] Exploding webapp...
[INFO] Assembling webapp context-bug in D:\workspace-3.3\context-bug\target\cont
ext-bug-0.0.1
[INFO] Copy webapp webResources to D:\workspace-3.3\context-bug\target\context-b
ug-0.0.1
[INFO] Copy webapp webResources to D:\workspace-3.3\context-bug\target\context-b
ug-0.0.1
[INFO] Generating war D:\workspace-3.3\context-bug\target\dummy.war
[INFO] Building war: D:\workspace-3.3\context-bug\target\dummy.war
[DEBUG] adding directory META-INF/
[DEBUG] adding entry META-INF/MANIFEST.MF
[DEBUG] adding directory WEB-INF/
[DEBUG] adding entry WEB-INF/web.xml
[DEBUG] adding directory META-INF/maven/
[DEBUG] adding directory META-INF/maven/context-bug/
[DEBUG] adding directory META-INF/maven/context-bug/context-bug/
[DEBUG] adding entry META-INF/maven/context-bug/context-bug/pom.xml
[DEBUG] adding entry META-INF/maven/context-bug/context-bug/pom.properties
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
{code}
Obviously, the option is recognized, the file is also copied into
target/context-bug-0.0.1/META-INF/ but it's ignored when the WAR is built.
Option containerConfigXML doesn't work
--
Key: MWAR-120
URL: http://jira.codehaus.org/browse/MWAR-120
Project: Maven 2.x War Plugin
Issue Type: Bug
Reporter: Aaron Digulla
Attachments: context-bug.zip
The file specified with containerConfigXML is copied to the exploded WAR
directory but it will not end up in the final WAR.
--
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-671) implement a license clickthrough
[ http://jira.codehaus.org/browse/MNG-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_98285 ] Aaron Digulla commented on MNG-671: --- Well, for the Sun stuff (JavaMail, Activation, etc), it would be very interesting to have a way to display a license and accept it. The Sun website gets more confusing to read/navigate every day. implement a license clickthrough Key: MNG-671 URL: http://jira.codehaus.org/browse/MNG-671 Project: Maven 2 Issue Type: New Feature Reporter: Brett Porter Fix For: 2.1.x Attachments: maven-artifact-manager-patch-2.txt, maven-artifact-manager-patch.txt, maven-artifact-patch-2.txt, maven-license-patches-3.zip, maven-settings-patch-2.txt, maven-settings-patch.txt we need some basic license acceptance policy for downloadable artifacts. For now, this can just be a Y/N that is saved forever. -- 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-2806) Provide a means of replacing one mojo binding with another, without knowing the location of the first binding in the lifecycle
[ http://jira.codehaus.org/browse/MNG-2806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_93279 ] Aaron Digulla commented on MNG-2806: In the AROS project, we have implemented such a system and it works pretty well. See my comment on http://docs.codehaus.org/display/MAVEN/Lifecycle+and+Plugin+Handling for more details. Provide a means of replacing one mojo binding with another, without knowing the location of the first binding in the lifecycle -- Key: MNG-2806 URL: http://jira.codehaus.org/browse/MNG-2806 Project: Maven 2 Issue Type: New Feature Components: POM Affects Versions: 2.0.4 Reporter: John Casey Fix For: 2.1-alpha-1 Lifecycle phase-bindings that are inherited from parent POMs or packaging-mappings are invisible to the user, without sometimes extensive research into the POM lineage and/or the extension artifact source that brings in the packaging-mapping. For end users in a large development environment, it should be possible to replace an inherited mojo binding with one specified in the local POM, without needing to know what phase that binding is attached to. It is possible to see the full mojo ID and execution ID for a replacement target in the debug output of a build, but phase transitions are not logged...which makes researching the phase-location of a mojo binding quite difficult. Replacement should be available at either the execution level, or the mojo level within a specified execution. If replacing a mojo in the lifecycle mapping given by the project's packaging, the executionId for the replacement should be 'default'. This feature should be accompanied by a new mojo in the help plugin which can print out the effective build steps in that project's lifecycle, to help with debugging replacements, etc. -- 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: (MWAR-99) context.xml is not copied into war anymore
context.xml is not copied into war anymore
--
Key: MWAR-99
URL: http://jira.codehaus.org/browse/MWAR-99
Project: Maven 2.x War Plugin
Issue Type: Bug
Affects Versions: 2.0.2
Reporter: Aaron Digulla
When I add this line to the config:
{code}
containerConfigXML${basedir}/webapp/META-INF/context.xml/containerConfigXML
{code}
I can see that the plugin takes the parameter into account:
{code}
[DEBUG] (s) containerConfigXML =
D:\workspace\GktGwt\webapp\META-INF\context.xml
{code}
but the resulting war file doesn't contain a context.xml file in META-INF/. I
also don't see adding entry in the debug output so my guess is that
something removes this entry.
I also cannot add this entry via dependentWarIncludes or webResources which
suggests that there is an invisible filter which just trows all these items
away.
--
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-2722) Create a strategy for providing sane default values in the MavenExecutionRequest
[
http://jira.codehaus.org/browse/MNG-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_87920
]
Aaron Digulla commented on MNG-2722:
This seems to be fixed with the latest embedder sources (2.1.0.20070213-1647)
Create a strategy for providing sane default values in the
MavenExecutionRequest
Key: MNG-2722
URL: http://jira.codehaus.org/browse/MNG-2722
Project: Maven 2
Issue Type: Task
Components: Embedding
Reporter: Jason van Zyl
Attachments: embedder-start-twice.patch
Ideally an Embedder user should be able to do something like:
MavenEmbedder embedder = new MavenEmbedder();
MavenExecutionRequestion request = new DefaultMavenExecutionRequestion()
.setBasedir( directory )
.setGoals( Arrays.asList( new String[]{ package } ) );
embedder.execute( request );
And this should 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
[jira] Commented: (MNG-2722) Create a strategy for providing sane default values in the MavenExecutionRequest
[
http://jira.codehaus.org/browse/MNG-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_87921
]
Aaron Digulla commented on MNG-2722:
Sorry, wrong issue. The path to the local repository is still not used when it
is defined in the global settings. But a lot of other ClassWorld issues have
been resolved with the latest embedder version.
Create a strategy for providing sane default values in the
MavenExecutionRequest
Key: MNG-2722
URL: http://jira.codehaus.org/browse/MNG-2722
Project: Maven 2
Issue Type: Task
Components: Embedding
Reporter: Jason van Zyl
Attachments: embedder-start-twice.patch
Ideally an Embedder user should be able to do something like:
MavenEmbedder embedder = new MavenEmbedder();
MavenExecutionRequestion request = new DefaultMavenExecutionRequestion()
.setBasedir( directory )
.setGoals( Arrays.asList( new String[]{ package } ) );
embedder.execute( request );
And this should 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
[jira] Commented: (MNG-2722) Create a strategy for providing sane default values in the MavenExecutionRequest
[
http://jira.codehaus.org/browse/MNG-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_86050
]
Aaron Digulla commented on MNG-2722:
I've added a hack with the defaulsPopulator() to make localRepository work in
MavenEmbedder:
request = defaultsPopulator.populateDefaults( request );
+ request.setLocalRepository(getLocalRepository());
+ request.setLocalRepositoryPath(getLocalRepository().getBasedir());
This doesn't fix the NPE, though. After some more debugging, I've found this in
the output after starting the embedder a second time:
[org.apache.maven:maven-plugin-tools-api:jar:2.0:runtime]
[ maven embedder DEBUG] Realm already exists for:
org.apache.maven.plugins:maven-help-plugin. Skipping addition...
I guess this means that the embedder still has same garbage left from the last
run so it won't load the plugin again even though it's now a different plugin
(or, as in the test, the same plugin but from a different localRepository).
I see two solutions: Clean up the class realms when the embedder is started a
second time (does that clear up static final variables?) or forbid to start it
twice (as my patch does).
Just to prove my point, I've added a hack to start(MavenEmbedRequest):
classWorld = new ClassWorld( plexus.core, classLoader );
With this code, it's possible to start the embedder twice but then, you either
have to remove the constructors which pass in a ClassWorld or you must patch
ClassWorld to support some kind of reset() method to clean up an existing
realm.
Create a strategy for providing sane default values in the
MavenExecutionRequest
Key: MNG-2722
URL: http://jira.codehaus.org/browse/MNG-2722
Project: Maven 2
Issue Type: Task
Components: Embedding
Reporter: Jason van Zyl
Attachments: embedder-start-twice.patch
Ideally an Embedder user should be able to do something like:
MavenEmbedder embedder = new MavenEmbedder();
MavenExecutionRequestion request = new DefaultMavenExecutionRequestion()
.setBasedir( directory )
.setGoals( Arrays.asList( new String[]{ package } ) );
embedder.execute( request );
And this should 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
[jira] Updated: (MNG-2722) Create a strategy for providing sane default values in the MavenExecutionRequest
[
http://jira.codehaus.org/browse/MNG-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Digulla updated MNG-2722:
---
Attachment: embedder-start-twice.patch
This fix causes all kinds of problems in various Maven plugins if you have to
change the settings, for example, by calling start() a second time with a
different settings.xml file (setUserSettingsFile() and setGlobalSettingsFile())
because some parts of Maven don't copy the new values.
In the attached test case, you'll find a couple of bugs:
- The embedder crashes horribly if you change the localRepository path to an
empty directory (see stacktrace in the test case).
- The path to the repository is correct in the embedder but not in the
execution request if the second settings file specifies localRepository
My guess is that this causes all kinds of strange bugs and behaviors in the
plugins which are then loaded.
Create a strategy for providing sane default values in the
MavenExecutionRequest
Key: MNG-2722
URL: http://jira.codehaus.org/browse/MNG-2722
Project: Maven 2
Issue Type: Task
Components: Embedding
Reporter: Jason van Zyl
Attachments: embedder-start-twice.patch
Ideally an Embedder user should be able to do something like:
MavenEmbedder embedder = new MavenEmbedder();
MavenExecutionRequestion request = new DefaultMavenExecutionRequestion()
.setBasedir( directory )
.setGoals( Arrays.asList( new String[]{ package } ) );
embedder.execute( request );
And this should 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
[jira] Commented: (MNG-2722) Create a strategy for providing sane default values in the MavenExecutionRequest
[
http://jira.codehaus.org/browse/MNG-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85989
]
Aaron Digulla commented on MNG-2722:
After some more tests, my patch doesn't seem the fix the localRepository
problem.
localRepository is only read when it is specified in ~/.m2/settings.xml. If it
is specified in the file specified with setGlobalSettingsFile(), it's ignored.
It also doesn't fix the issue MNGECLIPSE-231 as I had hoped :-(
All I can say is that defaultsPopulator doesn't fill in the correct local
repository when it is called in MavenEmbedder.
Create a strategy for providing sane default values in the
MavenExecutionRequest
Key: MNG-2722
URL: http://jira.codehaus.org/browse/MNG-2722
Project: Maven 2
Issue Type: Task
Components: Embedding
Reporter: Jason van Zyl
Attachments: embedder-start-twice.patch
Ideally an Embedder user should be able to do something like:
MavenEmbedder embedder = new MavenEmbedder();
MavenExecutionRequestion request = new DefaultMavenExecutionRequestion()
.setBasedir( directory )
.setGoals( Arrays.asList( new String[]{ package } ) );
embedder.execute( request );
And this should 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
[jira] Commented: (MRM-244) Mirror/Proxy functionality is broken in Archiva
[ http://jira.codehaus.org/browse/MRM-244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_85682 ] Aaron Digulla commented on MRM-244: --- I have now implemented a proxy which allows to mirror arbitrary maven repositories and which can inject patches in the download process transparently. The project page is at http://www.pdark.de/dsmp/ The source is only a few hundred lines. I'm not sure if it would make sense to merge this with Archiva, though (see http://www.pdark.de/dsmp/faq.html). Mirror/Proxy functionality is broken in Archiva --- Key: MRM-244 URL: http://jira.codehaus.org/browse/MRM-244 Project: Archiva Issue Type: Bug Components: remote proxy Reporter: Aaron Digulla Priority: Critical Fix For: 1.0 Currently, the archiva admin has to specify which sites Archiva should proxy/mirror and in which managed repository the downloaded artefacts should end up. This approach has several drawbacks: - Resources with a similar name but from different sites can end up in the same managed repository. This is deadly if there is a bug in the resource which is fixed on site A but archiva downloads it from B. Since the resource exists, Archiva will not download it again even after the problem is fixed and the maven mirrors re-synchronized. - Since every POM can define their own repositories, it's very hard to maintain the list of proxied repositories. The situation gets worse when you download a new plugin which in turn wants artefacts from other sites which are not yet in the list. Maven will not use Archiva for these which means every developer downloads those resources. This also means I have to configure maven to be able to access the internet directly while I would prefer to be able to force it to make all connections via archiva. This way, I can fix all broken POMs inhouse, for example. - In maven's settings, I have to specify which mirrors exist. The key for the decision is the ID of the repository. Unfortunately, the ID is just an arbitrary string. Many projects use different IDs for the same repository. Some use codehaus.org, some use codehaus. I've seen POMs which think codehaus.org is for snapshots while they use codehaus for the releases. In the end, there is no way to map repository IDs to mirrors which will work for all maven projects out there. Therefore, I suggest that you change the handling of proxied repositories. Instead of using mirror settings, I would prefer to use the proxy settings of maven to integrate Archiva. Archiva should keep a blacklist of repositories which are to be ignored but everything else should be downloaded into a mirror directory which contains the hostnames of the sites as first level. This means artefacts from http://people.apache.org/maven-snapshot-repository/; would end up in C:\archiva\mirror\people.apache.org\maven-snapshot-repository\... If the port number is != 80, you can add another level for the port. This should allow us to force maven to download everything through Archiva. We would be able to control which plugins and which versions are used and we could fix broken POMs. We could even put patched versions of plugins into the mirror directory. -- 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: (MSOURCES-11) When source plugin is used, it should make sure it is invoked during install
[ http://jira.codehaus.org/browse/MSOURCES-11?page=comments#action_84963 ] Aaron Digulla commented on MSOURCES-11: --- Have you tried this using a parent POM? Ie. move this code to the parent pom and then try to build the child project. You won't get a source JAR. Also, it would be great if the source plugin would attach itself to the package phase automatically because when I use, why would I want it to run at any other time? The default should be what most users want. When source plugin is used, it should make sure it is invoked during install Key: MSOURCES-11 URL: http://jira.codehaus.org/browse/MSOURCES-11 Project: Maven 2.x Sources Plugin Issue Type: Improvement Reporter: Aaron Digulla Assigned To: Jason van Zyl Fix For: 2.0.3 I have a really hard time to make the source plugin work. When I just run mvn install, the source plugin is ignored. I tried to use executions (http://garbuz.com/sm/content.php/articles/maven2_deploying_sources/) but that also doesn't work reliably. The only stable way I found so far is: mvn source:jar install but that's tedious. Isn't it possible to configure the plugin by default in such a way that, when it is used in the POM, it will be invoked automatically during mvn install, mvn deploy, etc? -- 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: (MWAR-64) resource processing does not occur correct hierarchical modules.
[ http://jira.codehaus.org/browse/MWAR-64?page=comments#action_84739 ]
Aaron Digulla commented on MWAR-64:
---
The solution is to set director to ${basedir}/src/main/webapp
This bug can be closed.
resource processing does not occur correct hierarchical modules.
Key: MWAR-64
URL: http://jira.codehaus.org/browse/MWAR-64
Project: Maven 2.x War Plugin
Issue Type: Bug
Affects Versions: 2.0.1
Environment: Windows XP
Reporter: Brian Keyser
I have a project that is similar to
+ - ProjectA
|
- pom.xml
|
+ ProjectB
|
- pom.xml
Within the pom.xml for ProjectB there is an entry describing additional
resources to include in the war
...
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
configuration
webResources
resource
directorysrc/main/resources/directory
filteringtrue/filtering
/resource
/webResources
/configuration
/plugin
...
When running 'mvn install' from the project A directory, I get the following
error
...
[INFO] Copy webapp webResources to
C:\thinktank\thinktank-d1.1.0\server\server-webapp\target\server-webapp-1.1.0-SNAPSHOT
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] basedir src\main\resources does not exist
[INFO]
[DEBUG] Trace
java.lang.IllegalStateException: basedir src\main\resources does not exist
at
org.codehaus.plexus.util.DirectoryScanner.scan(DirectoryScanner.java:542)
at
org.apache.maven.plugin.war.AbstractWarMojo.getWarFiles(AbstractWarMojo.java:810)
at
org.apache.maven.plugin.war.AbstractWarMojo.copyResources(AbstractWarMojo.java:437)
at
org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:355)
at
org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:161)
at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:127)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
However, if I change the directory to
...
directoryprojectb/src/main/resources/directory
...
The install goal works fine.
If I run 'mvn install' from projectb with the first configuration it does
perform an install, ie, when the directory is configured as
'src/main/resources'. Seems like there is a problem in reading the base
directory for hierarchical projects.
Thanks for taking a look at this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-134) target/classes not acceptable for eclipse
[ http://jira.codehaus.org/browse/MECLIPSE-134?page=comments#action_84475 ]
Aaron Digulla commented on MECLIPSE-134:
you can already use the outputDir parameter
I tried that and it didn't work. Can you please post an example?
Also, in the code, you write:
212 /**
213 * The default output directory
214 *
215 * @parameter expression=${outputDirectory} alias=outputDirectory
default-value=${project.build.outputDirectory}
216 * @required
217 */
218 private File buildOutputDirectory;
That means I have to define a property outputDirectory instead of
buildOutputDirectory, right?
I'd suggest to use eclipse.outputDirectory instead because outputDirectory is
easily confused with the Maven config element.
target/classes not acceptable for eclipse
-
Key: MECLIPSE-134
URL: http://jira.codehaus.org/browse/MECLIPSE-134
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Affects Versions: 2.0, 2.1, 2.2
Reporter: Jörg Hohwiller
Assigned To: fabrizio giustina
Priority: Minor
mvn eclipse:eclipse causes an eclipse configuration where the classfiles
generated by eclipse go to the same directory as the classes generated by
maven. This is extremly evil! Eclipse and maven are independent tools and
should therefore not compile to the same target folder causing side effects.
Especially when mvn clean is called and you re-run an existing application
inside eclipse, and get a NoClassDefFoundError you can get slightly confused.
Please use anything else than target/ My suggestion would be
.eclipse-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] Created: (MNG-2711) Maven cannot share properties with other tools (e.g. ant)
Maven cannot share properties with other tools (e.g. ant) - Key: MNG-2711 URL: http://jira.codehaus.org/browse/MNG-2711 Project: Maven 2 Issue Type: Improvement Components: POM, Profiles, Settings Affects Versions: 2.0.4 Reporter: Aaron Digulla I have a project which is built with Ant *and* Maven. It installs/deploys a set of third party JARs to our inhouse repository. Basically, I'm using Ant to invoke Maven several times to install each JAR. In Ant, I can export the properties to a file but maven can't do this. Therefore, I have to define all properties at least twice. I suggest to add a new element propertyFiles to the POM, Profiles and settings.xml where you can specify a list of files to be read. If a property is defined twice, the latest definition should win (unlike Ant), so you can control the properties using profiles. -- 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: (MNGECLIPSE-217) M2Eclipse plugin ignores compiler settings in project
M2Eclipse plugin ignores compiler settings in project - Key: MNGECLIPSE-217 URL: http://jira.codehaus.org/browse/MNGECLIPSE-217 Project: Maven 2.x Extension for Eclipse Issue Type: Improvement Components: Maven Launcher Affects Versions: 0.0.10 Reporter: Aaron Digulla I got this error in the console after starting Eclipse: 11.12.06 09:31:52 CET: [INFO] Error for project: * (during generate-test-resources) 11.12.06 09:31:52 CET: [INFO] 11.12.06 09:31:52 CET: [INFO] Compilation failure Unable to locate the Javac Compiler in: C:\Programme\Java\jre1.5.0_09\..\lib\tools.jar Please ensure you are using JDK 1.4 or above and not a JRE (the com.sun.tools.javac.Main class is required). In most cases you can change the location of your Java installation by setting the JAVA_HOME environment variable. I could create a skript to start Eclipse which sets JAVA_HOME but I don't want to do that. I have several different Java versions for testing on my machine and I need a clean environment. It would be nice if I could select the Java runtime to use in the M2Eclipse prefs pages. -- 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-2690) DefaultPluginManager.getConfiguredMojo() doesn't handle NoClassDefFoundError correctly
DefaultPluginManager.getConfiguredMojo() doesn't handle NoClassDefFoundError
correctly
--
Key: MNG-2690
URL: http://jira.codehaus.org/browse/MNG-2690
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0.4
Reporter: Aaron Digulla
If maven tries to download a file which doesn't exist and it believes there is
no other place where it can get the file, you can have the situation that Maven
tries to invoke a Plugin without a complete classpath. In the log, you'll see
something like this:
Downloading:
http://repository.codehaus.org/org/codehaus/mojo/dependency-maven-plugin/1.0/dependency-maven-plugin-1.0.pom
Downloading:
http://repo1.maven.org/maven2/org/codehaus/mojo/dependency-maven-plugin/1.0/dependency-maven-plugin-1.0.jar
15K downloaded
As you can see, Maven tries to download the POM from a different site than the
JAR. Now, the classpath of the JAR is incomplete because the POM is missing.
Things get really nasty when Maven tries to access the plugin. You'll get:
java.lang.NoClassDefFoundError:
Lorg/codehaus/plexus/archiver/manager/ArchiverManager;
which tells you exactly nothing since you have no idea who wants that class.
The cause of the problem is that PlexusContainer doesn't catch errors (well,
Java says you shouldn't but the user would really like to see what's going on).
My fix was to duplicate the catch in DefaultPluginManager.getConfiguredMojo()
(around line 530):
catch ( NoClassDefFoundError e )
{
throw new PluginManagerException( Unable to find the mojo ' +
mojoDescriptor.getRoleHint() +
' in the plugin ' + pluginDescriptor.getPluginLookupKey() +
' because of NoClassDefFoundError:, e );
}
This way, I get at least an idea which plugin is causing the problem.
But I guess the container should be fixed to catch these errors.
--
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-2691) DefaultPluginManager.addPlugin() doesn't tell which plugin is broken
DefaultPluginManager.addPlugin() doesn't tell which plugin is broken Key: MNG-2691 URL: http://jira.codehaus.org/browse/MNG-2691 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.5 Reporter: Aaron Digulla In DefaultPluginManager.addPlugin() is code like this: throw new IllegalStateException( The PluginDescriptor for the plugin + plugin + was not found. ); Unfortunately, plugin has no toString(), so you just see the Java classname and the object id. Replace all three places with plugin.getKey() or, even better, add a new method to Plugin which also includes the version string if there is one. Also the error message of the IllegalStateException should be: The PluginDescriptor for the plugin + plugin.getKey() + was not found. Are you sure this is a Maven plugin and not a normal 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
[jira] Created: (MRM-244) Mirror/Proxy functionality is broken in Archiva
Mirror/Proxy functionality is broken in Archiva --- Key: MRM-244 URL: http://jira.codehaus.org/browse/MRM-244 Project: Archiva Issue Type: Bug Components: remote proxy Reporter: Aaron Digulla Priority: Critical Currently, the archiva admin has to specify which sites Archiva should proxy/mirror and in which managed repository the downloaded artefacts should end up. This approach has several drawbacks: - Resources with a similar name but from different sites can end up in the same managed repository. This is deadly if there is a bug in the resource which is fixed on site A but archiva downloads it from B. Since the resource exists, Archiva will not download it again even after the problem is fixed and the maven mirrors re-synchronized. - Since every POM can define their own repositories, it's very hard to maintain the list of proxied repositories. The situation gets worse when you download a new plugin which in turn wants artefacts from other sites which are not yet in the list. Maven will not use Archiva for these which means every developer downloads those resources. This also means I have to configure maven to be able to access the internet directly while I would prefer to be able to force it to make all connections via archiva. This way, I can fix all broken POMs inhouse, for example. - In maven's settings, I have to specify which mirrors exist. The key for the decision is the ID of the repository. Unfortunately, the ID is just an arbitrary string. Many projects use different IDs for the same repository. Some use codehaus.org, some use codehaus. I've seen POMs which think codehaus.org is for snapshots while they use codehaus for the releases. In the end, there is no way to map repository IDs to mirrors which will work for all maven projects out there. Therefore, I suggest that you change the handling of proxied repositories. Instead of using mirror settings, I would prefer to use the proxy settings of maven to integrate Archiva. Archiva should keep a blacklist of repositories which are to be ignored but everything else should be downloaded into a mirror directory which contains the hostnames of the sites as first level. This means artefacts from http://people.apache.org/maven-snapshot-repository/; would end up in C:\archiva\mirror\people.apache.org\maven-snapshot-repository\... If the port number is != 80, you can add another level for the port. This should allow us to force maven to download everything through Archiva. We would be able to control which plugins and which versions are used and we could fix broken POMs. We could even put patched versions of plugins into the mirror directory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-17) Link to source repository broken
[ http://jira.codehaus.org/browse/MECLIPSE-17?page=comments#action_81480 ] Aaron Digulla commented on MECLIPSE-17: --- The links on http://m2eclipse.codehaus.org/source-repository.html are broken again: http://cvs.codehaus.org/viewrep/m2eclipse/trunk/ should be svn.codehaus.org and the links below all refer to https://m2eclipse.codehaus.org/trunk/ which should be https://svn.codehaus.org/m2eclipse/trunk/ Link to source repository broken Key: MECLIPSE-17 URL: http://jira.codehaus.org/browse/MECLIPSE-17 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Reporter: Jochen Wiedmann Assigned To: fabrizio giustina According to http://maven.apache.org/plugins/maven-eclipse-plugin/source-repository.html the eclipse plugins source can be found at http://svn.apache.org/viewcvs.cgi/maven/components/trunk/maven-plugins/maven-eclipse-plugin or http://svn.apache.org/repos/asf/maven/components/trunk/maven-plugins/maven-eclipse-plugin However, both URL's are obviously broken: There is no directory maven-plugins in components/trunk. -- 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: (MNGECLIPSE-213) Links on Source Repository page are broken
Links on Source Repository page are broken -- Key: MNGECLIPSE-213 URL: http://jira.codehaus.org/browse/MNGECLIPSE-213 Project: Maven 2.x Extension for Eclipse Issue Type: Improvement Reporter: Aaron Digulla The links on http://m2eclipse.codehaus.org/source-repository.html are broken: http://cvs.codehaus.org/viewrep/m2eclipse/trunk/ should be svn.codehaus.org and the links below all refer to https://m2eclipse.codehaus.org/trunk/ which should be https://svn.codehaus.org/m2eclipse/trunk/ -- 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: (MNGECLIPSE-214) Order of resources in classpath is wrong
Order of resources in classpath is wrong Key: MNGECLIPSE-214 URL: http://jira.codehaus.org/browse/MNGECLIPSE-214 Project: Maven 2.x Extension for Eclipse Issue Type: Bug Affects Versions: 0.0.9 Reporter: Aaron Digulla Create a project with src/main/resources and src/test/resources. Put the same resource in both paths (for example, log4j.properties). When you run the tests from maven, the resources from src/test shadow the files from src/main (as it should be). When you run the tests in Eclipse, src/main takes precedence. This is because the order of entries in the .classpath file is wrong. I'm not sure how to solve this. For maven, every project is made up from two modules: A test module and a main module. Depending on what you want to do, either the test module takes precedence or the main module (or rather: in the former case, the test module is injected as the first element in the classpath and in the second case, it's omitted). So when running a project in Eclipse, we're in trouble. If I move src/test to the top of the classpath, starting the real application could become an issue. I guess it's a limitation of Eclipse itself. I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=166321 to see what the Eclipse guys say. -- 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: (MRM-154) DigestUtils fails to verify checksum from ibiblio
[ http://jira.codehaus.org/browse/MRM-154?page=comments#action_81156 ]
Aaron Digulla commented on MRM-154:
---
The supplied patch fails if the filename is - (stdin) like in
http://repo1.maven.org/maven2/org/apache/maven/archetype/maven-archetype/1.0-alpha-4/maven-archetype-1.0-alpha-4.pom.md5:
54210dc92a25325496713d19d5ced2b9 -
DigestUtils fails to verify checksum from ibiblio
-
Key: MRM-154
URL: http://jira.codehaus.org/browse/MRM-154
Project: Archiva
Issue Type: Bug
Reporter: nicolas de loof
Assigned To: Brett Porter
Fix For: 1.0-beta-1
Attachments: DigestUtils.java.patch, MRM-154.patch
Downloading servletapi-24.pom fails.
DigestUtils.cleanChecksum check for filename in remote checksum file to be
same as local, but tets is inverted :
String filename = m.group( 2 );
if ( !path.endsWith( filename ) )
{
throw new DigesterException( Supplied checksum does not
match checksum pattern );
}
filename =
/home/projects/maven/repository-staging/to-ibiblio/maven2/servletapi/servletapi/2.4/servletapi-2.4.pom
path = servletapi-2.4.pom.
Patch provided to test if ( !path.endsWith( filename ) )
--
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: (MSOURCES-11) When source plugin is used, it should make sure it is invoked during install
[ http://jira.codehaus.org/browse/MSOURCES-11?page=comments#action_80754 ] Aaron Digulla commented on MSOURCES-11: --- Note: The executions (see link above) only work if they are in the POM of every module of your project. Just defining this once in the parent pom doesn't work. When source plugin is used, it should make sure it is invoked during install Key: MSOURCES-11 URL: http://jira.codehaus.org/browse/MSOURCES-11 Project: Maven 2.x Sources Plugin Issue Type: Improvement Reporter: Aaron Digulla I have a really hard time to make the source plugin work. When I just run mvn install, the source plugin is ignored. I tried to use executions (http://garbuz.com/sm/content.php/articles/maven2_deploying_sources/) but that also doesn't work reliably. The only stable way I found so far is: mvn source:jar install but that's tedious. Isn't it possible to configure the plugin by default in such a way that, when it is used in the POM, it will be invoked automatically during mvn install, mvn deploy, etc? -- 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: (MPMD-41) Upgrade to PMD 3.8
[ http://jira.codehaus.org/browse/MPMD-41?page=comments#action_79368 ] Aaron Digulla commented on MPMD-41: --- I've patched the PMD plugin locally to use PMD 3.8 (just changed the version number in the pom.xml and rebuilt) and I didn't run in any problems. Upgrade to PMD 3.8 -- Key: MPMD-41 URL: http://jira.codehaus.org/browse/MPMD-41 Project: Maven 2.x Pmd Plugin Issue Type: Task Affects Versions: 2.1 Reporter: Anthony Whitford PMD 3.8 was released October 4, 2006. The Maven plugin should be updated too. http://sourceforge.net/project/shownotes.php?release_id=452776group_id=56262 -- 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: (MSOURCES-11) When source plugin is used, it should make sure it is invoked during install
When source plugin is used, it should make sure it is invoked during install Key: MSOURCES-11 URL: http://jira.codehaus.org/browse/MSOURCES-11 Project: Maven 2.x Sources Plugin Issue Type: Improvement Reporter: Aaron Digulla I have a really hard time to make the source plugin work. When I just run mvn install, the source plugin is ignored. I tried to use executions (http://garbuz.com/sm/content.php/articles/maven2_deploying_sources/) but that also doesn't work reliably. The only stable way I found so far is: mvn source:jar install but that's tedious. Isn't it possible to configure the plugin by default in such a way that, when it is used in the POM, it will be invoked automatically during mvn install, mvn deploy, etc? -- 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: (MSOURCES-11) When source plugin is used, it should make sure it is invoked during install
[ http://jira.codehaus.org/browse/MSOURCES-11?page=comments#action_79401 ] Aaron Digulla commented on MSOURCES-11: --- Oh, I'm using Maven 2.0.4 and the source plugin is 2.0.1. When source plugin is used, it should make sure it is invoked during install Key: MSOURCES-11 URL: http://jira.codehaus.org/browse/MSOURCES-11 Project: Maven 2.x Sources Plugin Issue Type: Improvement Reporter: Aaron Digulla I have a really hard time to make the source plugin work. When I just run mvn install, the source plugin is ignored. I tried to use executions (http://garbuz.com/sm/content.php/articles/maven2_deploying_sources/) but that also doesn't work reliably. The only stable way I found so far is: mvn source:jar install but that's tedious. Isn't it possible to configure the plugin by default in such a way that, when it is used in the POM, it will be invoked automatically during mvn install, mvn deploy, etc? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-174) Plugin doesn't cache source not available status
[ http://jira.codehaus.org/browse/MECLIPSE-174?page=comments#action_78819 ] Aaron Digulla commented on MECLIPSE-174: Can't you reuse the standard maven2 cache? I would prefer if the command line maven and the plugin would agree on what has been tried and what hasn't. Also I don't think the target dir is a good place for this information. What happens when I close a project? Why not put this into the workspace instead? Plugin doesn't cache source not available status -- Key: MECLIPSE-174 URL: http://jira.codehaus.org/browse/MECLIPSE-174 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Affects Versions: 2.2 Reporter: Aaron Digulla Assigned To: fabrizio giustina Priority: Minor Fix For: 2.3 When the m2 plugin reads the POM files and Download sources is set in the Eclipse preferences, it tries to download the source every time. Instead, it should cache the source not available status somewhere (just like Maven itself does) and not print thousands of error messages (Unable to download the artifact from any repository). This also delays the build considerably (opening network connections) and real errors are drowned. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-174) Plugin doesn't cache source not available status
Plugin doesn't cache source not available status -- Key: MECLIPSE-174 URL: http://jira.codehaus.org/browse/MECLIPSE-174 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Aaron Digulla Priority: Minor When the m2 plugin reads the POM files and Download sources is set in the Eclipse preferences, it tries to download the source every time. Instead, it should cache the source not available status somewhere (just like Maven itself does) and not print thousands of error messages (Unable to download the artifact from any repository). This also delays the build considerably (opening network connections) and real errors are drowned. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-175) Error message Unable to index ...pom. Cannot delete workspace\.metadata\.plugins\org.maven.ide.eclipse\index\local\_gf.cfs
Error message Unable to index ...pom. Cannot delete workspace\.metadata\.plugins\org.maven.ide.eclipse\index\local\_gf.cfs Key: MECLIPSE-175 URL: http://jira.codehaus.org/browse/MECLIPSE-175 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Aaron Digulla I saw this during a build. The cause seems to be that the file doesn't exist in the first place. Should be trivial to fix. -- 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: (MPMD-44) Allow to specify the rulesets as described in the docs
[ http://jira.codehaus.org/browse/MPMD-44?page=comments#action_77861 ] Aaron Digulla commented on MPMD-44: --- Note: Maybe the docs are wrong. I'm referring to http://maven.apache.org/plugins/maven-pmd-plugin/examples/usingRuleSets.html Allow to specify the rulesets as described in the docs -- Key: MPMD-44 URL: http://jira.codehaus.org/browse/MPMD-44 Project: Maven 2.x Pmd Plugin Issue Type: Improvement Reporter: Aaron Digulla Adding rulesets doesn't work as described in the docs. Looking at the source, there is no place where the rulesets list is used or defined. -- 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: (MPMD-44) Allow to specify the rulesets as described in the docs
Allow to specify the rulesets as described in the docs -- Key: MPMD-44 URL: http://jira.codehaus.org/browse/MPMD-44 Project: Maven 2.x Pmd Plugin Issue Type: Improvement Reporter: Aaron Digulla Adding rulesets doesn't work as described in the docs. Looking at the source, there is no place where the rulesets list is used or defined. -- 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
