[jira] (MCHANGES-46) There is no link to the RSS feed of changes in the changes report
[ https://jira.codehaus.org/browse/MCHANGES-46?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MCHANGES-46. - Resolution: Fixed Fix Version/s: 2.9 Assignee: Lukas Theussl I have [committed my own patch|http://svn.apache.org/viewvc?view=revision&revision=1423355] after review and slight adaptations. However, I didn't do any extensive testing, so would appreciate any feedback. Use it with a configuration parameter 'feedType' with supported values: "rss_0.9", "rss_0.91N" (RSS 0.91 Netscape), "rss_0.91U" (RSS 0.91 Userland), "rss_0.92", "rss_0.93", "rss_0.94", "rss_1.0", "rss_2.0", "atom_0.3", "atom_1.0" > There is no link to the RSS feed of changes in the changes report > - > > Key: MCHANGES-46 > URL: https://jira.codehaus.org/browse/MCHANGES-46 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: changes.xml >Reporter: Dennis Lundberg >Assignee: Lukas Theussl > Fix For: 2.9 > > Attachments: MCHANGES-46-maven-changes-plugin.patch, MCHANGES-46.patch > > -- 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-5411) Missing file activation only works with hard coded vales
Bill Riemers created MNG-5411:
-
Summary: Missing file activation only works with hard coded vales
Key: MNG-5411
URL: https://jira.codehaus.org/browse/MNG-5411
Project: Maven 2 & 3
Issue Type: Bug
Components: POM
Affects Versions: 3.0.4
Environment: Fedora 17 x86_64, Java 1.7.0_09-icedtea
Reporter: Bill Riemers
Priority: Minor
...
Only works when the file name is hard coded between the missing tags to
activate a profile. If instead the file name is listed as a property (or
properties) the profile is always active.
e.g.
...
example.txt
${project.build.directory}/example.txt
...
${exampleDirectory}/${exampleFile}
...
...
...
The profile here will be active regardless if the wsdlFile exists. However,
if instead one hard codes the value like so:
target/example.txt
then the profile is only active when example.txt does not exist.
I'm guessing this is a chicken and egg problem. The properties section is
probably not evaluated until after deciding what profiles should be active. In
which case, the code itself is working as designed, it is just either that
design needs to be documented or updated to work the way one would expect.
--
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-5411) Missing file activation only works with hard coded vales
[
https://jira.codehaus.org/browse/MNG-5411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315869#comment-315869
]
Bill Riemers commented on MNG-5411:
---
Looks like from MNG-3524 this is actually a known issue. How about changing
the category of this report to documentation, rather than closing it. As it
is clear the restrictions in this activation method are obvious from the
documentation. Once one knows the restrictions it is only a minor issue.
> Missing file activation only works with hard coded vales
>
>
> Key: MNG-5411
> URL: https://jira.codehaus.org/browse/MNG-5411
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.0.4
> Environment: Fedora 17 x86_64, Java 1.7.0_09-icedtea
>Reporter: Bill Riemers
>Priority: Minor
>
> ...
> Only works when the file name is hard coded between the missing tags to
> activate a profile. If instead the file name is listed as a property (or
> properties) the profile is always active.
> e.g.
> ...
>
> example.txt
> ${project.build.directory}/example.txt
>
> ...
>
>
>
> ${exampleDirectory}/${exampleFile}
>
> ...
>
> ...
>
> ...
> The profile here will be active regardless if the wsdlFile exists. However,
> if instead one hard codes the value like so:
> target/example.txt
> then the profile is only active when example.txt does not exist.
> I'm guessing this is a chicken and egg problem. The properties section is
> probably not evaluated until after deciding what profiles should be active.
> In which case, the code itself is working as designed, it is just either that
> design needs to be documented or updated to work the way one would expect.
--
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-2363) does not work in a multi-project build
[
https://jira.codehaus.org/browse/MNG-2363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315870#comment-315870
]
Bill Riemers commented on MNG-2363:
---
While this bug has been fixed, most of the bugs that are marked as duplicates
of this bug have not been... As the only thing that has been fixed is the
usage of ${basedir}. Other properties still have problems, and the
documentation still does not list this limitation.
> does not work in a multi-project build
> ---
>
> Key: MNG-2363
> URL: https://jira.codehaus.org/browse/MNG-2363
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Profiles
>Reporter: David Boden
>Assignee: Benjamin Bentmann
>Priority: Critical
> Fix For: 3.0-alpha-3
>
> Attachments: DefaultMavenProjectBuilder.java,
> DefaultMavenProjectBuilder.java, DefaultMavenProjectBuilder.java.diff,
> problemactivation.zip, screenshot-1.jpg
>
>
> I would expect each subproject to have the profile turned on or off depending
> on whether ${basedir}/file-to-check-for exists.
> Instead, during a multi-project build the profile is either on or off
> depending on whether the file exists relative to the *aggregator pom*. The
> decision is made once.
> Variable substitution doesn't work, so I can't explicitly use
> ${basedir}/file-to-check-for or any variation on this theme
> to workaround the bug.
> Some background to my particular problem. I have 10 modules to build. Some of
> them are GUI modules and contain a file called plugin.xml in the subproject
> directory. I want to package these up specially and sign them, ready for
> deployment to webstart. The other modules are shared and server code and I
> don't want these packaged in the same way. So, I've got a dependency in my
> *parent* pom file which activates a profile called "guibundle" if a
> plugin.xml file exists in the subproject directory.
--
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] (SUREFIRE-938) out of memory when logging more messages than heap size
[ https://jira.codehaus.org/browse/SUREFIRE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315872#comment-315872 ] Kristian Rosenvold commented on SUREFIRE-938: - This problem has several facets to it; one is that we actually keep stdout/stderr from the process in memory on the plugin side. So technically increasing maven memory through MAVEN_OPTS should get you some way along the line (i.e. export MAVEN_OPTS=-Xmx1024m) The reason "must" keep the output in memory is because we use Xpp3Dom to write the XML reports, which basically keeps it all in memory. So for this issue to be "truly" fixed we'd need to stream the content directly to disk for the xml reports. A second solution could be to simply not buffer in-memory if we don't write xml, which would remove the need for the buffered content. But on the other hand, the stack-trace in question shows that we actually keep the entire output in memory twice, so we can most certainly improve on this situation by only storing it once ;) > out of memory when logging more messages than heap size > --- > > Key: SUREFIRE-938 > URL: https://jira.codehaus.org/browse/SUREFIRE-938 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.12.4 >Reporter: Andrew Gaul > > Observed OOM when logging more messages than heap size: > Exception in thread "ThreadedStreamConsumer" java.lang.OutOfMemoryError: Java > heap space > at java.util.Arrays.copyOfRange(Arrays.java:3209) > at java.lang.String.(String.java:215) > at java.lang.StringBuilder.toString(StringBuilder.java:430) > at > org.apache.maven.plugin.surefire.report.TestSetRunListener.getAsString(TestSetRunListener.java:225) > at > org.apache.maven.plugin.surefire.report.TestSetRunListener.wrap(TestSetRunListener.java:230) > at > org.apache.maven.plugin.surefire.report.TestSetRunListener.testSucceeded(TestSetRunListener.java:161) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:100) > at > org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) > at java.lang.Thread.run(Thread.java:662) -- 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-5412) Managed transitive dependencies are not always resolved correctly
Ryan Heinen created MNG-5412:
Summary: Managed transitive dependencies are not always resolved
correctly
Key: MNG-5412
URL: https://jira.codehaus.org/browse/MNG-5412
Project: Maven 2 & 3
Issue Type: Bug
Affects Versions: 3.0.4, 3.0.3
Reporter: Ryan Heinen
Attachments: mvn-bug.zip
Specifically, in the following example, I would expect that Project #2 resolves
v1.1 of Y since it has been managed by Project #1, but it actually resolves to
v1.0.
* X depends on Y 1.0
* Project #1 depends on X, sets version of Y to 1.1 via dependencyManagement
* Project #2 depends on Project #1
I've attached an example project that exhibits this bug. The setup is as
follows:
* library declares a dependency on msgpack 0.6.6, which has a transitive
dependency on javassist 3.16.1-GA.
* library manages javassist's version to 3.17.1-GA.
* consumer depends on library
>From the root run
{{mvn clean install -f library/pom.xml}}
{{mvn dependency:tree -f consumer/pom.xml}}
The dependency:tree command will show that javassist version 3.16.1-GA is
resolved for the consumer project.
I've also included the output of dependency:tree for the attached example:
{code}
$ mvn dependency:tree -f library/pom.xml
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building library 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ library ---
[INFO] com.example:library:jar:1.0-SNAPSHOT
[INFO] \- org.msgpack:msgpack:jar:0.6.6:compile
[INFO]+- com.googlecode.json-simple:json-simple:jar:1.1.1:compile
[INFO]| \- junit:junit:jar:4.10:compile
[INFO]| \- org.hamcrest:hamcrest-core:jar:1.1:compile
[INFO]\- org.javassist:javassist:jar:3.17.1-GA:compile (version managed
from 3.16.1-GA)
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1.370s
[INFO] Finished at: Tue Dec 18 11:24:59 PST 2012
[INFO] Final Memory: 5M/81M
[INFO]
{code}
{code}
$ mvn dependency:tree -f consumer/pom.xml
[INFO] Scanning for projects...
[INFO]
[INFO]
[INFO] Building consumer 1.0-SNAPSHOT
[INFO]
[INFO]
[INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ consumer ---
[INFO] com.example:consumer:jar:1.0-SNAPSHOT
[INFO] \- com.example:library:jar:1.0-SNAPSHOT:compile
[INFO]\- org.msgpack:msgpack:jar:0.6.6:compile
[INFO] +- com.googlecode.json-simple:json-simple:jar:1.1.1:compile
[INFO] | \- junit:junit:jar:4.10:compile
[INFO] | \- org.hamcrest:hamcrest-core:jar:1.1:compile
[INFO] \- org.javassist:javassist:jar:3.16.1-GA:compile
[INFO]
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 1.279s
[INFO] Finished at: Tue Dec 18 11:25:26 PST 2012
[INFO] Final Memory: 5M/81M
[INFO]
{code}
--
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-5412) Managed transitive dependencies are not always resolved correctly
[
https://jira.codehaus.org/browse/MNG-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315886#comment-315886
]
Ryan Heinen commented on MNG-5412:
--
Note that if I add an explicit dependency on javassist to the dependencies tag
in library/pom.xml the version resolves correctly in consumer:
{code}
org.javassist
javassist
{code}
> Managed transitive dependencies are not always resolved correctly
> -
>
> Key: MNG-5412
> URL: https://jira.codehaus.org/browse/MNG-5412
> Project: Maven 2 & 3
> Issue Type: Bug
>Affects Versions: 3.0.3, 3.0.4
>Reporter: Ryan Heinen
> Attachments: mvn-bug.zip
>
>
> Specifically, in the following example, I would expect that Project #2
> resolves v1.1 of Y since it has been managed by Project #1, but it actually
> resolves to v1.0.
> * X depends on Y 1.0
> * Project #1 depends on X, sets version of Y to 1.1 via dependencyManagement
> * Project #2 depends on Project #1
> I've attached an example project that exhibits this bug. The setup is as
> follows:
> * library declares a dependency on msgpack 0.6.6, which has a transitive
> dependency on javassist 3.16.1-GA.
> * library manages javassist's version to 3.17.1-GA.
> * consumer depends on library
> From the root run
> {{mvn clean install -f library/pom.xml}}
> {{mvn dependency:tree -f consumer/pom.xml}}
> The dependency:tree command will show that javassist version 3.16.1-GA is
> resolved for the consumer project.
> I've also included the output of dependency:tree for the attached example:
> {code}
> $ mvn dependency:tree -f library/pom.xml
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building library 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ library ---
> [INFO] com.example:library:jar:1.0-SNAPSHOT
> [INFO] \- org.msgpack:msgpack:jar:0.6.6:compile
> [INFO]+- com.googlecode.json-simple:json-simple:jar:1.1.1:compile
> [INFO]| \- junit:junit:jar:4.10:compile
> [INFO]| \- org.hamcrest:hamcrest-core:jar:1.1:compile
> [INFO]\- org.javassist:javassist:jar:3.17.1-GA:compile (version managed
> from 3.16.1-GA)
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.370s
> [INFO] Finished at: Tue Dec 18 11:24:59 PST 2012
> [INFO] Final Memory: 5M/81M
> [INFO]
>
> {code}
> {code}
> $ mvn dependency:tree -f consumer/pom.xml
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
>
> [INFO] Building consumer 1.0-SNAPSHOT
> [INFO]
>
> [INFO]
> [INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ consumer ---
> [INFO] com.example:consumer:jar:1.0-SNAPSHOT
> [INFO] \- com.example:library:jar:1.0-SNAPSHOT:compile
> [INFO]\- org.msgpack:msgpack:jar:0.6.6:compile
> [INFO] +- com.googlecode.json-simple:json-simple:jar:1.1.1:compile
> [INFO] | \- junit:junit:jar:4.10:compile
> [INFO] | \- org.hamcrest:hamcrest-core:jar:1.1:compile
> [INFO] \- org.javassist:javassist:jar:3.16.1-GA:compile
> [INFO]
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 1.279s
> [INFO] Finished at: Tue Dec 18 11:25:26 PST 2012
> [INFO] Final Memory: 5M/81M
> [INFO]
>
> {code}
--
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] (ARCHETYPE-358) Following mirror configuration from settings.xml
[
https://jira.codehaus.org/browse/ARCHETYPE-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315887#comment-315887
]
Chris Feldhacker commented on ARCHETYPE-358:
We're experiencing this problem, too.
We have our own Sonatype Nexus repository setup behind the firewall, which is
defined in the mirrors section of the settings.xml. Standard Maven operations
work fine, no proxy settings needed in the settings.xml file.
When executing {{monospaced}}mvn archetype:generate{{monospaced}}, however, the
error "Connection to http://repo1.maven.org refused" is given. (Similar
symptoms to ARCHETYPE-202, but different cause.) The archetype plugin should
NOT be trying to connect to this URL directly -- instead, it should be using
the mirror we have defined.
> Following mirror configuration from settings.xml
>
>
> Key: ARCHETYPE-358
> URL: https://jira.codehaus.org/browse/ARCHETYPE-358
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator, Plugin
>Affects Versions: 2.1
>Reporter: Grégory Joseph
>
> It looks like the current snapshot of the plugin does not follow the mirror
> configuration from my settings.xml when I do {{mvn archetype:generate}}. I
> would expect it to grab the catalog from
> {{http://nexus.magnolia-cms.com/content/groups/all/archetype-catalog.xml}}
> instead of the central one.
--
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] (ARCHETYPE-358) Following mirror configuration from settings.xml
[
https://jira.codehaus.org/browse/ARCHETYPE-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315887#comment-315887
]
Chris Feldhacker edited comment on ARCHETYPE-358 at 12/18/12 2:16 PM:
--
We're experiencing this problem, too.
We have our own Sonatype Nexus repository setup behind the firewall, which is
defined in the mirrors section of the settings.xml. Standard Maven operations
work fine, no proxy settings needed in the settings.xml file.
When executing {{mvn archetype:generate}}, however, the error "Connection to
http://repo1.maven.org refused" is given. (Similar symptoms to ARCHETYPE-202,
but different cause.) The archetype plugin should NOT be trying to connect to
this URL directly -- instead, it should be using the mirror we have defined.
was (Author: feldhacker):
We're experiencing this problem, too.
We have our own Sonatype Nexus repository setup behind the firewall, which is
defined in the mirrors section of the settings.xml. Standard Maven operations
work fine, no proxy settings needed in the settings.xml file.
When executing {{monospaced}}mvn archetype:generate{{monospaced}}, however, the
error "Connection to http://repo1.maven.org refused" is given. (Similar
symptoms to ARCHETYPE-202, but different cause.) The archetype plugin should
NOT be trying to connect to this URL directly -- instead, it should be using
the mirror we have defined.
> Following mirror configuration from settings.xml
>
>
> Key: ARCHETYPE-358
> URL: https://jira.codehaus.org/browse/ARCHETYPE-358
> Project: Maven Archetype
> Issue Type: Bug
> Components: Generator, Plugin
>Affects Versions: 2.1
>Reporter: Grégory Joseph
>
> It looks like the current snapshot of the plugin does not follow the mirror
> configuration from my settings.xml when I do {{mvn archetype:generate}}. I
> would expect it to grab the catalog from
> {{http://nexus.magnolia-cms.com/content/groups/all/archetype-catalog.xml}}
> instead of the central one.
--
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] (ARCHETYPE-403) Error reading archetype catalog http://repo1.maven.org/maven2 on archetype:generate
[
https://jira.codehaus.org/browse/ARCHETYPE-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315889#comment-315889
]
Chris Feldhacker commented on ARCHETYPE-403:
We're experiencing something similar -- I swear this problem didn't occur a
month or two ago, but I can't point to any changes on our end that would have
caused it.
Issue ARCHETYPE-358 is an earlier report (duplicate?), I posted my comments
there.
I think this issue is closer to what we are seeing as it also just recently
started happening for us...
> Error reading archetype catalog http://repo1.maven.org/maven2 on
> archetype:generate
>
>
> Key: ARCHETYPE-403
> URL: https://jira.codehaus.org/browse/ARCHETYPE-403
> Project: Maven Archetype
> Issue Type: Bug
> Components: Archetypes, Generator
>Affects Versions: 2.1, 2.2
>Reporter: Jens Rapp
>
> hello,
> we use maven behind a cascade of two maven proxies. (only second one is in
> our hands, the other one connects to internet)
> When we call mvn archetype:generate this happens:
> {quote}
> hal# /opt/maven-2.1.0/bin/mvn archetype:generate
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'archetype'.
> [INFO]
>
> [INFO] Building Maven Default Project
> [INFO]task-segment: [archetype:generate] (aggregator-style)
> [INFO]
>
> [INFO] Preparing archetype:generate
> [INFO] No goals needed for project - skipping
> [INFO] [archetype:generate]
> [INFO] Generating project in Interactive mode
> [WARNING] Error reading archetype catalog http://repo1.maven.org/maven2
> org.apache.maven.wagon.TransferFailedException: Error transferring file:
> repo1.maven.org
> at
> org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:143)
> at
> org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116)
> at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88)
> at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61)
> at
> org.apache.maven.archetype.source.RemoteCatalogArchetypeDataSource.downloadCatalog(RemoteCatalogArchetypeDataSource.java:119)
> at
> org.apache.maven.archetype.source.RemoteCatalogArchetypeDataSource.getArchetypeCatalog(RemoteCatalogArchetypeDataSource.java:87)
> at
> org.apache.maven.archetype.DefaultArchetypeManager.getRemoteCatalog(DefaultArchetypeManager.java:216)
> at
> org.apache.maven.archetype.DefaultArchetypeManager.getRemoteCatalog(DefaultArchetypeManager.java:205)
> at
> org.apache.maven.archetype.ui.generation.DefaultArchetypeSelector.getArchetypesByCatalog(DefaultArchetypeSelector.java:200)
> at
> org.apache.maven.archetype.ui.generation.DefaultArchetypeSelector.selectArchetype(DefaultArchetypeSelector.java:71)
> at
> org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execute(CreateProjectFromArchetypeMojo.java:197)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:553)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:523)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
> 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.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.Launc
[jira] (SUREFIRE-938) out of memory when logging more messages than heap size
[ https://jira.codehaus.org/browse/SUREFIRE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315893#comment-315893 ] Andrew Gaul commented on SUREFIRE-938: -- Kristian, I opened a pull request which avoids one of the copies: https://github.com/apache/maven-surefire/pull/16 I do not know enough about Surefire to tackle using a file-backed structure at this point. > out of memory when logging more messages than heap size > --- > > Key: SUREFIRE-938 > URL: https://jira.codehaus.org/browse/SUREFIRE-938 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.12.4 >Reporter: Andrew Gaul > > Observed OOM when logging more messages than heap size: > Exception in thread "ThreadedStreamConsumer" java.lang.OutOfMemoryError: Java > heap space > at java.util.Arrays.copyOfRange(Arrays.java:3209) > at java.lang.String.(String.java:215) > at java.lang.StringBuilder.toString(StringBuilder.java:430) > at > org.apache.maven.plugin.surefire.report.TestSetRunListener.getAsString(TestSetRunListener.java:225) > at > org.apache.maven.plugin.surefire.report.TestSetRunListener.wrap(TestSetRunListener.java:230) > at > org.apache.maven.plugin.surefire.report.TestSetRunListener.testSucceeded(TestSetRunListener.java:161) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:100) > at > org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) > at java.lang.Thread.run(Thread.java:662) -- 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] (MCOMPILER-192) Compiler includes non java files
Trevor Baker created MCOMPILER-192:
--
Summary: Compiler includes non java files
Key: MCOMPILER-192
URL: https://jira.codehaus.org/browse/MCOMPILER-192
Project: Maven 2.x Compiler Plugin
Issue Type: Bug
Affects Versions: 3.0
Environment: Windows 7
Reporter: Trevor Baker
I notice one of my builds had this in the maven-compiler-plugin configuration:
{noformat}
my/path/MyFile.inc
{noformat}
In 2.5.1, the inc file is excluded from the generated compiler file and the
build is successful.
In 3.0, the inc file is included in the generated compiler file and the build
is not successful. There are no warnings or errors displayed.
The CLI returnCode is 2 but there is no output to grab messages from. When I
grab the generated compiler file and run by myself on the command line, I get
this:
{noformat}
$ cmd.exe /X /C "C:\tools\jdk-1.6.0_33\bin\javac.exe
@C:/Tools/cygwin/tmp/org.codehaus.plexus.compiler.javac.JavacCompiler3357522045371592375arguments"
javac: invalid flag: C:/Users/me/project/src/java/my/path/MyFile.inc
Usage: javac
use -help for a list of possible options
{noformat}
I've removed the inc file from the compiler configuration, but the compiler
plugin should handle more gracefully.
--
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] (SUREFIRE-938) out of memory when logging more messages than heap size
[ https://jira.codehaus.org/browse/SUREFIRE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315901#comment-315901 ] Kristian Rosenvold commented on SUREFIRE-938: - I'm afraid the pull request doesn't entirely do it, since most of the memory related issues come from the bytBuffer.toString, which is where the nasty memory usage lies. The real problem is making the StatelessXmlReporter use a streaming xml api so it can immediately stream the stdout to file and keep stderr in a tempfile. It should be possible to make a simple unit test for the xml reporter while converting it to sax (it is tested extremely well through the IT's). If you want to have a shot at doing that, I can handle all the other changes that would need to be done (if you want to make it use Sax and works with a unit test I can fix the rest). The pull request has no real effect, please close it. btw; 2.13 is about 36 hours from now if you want it in there ;) > out of memory when logging more messages than heap size > --- > > Key: SUREFIRE-938 > URL: https://jira.codehaus.org/browse/SUREFIRE-938 > Project: Maven Surefire > Issue Type: Bug > Components: Maven Surefire Plugin >Affects Versions: 2.12.4 >Reporter: Andrew Gaul > > Observed OOM when logging more messages than heap size: > Exception in thread "ThreadedStreamConsumer" java.lang.OutOfMemoryError: Java > heap space > at java.util.Arrays.copyOfRange(Arrays.java:3209) > at java.lang.String.(String.java:215) > at java.lang.StringBuilder.toString(StringBuilder.java:430) > at > org.apache.maven.plugin.surefire.report.TestSetRunListener.getAsString(TestSetRunListener.java:225) > at > org.apache.maven.plugin.surefire.report.TestSetRunListener.wrap(TestSetRunListener.java:230) > at > org.apache.maven.plugin.surefire.report.TestSetRunListener.testSucceeded(TestSetRunListener.java:161) > at > org.apache.maven.plugin.surefire.booterclient.output.ForkClient.consumeLine(ForkClient.java:100) > at > org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:67) > at java.lang.Thread.run(Thread.java:662) -- 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-5414) Trying to compile code using maven 3.0.4 version but getting error - illegal character
Madhur Naidu created MNG-5414: - Summary: Trying to compile code using maven 3.0.4 version but getting error - illegal character Key: MNG-5414 URL: https://jira.codehaus.org/browse/MNG-5414 Project: Maven 2 & 3 Issue Type: Bug Components: POM::Encoding Affects Versions: 3.0.4 Environment: Windows 7 32 bit, JDK 1.6, Maven 3.0.4 Reporter: Madhur Naidu Hi, I am getting below mentioned error while trying to compile my java source code using maven. [INFO] Compiling 1072 source files to D:\mifidbe\target\classes [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] \mifidbe\src\main\java\com\infosys\useradmin\userdetails\datalayer\dao\UserDAOImpl.java:[1,0] illegal character: \65279 [INFO] 1 error PFA the detailed trace of the issue in text document. It looks like UTF-8 encoding may be an issue but not sure though. Please help me in resloving 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] (MNG-5413) Trying to compile code using maven 3.0.4 version but getting error - illegal character
Madhur Naidu created MNG-5413: - Summary: Trying to compile code using maven 3.0.4 version but getting error - illegal character Key: MNG-5413 URL: https://jira.codehaus.org/browse/MNG-5413 Project: Maven 2 & 3 Issue Type: Bug Components: POM::Encoding Affects Versions: 3.0.4 Environment: Windows 7 32 bit, JDK 1.6, Maven 3.0.4 Reporter: Madhur Naidu Hi, I am getting below mentioned error while trying to compile my java source code using maven. [INFO] Compiling 1072 source files to D:\mifidbe\target\classes [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] \mifidbe\src\main\java\com\infosys\useradmin\userdetails\datalayer\dao\UserDAOImpl.java:[1,0] illegal character: \65279 [INFO] 1 error PFA the detailed trace of the issue in text document. It looks like UTF-8 encoding may be an issue but not sure though. Please help me in resloving 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] (MRELEASE-798) Commit additional files with release plugin
[ https://jira.codehaus.org/browse/MRELEASE-798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315905#comment-315905 ] Thorsten Hoeger commented on MRELEASE-798: -- As 2.4 was announced I want to ask again if this will be implemented in the future. > Commit additional files with release plugin > --- > > Key: MRELEASE-798 > URL: https://jira.codehaus.org/browse/MRELEASE-798 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Components: prepare, scm >Affects Versions: 2.3.2 >Reporter: Thorsten Hoeger > > Hi, > is there any possibility to have the release-plugin commit additional files > which were > generated/modified in the preparationGoals. > Now only the pom.xml is commited. Using scm-plugin has some serious drawbacks > in this > situation. > If it is not possible at the moment, is there any chance to get this in the > future. Maybe > there could be a parameter additionalCommitFiles with a list of files to > commit along with > pom.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] (MCOMPILER-193) Trying to compile code using maven 3.0.4 version but getting error - illegal character
[ https://jira.codehaus.org/browse/MCOMPILER-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anders Hammar moved MNG-5413 to MCOMPILER-193: -- Complexity: (was: Intermediate) Component/s: (was: POM::Encoding) Affects Version/s: (was: 3.0.4) Key: MCOMPILER-193 (was: MNG-5413) Project: Maven 2.x Compiler Plugin (was: Maven 2 & 3) > Trying to compile code using maven 3.0.4 version but getting error - illegal > character > -- > > Key: MCOMPILER-193 > URL: https://jira.codehaus.org/browse/MCOMPILER-193 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug > Environment: Windows 7 32 bit, JDK 1.6, Maven 3.0.4 >Reporter: Madhur Naidu > > Hi, > I am getting below mentioned error while trying to compile my java source > code using maven. > [INFO] Compiling 1072 source files to D:\mifidbe\target\classes > [INFO] - > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] > \mifidbe\src\main\java\com\infosys\useradmin\userdetails\datalayer\dao\UserDAOImpl.java:[1,0] > illegal character: \65279 > [INFO] 1 error > PFA the detailed trace of the issue in text document. It looks like UTF-8 > encoding may be an issue but not sure though. Please help me in resloving > 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] (MCOMPILER-193) Trying to compile code using maven 3.0.4 version but getting error - illegal character
[ https://jira.codehaus.org/browse/MCOMPILER-193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=315910#comment-315910 ] Anders Hammar commented on MCOMPILER-193: - Moved to the compiler plugin. Please provide more info or this will be closed as incomplete! A test project showing the bug would help. > Trying to compile code using maven 3.0.4 version but getting error - illegal > character > -- > > Key: MCOMPILER-193 > URL: https://jira.codehaus.org/browse/MCOMPILER-193 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug > Environment: Windows 7 32 bit, JDK 1.6, Maven 3.0.4 >Reporter: Madhur Naidu > > Hi, > I am getting below mentioned error while trying to compile my java source > code using maven. > [INFO] Compiling 1072 source files to D:\mifidbe\target\classes > [INFO] - > [ERROR] COMPILATION ERROR : > [INFO] - > [ERROR] > \mifidbe\src\main\java\com\infosys\useradmin\userdetails\datalayer\dao\UserDAOImpl.java:[1,0] > illegal character: \65279 > [INFO] 1 error > PFA the detailed trace of the issue in text document. It looks like UTF-8 > encoding may be an issue but not sure though. Please help me in resloving > 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
