[jira] Commented: (MNG-2805) Provide mechanism for suppressing inherited/injected/mapped mojo binding
[ http://jira.codehaus.org/browse/MNG-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=199183#action_199183 ] Aleksander Adamowski commented on MNG-2805: --- See also this thread: http://markmail.org/message/xbbmieckqt4ayd75 Provide mechanism for suppressing inherited/injected/mapped mojo binding Key: MNG-2805 URL: http://jira.codehaus.org/browse/MNG-2805 Project: Maven 2 Issue Type: New Feature Components: POM Affects Versions: 2.0.4 Reporter: John Casey Fix For: 3.x In some cases, a mojo should be suppressed from the build process. If this mojo binding comes from a parent POM or a lifecycle mapping, it's not possible to simply comment out that mojo binding. Currently this sort of functionality is left to the individual plugins to implement as parameters that cause each mojo to bow out. This use case is common enough in large development environments (for addressing the 80% with no customization, but allowing the remaining 20% the control to use the same parent POM with subtractions) to warrant a built-in suppression/disabling functionality. Suppression should be available by plugin or by plugin-execution. To suppress bindings from the packaging-mapping, the default executionId 'default' can be used. -- 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: (MCHECKSTYLE-105) Update to Checkstyle 5.0
[ http://jira.codehaus.org/browse/MCHECKSTYLE-105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=179125#action_179125 ] Aleksander Adamowski commented on MCHECKSTYLE-105: -- So when are 2.4 snapshots hitting the central repository? This whole deal with 2.3-SNAPSHOT moving to Checkstyle 5.0 with version maven-checkstyle-plugin-2.3-20090518.081942-2, then going back to Checkstyle 4.4 in maven-checkstyle-plugin-2.3-20090531.103812-3 got me really confused. I'd like an artifact version that uses a concrete version of Checkstyle and doesn't jump between CS 4 and 5 forth and back... Update to Checkstyle 5.0 Key: MCHECKSTYLE-105 URL: http://jira.codehaus.org/browse/MCHECKSTYLE-105 Project: Maven 2.x Checkstyle Plugin Issue Type: Improvement Affects Versions: 2.2 Reporter: Felix Röthenbacher Assignee: nicolas de loof Fix For: 2.4 Attachments: patch.diff, update-to-5.0beta2.patch Checkstyle 5.0-beta01 adds support for generics, etc. See http://checkstyle.sourceforge.net/5.x/releasenotes.html for a list of new features. Note: Prerequisite is that checkstyle-all jar, version 5.0-beta01 is available from a public Maven repository. Patch updates plugin to changed API / implementation. -- 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-307) Site generation broken with multi-module property inheritence
[
http://jira.codehaus.org/browse/MSITE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=172284#action_172284
]
Aleksander Adamowski commented on MSITE-307:
Doron, Thomas, I've opened MSITE-399 that covers site plugin getting the module
artifacts from the repository.
It would be nice iy you could provide a sample testcase project for MSITE-399.
Site generation broken with multi-module property inheritence
-
Key: MSITE-307
URL: http://jira.codehaus.org/browse/MSITE-307
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: inheritance
Affects Versions: 2.0-beta-6
Environment: Ubuntu 7.10, Maven 2.0.8
Reporter: Eric Ryan
Attachments: module_project.zip, mvn_output.txt
Maven2 site plugin inheritence
I have a multi-module project with the following directory structure:
my-app
|
|---my-client-ui
| |
| |---pom.xml
|
|---my-core
| |
| |---pom.xml
|
|---my-common
| |
| |---pom.xml
|
|---pom.xml
I define properties such as ${myVersion}, ${myArtifactId}, ${myGroupId} in
the parent pom. These properties are used by the child poms to resolve the
parent pom (they are used in the parent tags). These properties are
inherited by the children (as expected) when running goals such as clean,
package, or install.
I start to see problems when I try to use the site plugin. I first run the
install goal to install my project's jars and poms into my local
repo(~/.m2/repository/). I then verify that the jars and poms are in my
local repo. When I try to run the site plugin it seems as though maven is
unable to interpret the properties defined in the parent pom. I receive the
following output for each module:
[INFO]
[INFO] Building my-client-ui
[INFO]task-segment: [site]
[INFO]
[INFO] [site:site]
Downloading:
http://repo1.maven.org/maven2/${myGroupId}/${myArtifactId}/${myVersion}/${myArtifactId}-${myVersion}.pom
[WARNING] Unable to load parent project from repository: Failed to validate
POM for project ${myGroupId}:${myArtifactId} at Artifact
[${myGroupId}:${myArtifactId}:pom:${myVersion}]
[INFO] Generating Continuous Integration report...
I've tried using site:deploy, site:run, and site:stage. In all cases I
recieve a sucessful build, but all sites generated contain broken links.
(Note. parent pom's distributionManagement site url=file:///home/eric/tmp)
When using site:deploy, there are two issues with the site. The first is
that none of the modules are listed for the project on the left hand side of
the screen. The second is that when I go to the Dependence Convergence
section, the links to my project's modules are broken. In example, the link
to my-client-ui incorrectly points to http://www.mycompany.com/my-client-ui
when it is in fact located at file:///home/eric/tmp/my-client-ui (Note.
http://www.mycompany.com is defined in the parent pom as the project's url).
site:run demonstrates the same problems as site:deploy.
When using site:stage -DstagingDirectory=/home/eric/tmp, there are again two
issues w/ the site. The first is the same, none of the modules are listed on
the left hand side of the screen. The second is also the same, except that
the links in the Dependency Convergence section now point to
file:///home/eric/localhost/home/eric/tmp/my-client-ui. This is incorrect
because the files are actually located at
file:///home/eric/tmp/localhost/home/eric/tmp/my-client-ui. It is missing
the tmp directory in the url string.
The only way I've been able to get the modules to be displayed on the left
hand side of the screen is using mvn -N site site:deploy. In this case, the
links point to the correct place (file:///home/eric/tmp/my-client-ui), but
the submodule's sites are never build because of the -N (non-recursive) flag.
Another thing to note is that the Dependency Convergence section is totally
missing from this site.
The only way I've been able to build a site with links that resolve properly
is if I remove all instances of properties in all of my poms and replace them
with hard coded values. In this case, the links for the modules do appear on
the left hand side of the screen. The downfall to this approach is that the
links in the Dependency Convergence section now point to
http://www.mycompany.com/my-client-ui.
From my discussion with others on the Maven mailing list, it seems as though
some other users are experiencing this same issue with site property
inheritence.
--
This message is automatically generated by JIRA.
-
If you think it was sent
[jira] Created: (MSITE-399) In a multi-module project, site plugin tries to get current project's artifacts from local repository (which may not be installed yet) even if relative paths are correctly
In a multi-module project, site plugin tries to get current project's artifacts from local repository (which may not be installed yet) even if relative paths are correctly set --- Key: MSITE-399 URL: http://jira.codehaus.org/browse/MSITE-399 Project: Maven 2.x Site Plugin Issue Type: Bug Reporter: Aleksander Adamowski As reported in MISTE-307 by distinct people: http://jira.codehaus.org/browse/MSITE-307?focusedCommentId=138004page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_138004 http://jira.codehaus.org/browse/MSITE-307?focusedCommentId=138503page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_138503 The problem is that the site plugin tries to get artifacts of the current multi-module project from the repository instead of using the configured inter-module relative paths, which may lead to stale data being used (artifacts from the previous build) or even build errors (if the artifact's didn't get installed yet). -- 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-307) Site generation broken with multi-module property inheritence
[
http://jira.codehaus.org/browse/MSITE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=171671#action_171671
]
Aleksander Adamowski commented on MSITE-307:
Hamid, did you open a new JIRA issue on problem 1) ? What's its number?
Site generation broken with multi-module property inheritence
-
Key: MSITE-307
URL: http://jira.codehaus.org/browse/MSITE-307
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: inheritance
Affects Versions: 2.0-beta-6
Environment: Ubuntu 7.10, Maven 2.0.8
Reporter: Eric Ryan
Attachments: module_project.zip, mvn_output.txt
Maven2 site plugin inheritence
I have a multi-module project with the following directory structure:
my-app
|
|---my-client-ui
| |
| |---pom.xml
|
|---my-core
| |
| |---pom.xml
|
|---my-common
| |
| |---pom.xml
|
|---pom.xml
I define properties such as ${myVersion}, ${myArtifactId}, ${myGroupId} in
the parent pom. These properties are used by the child poms to resolve the
parent pom (they are used in the parent tags). These properties are
inherited by the children (as expected) when running goals such as clean,
package, or install.
I start to see problems when I try to use the site plugin. I first run the
install goal to install my project's jars and poms into my local
repo(~/.m2/repository/). I then verify that the jars and poms are in my
local repo. When I try to run the site plugin it seems as though maven is
unable to interpret the properties defined in the parent pom. I receive the
following output for each module:
[INFO]
[INFO] Building my-client-ui
[INFO]task-segment: [site]
[INFO]
[INFO] [site:site]
Downloading:
http://repo1.maven.org/maven2/${myGroupId}/${myArtifactId}/${myVersion}/${myArtifactId}-${myVersion}.pom
[WARNING] Unable to load parent project from repository: Failed to validate
POM for project ${myGroupId}:${myArtifactId} at Artifact
[${myGroupId}:${myArtifactId}:pom:${myVersion}]
[INFO] Generating Continuous Integration report...
I've tried using site:deploy, site:run, and site:stage. In all cases I
recieve a sucessful build, but all sites generated contain broken links.
(Note. parent pom's distributionManagement site url=file:///home/eric/tmp)
When using site:deploy, there are two issues with the site. The first is
that none of the modules are listed for the project on the left hand side of
the screen. The second is that when I go to the Dependence Convergence
section, the links to my project's modules are broken. In example, the link
to my-client-ui incorrectly points to http://www.mycompany.com/my-client-ui
when it is in fact located at file:///home/eric/tmp/my-client-ui (Note.
http://www.mycompany.com is defined in the parent pom as the project's url).
site:run demonstrates the same problems as site:deploy.
When using site:stage -DstagingDirectory=/home/eric/tmp, there are again two
issues w/ the site. The first is the same, none of the modules are listed on
the left hand side of the screen. The second is also the same, except that
the links in the Dependency Convergence section now point to
file:///home/eric/localhost/home/eric/tmp/my-client-ui. This is incorrect
because the files are actually located at
file:///home/eric/tmp/localhost/home/eric/tmp/my-client-ui. It is missing
the tmp directory in the url string.
The only way I've been able to get the modules to be displayed on the left
hand side of the screen is using mvn -N site site:deploy. In this case, the
links point to the correct place (file:///home/eric/tmp/my-client-ui), but
the submodule's sites are never build because of the -N (non-recursive) flag.
Another thing to note is that the Dependency Convergence section is totally
missing from this site.
The only way I've been able to build a site with links that resolve properly
is if I remove all instances of properties in all of my poms and replace them
with hard coded values. In this case, the links for the modules do appear on
the left hand side of the screen. The downfall to this approach is that the
links in the Dependency Convergence section now point to
http://www.mycompany.com/my-client-ui.
From my discussion with others on the Maven mailing list, it seems as though
some other users are experiencing this same issue with site property
inheritence.
--
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] Commented: (MEAR-93) Class-Path entry in MANIFEST.MF not created when using ejb3Module
[ http://jira.codehaus.org/browse/MEAR-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=149345#action_149345 ] Aleksander Adamowski commented on MEAR-93: -- How can one know that it's deprecated if the documentation makes no mention of that: http://maven.apache.org/plugins/maven-ear-plugin/modules.html The EAR Plugin supports additional configurations of the following modules: ejb3Module ejbClientModule ejbModule jarModule (previously know as javaModule and deprecated) parModule rarModule sarModule webModule wsrModule harModule The mention about jarModule being deprecated adds to the confision. There's nothing about deprecation of ejb3Module in the docs. Class-Path entry in MANIFEST.MF not created when using ejb3Module - Key: MEAR-93 URL: http://jira.codehaus.org/browse/MEAR-93 Project: Maven 2.x Ear Plugin Issue Type: Bug Affects Versions: 2.3.1 Environment: Windows XP Reporter: Aleksander Adamowski Assignee: Stephane Nicoll Fix For: 2.3.1 Maven fails to add Class-Path entries to MANIFEST.MF for a module marked as ejb3. E.g.: In EJB module's pom.xml: ... modelVersion4.0.0/modelVersion groupIdsomegroup/groupId artifactIdsomeejb/artifactId packagingejb3/packaging ... build plugins plugin artifactIdmaven-ejb-plugin/artifactId configuration ejbVersion3.0/ejbVersion archive manifest addClasspathtrue/addClasspath /manifest /archive /configuration /plugin /plugins /build ... dependencies dependency groupIdsomegroup/groupId artifactIdsomecomponent/artifactId version0.0.1/version /dependency /dependencies /project In EAR packaging artifact's pom.xml: ... groupIdsomegroup/groupId artifactIdjboss-ear/artifactId version0.0.1/version packagingear/packaging nameSome project's J2EE bundle/name ... dependencies dependency groupIdsomegroup/groupId artifactIdsomeejb/artifactId version0.0.1/version typeejb3/type /dependency dependency groupId somegroup /groupId artifactId somecomponent/artifactId version0.0.1/version /dependency ... modules ejb3Module groupIdsomegroup/groupId artifactIdsomeejb/artifactId /ejb3Module jarModule groupIdsomegroup/groupId artifactIdsomecomponent/artifactId /jarModule /modules jboss version4/version loader-repositorycom.domain.someproject:app=ejb3/loader-repository /jboss ... What's interesting, all works fine if I change all occurences of ejb3 to simple ejb, but leave the ejbVersion3.0/ejbVersion in build section of my EJB artifact. -- 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-93) Class-Path entry in MANIFEST.MF not created when using ejb3Module
[ http://jira.codehaus.org/browse/MEAR-93?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=149353#action_149353 ] Aleksander Adamowski commented on MEAR-93: -- Still, it would be nice to document that ejb3Module depends on deprecated type and is thus deprecated transitively. Class-Path entry in MANIFEST.MF not created when using ejb3Module - Key: MEAR-93 URL: http://jira.codehaus.org/browse/MEAR-93 Project: Maven 2.x Ear Plugin Issue Type: Bug Affects Versions: 2.3.1 Environment: Windows XP Reporter: Aleksander Adamowski Assignee: Stephane Nicoll Fix For: 2.3.1 Maven fails to add Class-Path entries to MANIFEST.MF for a module marked as ejb3. E.g.: In EJB module's pom.xml: ... modelVersion4.0.0/modelVersion groupIdsomegroup/groupId artifactIdsomeejb/artifactId packagingejb3/packaging ... build plugins plugin artifactIdmaven-ejb-plugin/artifactId configuration ejbVersion3.0/ejbVersion archive manifest addClasspathtrue/addClasspath /manifest /archive /configuration /plugin /plugins /build ... dependencies dependency groupIdsomegroup/groupId artifactIdsomecomponent/artifactId version0.0.1/version /dependency /dependencies /project In EAR packaging artifact's pom.xml: ... groupIdsomegroup/groupId artifactIdjboss-ear/artifactId version0.0.1/version packagingear/packaging nameSome project's J2EE bundle/name ... dependencies dependency groupIdsomegroup/groupId artifactIdsomeejb/artifactId version0.0.1/version typeejb3/type /dependency dependency groupId somegroup /groupId artifactId somecomponent/artifactId version0.0.1/version /dependency ... modules ejb3Module groupIdsomegroup/groupId artifactIdsomeejb/artifactId /ejb3Module jarModule groupIdsomegroup/groupId artifactIdsomecomponent/artifactId /jarModule /modules jboss version4/version loader-repositorycom.domain.someproject:app=ejb3/loader-repository /jboss ... What's interesting, all works fine if I change all occurences of ejb3 to simple ejb, but leave the ejbVersion3.0/ejbVersion in build section of my EJB artifact. -- 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: (MEAR-93) Class-Path entry in MANIFEST.MF not created when using ejb3Module
Class-Path entry in MANIFEST.MF not created when using ejb3Module - Key: MEAR-93 URL: http://jira.codehaus.org/browse/MEAR-93 Project: Maven 2.x Ear Plugin Issue Type: Bug Affects Versions: 2.3.1 Environment: Windows XP Reporter: Aleksander Adamowski Maven fails to add Class-Path entries to MANIFEST.MF for a module marked as ejb3. E.g.: In EJB module's pom.xml: ... modelVersion4.0.0/modelVersion groupIdsomegroup/groupId artifactIdsomeejb/artifactId packagingejb3/packaging ... build plugins plugin artifactIdmaven-ejb-plugin/artifactId configuration ejbVersion3.0/ejbVersion archive manifest addClasspathtrue/addClasspath /manifest /archive /configuration /plugin /plugins /build ... dependencies dependency groupIdsomegroup/groupId artifactIdsomecomponent/artifactId version0.0.1/version /dependency /dependencies /project In EAR packaging artifact's pom.xml: ... groupIdsomegroup/groupId artifactIdjboss-ear/artifactId version0.0.1/version packagingear/packaging nameSome project's J2EE bundle/name ... dependencies dependency groupIdsomegroup/groupId artifactIdsomeejb/artifactId version0.0.1/version typeejb3/type /dependency dependency groupId somegroup /groupId artifactId somecomponent/artifactId version0.0.1/version /dependency ... modules ejb3Module groupIdsomegroup/groupId artifactIdsomeejb/artifactId /ejb3Module jarModule groupIdsomegroup/groupId artifactIdsomecomponent/artifactId /jarModule /modules jboss version4/version loader-repositorycom.domain.someproject:app=ejb3/loader-repository /jboss ... What's interesting, all works fine if I change all occurences of ejb3 to simple ejb, but leave the ejbVersion3.0/ejbVersion in build section of my EJB artifact. -- 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
