[jira] Closed: (MEAR-140) HTML Anchors on page EAR Modules defect
[ https://jira.codehaus.org/browse/MEAR-140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MEAR-140. Resolution: Fixed Fix Version/s: 2.7 Assignee: Dennis Lundberg Fixed in r1211791 by updating to a newer parent that uses a newer version of maven-site-plugin. HTML Anchors on page EAR Modules defect - Key: MEAR-140 URL: https://jira.codehaus.org/browse/MEAR-140 Project: Maven 2.x Ear Plugin Issue Type: Task Affects Versions: 2.6 Environment: Maven Site / Project Documentation Reporter: Thomas Assignee: Dennis Lundberg Priority: Trivial Fix For: 2.7 On the maven site page EAR Modules the Anchors are not working: http://maven.apache.org/plugins/maven-ear-plugin/modules.html They should link to the sections on the same page. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MEAR-48) Remove the deprecated resourcesDir parameter
[ https://jira.codehaus.org/browse/MEAR-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MEAR-48: Description: resourcesDir has been deprecated for a while now so it should be removed. (was: resourceDir is deprecated for a while now so it should be removed.) Assignee: Dennis Lundberg (was: Stephane Nicoll) Summary: Remove the deprecated resourcesDir parameter (was: Remove resourceDir deprecated feature) Remove the deprecated resourcesDir parameter Key: MEAR-48 URL: https://jira.codehaus.org/browse/MEAR-48 Project: Maven 2.x Ear Plugin Issue Type: Task Affects Versions: 2.3 Reporter: Stephane Nicoll Assignee: Dennis Lundberg Priority: Minor Fix For: 2.7 resourcesDir has been deprecated for a while now so it should be removed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-623) lifecycle dependency failure with code generation versus javadocs versus the site plugin
[ https://jira.codehaus.org/browse/MSITE-623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=285212#comment-285212 ] Benson Margulies commented on MSITE-623: I don't see how. This one is only in M3, not M2.2.1. It's really not a site thing at all. I believe that the bug is shaped as follows: If you ask the artifact resolver API for g:a:v:wsdl, and that isn't in the reactor, but g:a:v:jar is in the reactor, you get g:a:b:jar instead of searching repos or nuthin. lifecycle dependency failure with code generation versus javadocs versus the site plugin Key: MSITE-623 URL: https://jira.codehaus.org/browse/MSITE-623 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Components: Maven 3 Affects Versions: 3.0 Reporter: Benson Margulies This is related to MSITE-622. In a multi-module project, one module has a plugin execution in phase 'process-classes' that produces an attached artifact (with type 'wsdl'). A second module depends on it, and has another plugin execution in phase 'generate-sources' that depends on the artifact from the first one. The second project declares this dependency. When I run site:site, it does not run compile, or process-classes, so the wsdl artifact is not in the reactor, and then the second plugin can't find it, and the build fails (and, as per -622, no explanation is shown without -X). (That's particularly odd, since it should be sitting in the local repo from a previous build.) How is something like this supposed to work? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-701) NPE org.maven.ide.eclipse.wtp.WTPProjectsUtil.isQualifiedAsWebFragment(WTPProjectsUtil.java:462)
[
https://jira.codehaus.org/browse/MECLIPSE-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=285213#comment-285213
]
Gabriel Forro commented on MECLIPSE-701:
The problem is caused by the:
{code:xml}
resource
directory../../build/properties/directory
/resource
{code}
Probably the '../..' expression is evaluated to a {{null}} value (see line 462
in
[WTPProjectsUtil.java|https://github.com/sonatype/m2eclipse-wtp/blob/master/org.maven.ide.eclipse.wtp/src/org/maven/ide/eclipse/wtp/WTPProjectsUtil.java],
where {{resourceFolderPath}} has a {{null}} value)
Fortunately there is a workaround:
Replace the mentioned resource definition by the following one in your
{{pom.xml}}:
{code:xml}
resource
direcotory${project.build.directory}/../../../build/properties/directory
resource
{code}
This fixed the problem for me. Unfortunately You can not use the
{{$\{basedir\}}} maven property as its usage results to the same NPE. I do not
know the reason. :(
NPE
org.maven.ide.eclipse.wtp.WTPProjectsUtil.isQualifiedAsWebFragment(WTPProjectsUtil.java:462)
Key: MECLIPSE-701
URL: https://jira.codehaus.org/browse/MECLIPSE-701
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: M2Eclipse support
Affects Versions: 2.8
Reporter: Sebastien Tardif
Attachments: EclipseIntegration.png, More installation info.png
Systematically get NPE when importing simple Maven project to Eclipse
SpringSource Tool Suite 2.8.0 release
Which use m2e 1.0.100.20110804-1717
Same similar NPE with previous version of Maven integration. I do wonder for
the last 6 months if I'm the only one using Maven integration with Eclipse,
no kidding.
!ENTRY org.eclipse.core.jobs 4 2 2011-10-27 10:32:04.383
!MESSAGE An internal error occurred during: Importing Maven projects.
!STACK 0
java.lang.NullPointerException
at
org.maven.ide.eclipse.wtp.WTPProjectsUtil.isQualifiedAsWebFragment(WTPProjectsUtil.java:462)
at
org.maven.ide.eclipse.wtp.WebFragmentProjectConfigurator.configure(WebFragmentProjectConfigurator.java:59)
at
org.eclipse.m2e.core.project.configurator.AbstractLifecycleMapping.configure(AbstractLifecycleMapping.java:72)
at
org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:302)
at
org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.configureNewMavenProject(ProjectConfigurationManager.java:234)
at
org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.importProjects(ProjectConfigurationManager.java:150)
at
org.eclipse.m2e.core.ui.internal.wizards.MavenImportWizard$1.doCreateMavenProjects(MavenImportWizard.java:164)
at
org.eclipse.m2e.core.ui.internal.wizards.AbstractCreateMavenProjectsOperation.run(AbstractCreateMavenProjectsOperation.java:73)
at
org.eclipse.m2e.core.ui.internal.wizards.MavenImportWizard$3.runInWorkspace(MavenImportWizard.java:249)
at
org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
!ENTRY org.eclipse.core.jobs 4 2 2011-10-27 10:32:15.816
!MESSAGE An internal error occurred during: Updating Maven Configuration.
!STACK 0
java.lang.NullPointerException
at
org.maven.ide.eclipse.wtp.WTPProjectsUtil.isQualifiedAsWebFragment(WTPProjectsUtil.java:462)
at
org.maven.ide.eclipse.wtp.WebFragmentProjectConfigurator.configure(WebFragmentProjectConfigurator.java:59)
at
org.eclipse.m2e.core.project.configurator.AbstractLifecycleMapping.configure(AbstractLifecycleMapping.java:72)
at
org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:302)
at
org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:277)
at
org.eclipse.m2e.core.ui.internal.UpdateConfigurationJob.runInWorkspace(UpdateConfigurationJob.java:87)
at
org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
pom.xml
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.onassignment.ops/groupId
artifactIdfunctional.tests/artifactId
packagingjar/packaging
version0.0.1-SNAPSHOT/version
nameOPS Functional Tests/name
properties
[jira] Moved: (MNG-5214) lifecycle dependency failure with code generation versus javadocs versus the site plugin
[ https://jira.codehaus.org/browse/MNG-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies moved MSITE-623 to MNG-5214: - Complexity: Intermediate Component/s: (was: Maven 3) Dependencies Affects Version/s: (was: 3.0) 3.0 Key: MNG-5214 (was: MSITE-623) Project: Maven 2 3 (was: Maven 2.x and 3.x Site Plugin) lifecycle dependency failure with code generation versus javadocs versus the site plugin Key: MNG-5214 URL: https://jira.codehaus.org/browse/MNG-5214 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0 Reporter: Benson Margulies This is related to MSITE-622. In a multi-module project, one module has a plugin execution in phase 'process-classes' that produces an attached artifact (with type 'wsdl'). A second module depends on it, and has another plugin execution in phase 'generate-sources' that depends on the artifact from the first one. The second project declares this dependency. When I run site:site, it does not run compile, or process-classes, so the wsdl artifact is not in the reactor, and then the second plugin can't find it, and the build fails (and, as per -622, no explanation is shown without -X). (That's particularly odd, since it should be sitting in the local repo from a previous build.) How is something like this supposed to work? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-5214) Dependency resolution substitutes g:a:v:jar for j:a:v:something-else when something-else isn't in the reactor
[ https://jira.codehaus.org/browse/MNG-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated MNG-5214: -- Description: Start with: https://svn.apache.org/repos/asf/cxf/trunk Put some pergem space into MAVEN_OPTS (http://cxf.apache.org/building.html) run mvn -Pfastinstall Now, cd to systests/wsdl_maven Run mvn site:site Here's what's happening under the covers. The first child module has an execution of the CXF java2ws plugin in 'process-classes'. The second module has an execution of the CXF codegen plugin in 'generate-sources'. The first module creates, and attaches, an artifact: org.apache.cxf.systests.wsdl_maven:cxf-systests-java2ws:(v):wsdl. The second module declares it as a dependency. In a multi-module project, one module has a plugin execution in phase 'process-classes' that produces an attached artifact (with type 'wsdl'). The site lifecycle does not, by default, include process-classes. So the wsdl isn't in the reactor, but it's cousin the 'jar' is. When the codegen plugin calls the artifact resolver, it expects to get an error, or, better yet, a copy of that wsdl from the local repo or the apache snapshot repo. Instead, the resolver 'resolves' the artifact to the corresponding 'jar' in the reactor. Calling getFile() returns the target/classes directory. was: This is related to MSITE-622. In a multi-module project, one module has a plugin execution in phase 'process-classes' that produces an attached artifact (with type 'wsdl'). A second module depends on it, and has another plugin execution in phase 'generate-sources' that depends on the artifact from the first one. The second project declares this dependency. When I run site:site, it does not run compile, or process-classes, so the wsdl artifact is not in the reactor, and then the second plugin can't find it, and the build fails (and, as per -622, no explanation is shown without -X). (That's particularly odd, since it should be sitting in the local repo from a previous build.) How is something like this supposed to work? Testcase included: yes Summary: Dependency resolution substitutes g:a:v:jar for j:a:v:something-else when something-else isn't in the reactor (was: lifecycle dependency failure with code generation versus javadocs versus the site plugin) Dependency resolution substitutes g:a:v:jar for j:a:v:something-else when something-else isn't in the reactor - Key: MNG-5214 URL: https://jira.codehaus.org/browse/MNG-5214 Project: Maven 2 3 Issue Type: Bug Components: Dependencies Affects Versions: 3.0 Reporter: Benson Margulies Start with: https://svn.apache.org/repos/asf/cxf/trunk Put some pergem space into MAVEN_OPTS (http://cxf.apache.org/building.html) run mvn -Pfastinstall Now, cd to systests/wsdl_maven Run mvn site:site Here's what's happening under the covers. The first child module has an execution of the CXF java2ws plugin in 'process-classes'. The second module has an execution of the CXF codegen plugin in 'generate-sources'. The first module creates, and attaches, an artifact: org.apache.cxf.systests.wsdl_maven:cxf-systests-java2ws:(v):wsdl. The second module declares it as a dependency. In a multi-module project, one module has a plugin execution in phase 'process-classes' that produces an attached artifact (with type 'wsdl'). The site lifecycle does not, by default, include process-classes. So the wsdl isn't in the reactor, but it's cousin the 'jar' is. When the codegen plugin calls the artifact resolver, it expects to get an error, or, better yet, a copy of that wsdl from the local repo or the apache snapshot repo. Instead, the resolver 'resolves' the artifact to the corresponding 'jar' in the reactor. Calling getFile() returns the target/classes directory. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MEAR-48) Remove the deprecated resourcesDir parameter
[ https://jira.codehaus.org/browse/MEAR-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MEAR-48. --- Resolution: Fixed Fixed in [r1211869|http://svn.apache.org/viewvc?view=revisionrevision=1211869]. Remove the deprecated resourcesDir parameter Key: MEAR-48 URL: https://jira.codehaus.org/browse/MEAR-48 Project: Maven 2.x Ear Plugin Issue Type: Task Affects Versions: 2.3 Reporter: Stephane Nicoll Assignee: Dennis Lundberg Priority: Minor Fix For: 2.7 resourcesDir has been deprecated for a while now so it should be removed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MEAR-142) bundleFileName ignored when plugin used with multiple profile
[
https://jira.codehaus.org/browse/MEAR-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MEAR-142:
-
Description:
I want to build ear with different sets of modules based on the profiles
activated
In every profile i have a configuration like this
{code:xml}
profile
idprofile1/id
dependencies
dependency
..
/dependency
/dependencies
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
version2.6/version
configuration
modules
ejbModule
groupId/groupId
artifactIdxxx-yyy/artifactId
bundleFileNamexxx-yyy.jar/bundleFileName
/ejbModule
/modules
/configuration
/plugin
/plugins
/build
/profile
{code}
As soon as i use two different profiles the bundleFileName attribute is ignored
and ejb/jar/war are packaged with the original filename
Only workaround possibile at the moment:
have only two profiles
replicate all the ejb/jar/war in the two profiles
but obviously this is less than optimal
bye
was:
I want to build ear with different sets of modules based on the profiles
activated
In every profile i have a configuration like this
profile
idprofile1/id
dependencies
dependency
..
/dependency
/dependencies
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
version2.6/version
configuration
modules
ejbModule
groupId/groupId
artifactIdxxx-yyy/artifactId
bundleFileNamexxx-yyy.jar/bundleFileName
/ejbModule
/modules
/configuration
/plugin
/plugins
/build
/profile
As soon as i use two different profiles the bundleFileName attribute is ignored
and ejb/jar/war are packaged with the original filename
Only workaround possibile at the moment:
have only two profiles
replicate all the ejb/jar/war in the two profiles
but obviously this is less than optimal
bye
bundleFileName ignored when plugin used with multiple profile
-
Key: MEAR-142
URL: https://jira.codehaus.org/browse/MEAR-142
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.6
Environment: linux, or windows same behaviour
maven 2, jdk 1.5
Reporter: Stefano Ghezzi
Attachments: ear-bundle-file-name.zip
I want to build ear with different sets of modules based on the profiles
activated
In every profile i have a configuration like this
{code:xml}
profile
idprofile1/id
dependencies
dependency
..
/dependency
/dependencies
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
version2.6/version
configuration
modules
ejbModule
groupId/groupId
artifactIdxxx-yyy/artifactId
bundleFileNamexxx-yyy.jar/bundleFileName
/ejbModule
/modules
/configuration
/plugin
/plugins
/build
/profile
{code}
As soon as i use two different profiles the bundleFileName attribute is
ignored and ejb/jar/war are packaged with the original filename
Only workaround possibile at the moment:
have only two profiles
replicate all the ejb/jar/war in the two profiles
but obviously this is less than optimal
bye
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MEAR-60) Improve support for skinny war files
[ https://jira.codehaus.org/browse/MEAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MEAR-60: Fix Version/s: 2.7 Improve support for skinny war files Key: MEAR-60 URL: https://jira.codehaus.org/browse/MEAR-60 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.3 Environment: mvn 2.0.5 Reporter: Marcel Schutte Assignee: Dennis Lundberg Priority: Critical Fix For: 2.7 Attachments: maven-ear-plugin-MEAR-60.patch Provide a boolean configuration option for webModules to include the war's transitive dependencies. As described on http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html it is very common in a J2EE environment to use so called skinny wars. Here the war's WEB-INF/lib will not contain the dependent jars, but instead they are packaged inside the EAR. The war references them through its META-INF/MANIFEST.MF This option could be used to avoid the 'painful part' mentioned in the above web page. The war's dependencies wouldn't have to be duplicated alongside the ear's. I also found an old issue (MEAR-14) which has asked for the current default behavior of not including the transitive dependencies. It suggests a property to include specific dependencies of the war. As far as I can tell this has never been implemented and this is also not what I am asking for. My proposal is an all of nothing kind of option for each war module in the ear. On a side note, for me this is the part where removal of the old maven 1 style properties per dependency is missed the most. With them it was possible to decide for each single dependency whether to put it in WEB-INF/lib or reference it through the manifest classpath. But of course, then we didn't have the transitive dependencies -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MEAR-113) The default contextRoot should match the default bundleFileName
[ https://jira.codehaus.org/browse/MEAR-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg updated MEAR-113: - Fix Version/s: (was: 2.7) The default contextRoot should match the default bundleFileName --- Key: MEAR-113 URL: https://jira.codehaus.org/browse/MEAR-113 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.3.2 Reporter: Michael Semb Wever Attachments: MEAR-113.patch, MEAR-113.patch In a webModule the contextRoot defaults to / + a.getArtifactId() There is no way AFAIK to have a contextRoot that honours the webModule artifact's finalName, necessary if it was dynamically set via profiles. (The only way i see here is to duplicate all the profile information and put the maven-ear-plugin configuration into each profile, just to insert the various contextRoot values). By making the contextRoot instead default to / + getBundleFileName() this scenario is solved. The webModule's contextRoot defaults to the build name of the artifact if it were customised. If that artifact's finalName was not customised then it defaults back to the artifactId therefore maintaining today's behavior and not breaking any compatibility. Patch attached. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-701) NPE org.maven.ide.eclipse.wtp.WTPProjectsUtil.isQualifiedAsWebFragment(WTPProjectsUtil.java:462)
[ https://jira.codehaus.org/browse/MECLIPSE-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte closed MECLIPSE-701. --- Resolution: Incomplete Since M2Eclipse has been moved to Eclipse, you should use their bugzilla: https://bugs.eclipse.org/bugs/enter_bug.cgi?product=m2e NPE org.maven.ide.eclipse.wtp.WTPProjectsUtil.isQualifiedAsWebFragment(WTPProjectsUtil.java:462) Key: MECLIPSE-701 URL: https://jira.codehaus.org/browse/MECLIPSE-701 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: M2Eclipse support Affects Versions: 2.8 Reporter: Sebastien Tardif Attachments: EclipseIntegration.png, More installation info.png Systematically get NPE when importing simple Maven project to Eclipse SpringSource Tool Suite 2.8.0 release Which use m2e 1.0.100.20110804-1717 Same similar NPE with previous version of Maven integration. I do wonder for the last 6 months if I'm the only one using Maven integration with Eclipse, no kidding. !ENTRY org.eclipse.core.jobs 4 2 2011-10-27 10:32:04.383 !MESSAGE An internal error occurred during: Importing Maven projects. !STACK 0 java.lang.NullPointerException at org.maven.ide.eclipse.wtp.WTPProjectsUtil.isQualifiedAsWebFragment(WTPProjectsUtil.java:462) at org.maven.ide.eclipse.wtp.WebFragmentProjectConfigurator.configure(WebFragmentProjectConfigurator.java:59) at org.eclipse.m2e.core.project.configurator.AbstractLifecycleMapping.configure(AbstractLifecycleMapping.java:72) at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:302) at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.configureNewMavenProject(ProjectConfigurationManager.java:234) at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.importProjects(ProjectConfigurationManager.java:150) at org.eclipse.m2e.core.ui.internal.wizards.MavenImportWizard$1.doCreateMavenProjects(MavenImportWizard.java:164) at org.eclipse.m2e.core.ui.internal.wizards.AbstractCreateMavenProjectsOperation.run(AbstractCreateMavenProjectsOperation.java:73) at org.eclipse.m2e.core.ui.internal.wizards.MavenImportWizard$3.runInWorkspace(MavenImportWizard.java:249) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) !ENTRY org.eclipse.core.jobs 4 2 2011-10-27 10:32:15.816 !MESSAGE An internal error occurred during: Updating Maven Configuration. !STACK 0 java.lang.NullPointerException at org.maven.ide.eclipse.wtp.WTPProjectsUtil.isQualifiedAsWebFragment(WTPProjectsUtil.java:462) at org.maven.ide.eclipse.wtp.WebFragmentProjectConfigurator.configure(WebFragmentProjectConfigurator.java:59) at org.eclipse.m2e.core.project.configurator.AbstractLifecycleMapping.configure(AbstractLifecycleMapping.java:72) at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:302) at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:277) at org.eclipse.m2e.core.ui.internal.UpdateConfigurationJob.runInWorkspace(UpdateConfigurationJob.java:87) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) pom.xml project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd; modelVersion4.0.0/modelVersion groupIdcom.onassignment.ops/groupId artifactIdfunctional.tests/artifactId packagingjar/packaging version0.0.1-SNAPSHOT/version nameOPS Functional Tests/name properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties dependencies dependency groupIdorg.seleniumhq.selenium/groupId artifactIdselenium-java/artifactId version2.9.0/version /dependency dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.8.2/version scopetest/scope /dependency dependency groupIdcpsuite/groupId artifactIdcpsuite/artifactId
[jira] Commented: (MSKINS-15) With sidebar and no topbar external links should be rendered as menu
[
https://jira.codehaus.org/browse/MSKINS-15?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=285234#comment-285234
]
Robert Scholte commented on MSKINS-15:
--
I thought you'd preferred groovy? ;) I'll translate it, thnx!
With sidebar and no topbar external links should be rendered as menu
Key: MSKINS-15
URL: https://jira.codehaus.org/browse/MSKINS-15
Project: Maven Skins
Issue Type: Bug
Components: Fluido Skin
Affects Versions: fluido-1.0, fluido-1.1
Environment: mvn --version
Apache Maven 3.0.4 (r1209000; 2011-12-01 09:49:38+0100)
Maven home: /usr/local/Cellar/maven/current/libexec
Java version: 1.6.0_29, vendor: Apple Inc.
Java home:
/Library/Java/JavaVirtualMachines/1.6.0_29-b11-402.jdk/Contents/Home
Default locale: de_DE, platform encoding: MacRoman
OS name: mac os x, version: 10.7.2, arch: x86_64, family: mac
Reporter: Mirko Friedenhagen
Assignee: Robert Scholte
Fix For: fluido-1.1
Attachments: documentation.patch,
enable-external-links-for-sidebar-when-no-topbar.patch, verify.bsh
External links specified in {{//project/body/links}} of the {{site.xml}} are
only rendered as dropdown menu when the topbar is enabled.
When only the sidebar is enabled these links are missing completely. I have
attached a patch against revision 1206640 of
http://svn.apache.org/repos/asf/maven/skins/trunk/maven-fluido-skin, which
will render these links as additional menu in the sidebar when
{{topbarEnabled==false}} and {{sidebarEnabled==true}}.
Example output might be found at http://mojo.codehaus.org/fluido-preview/ for
the ckjm-maven-plugin.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-803) Multiple Surefire executions - FAILURE in an execution prevents successive from running.
[ https://jira.codehaus.org/browse/SUREFIRE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=285238#comment-285238 ] Paul Gier commented on SUREFIRE-803: I'm not sure how this could be fixed in Surefire without changes to Maven core. There would need to be a change to Maven, maybe a new Mojo Exception that would tell Maven that there was a failure but that it's ok to continue building the module. Multiple Surefire executions - FAILURE in an execution prevents successive from running. Key: SUREFIRE-803 URL: https://jira.codehaus.org/browse/SUREFIRE-803 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.10 Reporter: Ondrej Zizka Priority: Critical Let's have multiple Surefire executions in a single module (different config needed). A failure of a test in one of these executions prevents running the successive. Surefire's testFailureIgnore is not an option because it makes a run with failures succeed. This behavior is undocumented. Also, it is undesired - the module as a whole should fail, but all it's tests should run. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-806) Make ignoring of includes and excludes on -Dtest=... optional (for multiple Surefire executions)
Make ignoring of includes and excludes on -Dtest=... optional (for multiple
Surefire executions)
Key: SUREFIRE-806
URL: https://jira.codehaus.org/browse/SUREFIRE-806
Project: Maven Surefire
Issue Type: Bug
Components: Maven Surefire Plugin
Affects Versions: 2.11
Reporter: Ondrej Zizka
Let's have a single module with multiple Surefire executions (e.g. with
different Arquillian configs)
Tests are divided to run in either one, using includes and excludes.
Then, if you use -Dtest=..., the specified test(s) is run twice - once for each
execution (and usually fails in one of them in our scenario).
My suggestion is to introduce a Surefire config property which would make this
behavior optional:
{code}
configuration
ignoreIncludesOnSingleTestfalse/ignoreIncludesOnSingleTest
/configuration
{code}
This would cause Surefire to run the intersection of the two sets -
one created by the mask from -Dtest=...,
second created by the includes and excludes of the respective execution.
Current description from
http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html :
{quote}
Specify this parameter to run individual tests by file name, overriding the
includes/excludes parameters. Each pattern you specify here will be used to
create an include pattern formatted like **/${test}.java, so you can just type
-Dtest=MyTest to run a single test called foo/MyTest.java.
This parameter overrides the includes/excludes parameters, and the TestNG
suiteXmlFiles parameter.
{quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-803) Multiple Surefire executions - FAILURE in an execution prevents successive from running.
[ https://jira.codehaus.org/browse/SUREFIRE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=285241#comment-285241 ] John Casey commented on SUREFIRE-803: - Something akin to what the failsafe plugin does might work, but it'd require a surefire mojo executing later in the build process to read the reports and trigger the build failure...which means running `mvn clean test Multiple Surefire executions - FAILURE in an execution prevents successive from running. Key: SUREFIRE-803 URL: https://jira.codehaus.org/browse/SUREFIRE-803 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.10 Reporter: Ondrej Zizka Priority: Critical Let's have multiple Surefire executions in a single module (different config needed). A failure of a test in one of these executions prevents running the successive. Surefire's testFailureIgnore is not an option because it makes a run with failures succeed. This behavior is undocumented. Also, it is undesired - the module as a whole should fail, but all it's tests should run. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SUREFIRE-803) Multiple Surefire executions - FAILURE in an execution prevents successive from running.
[ https://jira.codehaus.org/browse/SUREFIRE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=285241#comment-285241 ] John Casey edited comment on SUREFIRE-803 at 12/8/11 11:39 AM: --- Something akin to what the failsafe plugin does might work, but it'd require a surefire mojo executing later in the build process to read the reports and trigger the build failure...which means running `mvn clean test` might not cut it without re-shuffling the surefire executions to some earlier phase. There might be other ways to detect whether the current execution is the last (and therefore whether it's okay to fail the build now), but I'm not sure off the top of my head. was (Author: jdcasey): Something akin to what the failsafe plugin does might work, but it'd require a surefire mojo executing later in the build process to read the reports and trigger the build failure...which means running `mvn clean test Multiple Surefire executions - FAILURE in an execution prevents successive from running. Key: SUREFIRE-803 URL: https://jira.codehaus.org/browse/SUREFIRE-803 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.10 Reporter: Ondrej Zizka Priority: Critical Let's have multiple Surefire executions in a single module (different config needed). A failure of a test in one of these executions prevents running the successive. Surefire's testFailureIgnore is not an option because it makes a run with failures succeed. This behavior is undocumented. Also, it is undesired - the module as a whole should fail, but all it's tests should run. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5215) Irritating message from Wagon
Irritating message from Wagon
-
Key: MNG-5215
URL: https://jira.codehaus.org/browse/MNG-5215
Project: Maven 2 3
Issue Type: Bug
Components: Artifacts and Repositories
Affects Versions: 3.0.4
Environment: Ubuntu 11.10, JDK 7
Reporter: Jesse Glick
Priority: Minor
In 3.0.4, the message
{code}
wagon http use multi threaded http connection manager maxPerRoute 20, max
total 40
{code}
is printed to the log whenever a connection is first made. I am not sure
exactly what the message is telling me but I probably do not care. Please
suppress this unless I am running in debug mode.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-803) Multiple Surefire executions - FAILURE in an execution prevents successive from running.
[ https://jira.codehaus.org/browse/SUREFIRE-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated SUREFIRE-803: Attachment: surefire-803-failure-prevents-subsequent-executions.zip I believe this is the basic test case that distills the issue. Of course, multimodule builds may also exhibit the symptom found here, but they also obscure the essential bug, IMO. Fix this test case, and the multimodule case will be fixed as well. Multiple Surefire executions - FAILURE in an execution prevents successive from running. Key: SUREFIRE-803 URL: https://jira.codehaus.org/browse/SUREFIRE-803 Project: Maven Surefire Issue Type: Bug Components: Maven Surefire Plugin Affects Versions: 2.10 Reporter: Ondrej Zizka Priority: Critical Attachments: surefire-803-failure-prevents-subsequent-executions.zip Let's have multiple Surefire executions in a single module (different config needed). A failure of a test in one of these executions prevents running the successive. Surefire's testFailureIgnore is not an option because it makes a run with failures succeed. This behavior is undocumented. Also, it is undesired - the module as a whole should fail, but all it's tests should run. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SUREFIRE-799) Allow test parallelisation when forkMode=always
[ https://jira.codehaus.org/browse/SUREFIRE-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nkeywal updated SUREFIRE-799: - Attachment: surefire_799_212_trunk.patch Allow test parallelisation when forkMode=always --- Key: SUREFIRE-799 URL: https://jira.codehaus.org/browse/SUREFIRE-799 Project: Maven Surefire Issue Type: Improvement Components: process forking Affects Versions: 2.10 Environment: all Reporter: nkeywal Attachments: surefire_799_212_trunk.patch Surefire already allows: - forking - parallelization within a JVM Mixing both features would mean forking multiple JVM instead of only one. It would allow to parallelize tests that need to be executed in a separate JVM (i.e.: with forkMode=always). Usually these tests take longer than the simple ones. In our case, 40% of the tests are executed in 4 minutes, the other 60% need two hours. So it's obviously more interesting to parallelize the former, but these ones need to fork. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MANTRUN-172) Properties passed to Maven as -D don't get passed to ant invocations when a profile sets the same property
Properties passed to Maven as -D don't get passed to ant invocations when a profile sets the same property Key: MANTRUN-172 URL: https://jira.codehaus.org/browse/MANTRUN-172 Project: Maven 2.x Antrun Plugin Issue Type: Bug Affects Versions: 1.7 Reporter: Derek Lewis Attachments: maven-antrun-plugin-bug.zip When I invoke Maven as follows: mvn package -Dmy.test.property=from commandline -Ptest-profile Setting my.test.property on the command line, I expect to see the following output from the testcase: [echo] pom.xml: ptest = from commandline [echo] pom.xml: my.test.property = from commandline [echo] build.xml: ptest = from commandline [echo] build.xml: my.test.property = from commandline But instead I see: [echo] pom.xml: ptest = from commandline [echo] pom.xml: my.test.property = from commandline [echo] build.xml: ptest = from commandline [echo] build.xml: my.test.property = from profile It looks like the ant task is causing properties set on the command line to not be inherited. When run without -Ptest-profile, the expected output is seen. The comments on MANTRUN-121 would seem to imply that properties set on the commandline should always be passed to sub ant builds, regardless of the value of the inheritAll property. I've tested with a profile in the pom as well as in settings.xml, and the same behavior is observed regardless of where the profile is, so long as it is activated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-701) NPE org.maven.ide.eclipse.wtp.WTPProjectsUtil.isQualifiedAsWebFragment(WTPProjectsUtil.java:462)
[ https://jira.codehaus.org/browse/MECLIPSE-701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=285287#comment-285287 ] Gabriel Forro commented on MECLIPSE-701: Reported in the recommended bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=366141 NPE org.maven.ide.eclipse.wtp.WTPProjectsUtil.isQualifiedAsWebFragment(WTPProjectsUtil.java:462) Key: MECLIPSE-701 URL: https://jira.codehaus.org/browse/MECLIPSE-701 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: M2Eclipse support Affects Versions: 2.8 Reporter: Sebastien Tardif Attachments: EclipseIntegration.png, More installation info.png Systematically get NPE when importing simple Maven project to Eclipse SpringSource Tool Suite 2.8.0 release Which use m2e 1.0.100.20110804-1717 Same similar NPE with previous version of Maven integration. I do wonder for the last 6 months if I'm the only one using Maven integration with Eclipse, no kidding. !ENTRY org.eclipse.core.jobs 4 2 2011-10-27 10:32:04.383 !MESSAGE An internal error occurred during: Importing Maven projects. !STACK 0 java.lang.NullPointerException at org.maven.ide.eclipse.wtp.WTPProjectsUtil.isQualifiedAsWebFragment(WTPProjectsUtil.java:462) at org.maven.ide.eclipse.wtp.WebFragmentProjectConfigurator.configure(WebFragmentProjectConfigurator.java:59) at org.eclipse.m2e.core.project.configurator.AbstractLifecycleMapping.configure(AbstractLifecycleMapping.java:72) at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:302) at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.configureNewMavenProject(ProjectConfigurationManager.java:234) at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.importProjects(ProjectConfigurationManager.java:150) at org.eclipse.m2e.core.ui.internal.wizards.MavenImportWizard$1.doCreateMavenProjects(MavenImportWizard.java:164) at org.eclipse.m2e.core.ui.internal.wizards.AbstractCreateMavenProjectsOperation.run(AbstractCreateMavenProjectsOperation.java:73) at org.eclipse.m2e.core.ui.internal.wizards.MavenImportWizard$3.runInWorkspace(MavenImportWizard.java:249) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) !ENTRY org.eclipse.core.jobs 4 2 2011-10-27 10:32:15.816 !MESSAGE An internal error occurred during: Updating Maven Configuration. !STACK 0 java.lang.NullPointerException at org.maven.ide.eclipse.wtp.WTPProjectsUtil.isQualifiedAsWebFragment(WTPProjectsUtil.java:462) at org.maven.ide.eclipse.wtp.WebFragmentProjectConfigurator.configure(WebFragmentProjectConfigurator.java:59) at org.eclipse.m2e.core.project.configurator.AbstractLifecycleMapping.configure(AbstractLifecycleMapping.java:72) at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:302) at org.eclipse.m2e.core.internal.project.ProjectConfigurationManager.updateProjectConfiguration(ProjectConfigurationManager.java:277) at org.eclipse.m2e.core.ui.internal.UpdateConfigurationJob.runInWorkspace(UpdateConfigurationJob.java:87) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) pom.xml project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd; modelVersion4.0.0/modelVersion groupIdcom.onassignment.ops/groupId artifactIdfunctional.tests/artifactId packagingjar/packaging version0.0.1-SNAPSHOT/version nameOPS Functional Tests/name properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties dependencies dependency groupIdorg.seleniumhq.selenium/groupId artifactIdselenium-java/artifactId version2.9.0/version /dependency dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.8.2/version scopetest/scope /dependency dependency groupIdcpsuite/groupId artifactIdcpsuite/artifactId version1.2.5/version
[jira] Commented: (MEAR-60) Improve support for skinny war files
[ https://jira.codehaus.org/browse/MEAR-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=285288#comment-285288 ] Dennis Lundberg commented on MEAR-60: - Andreas, Thanks for your feedback! Would you mind sharing your configuration with us. I'd like to add it to the documentation, in case others face the same issue. Improve support for skinny war files Key: MEAR-60 URL: https://jira.codehaus.org/browse/MEAR-60 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.3 Environment: mvn 2.0.5 Reporter: Marcel Schutte Assignee: Dennis Lundberg Priority: Critical Fix For: 2.7 Attachments: maven-ear-plugin-MEAR-60.patch Provide a boolean configuration option for webModules to include the war's transitive dependencies. As described on http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html it is very common in a J2EE environment to use so called skinny wars. Here the war's WEB-INF/lib will not contain the dependent jars, but instead they are packaged inside the EAR. The war references them through its META-INF/MANIFEST.MF This option could be used to avoid the 'painful part' mentioned in the above web page. The war's dependencies wouldn't have to be duplicated alongside the ear's. I also found an old issue (MEAR-14) which has asked for the current default behavior of not including the transitive dependencies. It suggests a property to include specific dependencies of the war. As far as I can tell this has never been implemented and this is also not what I am asking for. My proposal is an all of nothing kind of option for each war module in the ear. On a side note, for me this is the part where removal of the old maven 1 style properties per dependency is missed the most. With them it was possible to decide for each single dependency whether to put it in WEB-INF/lib or reference it through the manifest classpath. But of course, then we didn't have the transitive dependencies -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
