[jira] Created: (MREPOSITORY-25) bundle-create creates jar making a preceding gpg:sign step invalid
bundle-create creates jar making a preceding gpg:sign step invalid
--
Key: MREPOSITORY-25
URL: http://jira.codehaus.org/browse/MREPOSITORY-25
Project: Maven 2.x Repository Plugin
Issue Type: Bug
Affects Versions: 2.3.1
Environment: Ubuntu 10.4, Sun Java 1.6.0_20, Maven 2.2.1
Reporter: Anthony Whitford
Despite following instructions found here:
https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+Maven+Central
I ran into a problem uploading the bundle to Sonatype's Staging area.
Specifically, I received an *Invalid Signature* error for the main jar
artifact.
Sure enough, I ran the following: {noformat}gpg --verify foo.jar.asc{noformat}
and it confirmed that the signature was BAD.
Upon further investigation, it would seem that the problem is that the
repository:bundle-create goal is recreating the jar file, so the
command:{noformat}mvn source:jar javadoc:jar package gpg:sign
repository:bundle-create -Dgpg.passphrase=xx{noformat}
seems to be creating the jar, signing it, and then creating the jar again --
resulting in an invalid gpg signature for the jar.
Note that my pom does not include a gpg signing step -- that is why it is part
of the command line. My guess is that configuring the maven-gpg-plugin in the
project pom may make this work -- but I did not have the luxury of being able
to do that this time.
The bundle-create goal needs to not recreate the jar file -- just make the
bundle. Or clarify the documentation.
--
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: (MEAR-130) maven build hangs when earSourceDirectory is set to /
[ http://jira.codehaus.org/browse/MEAR-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MEAR-130. Resolution: Not A Bug Like I said, you're trying to copy your whole drive ... maven build hangs when earSourceDirectory is set to / - Key: MEAR-130 URL: http://jira.codehaus.org/browse/MEAR-130 Project: Maven 2.x Ear Plugin Issue Type: Bug Affects Versions: 2.4.1 Environment: apache-maven-3.0-beta-2 Reporter: Cremers stijn Assignee: Stephane Nicoll Priority: Critical Fix For: 2.4.3 Attachments: DEV_V01.00.00.zip, maven.log When building a maven project with apache-maven-3.0-beta-2, the build hangs on [INFO] Copy ear sources to. This is only when the earSourceDirectory//earSourceDirectory is specified. A log file with the maven output is attached -- 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] Work started: (MEAR-116) different build results from single module build and from reactor build
[ http://jira.codehaus.org/browse/MEAR-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MEAR-116 started by Stephane Nicoll. different build results from single module build and from reactor build --- Key: MEAR-116 URL: http://jira.codehaus.org/browse/MEAR-116 Project: Maven 2.x Ear Plugin Issue Type: Bug Affects Versions: 2.4 Environment: maven 2.2.0 Reporter: Milos Kleint Assignee: Stephane Nicoll Priority: Critical Fix For: 2.4.3 Attachments: ear116.zip, MEAR-116.patch attached is a sample application as generated by netbeans 6.8 (using archetypes from org.codehaus.mojo.archetypes) a simple ear+ejb+war multiproject. when building everything together from the root pom, I get this output: [ear:ear] Copying artifact[ejb:org.kleint:samplejavaee6-ejb:1.0-SNAPSHOT] to[samplejavaee6-ejb.jar] Copying artifact[war:org.kleint:samplejavaee6-web:1.0-SNAPSHOT] to[samplejavaee6-web.war] and the war and ejb artifacts are included with names not including version. However if I later do a mvn clean install on the ear project, I get this output: [ear:ear] Copying artifact[ejb:org.kleint:samplejavaee6-ejb:1.0-SNAPSHOT] to[samplejavaee6-ejb-1.0-SNAPSHOT.jar] Copying artifact[war:org.kleint:samplejavaee6-web:1.0-SNAPSHOT] to[samplejavaee6-web-1.0-SNAPSHOT.war] and the war/ejb artifacts get a version in the name. This sounds like it has to do with the finalname being resolved differently in single module build and in reactor build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MEAR-120) finalName does not work in multi module project
[
http://jira.codehaus.org/browse/MEAR-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234246#action_234246
]
Stephane Nicoll commented on MEAR-120:
--
I am confused by your report. What is not working exactly? The generate EAR
does not have the proper final name or the modules bundled in the EAR? If you
are talking about the modules bundled in the EAR, it's just not going to work,
finalName is not honored outside the module (look at the file name when you
deploy it in the repository).
Please attach a sample project that demonstrates your issue.
finalName does not work in multi module project
-
Key: MEAR-120
URL: http://jira.codehaus.org/browse/MEAR-120
Project: Maven 2.x Ear Plugin
Issue Type: Bug
Affects Versions: 2.3.1
Environment: OS name: linux version: 2.6.5-7.244-smp arch: i386
Family: unix
Reporter: Deepak Chavan
I have given finalName for my projects but it is not working for some
modules. Following tag has been added in root pom.xml of my project:
buildfinalNameso-${pom.artifactId}-${pom.version}/finalName
.
.
./build
According to this it should append prefix so- for all modules but it is not
working as expected.
maven-ear-plugin version : 2.3.1
maven : maven 2.0.8
Thanks,
Deepak
--
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: (MEAR-124) transitive ejb modules not added to application.xml in correct deployment order for Jboss 4.2.x
[ http://jira.codehaus.org/browse/MEAR-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MEAR-124. Resolution: Not A Bug Assignee: Stephane Nicoll No feedback from user. transitive ejb modules not added to application.xml in correct deployment order for Jboss 4.2.x --- Key: MEAR-124 URL: http://jira.codehaus.org/browse/MEAR-124 Project: Maven 2.x Ear Plugin Issue Type: Bug Affects Versions: 2.4.1 Reporter: Ulrich Roell Assignee: Stephane Nicoll EJB module entries should be added according to their dependencies. Assume you have a multi-module maven project with two EJB modules EJB_A, EJB_B and one EAR module. EJB_A depends on EJB_B and only EJB_A is declared as a dependency inside the EAR module's POM. So if you want to use module-order = strict, EJB_B must be added before EJB_A to your application.xml. Otherwise is it very likely that the JBoss deployment will fail! A workaround is to declare both EJB_A and EJB_B manually add EJB_B before EJB_A. But with Maven's dependency mechanism this could be done dynamically. -- 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: (MEAR-116) different build results from single module build and from reactor build
[ http://jira.codehaus.org/browse/MEAR-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MEAR-116. Resolution: Fixed Fixed. I just deployed a snapshot of 2.4.3 for you to try. Your sample project works fine now. different build results from single module build and from reactor build --- Key: MEAR-116 URL: http://jira.codehaus.org/browse/MEAR-116 Project: Maven 2.x Ear Plugin Issue Type: Bug Affects Versions: 2.4 Environment: maven 2.2.0 Reporter: Milos Kleint Assignee: Stephane Nicoll Priority: Critical Fix For: 2.4.3 Attachments: ear116.zip, MEAR-116.patch attached is a sample application as generated by netbeans 6.8 (using archetypes from org.codehaus.mojo.archetypes) a simple ear+ejb+war multiproject. when building everything together from the root pom, I get this output: [ear:ear] Copying artifact[ejb:org.kleint:samplejavaee6-ejb:1.0-SNAPSHOT] to[samplejavaee6-ejb.jar] Copying artifact[war:org.kleint:samplejavaee6-web:1.0-SNAPSHOT] to[samplejavaee6-web.war] and the war and ejb artifacts are included with names not including version. However if I later do a mvn clean install on the ear project, I get this output: [ear:ear] Copying artifact[ejb:org.kleint:samplejavaee6-ejb:1.0-SNAPSHOT] to[samplejavaee6-ejb-1.0-SNAPSHOT.jar] Copying artifact[war:org.kleint:samplejavaee6-web:1.0-SNAPSHOT] to[samplejavaee6-web-1.0-SNAPSHOT.war] and the war/ejb artifacts get a version in the name. This sounds like it has to do with the finalname being resolved differently in single module build and in reactor build. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MEAR-35) Generate id for modules in application.xml
[ http://jira.codehaus.org/browse/MEAR-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MEAR-35 started by Stephane Nicoll. Generate id for modules in application.xml -- Key: MEAR-35 URL: http://jira.codehaus.org/browse/MEAR-35 Project: Maven 2.x Ear Plugin Issue Type: Improvement Reporter: Manikandan Balasubramanian Assignee: Stephane Nicoll Priority: Minor Fix For: 2.4.3 Attachments: ear-module-id.patch, MEAR-35-maven-ear-plugin-2.patch, MEAR-35-maven-ear-plugin.patch When the ear plugin generates application.xml, it should generate an id with each module. This id is according to application.xml schema. This would help eclipse plugin to generate correct eclipse metedata. -- 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: (MEAR-35) Generate id for modules in application.xml
[ http://jira.codehaus.org/browse/MEAR-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MEAR-35: Fix Version/s: (was: 2.5) 2.4.3 Generate id for modules in application.xml -- Key: MEAR-35 URL: http://jira.codehaus.org/browse/MEAR-35 Project: Maven 2.x Ear Plugin Issue Type: Improvement Reporter: Manikandan Balasubramanian Assignee: Stephane Nicoll Priority: Minor Fix For: 2.4.3 Attachments: ear-module-id.patch, MEAR-35-maven-ear-plugin-2.patch, MEAR-35-maven-ear-plugin.patch When the ear plugin generates application.xml, it should generate an id with each module. This id is according to application.xml schema. This would help eclipse plugin to generate correct eclipse metedata. -- 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: (MREPOSITORY-25) bundle-create creates jar making a preceding gpg:sign step invalid
[
http://jira.codehaus.org/browse/MREPOSITORY-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234254#action_234254
]
Dennis Lundberg commented on MREPOSITORY-25:
It seems that the docs at Sonatype are wrong.
From the plugin doc:
bq. repository:bundle-create Invokes the execution of the lifecycle phase
package prior to executing itself.
repository:bundle-pack might be a better choice for you.
bundle-create creates jar making a preceding gpg:sign step invalid
--
Key: MREPOSITORY-25
URL: http://jira.codehaus.org/browse/MREPOSITORY-25
Project: Maven 2.x Repository Plugin
Issue Type: Bug
Affects Versions: 2.3.1
Environment: Ubuntu 10.4, Sun Java 1.6.0_20, Maven 2.2.1
Reporter: Anthony Whitford
Despite following instructions found here:
https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+Maven+Central
I ran into a problem uploading the bundle to Sonatype's Staging area.
Specifically, I received an *Invalid Signature* error for the main jar
artifact.
Sure enough, I ran the following: {noformat}gpg --verify
foo.jar.asc{noformat}
and it confirmed that the signature was BAD.
Upon further investigation, it would seem that the problem is that the
repository:bundle-create goal is recreating the jar file, so the
command:{noformat}mvn source:jar javadoc:jar package gpg:sign
repository:bundle-create -Dgpg.passphrase=xx{noformat}
seems to be creating the jar, signing it, and then creating the jar again --
resulting in an invalid gpg signature for the jar.
Note that my pom does not include a gpg signing step -- that is why it is
part of the command line. My guess is that configuring the maven-gpg-plugin
in the project pom may make this work -- but I did not have the luxury of
being able to do that this time.
The bundle-create goal needs to not recreate the jar file -- just make the
bundle. Or clarify the documentation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSITE-500) Warning message about missing report plugin version shows null instead of plugin groupId:aritfactId
Warning message about missing report plugin version shows null instead of
plugin groupId:aritfactId
---
Key: MSITE-500
URL: http://jira.codehaus.org/browse/MSITE-500
Project: Maven 2.x Site Plugin
Issue Type: Bug
Affects Versions: 3.0-beta-2
Reporter: Dennis Lundberg
Without debugging enabled I get this:
{noformat}
[WARNING] Report plugin null has an empty version.
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten
the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
{noformat}
With debugging enabled (-X flag used) I get
{noformat}
[WARNING] Report plugin
org.apache.maven.plugins:maven-project-info-reports-plugin has an empty version.
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten
the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
{noformat}
--
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: (MEAR-35) Generate id for modules in application.xml
[ http://jira.codehaus.org/browse/MEAR-35?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MEAR-35. --- Resolution: Fixed Well, this took a long time but this request will be available in 2.4.3. Thanks for the folks who provided a patch. I used the one from Matt Jensen, adding the ability to enable/disable the moduleId generation. I also added documentation and tests. Generate id for modules in application.xml -- Key: MEAR-35 URL: http://jira.codehaus.org/browse/MEAR-35 Project: Maven 2.x Ear Plugin Issue Type: Improvement Reporter: Manikandan Balasubramanian Assignee: Stephane Nicoll Priority: Minor Fix For: 2.4.3 Attachments: ear-module-id.patch, MEAR-35-maven-ear-plugin-2.patch, MEAR-35-maven-ear-plugin.patch When the ear plugin generates application.xml, it should generate an id with each module. This id is according to application.xml schema. This would help eclipse plugin to generate correct eclipse metedata. -- 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: (MEAR-129) ejb3Module broken and deprecated but not indicated as such in website documentation
[ http://jira.codehaus.org/browse/MEAR-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MEAR-129. Resolution: Not A Bug Assignee: Stephane Nicoll No response from user. ejb3Module broken and deprecated but not indicated as such in website documentation --- Key: MEAR-129 URL: http://jira.codehaus.org/browse/MEAR-129 Project: Maven 2.x Ear Plugin Issue Type: Improvement Reporter: David Wallace Croft Assignee: Stephane Nicoll EAR configuration ejb3Module is listed in documentation as though it were still working: http://maven.apache.org/plugins/maven-ear-plugin/modules.html#ejb3Module User gets Artifact[ejb3:*.*.*] is not a dependency of the project. error. User, being new to Maven, spends a couple of hours trying to fix the error by tweaking his other POMs to set dependency type to EJB3, etc. User turns to Google. User discovers that ejb3Module is broken and deprecated and has been for over a year or two: http://www.5341.com/msg/224841.html http://jira.codehaus.org/browse/MEAR-40 (see comments) -- 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: (MEAR-128) Support for Java EE 6 application.xml
[ http://jira.codehaus.org/browse/MEAR-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MEAR-128: - Fix Version/s: 2.5 Support for Java EE 6 application.xml - Key: MEAR-128 URL: http://jira.codehaus.org/browse/MEAR-128 Project: Maven 2.x Ear Plugin Issue Type: Improvement Reporter: Peter Major Assignee: Stephane Nicoll Fix For: 2.5 Currently the Java EE 6 is not supported, and the generated XML's are using Java EE 5 namespaces and elements. For example the EE 6 has a new element: application-name, which could be useful for Global JNDI naming. -- 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: (MEAR-113) The default contextRoot should match the default bundleFileName
[ http://jira.codehaus.org/browse/MEAR-113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MEAR-113: - Fix Version/s: 2.5 The default contextRoot should match the default bundleFileName --- Key: MEAR-113 URL: http://jira.codehaus.org/browse/MEAR-113 Project: Maven 2.x Ear Plugin Issue Type: Improvement Affects Versions: 2.3.2 Reporter: Michael Semb Wever Fix For: 2.5 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. - 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: (MEAR-98) Add an implementation of FileNameMapping that allows to remove version of artefact in the ear.
[
http://jira.codehaus.org/browse/MEAR-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll updated MEAR-98:
Fix Version/s: 2.4.3
Add an implementation of FileNameMapping that allows to remove version of
artefact in the ear.
--
Key: MEAR-98
URL: http://jira.codehaus.org/browse/MEAR-98
Project: Maven 2.x Ear Plugin
Issue Type: Improvement
Affects Versions: 2.3.1
Environment: Any
Reporter: Benjamin LERMAN
Fix For: 2.4.3
Attachments: 02-patch-simplified-name-mapping.patch,
02-patch-simplified-name-mapping.patch
Right now there is 2 implementations of FileNameMapping, one that bundle
artifact in the form ${artifactId}{$dashClassifider?}-${version}.${type} and
one in the form
${groupId}-${artifactId}{$dashClassifider?}-${version}.${type}. This add a
new FileNameMapping that bundle artifact in the form
${artifactId}{$dashClassifider?}.${type} (it removes the version information).
--
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] Work started: (MEAR-98) Add an implementation of FileNameMapping that allows to remove version of artefact in the ear.
[
http://jira.codehaus.org/browse/MEAR-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MEAR-98 started by Stephane Nicoll.
Add an implementation of FileNameMapping that allows to remove version of
artefact in the ear.
--
Key: MEAR-98
URL: http://jira.codehaus.org/browse/MEAR-98
Project: Maven 2.x Ear Plugin
Issue Type: Improvement
Affects Versions: 2.3.1
Environment: Any
Reporter: Benjamin LERMAN
Assignee: Stephane Nicoll
Fix For: 2.4.3
Attachments: 02-patch-simplified-name-mapping.patch,
02-patch-simplified-name-mapping.patch
Right now there is 2 implementations of FileNameMapping, one that bundle
artifact in the form ${artifactId}{$dashClassifider?}-${version}.${type} and
one in the form
${groupId}-${artifactId}{$dashClassifider?}-${version}.${type}. This add a
new FileNameMapping that bundle artifact in the form
${artifactId}{$dashClassifider?}.${type} (it removes the version information).
--
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: (MEAR-98) Add an implementation of FileNameMapping that allows to remove version of artefact in the ear.
[
http://jira.codehaus.org/browse/MEAR-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephane Nicoll closed MEAR-98.
---
Resolution: Fixed
Used your patch, thanks. Also added a no-version entry in the mapping
registry so that you can do something like:
{code:xml}
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-ear-plugin/artifactId
configuration
fileNameMappingno-version/fileNameMapping
/configuration
/plugin
{code}
Add an implementation of FileNameMapping that allows to remove version of
artefact in the ear.
--
Key: MEAR-98
URL: http://jira.codehaus.org/browse/MEAR-98
Project: Maven 2.x Ear Plugin
Issue Type: Improvement
Affects Versions: 2.3.1
Environment: Any
Reporter: Benjamin LERMAN
Assignee: Stephane Nicoll
Fix For: 2.4.3
Attachments: 02-patch-simplified-name-mapping.patch,
02-patch-simplified-name-mapping.patch
Right now there is 2 implementations of FileNameMapping, one that bundle
artifact in the form ${artifactId}{$dashClassifider?}-${version}.${type} and
one in the form
${groupId}-${artifactId}{$dashClassifider?}-${version}.${type}. This add a
new FileNameMapping that bundle artifact in the form
${artifactId}{$dashClassifider?}.${type} (it removes the version information).
--
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: (MEAR-92) Add createEarFile property
[ http://jira.codehaus.org/browse/MEAR-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234265#action_234265 ] Stephane Nicoll edited comment on MEAR-92 at 9/5/10 1:25 PM: - It's called prepare-package. We should consider changing the lifecycle, indeed. was (Author: sni): It's called prepared-package. We should consider changing the lifecycle, indeed. Add createEarFile property -- Key: MEAR-92 URL: http://jira.codehaus.org/browse/MEAR-92 Project: Maven 2.x Ear Plugin Issue Type: New Feature Affects Versions: 2.3.2 Reporter: Kem Elbrader Attachments: EarMojo.java, EarMojo.patch When directory deploying an ear project often a majority of the time is spent unnecessarily building the ear archive i.e. Building jar: Since it isn't needed during development it'd be nice if the ear plugin could be configured to stop short of actually building the archive file. The attahced patch adds a createEarFile property to the EarMojo class to control whether to create the .ear file archive or not. All changes in this patch are in the EarMojo.java file which is also attached. -- 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: (MEAR-92) Add createEarFile property
[ http://jira.codehaus.org/browse/MEAR-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=234265#action_234265 ] Stephane Nicoll commented on MEAR-92: - It's called prepared-package. We should consider changing the lifecycle, indeed. Add createEarFile property -- Key: MEAR-92 URL: http://jira.codehaus.org/browse/MEAR-92 Project: Maven 2.x Ear Plugin Issue Type: New Feature Affects Versions: 2.3.2 Reporter: Kem Elbrader Attachments: EarMojo.java, EarMojo.patch When directory deploying an ear project often a majority of the time is spent unnecessarily building the ear archive i.e. Building jar: Since it isn't needed during development it'd be nice if the ear plugin could be configured to stop short of actually building the archive file. The attahced patch adds a createEarFile property to the EarMojo class to control whether to create the .ear file archive or not. All changes in this patch are in the EarMojo.java file which is also attached. -- 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: (MEAR-91) Include files in the ear file with fileset
[ http://jira.codehaus.org/browse/MEAR-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MEAR-91. --- Resolution: Won't Fix Assignee: Stephane Nicoll I don't see what this feature brings except build hacks. Until you provide a patch that demonstrates how this can be used, I am going to close this one. Include files in the ear file with fileset -- Key: MEAR-91 URL: http://jira.codehaus.org/browse/MEAR-91 Project: Maven 2.x Ear Plugin Issue Type: New Feature Affects Versions: 2.3.2 Environment: all Reporter: Petar Tahchiev Assignee: Stephane Nicoll I want it to be possible to include files(modules) in the ear file with a fileset, not only by specifying groupID, artifactID and version. Because this way I can include some files as modules in the ear, even if they are not present in the repositor. Thanks a lot. -- 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-574) GitCheckInCommand fails on empty changed files list
GitCheckInCommand fails on empty changed files list --- Key: SCM-574 URL: http://jira.codehaus.org/browse/SCM-574 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.4 Reporter: Andrey Paramonov Attachments: GitCheckInCommand.patch If there is no file in the Git index git checkin returns exit code 1, which causes failed CheckInScmResult. Because of that mvn release:branch always fails for Git repositories (see MRELEASE-579). We shouldn't probably call git checkin if there is nothing to check in. After I applied the attached patch, mvn release:branch succeeded. -- 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
