[jira] (MEAR-156) defaultLibBundleDir setting producing odd behavior in Oracle's oepe version of eclipse Galileo
[ https://jira.codehaus.org/browse/MEAR-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stéphane Nicoll closed MEAR-156. Resolution: Won't Fix Assignee: Stéphane Nicoll And I can't run your project either (the parent-pom is not available). Looking back at your description, it seems you are talking of a build inside Galileo. There's nothing I can do here for this. > defaultLibBundleDir setting producing odd behavior in Oracle's oepe version > of eclipse Galileo > -- > > Key: MEAR-156 > URL: https://jira.codehaus.org/browse/MEAR-156 > Project: Maven 2.x Ear Plugin > Issue Type: Bug >Affects Versions: 2.7 > Environment: Windows 7, Eclipse Galileo (Oracle bundled oepe), 2.9 > maven-eclipse-plugin, 2.7 maven-ear-plugin and 2.0 wtp >Reporter: robert stettler >Assignee: Stéphane Nicoll > Attachments: epf-refapp-federated-producer4.zip > > > When I set defaultLibBundle dir as APP-INF/lib my maven dependency libraries > are dropped into the APP-INF/lib/APP-INF. When I look at the eclipse project > settings under JEE Dependencies I see jars listed as > APP-INF/lib/../myjar.jar. > In the org.eclipse.wst.common.component file that was generated the > archiveName for each jar has ../myjar.jar and the deploy-path is set as > APP-INF/lib. If I manually remove the .. from the entries the EAR builds as > expected. Not sure what is driving the .. -- 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-901) Failsafe verify fails if no failsafe-summary.xml can be found
[
https://jira.codehaus.org/browse/SUREFIRE-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305973#comment-305973
]
Mike Youngstrom commented on SUREFIRE-901:
--
This appears to be a regression in 2.12.2 only as 2.12.1 seems to work fine.
> Failsafe verify fails if no failsafe-summary.xml can be found
> -
>
> Key: SUREFIRE-901
> URL: https://jira.codehaus.org/browse/SUREFIRE-901
> Project: Maven Surefire
> Issue Type: Bug
> Components: Maven Failsafe Plugin
>Affects Versions: 2.12.2
>Reporter: Mike Youngstrom
>Priority: Blocker
>
> I just upgraded to 2.12.2 and failsafe verify appears to be failing if
> failsafe didn't run any tests. It appears to be looking for a
> failsafe-summary.xml file which wasn't created when failsafe ran no tests.
> Even though the build log says "Recording test results[INFO] Failsafe report
> directory:
> /home/bldmgr/Hudson/workspace/stack-tcat/api/target/failsafe-reports" no
> failsafe-reports directory was ever created.
> {code}
> [INFO] --- maven-failsafe-plugin:2.12.2:integration-test (integration-tests)
> @ stack-tcat-api ---
> [JENKINS] Recording test results[INFO] Failsafe report directory:
> /home/bldmgr/Hudson/workspace/stack-tcat/api/target/failsafe-reports
> [INFO]
> [INFO] --- maven-failsafe-plugin:2.12.2:verify (verify-integration-tests) @
> stack-tcat-api ---
> [JENKINS] Archiving disabled - not archiving
> /home/bldmgr/Hudson/workspace/stack-tcat/api/pom.xml
> [JENKINS] Archiving disabled - not archiving
> /home/bldmgr/Hudson/workspace/stack-tcat/api/target/stack-tcat-api-1.1.15-SNAPSHOT.jar
> [JENKINS] Archiving disabled - not archiving
> /home/bldmgr/Hudson/workspace/stack-tcat/api/target/stack-tcat-api-1.1.15-SNAPSHOT-sources.jar
> [JENKINS] Archiving disabled - not archiving
> /home/bldmgr/Hudson/workspace/stack-tcat/api/target/stack-tcat-api-1.1.15-SNAPSHOT-test-sources.jar
> [JENKINS] Archiving disabled - not archiving
> /home/bldmgr/Hudson/workspace/stack-tcat/api/target/stack-tcat-api-1.1.15-SNAPSHOT-javadoc.jar
> [INFO]
>
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Stack TCat Parent . SUCCESS [19.813s]
> [INFO] Stack Tcat API FAILURE [32.484s]
> [INFO] Stack Tcat Deploy Plugin .. SKIPPED
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 54.724s
> [INFO] Finished at: Fri Aug 10 11:13:32 MDT 2012
> [WARNING] The requested profile "ics-profile" could not be activated because
> it does not exist.
> [WARNING] The requested profile "continuous" could not be activated because
> it does not exist.
> [INFO] Final Memory: 27M/172M
> [INFO]
>
> mavenExecutionResult exceptions not empty
> message : Failed to execute goal
> org.apache.maven.plugins:maven-failsafe-plugin:2.12.2:verify
> (verify-integration-tests) on project stack-tcat-api:
> /home/bldmgr/Hudson/workspace/stack-tcat/api/target/failsafe-reports/failsafe-summary.xml
> (No such file or directory)
> cause :
> /home/bldmgr/Hudson/workspace/stack-tcat/api/target/failsafe-reports/failsafe-summary.xml
> (No such file or directory)
> Stack trace :
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
> goal org.apache.maven.plugins:maven-failsafe-plugin:2.12.2:verify
> (verify-integration-tests) on project stack-tcat-api:
> /home/bldmgr/Hudson/workspace/stack-tcat/api/target/failsafe-reports/failsafe-summary.xml
> (No such file or directory)
> 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:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at
> org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
> at sun.r
[jira] (SUREFIRE-901) Failsafe verify fails if no failsafe-summary.xml can be found
Mike Youngstrom created SUREFIRE-901:
Summary: Failsafe verify fails if no failsafe-summary.xml can be
found
Key: SUREFIRE-901
URL: https://jira.codehaus.org/browse/SUREFIRE-901
Project: Maven Surefire
Issue Type: Bug
Components: Maven Failsafe Plugin
Affects Versions: 2.12.2
Reporter: Mike Youngstrom
Priority: Blocker
I just upgraded to 2.12.2 and failsafe verify appears to be failing if failsafe
didn't run any tests. It appears to be looking for a failsafe-summary.xml file
which wasn't created when failsafe ran no tests.
Even though the build log says "Recording test results[INFO] Failsafe report
directory:
/home/bldmgr/Hudson/workspace/stack-tcat/api/target/failsafe-reports" no
failsafe-reports directory was ever created.
{code}
[INFO] --- maven-failsafe-plugin:2.12.2:integration-test (integration-tests) @
stack-tcat-api ---
[JENKINS] Recording test results[INFO] Failsafe report directory:
/home/bldmgr/Hudson/workspace/stack-tcat/api/target/failsafe-reports
[INFO]
[INFO] --- maven-failsafe-plugin:2.12.2:verify (verify-integration-tests) @
stack-tcat-api ---
[JENKINS] Archiving disabled - not archiving
/home/bldmgr/Hudson/workspace/stack-tcat/api/pom.xml
[JENKINS] Archiving disabled - not archiving
/home/bldmgr/Hudson/workspace/stack-tcat/api/target/stack-tcat-api-1.1.15-SNAPSHOT.jar
[JENKINS] Archiving disabled - not archiving
/home/bldmgr/Hudson/workspace/stack-tcat/api/target/stack-tcat-api-1.1.15-SNAPSHOT-sources.jar
[JENKINS] Archiving disabled - not archiving
/home/bldmgr/Hudson/workspace/stack-tcat/api/target/stack-tcat-api-1.1.15-SNAPSHOT-test-sources.jar
[JENKINS] Archiving disabled - not archiving
/home/bldmgr/Hudson/workspace/stack-tcat/api/target/stack-tcat-api-1.1.15-SNAPSHOT-javadoc.jar
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Stack TCat Parent . SUCCESS [19.813s]
[INFO] Stack Tcat API FAILURE [32.484s]
[INFO] Stack Tcat Deploy Plugin .. SKIPPED
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 54.724s
[INFO] Finished at: Fri Aug 10 11:13:32 MDT 2012
[WARNING] The requested profile "ics-profile" could not be activated because it
does not exist.
[WARNING] The requested profile "continuous" could not be activated because it
does not exist.
[INFO] Final Memory: 27M/172M
[INFO]
mavenExecutionResult exceptions not empty
message : Failed to execute goal
org.apache.maven.plugins:maven-failsafe-plugin:2.12.2:verify
(verify-integration-tests) on project stack-tcat-api:
/home/bldmgr/Hudson/workspace/stack-tcat/api/target/failsafe-reports/failsafe-summary.xml
(No such file or directory)
cause :
/home/bldmgr/Hudson/workspace/stack-tcat/api/target/failsafe-reports/failsafe-summary.xml
(No such file or directory)
Stack trace :
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
org.apache.maven.plugins:maven-failsafe-plugin:2.12.2:verify
(verify-integration-tests) on project stack-tcat-api:
/home/bldmgr/Hudson/workspace/stack-tcat/api/target/failsafe-reports/failsafe-summary.xml
(No such file or directory)
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:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at
org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
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.launchStandard(Launcher.java:329)
at
org.codehaus.plexus.classworlds.launcher.Launcher.
[jira] (SUREFIRE-857) Non-ASCII source and name in ReportEntry are escaped unicode on fork.
[
https://jira.codehaus.org/browse/SUREFIRE-857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Rosenvold closed SUREFIRE-857.
---
Resolution: Fixed
Fix Version/s: 2.13.0
Assignee: Kristian Rosenvold
Fixed in r1371763, thanks for the patch! Added IT, let's see if it works on any
other machines than my own ;)
> Non-ASCII source and name in ReportEntry are escaped unicode on fork.
> -
>
> Key: SUREFIRE-857
> URL: https://jira.codehaus.org/browse/SUREFIRE-857
> Project: Maven Surefire
> Issue Type: Bug
> Components: process forking
>Affects Versions: 2.9, 2.10, 2.11, 2.12
>Reporter: kayakiss
>Assignee: Kristian Rosenvold
> Fix For: 2.13.0
>
> Attachments: unescape.patch
>
>
> Non-ASCII source and name in ReportEntry are escaped unicode on fork. For
> example 'À'(A with grave) is replaced \u00C0.
> {noformat}
> public class EscapeÀTest {
> @Test
> public void testÀTest() {
> }
> }
> {noformat}
> XML report of this test class is following.
> {noformat}
>
> {noformat}
> This problem is that
> *org.apache.maven.plugin.surefire.booterclient.outpu.ForkClient* is not
> unescape for ReportEntry source and name. Because these are escaped with
> *org.apache.maven.surefire.booter.ForingRunListener*, *ForkClient* must be
> unescaped.
> In the attached patch for 2.12 I fixed this problem.
--
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] (MPLUGIN-223) HelpMojo is not extracted when using java-annotations extractor
Martin Ellis created MPLUGIN-223:
Summary: HelpMojo is not extracted when using java-annotations
extractor
Key: MPLUGIN-223
URL: https://jira.codehaus.org/browse/MPLUGIN-223
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Affects Versions: 3.1
Reporter: Martin Ellis
The generated HelpMojo uses javadoc tags rather than Java annotations.
If the plugin is only configured to use only the java-annotations extractor,
then it does not recognise the HelpMojo as a valid mojo:
{noformat}
java-annotations
{noformat}
In this case, the plugin will silently fail to include the 'help' goal in the
plugin descriptor.
--
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] (MSHARED-235) Invalid artifact type with maven 3
Tuomas Kiviaho created MSHARED-235: -- Summary: Invalid artifact type with maven 3 Key: MSHARED-235 URL: https://jira.codehaus.org/browse/MSHARED-235 Project: Maven Shared Components Issue Type: Bug Components: maven-dependency-tree Affects Versions: maven-dependency-tree-2.0 Reporter: Tuomas Kiviaho Priority: Blocker Attachments: Maven3DependencyGraphBuilder.patch Maven3DependencyGraphBuilder seems to anticipate that type is always the same as Aether artifact extension. This is not true for instance with maven-bundle-plugin that uses 'jar' as extension but type as 'bundle'. Included a small one-liner patch that fixes the problem. -- 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-473) when branching the minor-version-number should be increased not the incremental version
[ https://jira.codehaus.org/browse/MRELEASE-473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305952#comment-305952 ] Michael Wenig commented on MRELEASE-473: Hi Sergio, we did workaround this problem. We have an application which is using the release plugin and decides which version (and set them manually) - not really nice but it is working. For now this app has been growing and therefore now also the right place to decide this (e.g. there are some automatism to reconfiguring jenkins jobs etc.) But of course - the plugin should work in a usable way Regards Michael > when branching the minor-version-number should be increased not the > incremental version > --- > > Key: MRELEASE-473 > URL: https://jira.codehaus.org/browse/MRELEASE-473 > Project: Maven 2.x Release Plugin > Issue Type: Wish > Components: branch >Affects Versions: 2.0-beta-9 >Reporter: Michael Wenig > > When you are using the branches the follwowing method is normally used (at > least at the sites I am working): > trunk: > major.minor.1-SNAPSHOT > releases are only made out of a branch, so the branch name is normally > Release_major_minor and the incremental number denotes the release. > Now a problem occurs in the trunk as per default just the incremental version > is increased (as -SNAPSHOT) > Example: > Version on trunk: 0.0.1-SNAPSHOT > create a branch Release_0_0 > Now on branch there is 0.0.1-SNAPSHOT (correct) > On trunk is 0.0.2-SNAPSHOT per default which will conflict when doing a > release on the branch (as there will be also a 0.0.2-SNAPSHOT per default) > On trunk it would make more sense to have either 0.1.0-SNAPSHOT oder > 1.0.0-SNAPSHOT > So the normal case is to have someone decide on branching if the major or > minor-version should be increased on the trunk. Currently everytime someone > has to manually redefine the new development version. Increasing the > minor-number and resetting the incremental to '0' would be a more useful > default as it is the way 99% of the numbers are made. > Another way I saw is to have on trunk only 2-numbered-versions (as > 0.1-SNAPSHOT) and then directly after branching changing the version on the > branch to 0.1.0-SNAPSHOT. This also makes sense especially if you only want > to branch if you have to make some hotfixes. > I would suggest to add a parameter to the branch goal which is able to switch > between the three possibilities: > - the 'old way' (even if from my sight the current scheme could be > completely dropped as I do not know any project which is able to use this) > - increasing the minor number on trunk and resetting the incremental to > 0-SNAPSHOT > - using two-number-scheme on trunk and three number-scheme on branch -- 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] (MECLIPSE-712) filteredResources in Eclipse .project is not supported and discarded by the Maven 2.x Eclipse Plugin
[
https://jira.codehaus.org/browse/MECLIPSE-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=305951#comment-305951
]
Nicolas Ternisien commented on MECLIPSE-712:
I do agree it would be really useful! I actually don't see why everything
except test-classes and classes are not filtered out by default by Maven
Eclipse plugin (generating the proper filters automatically in .project file).
Could it be somehow possible to configure everything Eclipse allows to do in
.project file in the Eclipse Maven plugin (meaning: all tags), this way, we
would not constantly complain about a missing feature, the integration would be
really better.
> filteredResources in Eclipse .project is not supported and discarded by the
> Maven 2.x Eclipse Plugin
>
>
> Key: MECLIPSE-712
> URL: https://jira.codehaus.org/browse/MECLIPSE-712
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : .project
>Affects Versions: 2.8
> Environment: Maven 3, Windows 7, Eclipse Indigo Service Release 1
>Reporter: René de Bloois
> Attachments: screenshot-1.jpg
>
>
> There is a beautiful way to let Eclipse ignore the target folder:
> {code:xml|title=.project}
>
>
> ...
>
>
> 1328280594689
>
> 10
>
> org.eclipse.ui.ide.multiFilter
>
> 1.0-projectRelativePath-matches-true-false-target
>
>
>
>
> {code}
> Which in Eclipse means (in the Edit Resource Filter window): "Exclude all",
> "Folders", "not recursive", "Project Relative Path matches "target" case
> sensitive".
> This will cause Eclipse to completely ignore this folder and its contents.
> Problem is, after running mvn eclipse:eclipse, this section is removed from
> the .project file.
> It is also not possible to configure the maven eclipse plugin to add this
> filteredResources section.
> Maybe it could even be generated by default by the maven eclipse plugin?
--
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
