[jira] Commented: (MEAR-130) maven build hangs when earSourceDirectory is set to /
[ http://jira.codehaus.org/browse/MEAR-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=234297#action_234297 ] Cremers stijn commented on MEAR-130: It works with maven 2.0.9! This is what i'm trying to accomplish: The is my ear project: mvn3-ear/ mvn3-ear/lib/ mvn3-ear/lib/*(all libs) mvn3-ear/META-INF/application.xml mvn3-ear/META-INF/ibm-application-bnd.xmi The ibm-application-bnd.xmi must be included in the with maven generated ear. So this my configuration maven-ear-plugin ... / **/META-INF/ibm-application-bnd.xmi It do not want to scan the whole drive, but just the mvn3-ear project. > 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 / 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] 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
[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 , and . > 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] Commented: (MEAR-92) Add createEarFile property
[ http://jira.codehaus.org/browse/MEAR-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] Issue Comment Edited: (MEAR-92) Add createEarFile property
[ http://jira.codehaus.org/browse/MEAR-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] 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}
org.apache.maven.plugins
maven-ear-plugin
no-version
{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] Closed: (MSITE-500) Warning message about missing report plugin version shows null instead of plugin groupId:aritfactId
[
http://jira.codehaus.org/browse/MSITE-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MSITE-500.
--
Resolution: Fixed
Fix Version/s: 3.0-beta-3
fixed rev 992829
> 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
>Assignee: Olivier Lamy
> Fix For: 3.0-beta-3
>
>
> 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] 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] 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] 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-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] 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 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] 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] 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] 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-tabpanel&focusedCommentId=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] 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] 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] 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] 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] Commented: (MEAR-120) does not work in multi module project
[
http://jira.codehaus.org/browse/MEAR-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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.
> 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:
> so-${pom.artifactId}-${pom.version}
> .
> .
> .
> 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] 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] 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 / 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] 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
