[jira] Commented: (MRELEASE-516) release:prepare should support a nested/flat hybrid SCM structure
[
http://jira.codehaus.org/browse/MRELEASE-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215080#action_215080
]
Erik Magnusson commented on MRELEASE-516:
-
I would like to add that it would be desirable if this could also support the
case where the modules do not have the aggregator pom as their parent, i.e. the
following scenario:
{code}
release-workspace\
|
|--release-parent
| |+pom.xml (modules: ../release-module1, ../release-module2)
|
|--release-module1
| |+pom.xml (parent: corporate root pom)
|
|--release-module2
|+pom.xml (parent: some other parent)
{code}
We would like to have this set up in order to support a collective release
consisting of a dynamic set of modules (the list of modules in the aggregator
pom is dynamically generated from a dialog where you can choose which modules
to release at a particular time).
The release cycle for these modules may or may not coincide at any point in
time, it depends entirely on which features should be pushed to production, and
we want this flexible workflow. (And we certainly do not want to release every
module independently since it can be up to 30-40 modules and releases can be as
frequent as every week.)
Also, it would be ideal if any SCM structure could be supported (since SCM
information is readily available in each module's pom anyway), e.g. the modules
above might look like this in the repo:
{code}
repo-root\
|
|--release-parent\trunk
| |+pom.xml (modules: ../release-module1, ../release-module2)
|
|--subdirectory1\
| |
| |release-module1\trunk
| |+pom.xml (parent: corporate root pom)
|
|--release-module2\trunk
|+pom.xml (parent: some other parent)
{code}
release:prepare should support a nested/flat hybrid SCM structure
-
Key: MRELEASE-516
URL: http://jira.codehaus.org/browse/MRELEASE-516
Project: Maven 2.x Release Plugin
Issue Type: Improvement
Components: perform, prepare
Affects Versions: 2.0-beta-9
Environment: OS X 10.5.8, Windows XP Prof, JDK 1.5.0_12, SVN, GIT, CVS
Reporter: Eric Miles
Attachments: maven-release-issue.zip, odd-tags.png
This issue is related to MRELEASE-261 in that release prepare is having some
difficulty in dealing with certain SCM structures during the prepare goal.
Our project structure is flat as you would see in a typical IDE setup:
{noformat}
release-workspace\
|
|--release-parent
||+pom.xml (modules: ../release-module1, ../release-module2)
|
|--release-module1
||+pom.xml (parent: ../release-parent)
|
|--release-module2
|+pom.xml (parent: ../release-parent)
{noformat}
Our SCM (svn) structure is as follows:
{noformat}
svnroot
|
+--release-parent/trunk/pom.xml
+--release-parent/tags/release-parent-1.0.9/pom.xml
|
+--release-module1/trunk/pom.xml
+--release-module1/tags/release-module1-1.0.9/pom.xml
|
+--release-module1/trunk/pom.xml
+--release-module2/tags/release-module2-1.0.9/pom.xml
{noformat}
If we execute release:prepare with no configuration to the release plugin, we
get the following error:
{noformat}
[INFO] [INFO]
[INFO] Checking in modified POMs...
[INFO] Executing: /bin/sh -c cd
/Users/emiles/Projects/release-workspace/release-parent svn
--non-interactive commit --file
/var/folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-1253932520.commit
--targets
/var/folders/fH/fHNZYBGdFd0bMMIPiloA2U+++TI/-Tmp-/maven-scm-4376558781490229966-targets
[INFO] Working directory:
/Users/emiles/Projects/release-workspace/release-parent
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Unable to commit files
Provider message:
The svn command failed.
Command output:
svn: '/Users/emiles/Projects/release-workspace' is not a working copy
{noformat}
If we use the 2.0-beta-10-SNAPSHOT with flat project support and provide the
-DcommitByProject=true JVM parameter, we do not get any errors, however
tagging does not happen as expected. Rather than having tags for each of the
projects, some odd tagging happened at the parent level where an entire
structure was created (with branches, tags and trunk under the tag folder).
I'm attaching a screen shot for reference.
Ignoring the fact that the prepare only somewhat worked, when I attempted to
perform the release, I get an error:
[jira] Issue Comment Edited: (MRELEASE-516) release:prepare should support a nested/flat hybrid SCM structure
[
http://jira.codehaus.org/browse/MRELEASE-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215080#action_215080
]
Erik Magnusson edited comment on MRELEASE-516 at 3/24/10 1:30 AM:
--
I would like to add that it would be desirable if this could also support the
case where the modules do not have the aggregator pom as their parent, i.e. the
following scenario:
{code}
release-workspace\
|
|--release-parent
||+pom.xml (modules: ../release-module1, ../release-module2)
|
|--release-module1
||+pom.xml (parent: corporate root pom)
|
|--release-module2
|+pom.xml (parent: some other parent)
{code}
We would like to have this set up in order to support a collective release
consisting of a dynamic set of modules (the list of modules in the aggregator
pom is dynamically generated from a dialog where you can choose which modules
to release at a particular time).
The release cycle for these modules may or may not coincide at any point in
time, it depends entirely on which features should be pushed to production, and
we want this flexible workflow. (And we certainly do not want to release every
module independently since it can be up to 30-40 modules and releases can be as
frequent as every week.)
Also, it would be ideal if any SCM structure could be supported (since SCM
information is readily available in each module's pom anyway), e.g. the modules
above might look like this in the repo:
{code}
repo-root\
|
|--release-parent\trunk
| |+pom.xml (modules: ../release-module1,
../release-module2)
|
|--subdirectory1\
||
||release-module1\trunk
| |+pom.xml (parent: corporate root pom)
|
|--release-module2\trunk
|+pom.xml (parent: some other parent)
{code}
was (Author: erimag):
I would like to add that it would be desirable if this could also support
the case where the modules do not have the aggregator pom as their parent, i.e.
the following scenario:
{code}
release-workspace\
|
|--release-parent
| |+pom.xml (modules: ../release-module1, ../release-module2)
|
|--release-module1
| |+pom.xml (parent: corporate root pom)
|
|--release-module2
|+pom.xml (parent: some other parent)
{code}
We would like to have this set up in order to support a collective release
consisting of a dynamic set of modules (the list of modules in the aggregator
pom is dynamically generated from a dialog where you can choose which modules
to release at a particular time).
The release cycle for these modules may or may not coincide at any point in
time, it depends entirely on which features should be pushed to production, and
we want this flexible workflow. (And we certainly do not want to release every
module independently since it can be up to 30-40 modules and releases can be as
frequent as every week.)
Also, it would be ideal if any SCM structure could be supported (since SCM
information is readily available in each module's pom anyway), e.g. the modules
above might look like this in the repo:
{code}
repo-root\
|
|--release-parent\trunk
| |+pom.xml (modules: ../release-module1, ../release-module2)
|
|--subdirectory1\
| |
| |release-module1\trunk
| |+pom.xml (parent: corporate root pom)
|
|--release-module2\trunk
|+pom.xml (parent: some other parent)
{code}
release:prepare should support a nested/flat hybrid SCM structure
-
Key: MRELEASE-516
URL: http://jira.codehaus.org/browse/MRELEASE-516
Project: Maven 2.x Release Plugin
Issue Type: Improvement
Components: perform, prepare
Affects Versions: 2.0-beta-9
Environment: OS X 10.5.8, Windows XP Prof, JDK 1.5.0_12, SVN, GIT, CVS
Reporter: Eric Miles
Attachments: maven-release-issue.zip, odd-tags.png
This issue is related to MRELEASE-261 in that release prepare is having some
difficulty in dealing with certain SCM structures during the prepare goal.
Our project structure is flat as you would see in a typical IDE setup:
{noformat}
release-workspace\
|
|--release-parent
||+pom.xml (modules: ../release-module1, ../release-module2)
|
|--release-module1
||+pom.xml (parent: ../release-parent)
|
|--release-module2
|+pom.xml (parent: ../release-parent)
{noformat}
Our SCM (svn) structure is as follows:
[jira] Commented: (MNG-4301) Invalid checksums on deploy when using webdav without extension
[ http://jira.codehaus.org/browse/MNG-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215108#action_215108 ] gesha commented on MNG-4301: @deckrider thankx for valuable tipps :/ Result is attached + Error stacktraces are turned on. Error reading settings.xml: end tag name /all must be the same as start tag put from line 28 (position: TEXT seen .../params\r\n /all... @35:17) Line: 35 Column: 17 Error stacktrace: org.apache.maven.SettingsConfigurationException: end tag name /all must be the same as start tag put from line 28 (position: TEXT seen .../params\r\n /all... @35:1 7) Line: 35 Column: 17 at org.apache.maven.cli.MavenCli.buildSettings(MavenCli.java:432) at org.apache.maven.cli.MavenCli.main(MavenCli.java:202) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) 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.Launcher.main(Launcher.java:375) Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: end tag name /all must be the same as start tag put from line 28 (position: TEXT seen .../params\r\n /all... @35:17) at hidden.org.codehaus.plexus.util.xml.pull.MXParser.parseEndTag(MXParser.java:1708) at hidden.org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1143) at hidden.org.codehaus.plexus.util.xml.pull.MXParser.next(MXParser.java:1105) at hidden.org.codehaus.plexus.util.xml.Xpp3DomBuilder.build(Xpp3DomBuilder.java:179) at hidden.org.codehaus.plexus.util.xml.Xpp3DomBuilder.build(Xpp3DomBuilder.java:86) at org.apache.maven.settings.io.xpp3.SettingsXpp3Reader.parseServer(SettingsXpp3Reader.java:1062) at org.apache.maven.settings.io.xpp3.SettingsXpp3Reader.parseSettings(SettingsXpp3Reader.java:1158) at org.apache.maven.settings.io.xpp3.SettingsXpp3Reader.read(SettingsXpp3Reader.java:1579) at org.apache.maven.settings.DefaultMavenSettingsBuilder.readSettings(DefaultMavenSettingsBuilder.java:122) at org.apache.maven.settings.DefaultMavenSettingsBuilder.buildSettings(DefaultMavenSettingsBuilder.java:163) at org.apache.maven.settings.DefaultMavenSettingsBuilder.buildSettings(DefaultMavenSettingsBuilder.java:154) at org.apache.maven.settings.DefaultMavenSettingsBuilder.buildSettings(DefaultMavenSettingsBuilder.java:142) at org.apache.maven.cli.MavenCli.buildSettings(MavenCli.java:423) ... 10 more Invalid checksums on deploy when using webdav without extension --- Key: MNG-4301 URL: http://jira.codehaus.org/browse/MNG-4301 Project: Maven 2 3 Issue Type: Bug Components: Deployment Affects Versions: 2.2.1 Environment: n/a Reporter: Kevin Shekleton Priority: Blocker With maven 2.2.1, our deployments via webdav are producing invalid checksums, similar to the issue reported in MNG-4235. From maven 2.0.8 and previous, the following build extension was required to deploy via webdav: extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-webdav/artifactId version1.0-beta-2/version /extension /extensions Starting with maven 2.0.9 (see MNG-3418), webdav was included by default and the aforementioned build extension must be removed from the project. If it was included in the project the deployment would fail as Maven would report multiple versions of wagon-webdav present. With maven 2.2.0, our deployment suffered from invalid checksums reported in MNG-4235. With maven 2.2.1, we still see the invalid checksums on deployment as reported in MNG-4235. However, I've found that if you add the above build extension into the project, we don't experience this issue (of generating invalid checksums). Is this workaround an intentional change brought about by the fix of MNG-4235? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-482) Surefire tries to run JUnit4 tests that contain no @Test annotations
[ http://jira.codehaus.org/browse/SUREFIRE-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215118#action_215118 ] Daniel Triphaus commented on SUREFIRE-482: -- This should be fixed, for me this is no real junit4 support if I need a naming-convention for my classfiles. Surefire tries to run JUnit4 tests that contain no @Test annotations Key: SUREFIRE-482 URL: http://jira.codehaus.org/browse/SUREFIRE-482 Project: Maven Surefire Issue Type: Bug Components: Junit 4.x support Affects Versions: 2.4.2 Reporter: Mark Hobson Attachments: test.zip Similar to SUREFIRE-346 but for JUnit4, Surefire tries to run classes that contain no @Test annotations as tests, resulting in the exception: java.lang.Exception: No runnable methods at org.junit.internal.runners.MethodValidator.validateInstanceMethods(MethodValidator.java:32) at org.junit.internal.runners.MethodValidator.validateMethodsForDefaultRunner(MethodValidator.java:43) at org.junit.internal.runners.JUnit4ClassRunner.validate(JUnit4ClassRunner.java:36) at org.junit.internal.runners.JUnit4ClassRunner.init(JUnit4ClassRunner.java:27) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.junit.internal.requests.ClassRequest.buildRunner(ClassRequest.java:33) at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:28) at org.apache.maven.surefire.junit4.JUnit4TestSet.init(JUnit4TestSet.java:45) at org.apache.maven.surefire.junit4.JUnit4DirectoryTestSuite.createTestSet(JUnit4DirectoryTestSuite.java:56) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.locateTestSets(AbstractDirectoryTestSuite.java:96) at org.apache.maven.surefire.Surefire.createSuiteFromDefinition(Surefire.java:209) at org.apache.maven.surefire.Surefire.run(Surefire.java:156) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:338) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:997) Such classes should be ignored by Surefire. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4301) Invalid checksums on deploy when using webdav without extension
[ http://jira.codehaus.org/browse/MNG-4301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215125#action_215125 ] Stephen Pack commented on MNG-4301: --- @gesha: replace the /all in deckrider's snippet with /put. This workaround works for me using Maven 2.2.1 (note that if you deploy a snapshot that already exists -- or anyone on your team doesn't implement the workaround as well -- you may get the error, since the artifact being replaced has the issue). Invalid checksums on deploy when using webdav without extension --- Key: MNG-4301 URL: http://jira.codehaus.org/browse/MNG-4301 Project: Maven 2 3 Issue Type: Bug Components: Deployment Affects Versions: 2.2.1 Environment: n/a Reporter: Kevin Shekleton Priority: Blocker With maven 2.2.1, our deployments via webdav are producing invalid checksums, similar to the issue reported in MNG-4235. From maven 2.0.8 and previous, the following build extension was required to deploy via webdav: extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-webdav/artifactId version1.0-beta-2/version /extension /extensions Starting with maven 2.0.9 (see MNG-3418), webdav was included by default and the aforementioned build extension must be removed from the project. If it was included in the project the deployment would fail as Maven would report multiple versions of wagon-webdav present. With maven 2.2.0, our deployment suffered from invalid checksums reported in MNG-4235. With maven 2.2.1, we still see the invalid checksums on deployment as reported in MNG-4235. However, I've found that if you add the above build extension into the project, we don't experience this issue (of generating invalid checksums). Is this workaround an intentional change brought about by the fix of MNG-4235? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Generate directories for multi-module maven project in workspace
Hi, I have developed an archetype maven which generate a multi module project. When I create a project foo in m2eclipse using my archetype, I obtain this structure in eclipse (foo, entity, web, service). The issue is that I obtain in my workspace a simple directrory foo which contain other directories (entity, web, service). Is there any one who can help me to generate the same structure in my workspace like the eclipse structure. Thank you very much for your help,
[jira] Created: (MECLIPSE-649) generated application.xml is invalid - EAR fails to deploy
generated application.xml is invalid - EAR fails to deploy -- Key: MECLIPSE-649 URL: http://jira.codehaus.org/browse/MECLIPSE-649 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: M2Eclipse support Affects Versions: 2.0 Environment: Windows XP, Eclipse 3.5.2.SR2, JBoss AS 4.2.2.GA, Maven 2.0.8, Java 1.5, m2eclipse 0.10.0 Reporter: Arbi Sookazian Priority: Minor Attachments: application.xml See attached application.xml. Note that some of the ejb modules have .ejb instead of the correct and expected .jar extensions. The location of the application.xml generated by m2eclipse is: \myModule\src\main\application\META-INF EAR fails to deploy on JBoss 4.2.2.GA. The mvn build (when I run 'mvn clean install') is using a bad application.xml presumably generated by m2eclipse when the EAR is constructed (i.e. both packaged and exploded EAR versions have the bad application.xml). The contents of the bad application.xml look like this: module ejbcom.echo.cis.ejb.dao-1.5.1-SNAPSHOT.ejb/ejb /module module ejbcom.echo.cis.editors-1.5.1-SNAPSHOT.ejb/ejb /module module ejbcom.echo.cis.crud.dao-1.5.1-SNAPSHOT.ejb/ejb /module module ejb/com.echo.cis.ejb.dao-1.5.1-SNAPSHOT.jar/ejb /module module ejb/com.echo.cis.crud.dao-1.5.1-SNAPSHOT.jar/ejb /module Note the .ejb extensions on some of the ejb modules above. The files exist in the EAR with .jar extensions so JBoss AS throws following exception when I deploy the EAR: 09:46:55,671 ERROR [MainDeployer] Could not initialise deployment: file:/C:/java/jboss-4.2.2.GA/server/default/deploy/com.echo.cis.gui.ear-1.5.1-SNAPSHOT.ear/ org.jboss.deployment.DeploymentException: url file:/C:/java/jboss-4.2.2.GA/server/default/deploy/com.echo.cis.gui.ear-1.5.1-SNAPSHOT.ear/com.echo.cis.services.merchant-1.5.1-SNAPSHOT.ejb could not be opened, does it exist? When I delete the bad application.xml in foo/src/main/application/META-INF directory and run 'mvn clean install' again, the application.xml in the packaged or exploded EAR is correct (i.e. all ejb module now have .jar extensions, not .ejb). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-649) generated application.xml is invalid - EAR fails to deploy
[ http://jira.codehaus.org/browse/MECLIPSE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215157#action_215157 ] Arbi Sookazian commented on MECLIPSE-649: - This problem is reproducible with Maven 2.2.1 as well... generated application.xml is invalid - EAR fails to deploy -- Key: MECLIPSE-649 URL: http://jira.codehaus.org/browse/MECLIPSE-649 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: M2Eclipse support Affects Versions: 2.0 Environment: Windows XP, Eclipse 3.5.2.SR2, JBoss AS 4.2.2.GA, Maven 2.0.8, Java 1.5, m2eclipse 0.10.0 Reporter: Arbi Sookazian Priority: Minor Attachments: application.xml See attached application.xml. Note that some of the ejb modules have .ejb instead of the correct and expected .jar extensions. The location of the application.xml generated by m2eclipse is: \myModule\src\main\application\META-INF EAR fails to deploy on JBoss 4.2.2.GA. The mvn build (when I run 'mvn clean install') is using a bad application.xml presumably generated by m2eclipse when the EAR is constructed (i.e. both packaged and exploded EAR versions have the bad application.xml). The contents of the bad application.xml look like this: module ejbcom.echo.cis.ejb.dao-1.5.1-SNAPSHOT.ejb/ejb /module module ejbcom.echo.cis.editors-1.5.1-SNAPSHOT.ejb/ejb /module module ejbcom.echo.cis.crud.dao-1.5.1-SNAPSHOT.ejb/ejb /module module ejb/com.echo.cis.ejb.dao-1.5.1-SNAPSHOT.jar/ejb /module module ejb/com.echo.cis.crud.dao-1.5.1-SNAPSHOT.jar/ejb /module Note the .ejb extensions on some of the ejb modules above. The files exist in the EAR with .jar extensions so JBoss AS throws following exception when I deploy the EAR: 09:46:55,671 ERROR [MainDeployer] Could not initialise deployment: file:/C:/java/jboss-4.2.2.GA/server/default/deploy/com.echo.cis.gui.ear-1.5.1-SNAPSHOT.ear/ org.jboss.deployment.DeploymentException: url file:/C:/java/jboss-4.2.2.GA/server/default/deploy/com.echo.cis.gui.ear-1.5.1-SNAPSHOT.ear/com.echo.cis.services.merchant-1.5.1-SNAPSHOT.ejb could not be opened, does it exist? When I delete the bad application.xml in foo/src/main/application/META-INF directory and run 'mvn clean install' again, the application.xml in the packaged or exploded EAR is correct (i.e. all ejb module now have .jar extensions, not .ejb). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MECLIPSE-649) generated application.xml is invalid - EAR fails to deploy
[ http://jira.codehaus.org/browse/MECLIPSE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215157#action_215157 ] Arbi Sookazian edited comment on MECLIPSE-649 at 3/24/10 1:02 PM: -- This problem is reproducible with Maven 2.2.1. I reverted to Eclipse 3.5.1.SR1 and m2eclipse 0.9.8. After I deleted the bad application.xml, ran 'mvn clean install', and deploy, there are no issues. was (Author: asookazian): This problem is reproducible with Maven 2.2.1 as well... generated application.xml is invalid - EAR fails to deploy -- Key: MECLIPSE-649 URL: http://jira.codehaus.org/browse/MECLIPSE-649 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: M2Eclipse support Affects Versions: 2.0 Environment: Windows XP, Eclipse 3.5.2.SR2, JBoss AS 4.2.2.GA, Maven 2.0.8, Java 1.5, m2eclipse 0.10.0 Reporter: Arbi Sookazian Priority: Minor Attachments: application.xml See attached application.xml. Note that some of the ejb modules have .ejb instead of the correct and expected .jar extensions. The location of the application.xml generated by m2eclipse is: \myModule\src\main\application\META-INF EAR fails to deploy on JBoss 4.2.2.GA. The mvn build (when I run 'mvn clean install') is using a bad application.xml presumably generated by m2eclipse when the EAR is constructed (i.e. both packaged and exploded EAR versions have the bad application.xml). The contents of the bad application.xml look like this: module ejbcom.echo.cis.ejb.dao-1.5.1-SNAPSHOT.ejb/ejb /module module ejbcom.echo.cis.editors-1.5.1-SNAPSHOT.ejb/ejb /module module ejbcom.echo.cis.crud.dao-1.5.1-SNAPSHOT.ejb/ejb /module module ejb/com.echo.cis.ejb.dao-1.5.1-SNAPSHOT.jar/ejb /module module ejb/com.echo.cis.crud.dao-1.5.1-SNAPSHOT.jar/ejb /module Note the .ejb extensions on some of the ejb modules above. The files exist in the EAR with .jar extensions so JBoss AS throws following exception when I deploy the EAR: 09:46:55,671 ERROR [MainDeployer] Could not initialise deployment: file:/C:/java/jboss-4.2.2.GA/server/default/deploy/com.echo.cis.gui.ear-1.5.1-SNAPSHOT.ear/ org.jboss.deployment.DeploymentException: url file:/C:/java/jboss-4.2.2.GA/server/default/deploy/com.echo.cis.gui.ear-1.5.1-SNAPSHOT.ear/com.echo.cis.services.merchant-1.5.1-SNAPSHOT.ejb could not be opened, does it exist? When I delete the bad application.xml in foo/src/main/application/META-INF directory and run 'mvn clean install' again, the application.xml in the packaged or exploded EAR is correct (i.e. all ejb module now have .jar extensions, not .ejb). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-540) Hornor scm:checkout scm:export's excludes/includes configuration
Hornor scm:checkout scm:export's excludes/includes configuration Key: SCM-540 URL: http://jira.codehaus.org/browse/SCM-540 Project: Maven SCM Issue Type: Bug Components: maven-plugin Affects Versions: 1.3 Environment: all Reporter: Dan Tran Current, scm:checkout and scm:export allows excludes/includes configuration. However these params are ignored. We should perform the filter (remove necessary files ) after scm action complete. The question here: should it be done at plugin level or api level. This use case is a good feature to have, rather having the user to use antrun to do the post filter -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SCM-540) Hornor scm:checkout scm:export's excludes/includes configuration
[ http://jira.codehaus.org/browse/SCM-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran closed SCM-540. Resolution: Duplicate Fix Version/s: 1.4 it is a duplicate of SCM-526 Hornor scm:checkout scm:export's excludes/includes configuration Key: SCM-540 URL: http://jira.codehaus.org/browse/SCM-540 Project: Maven SCM Issue Type: Bug Components: maven-plugin Affects Versions: 1.3 Environment: all Reporter: Dan Tran Fix For: 1.4 Current, scm:checkout and scm:export allows excludes/includes configuration. However these params are ignored. We should perform the filter (remove necessary files ) after scm action complete. The question here: should it be done at plugin level or api level. This use case is a good feature to have, rather having the user to use antrun to do the post filter -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (SCM-540) Hornor scm:checkout scm:export's excludes/includes configuration
[ http://jira.codehaus.org/browse/SCM-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated SCM-540: -- Fix Version/s: (was: 1.4) Hornor scm:checkout scm:export's excludes/includes configuration Key: SCM-540 URL: http://jira.codehaus.org/browse/SCM-540 Project: Maven SCM Issue Type: Bug Components: maven-plugin Affects Versions: 1.3 Environment: all Reporter: Dan Tran Current, scm:checkout and scm:export allows excludes/includes configuration. However these params are ignored. We should perform the filter (remove necessary files ) after scm action complete. The question here: should it be done at plugin level or api level. This use case is a good feature to have, rather having the user to use antrun to do the post filter -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-649) generated application.xml is invalid - EAR fails to deploy
[ http://jira.codehaus.org/browse/MECLIPSE-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MECLIPSE-649. -- Resolution: Not A Bug Assignee: Benjamin Bentmann This issue belongs to https://issues.sonatype.org/browse/MNGECLIPSE, this issue tracker is for the maven-eclipse-plugin, i.e. mvn eclipse:eclipse. generated application.xml is invalid - EAR fails to deploy -- Key: MECLIPSE-649 URL: http://jira.codehaus.org/browse/MECLIPSE-649 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: M2Eclipse support Affects Versions: 2.0 Environment: Windows XP, Eclipse 3.5.2.SR2, JBoss AS 4.2.2.GA, Maven 2.0.8, Java 1.5, m2eclipse 0.10.0 Reporter: Arbi Sookazian Assignee: Benjamin Bentmann Priority: Minor Attachments: application.xml See attached application.xml. Note that some of the ejb modules have .ejb instead of the correct and expected .jar extensions. The location of the application.xml generated by m2eclipse is: \myModule\src\main\application\META-INF EAR fails to deploy on JBoss 4.2.2.GA. The mvn build (when I run 'mvn clean install') is using a bad application.xml presumably generated by m2eclipse when the EAR is constructed (i.e. both packaged and exploded EAR versions have the bad application.xml). The contents of the bad application.xml look like this: module ejbcom.echo.cis.ejb.dao-1.5.1-SNAPSHOT.ejb/ejb /module module ejbcom.echo.cis.editors-1.5.1-SNAPSHOT.ejb/ejb /module module ejbcom.echo.cis.crud.dao-1.5.1-SNAPSHOT.ejb/ejb /module module ejb/com.echo.cis.ejb.dao-1.5.1-SNAPSHOT.jar/ejb /module module ejb/com.echo.cis.crud.dao-1.5.1-SNAPSHOT.jar/ejb /module Note the .ejb extensions on some of the ejb modules above. The files exist in the EAR with .jar extensions so JBoss AS throws following exception when I deploy the EAR: 09:46:55,671 ERROR [MainDeployer] Could not initialise deployment: file:/C:/java/jboss-4.2.2.GA/server/default/deploy/com.echo.cis.gui.ear-1.5.1-SNAPSHOT.ear/ org.jboss.deployment.DeploymentException: url file:/C:/java/jboss-4.2.2.GA/server/default/deploy/com.echo.cis.gui.ear-1.5.1-SNAPSHOT.ear/com.echo.cis.services.merchant-1.5.1-SNAPSHOT.ejb could not be opened, does it exist? When I delete the bad application.xml in foo/src/main/application/META-INF directory and run 'mvn clean install' again, the application.xml in the packaged or exploded EAR is correct (i.e. all ejb module now have .jar extensions, not .ejb). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-479) Add option to generate Posix tar files.
Add option to generate Posix tar files. --- Key: MASSEMBLY-479 URL: http://jira.codehaus.org/browse/MASSEMBLY-479 Project: Maven 2.x Assembly Plugin Issue Type: Improvement Environment: AIX, systems using Posix tar utility. Reporter: Jamie Goodyear On some systems gnu tar utility is not present however posix tar does exist. It would be nice if we could specify as a target ptar as a file format to allow users of the assembly plugin to generate this particular kind of tar file. As a note, using posix tar to extract a gnu tar file results in truncated files and other anomalies. The difference in tar format is described here in detail http://www.delorie.com/gnu/docs/tar/tar_114.html As a work around for users that need an archive format, but can not use zip or gnu tar, they can try building their files into a jar file. The jar utility can then be used to extract the contents. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-480) Files with ending with a .formatted extention not cleaned up
Files with ending with a .formatted extention not cleaned up Key: MASSEMBLY-480 URL: http://jira.codehaus.org/browse/MASSEMBLY-480 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-5 Environment: dev on windows, build runs on Linux Reporter: J T In the target directory below my project directory a folder called archive-tmp is created and never cleaned up. In it are directories ending in .formatted and files that were being copied as part of this task ending in .formatted. Also in the primary directory where the output of the build is placed there are tons of .formatted files co-mingled with regular files we want to output. Looking through some of the code I think the .formatted extention appears to be used to create temp files as things are copied around but I'm not sure why they are never being cleaned up. We use the outputed files placed in the target directory so this is causing us to get a bunch of unwanted files as part of our build output. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-459) Fatal Error on site:deploy
[
http://jira.codehaus.org/browse/MSITE-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215187#action_215187
]
Anthony Whitford commented on MSITE-459:
The root issue may be related to doxia, because we think we can work around
this bug doing something like:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-site-plugin/artifactId
version2.1/version
configuration
inputEncodingUTF-8/inputEncoding
outputEncodingUTF-8/outputEncoding
/configuration
!-- Need to exclude commons-logging due to bug.
See: http://jira.codehaus.org/browse/MSITE-459 --
dependencies
dependency
groupIdorg.apache.maven.doxia/groupId
artifactIddoxia-module-xhtml/artifactId
version1.1.2/version
exclusions
exclusion
groupIdcommons-logging/groupId
artifactIdcommons-logging/artifactId
/exclusion
/exclusions
/dependency
/dependencies
/plugin
{code}
Fatal Error on site:deploy
--
Key: MSITE-459
URL: http://jira.codehaus.org/browse/MSITE-459
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 2.1
Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_17
OS name: mac os x version: 10.6.2 arch: x86_64 Family: mac
Reporter: Lorenzo Bigagli
Priority: Blocker
Attachments: lablib-checkboxtree.zip
site:deploy fails as follows (related to wagon-webdav dependencies?
Commons-logging?).
Reverting to maven-site-plugin:2.0.x works around the issue.
I attach the project zip (appropriate server/dav configuration needed to
reproduce the problem).
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'site'.
[INFO] org.apache.maven.plugins: checking for updates from
maven2-repo-dev-java-net
[INFO] org.apache.maven.plugins: checking for updates from
maven-repository.dev.java.net
[INFO] org.apache.maven.plugins: checking for updates from hosted.repos
[INFO] org.codehaus.mojo: checking for updates from maven2-repo-dev-java-net
[INFO] org.codehaus.mojo: checking for updates from
maven-repository.dev.java.net
[INFO] org.codehaus.mojo: checking for updates from hosted.repos
[INFO]
[INFO] Building CheckboxTree
[INFO]task-segment: [site:deploy]
[INFO]
[INFO] [site:deploy {execution: default-cli}]
WAGON_VERSION: 1.0-beta-2
http://zeus.pin.unifi.it/projectsSites/lablib-checkboxtree_snap - Session:
Disconnecting
http://zeus.pin.unifi.it/projectsSites/lablib-checkboxtree_snap - Session:
Disconnected
[FATAL ERROR] org.apache.maven.plugins.site.SiteDeployMojo#execute() caused a
linkage error (java.lang.ExceptionInInitializerError) and may be out-of-date.
Check the realms:
[FATAL ERROR] Plugin realm =
app0.child-container[org.apache.maven.plugins:maven-site-plugin:2.1]
urls[0] =
file:/Users/bigagli/.m2/repository/org/apache/maven/plugins/maven-site-plugin/2.1/maven-site-plugin-2.1.jar
urls[1] =
file:/Users/bigagli/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.1/plexus-utils-1.5.1.jar
urls[2] =
file:/Users/bigagli/.m2/repository/org/apache/maven/doxia/doxia-module-xhtml/1.1.2/doxia-module-xhtml-1.1.2.jar
urls[3] =
file:/Users/bigagli/.m2/repository/org/apache/maven/doxia/doxia-core/1.1.2/doxia-core-1.1.2.jar
urls[4] =
file:/Users/bigagli/.m2/repository/xerces/xercesImpl/2.8.1/xercesImpl-2.8.1.jar
urls[5] =
file:/Users/bigagli/.m2/repository/xml-apis/xml-apis/1.3.03/xml-apis-1.3.03.jar
urls[6] =
file:/Users/bigagli/.m2/repository/commons-lang/commons-lang/2.1/commons-lang-2.1.jar
urls[7] =
file:/Users/bigagli/.m2/repository/commons-httpclient/commons-httpclient/3.1/commons-httpclient-3.1.jar
urls[8] =
file:/Users/bigagli/.m2/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar
urls[9] =
file:/Users/bigagli/.m2/repository/commons-codec/commons-codec/1.2/commons-codec-1.2.jar
urls[10] =
file:/Users/bigagli/.m2/repository/org/apache/maven/doxia/doxia-module-apt/1.1.2/doxia-module-apt-1.1.2.jar
urls[11] =
file:/Users/bigagli/.m2/repository/org/apache/maven/doxia/doxia-module-xdoc/1.1.2/doxia-module-xdoc-1.1.2.jar
urls[12] =
file:/Users/bigagli/.m2/repository/org/apache/maven/doxia/doxia-module-fml/1.1.2/doxia-module-fml-1.1.2.jar
urls[13] =
file:/Users/bigagli/.m2/repository/org/apache/maven/doxia/doxia-decoration-model/1.1.2/doxia-decoration-model-1.1.2.jar
urls[14] =
[jira] Updated: (ARCHETYPE-281) Update to Velocity 1.5
[ http://jira.codehaus.org/browse/ARCHETYPE-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated ARCHETYPE-281: Component/s: (was: Archetypes) Generator Update to Velocity 1.5 -- Key: ARCHETYPE-281 URL: http://jira.codehaus.org/browse/ARCHETYPE-281 Project: Maven Archetype Issue Type: Improvement Components: Generator Affects Versions: 2.0-alpha-4 Environment: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.5.0_17 Default locale: fr_FR, platform encoding: Cp1252 OS name: windows xp version: 5.1 arch: x86 Family: windows Reporter: Khaled LABIDI Priority: Minor Hi, I'm using version 2.0-alpha-4 of archetype-plugin and noticed that some velocity features are not supported (leading to parser erreor) particularily the HashMap declaration within a template (Actually, my POM includes some VTL statements) This is because the archetype-plugin 2.0-apha-4 depends on archetype-common 2.0-alpha-4 wich depends on plexus-velocity 1.1.3 which depends on velocity 1.4 and the later become quite old (current version is 1.6) The plexus-velocity version 1.1.8 has been released since Nov.2009 and it updated to use velocity 1.5. Is upgrading archetype-common dependency on plexus-velocity (from 1.1.3 to 1.1.8) planned for archetype-plugin 2.0-apha-5 ? By the way, when does the archetype-plugin 2.0-apha-5 release planned ? Best regards, K.L -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (ARCHETYPE-249) Add Apache Camel WAR archetype to internal catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed ARCHETYPE-249. --- Resolution: Fixed Fix Version/s: 2.0-alpha-5 patch applied in r927210 please consider adding it to the [Archetypes List wiki page|http://docs.codehaus.org/display/MAVENUSER/Archetypes+List]: catalog update lifecycle isn't really published for the moment, but this page is the most complete one Add Apache Camel WAR archetype to internal catalog -- Key: ARCHETYPE-249 URL: http://jira.codehaus.org/browse/ARCHETYPE-249 Project: Maven Archetype Issue Type: Improvement Components: Archetypes Reporter: Jonathan Anstey Assignee: Herve Boutemy Fix For: 2.0-alpha-5 Attachments: camel-archetype-war.patch Could someone apply this patch to add camel-archetype-war to the internal catalog? I'd like to get it in before the next release of the archetype plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (ARCHETYPE-120) Webapp sample contains the wrong project layout
[ http://jira.codehaus.org/browse/ARCHETYPE-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed ARCHETYPE-120. --- Resolution: Fixed Assignee: Herve Boutemy fixed in r927221. Webapp sample contains the wrong project layout --- Key: ARCHETYPE-120 URL: http://jira.codehaus.org/browse/ARCHETYPE-120 Project: Maven Archetype Issue Type: Improvement Components: Archetypes Reporter: Nick Stolwijk Assignee: Herve Boutemy Attachments: fix-webapp-example.patch The Creating a Webapp example page (http://maven.apache.org/plugins/maven-archetype-plugin/examples/webapp.html) contains the wrong directory layout. (Fix included) Also, the files in the archetype plugin have no svn property svn:line-endings native set. (No fix included) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3004) Allow build lifecycle to execute projects in parallel
[ http://jira.codehaus.org/browse/MNG-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215204#action_215204 ] Arnaud Heritier commented on MNG-3004: -- Nothing new since december ? Allow build lifecycle to execute projects in parallel - Key: MNG-3004 URL: http://jira.codehaus.org/browse/MNG-3004 Project: Maven 2 3 Issue Type: Improvement Components: Bootstrap Build, General, Performance Affects Versions: 2.0.6 Reporter: Nigel Magnay Fix For: 3.0-alpha-8 Attachments: MNG-3004-Resurrected-StringSearchModelInterpolatorTest.patch, MNG-3004.increased-testability.patch, MNG3004-SSMI.patch, mng3004.patch, mng3004v2_rev2.patch, parallel-builds.patch One of the great advantages with maven over scripted build environments is that it can calculate the dependencies of the build, and it could execute items that are independent of each other in parallel. Unfortunately it currently doesn't do this, which would be a big win over tools such as 'ant'. It also means that multicore machines have lots of idle capacity when running a serial build that could be utilised. I had a quick shot at seeing what might be required. Bear in mind this is the first time I have looked at maven internally, and I was just trying to feel my way around and build a POC. I got some of the way there, but my build threads don't seem to have the correct classpath - I think this is something to do with plexus / classworlds - but I don't know enough. It'd be great to get this feature in a future version, or a way of running my hack (figuring out why in a thread has not the plexus stuff) in the interim. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-249) Add Apache Camel WAR archetype to internal catalog
[ http://jira.codehaus.org/browse/ARCHETYPE-249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215207#action_215207 ] Jonathan Anstey commented on ARCHETYPE-249: --- Thanks for applying the patch Herve! I've updated that wiki page with the new archetype. Do you happen to know when a release is planned of the archetype plugin? I'm eager to get the Camel archetypes (there were others in JIRAs before this one) showing up in the list when users run mvn archetype:generate. Cheers, Jon Add Apache Camel WAR archetype to internal catalog -- Key: ARCHETYPE-249 URL: http://jira.codehaus.org/browse/ARCHETYPE-249 Project: Maven Archetype Issue Type: Improvement Components: Archetypes Reporter: Jonathan Anstey Assignee: Herve Boutemy Fix For: 2.0-alpha-5 Attachments: camel-archetype-war.patch Could someone apply this patch to add camel-archetype-war to the internal catalog? I'd like to get it in before the next release of the archetype plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-2802) Concurrent-safe access to local Maven repository
[ http://jira.codehaus.org/browse/MNG-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215219#action_215219 ] Paul Benedict commented on MNG-2802: Giving Maven an exclusive lock on an artifact's local metadata should be a sure way of ensuring this. Concurrent-safe access to local Maven repository Key: MNG-2802 URL: http://jira.codehaus.org/browse/MNG-2802 Project: Maven 2 3 Issue Type: Improvement Components: Artifacts and Repositories Reporter: Stepan Roh Assignee: John Casey Fix For: 3.x (to be reviewed) It seems that access to local Maven repository is not concurrent-safe that is multiple Mavens running in parallel may damage contents of local Maven repository. It would be a nice improvement, because sharing of local repository will lower the need for contacting any other repository. I know that Maven proxy can be used, but that adds another layer which may unnecessarily stress the machine it runs on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4599) Provide a way to create virtual artifacts out of plain .jar file.
[ http://jira.codehaus.org/browse/MNG-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215226#action_215226 ] Ondrej Zizka commented on MNG-4599: --- Paul, the way people make dinner is: * Peel the potatoes * Salt the potatoes * Boil the potatoes * Fry some steak * Put it on the plate So if I want to make a tea, I should: * Peel the potatoes * Salt the potatoes * Boil the potatoes because that's the way how potatoes are prepared. Provide a way to create virtual artifacts out of plain .jar file. --- Key: MNG-4599 URL: http://jira.codehaus.org/browse/MNG-4599 Project: Maven 2 3 Issue Type: Improvement Reporter: Ondrej Zizka Assignee: Brett Porter During the time I have been using Maven, I have come across numerous cases when I desperately needed to turn a simple .jar file into a dependency. Currently, this involves installing it properly to the repository first, and only then it can be used. I suggest to introduce some construct which would take a list of .jar files and turn them into dependencies in the sense they would be added to the classpaths, could be used for WAR overlays, etc. Of course, they would not have any transitional dependencies. dependencyManagement jarPaths jarPath../../releases/50GAAS/jboss-as/common/lib/jarPath /jarPaths ... /dependencyManagement This would greately improve Maven's openness to non-mavenized world, and usability in cases when you really get a plain .jar/.war/.ear/... before every build cycle. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4599) Provide a way to create virtual artifacts out of plain .jar file.
[ http://jira.codehaus.org/browse/MNG-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215226#action_215226 ] Ondrej Zizka edited comment on MNG-4599 at 3/24/10 10:49 PM: - Paul, the way people make dinner is: * Peel the potatoes * Salt the potatoes * Boil the potatoes * Fry some steak * Put it on the plate So if I want to make a tea, I should: * Peel the potatoes * Salt the potatoes * Boil the potatoes * Pour the water to a cup with a tea bag because that's the way how potatoes are prepared. was (Author: pekarna): Paul, the way people make dinner is: * Peel the potatoes * Salt the potatoes * Boil the potatoes * Fry some steak * Put it on the plate So if I want to make a tea, I should: * Peel the potatoes * Salt the potatoes * Boil the potatoes * Pour the water to a cup with a tea bag because that's the way how potatoes are prepared. Provide a way to create virtual artifacts out of plain .jar file. --- Key: MNG-4599 URL: http://jira.codehaus.org/browse/MNG-4599 Project: Maven 2 3 Issue Type: Improvement Reporter: Ondrej Zizka Assignee: Brett Porter During the time I have been using Maven, I have come across numerous cases when I desperately needed to turn a simple .jar file into a dependency. Currently, this involves installing it properly to the repository first, and only then it can be used. I suggest to introduce some construct which would take a list of .jar files and turn them into dependencies in the sense they would be added to the classpaths, could be used for WAR overlays, etc. Of course, they would not have any transitional dependencies. dependencyManagement jarPaths jarPath../../releases/50GAAS/jboss-as/common/lib/jarPath /jarPaths ... /dependencyManagement This would greately improve Maven's openness to non-mavenized world, and usability in cases when you really get a plain .jar/.war/.ear/... before every build cycle. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4599) Provide a way to create virtual artifacts out of plain .jar file.
[ http://jira.codehaus.org/browse/MNG-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215226#action_215226 ] Ondrej Zizka edited comment on MNG-4599 at 3/24/10 10:48 PM: - Paul, the way people make dinner is: * Peel the potatoes * Salt the potatoes * Boil the potatoes * Fry some steak * Put it on the plate So if I want to make a tea, I should: * Peel the potatoes * Salt the potatoes * Boil the potatoes * Pour the water to a cup with a tea bag because that's the way how potatoes are prepared. was (Author: pekarna): Paul, the way people make dinner is: * Peel the potatoes * Salt the potatoes * Boil the potatoes * Fry some steak * Put it on the plate So if I want to make a tea, I should: * Peel the potatoes * Salt the potatoes * Boil the potatoes because that's the way how potatoes are prepared. Provide a way to create virtual artifacts out of plain .jar file. --- Key: MNG-4599 URL: http://jira.codehaus.org/browse/MNG-4599 Project: Maven 2 3 Issue Type: Improvement Reporter: Ondrej Zizka Assignee: Brett Porter During the time I have been using Maven, I have come across numerous cases when I desperately needed to turn a simple .jar file into a dependency. Currently, this involves installing it properly to the repository first, and only then it can be used. I suggest to introduce some construct which would take a list of .jar files and turn them into dependencies in the sense they would be added to the classpaths, could be used for WAR overlays, etc. Of course, they would not have any transitional dependencies. dependencyManagement jarPaths jarPath../../releases/50GAAS/jboss-as/common/lib/jarPath /jarPaths ... /dependencyManagement This would greately improve Maven's openness to non-mavenized world, and usability in cases when you really get a plain .jar/.war/.ear/... before every build cycle. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2758) Upload request for Magja
Upload request for Magja Key: MAVENUPLOAD-2758 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2758 Project: Maven Upload Requests Issue Type: Wish Reporter: André Fabbro I'm a developer in Magja, please upload! Its my first time here, hope everything its ok! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2758) Upload request for Magja
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215228#action_215228 ] Dan Tran commented on MAVENUPLOAD-2758: --- you will need to fix your pom.xml since it has snapshot best if you register with Sonatype to deploy your artifact there Upload request for Magja Key: MAVENUPLOAD-2758 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2758 Project: Maven Upload Requests Issue Type: Wish Reporter: André Fabbro I'm a developer in Magja, please upload! Its my first time here, hope everything its ok! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4599) Provide a way to create virtual artifacts out of plain .jar file.
[ http://jira.codehaus.org/browse/MNG-4599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215229#action_215229 ] Paul Benedict commented on MNG-4599: Ondrej, I think you are missing the point. Maven is a system thus there is a systematic way of doing things. You are proposing alternatives, yes, but to the detriment of the benefits which the system is intended to bring. Your opinions are not necessarily wrong; just not how things should be done with Maven. Provide a way to create virtual artifacts out of plain .jar file. --- Key: MNG-4599 URL: http://jira.codehaus.org/browse/MNG-4599 Project: Maven 2 3 Issue Type: Improvement Reporter: Ondrej Zizka Assignee: Brett Porter During the time I have been using Maven, I have come across numerous cases when I desperately needed to turn a simple .jar file into a dependency. Currently, this involves installing it properly to the repository first, and only then it can be used. I suggest to introduce some construct which would take a list of .jar files and turn them into dependencies in the sense they would be added to the classpaths, could be used for WAR overlays, etc. Of course, they would not have any transitional dependencies. dependencyManagement jarPaths jarPath../../releases/50GAAS/jboss-as/common/lib/jarPath /jarPaths ... /dependencyManagement This would greately improve Maven's openness to non-mavenized world, and usability in cases when you really get a plain .jar/.war/.ear/... before every build cycle. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-523) ReleaseUtil throws java.lang.StringIndexOutOfBoundsException: String index out of range: -1
[
http://jira.codehaus.org/browse/MRELEASE-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215240#action_215240
]
Jeff Jensen commented on MRELEASE-523:
--
Me too. Trying to release multi-module (parent with 2 modules and all 3 in
sibling dirs) w/ 2.0 on Win 7 using cmd.
ReleaseUtil throws java.lang.StringIndexOutOfBoundsException: String index
out of range: -1
-
Key: MRELEASE-523
URL: http://jira.codehaus.org/browse/MRELEASE-523
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.0
Environment: Windows XP, Maven 2.2.1
Reporter: Ulrich Hofstötter
Attachments: log.txt
Hello,
i have an issue using the maven release plugin 2.0, previous versions did not
have this issue.
In a multimodule project, release:prepare exits with the attached stack trace.
After a litte debugging, i found out that in ReleaseUtil, line 188
String dir = FileUtils.normalize( p.getBasedir().getPath().replace( '\\', '/'
) );
returns c:\... for the parent module, but C:\... for the first submodule.
So in line 202
basedir = StringUtils.getCommonPrefix( new String[]{dir, basedir} );
results in an empty String, which leads to the exception in line 206.
I will try to compose a simple example as soon as possible.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2758) Upload request for Magja
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=215242#action_215242 ] André Fabbro commented on MAVENUPLOAD-2758: --- Sorry Dan, I am new in maven and sometimes be little confuse with version conventions yet, it's my first open source project! Follow the new dist with pom fixed: http://magja.googlecode.com/files/magja-0.0.1-bundle.jar I just did the steps in maven guide to upload (http://maven.apache.org/guides/mini/guide-central-repository-upload.html) and didn't know about Sonatype, must I follow these steps: http://nexus.sonatype.org/oss-repository-hosting.html ?? Thanks a lot for help! Upload request for Magja Key: MAVENUPLOAD-2758 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2758 Project: Maven Upload Requests Issue Type: Wish Reporter: André Fabbro I'm a developer in Magja, please upload! Its my first time here, hope everything its ok! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
