[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] Created: (SCM-454) GitChangelogCommand doesn't support tag ranges yet
GitChangelogCommand doesn't support tag ranges yet -- Key: SCM-454 URL: http://jira.codehaus.org/browse/SCM-454 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.2 Reporter: Mark Struberg The current GitChangeLogCommand always uses --since and --until parameters for start and end version. Since those parameters may only be used for date ranges, we have to use the [start]..[end] syntax. -- 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-454) GitChangelogCommand doesn't support tag ranges yet
[ http://jira.codehaus.org/browse/SCM-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg updated SCM-454: -- Attachment: SCM-454.patch This patch contains fixes for SCM-454 and also for SCM-453 including test cases. txs 2 Imran Yousuf for providing information and a first patch. GitChangelogCommand doesn't support tag ranges yet -- Key: SCM-454 URL: http://jira.codehaus.org/browse/SCM-454 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.2 Reporter: Mark Struberg Attachments: SCM-454.patch The current GitChangeLogCommand always uses --since and --until parameters for start and end version. Since those parameters may only be used for date ranges, we have to use the [start]..[end] syntax. -- 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: (SCM-453) changelog command doesn't support branches yet
[ http://jira.codehaus.org/browse/SCM-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=171673#action_171673 ] Mark Struberg commented on SCM-453: --- patch has been attached in SCM-454. changelog command doesn't support branches yet -- Key: SCM-453 URL: http://jira.codehaus.org/browse/SCM-453 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.2 Reporter: Mark Struberg GitChangeLogCommand doesn't support branches 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] Updated: (SCM-454) GitChangelogCommand doesn't support tag ranges yet
[ http://jira.codehaus.org/browse/SCM-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-454: - Assignee: Olivier Lamy Fix Version/s: 1.3 GitChangelogCommand doesn't support tag ranges yet -- Key: SCM-454 URL: http://jira.codehaus.org/browse/SCM-454 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.2 Reporter: Mark Struberg Assignee: Olivier Lamy Fix For: 1.3 Attachments: SCM-454.patch The current GitChangeLogCommand always uses --since and --until parameters for start and end version. Since those parameters may only be used for date ranges, we have to use the [start]..[end] syntax. -- 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: (MPIR-136) French properties file reference unexistant unicode char
[ http://jira.codehaus.org/browse/MPIR-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=171676#action_171676 ] Rémy Sanlaville commented on MPIR-136: -- One proposition is to use \u00B4 instead. It's not exactly quote char but it looks like It works with UTF-8 encoding but I don't know for others encoding. French properties file reference unexistant unicode char Key: MPIR-136 URL: http://jira.codehaus.org/browse/MPIR-136 Project: Maven 2.x Project Info Reports Plugin Issue Type: Bug Affects Versions: 2.1 Environment: Any Reporter: Eric Chatellier Priority: Minor French property file (http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-project-info-reports-plugin/src/main/resources/project-info-report_fr.properties) contains unexistant unicode char : \u0092 Should be : ' or \u0027, but test fails with that char -- 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: (MPIR-59) Site generation exception for french language, error with simple quote in translation S'inscrire for mailing list
[
http://jira.codehaus.org/browse/MPIR-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=171677#action_171677
]
Rémy Sanlaville commented on MPIR-59:
-
For information, it does not work with UTF-8 encoding
Cf . [MPIR-136|http://jira.codehaus.org/browse/MPIR-136]
Site generation exception for french language, error with simple quote in
translation S'inscrire for mailing list
Key: MPIR-59
URL: http://jira.codehaus.org/browse/MPIR-59
Project: Maven 2.x Project Info Reports Plugin
Issue Type: Bug
Affects Versions: 2.0.1
Environment: linux Debian sarge
jdk 1.6
maven 2.0.4
Reporter: Benjamin POUSSIN
Assignee: Arnaud Heritier
Priority: Blocker
Fix For: 2.1
Attachments: MPIR-french-translation.patch
When we try to generate site in french localesfr/locales in site plugin
we have exception:
[ERROR] FATAL ERROR
[INFO]
[INFO] Unmatched braces in the pattern in '{S'incrire,
http://lists.labs.libre-entreprise.org/mailman/listinfo/lutinutil-cvscommit}'
[INFO]
[INFO] Trace
java.lang.IllegalArgumentException: Unmatched braces in the pattern.
at
org.apache.maven.reporting.AbstractMavenReportRenderer.applyPattern(AbstractMavenReportRenderer.java:619)
at
org.apache.maven.reporting.AbstractMavenReportRenderer.linkPatternedText(AbstractMavenReportRenderer.java:353)
at
org.apache.maven.reporting.AbstractMavenReportRenderer.tableCell(AbstractMavenReportRenderer.java:213)
at
org.apache.maven.reporting.AbstractMavenReportRenderer.tableCell(AbstractMavenReportRenderer.java:193)
at
org.apache.maven.reporting.AbstractMavenReportRenderer.tableRow(AbstractMavenReportRenderer.java:225)
at
org.apache.maven.report.projectinfo.MailingListsReport$MailingListsRenderer.renderBody(MailingListsReport.java:238)
at
org.apache.maven.reporting.AbstractMavenReportRenderer.render(AbstractMavenReportRenderer.java:65)
at
org.apache.maven.report.projectinfo.MailingListsReport.executeReport(MailingListsReport.java:65)
at
org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:101)
...
in applyPattern some test is done to know if simple quote \' are opened but
this test is not good for some translation as:
report.mailing-lists.column.subscribe = S'incrire
because this become:
{S'incrire,
http://lists.labs.libre-entreprise.org/mailman/listinfo/lutinutil-cvscommit}
and applyPattern method think that quote is nether close.
quick fix is to put two simple quote: S''incrire
but this render two simple quote in html page.
I think applyPattern must be rewritten to correct this problem
--
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-3832) Allow wildcards in dependency exclusions
[
http://jira.codehaus.org/browse/MNG-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=171684#action_171684
]
Vincenzo Vitale commented on MNG-3832:
--
+1
Allow wildcards in dependency exclusions
Key: MNG-3832
URL: http://jira.codehaus.org/browse/MNG-3832
Project: Maven 2
Issue Type: New Feature
Components: Dependencies
Reporter: Paul Gier
Fix For: 2.x
I would like to be able to exclude all transitive dependencies from a certain
dependencies. This is especially useful when depending on an artifact with a
classifier that may not have the same dependencies as the main artifact.
Currently the only way to do this is by excluding each dependency
individually which requires significant effort and is prone to becoming out
of date. The following syntax is one possibility.
Exclude all transitive dependencies
{code}
exclusion
groupId*/groupId
/exclusion
{code}
Exclude transitive dependencies with the groupId org.company
{code}
exclusion
groupIdorg.company/groupId
artifactId*/artifactId
/exclusion
{code}
--
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-4120) Profile activation should be per module
[ http://jira.codehaus.org/browse/MNG-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=171685#action_171685 ] Karsten Tinnefeld commented on MNG-4120: Second try. Profile activation should be per module --- Key: MNG-4120 URL: http://jira.codehaus.org/browse/MNG-4120 Project: Maven 2 Issue Type: Bug Components: Dependencies, POM Affects Versions: 2.0.9 Reporter: Karsten Tinnefeld In a multi-module-project, one might wish to run certain targets dependent on the existance of some file or directory. In a single-module-project, I'd say profilesprofileiddo-if-file-exists/id activationexistssome/special/path/exists/activation plugins!-- my specific configuration --/plugins/profile/profiles This however does not work on a per-module base in a multi-module project, but the profile is (de)activated depending on the situation on the run pom only, and this is not even documented. In my opinion, profile activation should be on a per-module basis. -- 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-4120) Profile activation should be per module
[
http://jira.codehaus.org/browse/MNG-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=171685#action_171685
]
Karsten Tinnefeld edited comment on MNG-4120 at 4/1/09 5:00 AM:
In order to deliver configuration files etc. with the other project artifacts,
I had this defined in a profile attached to my master configuration pom in a
large-scale banking portal project. The idea is that this automatically copies
the project attachments to the target directory whenever src/main/attachments
exists.
plugin
artifactIdmaven-antrun-plugin/artifactId
version1.3/version
executions
execution
idcopy-attachments/id
goals
goalrun/goal
/goals
phaseprocess-resources/phase
configuration
tasks
copy
preservelastmodified=true todir=${project.build.directory}
flatten=true
fileset dir=${basedir}/src/main/attachments
includes=**/* /
regexpmapper from=^(.*)$$
to=${project.artifactId}-${project.version}-\1 /
/copy
/tasks
/configuration
/execution
/executions
dependencies
dependency
groupIdorg.apache.ant/groupId
artifactIdant-nodeps/artifactId
version1.7.1/version
/dependency
/dependencies
/plugin
I would then attach these artifacts (did not yet figure out a generic way for
it) in the concrete projects, e.g. a log4j configuration:
plugins
plugin
artifactIdmaven-antrun-plugin/artifactId
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdbuild-helper-maven-plugin/artifactId
executions
execution
idattach-supplemental/id
goals
goalattach-artifact/goal
/goals
configuration
artifacts
artifact
file
target/${project.artifactId}-${project.version}-log4j.xml
/file
typexml/type
classifierlog4j/classifier
/artifact
/artifacts
/configuration
/execution
/executions
/plugin
/plugins
Hope, this helps.
was (Author: tinne):
Second try.
Profile activation should be per module
---
[jira] Updated: (SCM-445) Extend command coverage of AccuRev provider for use with Continuum and Release Plugin
[ http://jira.codehaus.org/browse/SCM-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Gardner updated SCM-445: -- Attachment: maven-scm-provider-accurev.tar.gz Fixed a couple of Windows bugs and implemented support for the Remove command Extend command coverage of AccuRev provider for use with Continuum and Release Plugin - Key: SCM-445 URL: http://jira.codehaus.org/browse/SCM-445 Project: Maven SCM Issue Type: Improvement Components: maven-scm-provider-accurev Reporter: Grant Gardner Attachments: maven-scm-provider-accurev.tar.gz, maven-scm-provider-accurev.tar.gz Replacement accurev provider with additional commands - Login, Checkout, Update, Add, Changelog, CheckIn, Status, Tag, Export. See site documentation for full coverage Note that the URL syntax is different from the original minimal AccuRev 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] Created: (MECLIPSE-542) Source not found. in debug session with m2eclipse and jetty
Source not found. in debug session with m2eclipse and jetty --- Key: MECLIPSE-542 URL: http://jira.codehaus.org/browse/MECLIPSE-542 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Environment: Version is unknown, my plugin shows Maven Integration for Eclipse 0.9.7.2009020909 I hope Maven 2.x Eclipse Plugin means Maven Integration for Eclipse Reporter: Janning Vygen Attachments: maven-debug-issue.txt Attached is exception log from eclispe, my jetty launch configuration and my debug launch configuration. When debugging source from the project itself is found but not from the Maven Dependencies Source code is available and downloaded. I can open it, set a breakpoint and the breakpoint gets triggered, it opens an editor shows the source code for less than half a second and then it shows Source not found / Edit Lookup Path. Funny that the hierarchy in Maven Dependencies in the package explorer is opened when i have Link with editor. So it seams to be found but overriden by someone -- 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-395) Maven site multi module url problem
[ http://jira.codehaus.org/browse/MSITE-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=171712#action_171712 ] murray commented on MSITE-395: -- Url problem happens on os x and in red hat linux . The relative paths are added without being asked for. it does work on windows xp. Jdk 1.5.0_16 maven 2.1,2.0.9 maven-site-plugin 2.0-beta-6, 2.0.-beta7, 2.0 Maven site multi module url problem --- Key: MSITE-395 URL: http://jira.codehaus.org/browse/MSITE-395 Project: Maven 2.x Site Plugin Issue Type: Bug Components: multi module Affects Versions: 2.0 Reporter: valsho Priority: Blocker The generated maven (2.0.10) site for a multi module project is different on windows and linux. The difference is the relative url for the modules. -- Here's the project structure : myProject/ trunk/ pom.xml module1/ pom.xml src/ module2/ pom.xml src/ -- Here's myProject/trunk/pom.xml definition : groupIdcom.myProject/groupId artifactIdmodulepom/artifactId packagingpom/packaging namePOM myProject/name version1.0-SNAPSHOT/version modules modulemodule1/module modulemodule2/module /modules distributionManagement site idsite/id nameMaven site/name urlfile:///url /site /distributionManagement build plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-site-plugin/artifactId version2.0/version /plugin /build -- On module1 and module2 pom, I didn't declare any distributionManagement information. I've only declared the parent parent groupIdcom.myProject/groupId artifactIdmodulepom/artifactId version1.0-SNAPSHOT/version /parent groupIdcom.myProject/groupId artifactIdmodule1/artifactId packagingjar/packaging version1.0-SNAPSHOT/version namemodule1 name/name -- Here are the index.html files generated on windows and linux in myProject/trunk/target/staging/localhost/ after launching mvn site:stage in directory myProject/trunk/ -- Site deployed on Windows which is correct h5Modules/h5ul li class=none a href=module1/index.htmlmodule1 name/a /li li class=none a href=module2/index.htmlmodule2 name/a /li ... -- Site deployed on Linux which isn't correct ... h5Modules/h5ul li class=none a href=../../tmp/testProject/myProject/trunk/../localhostmodule1 name/a /li li class=none a href=../../tmp/testProject/myProject/trunk/../localhostmodule2 name/a /li ... where /tmp/testProject/ is the absolute path where is stored myProject/ on linux -- Any idea ? Maybe i should use something different in distributionManagement than urlfile:///url Thanks for your help -- 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-395) Maven site multi module url problem
[ http://jira.codehaus.org/browse/MSITE-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=171713#action_171713 ] murray commented on MSITE-395: -- happens with or without the distributionManagement on both site and site:stage Maven site multi module url problem --- Key: MSITE-395 URL: http://jira.codehaus.org/browse/MSITE-395 Project: Maven 2.x Site Plugin Issue Type: Bug Components: multi module Affects Versions: 2.0 Reporter: valsho Priority: Blocker The generated maven (2.0.10) site for a multi module project is different on windows and linux. The difference is the relative url for the modules. -- Here's the project structure : myProject/ trunk/ pom.xml module1/ pom.xml src/ module2/ pom.xml src/ -- Here's myProject/trunk/pom.xml definition : groupIdcom.myProject/groupId artifactIdmodulepom/artifactId packagingpom/packaging namePOM myProject/name version1.0-SNAPSHOT/version modules modulemodule1/module modulemodule2/module /modules distributionManagement site idsite/id nameMaven site/name urlfile:///url /site /distributionManagement build plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-site-plugin/artifactId version2.0/version /plugin /build -- On module1 and module2 pom, I didn't declare any distributionManagement information. I've only declared the parent parent groupIdcom.myProject/groupId artifactIdmodulepom/artifactId version1.0-SNAPSHOT/version /parent groupIdcom.myProject/groupId artifactIdmodule1/artifactId packagingjar/packaging version1.0-SNAPSHOT/version namemodule1 name/name -- Here are the index.html files generated on windows and linux in myProject/trunk/target/staging/localhost/ after launching mvn site:stage in directory myProject/trunk/ -- Site deployed on Windows which is correct h5Modules/h5ul li class=none a href=module1/index.htmlmodule1 name/a /li li class=none a href=module2/index.htmlmodule2 name/a /li ... -- Site deployed on Linux which isn't correct ... h5Modules/h5ul li class=none a href=../../tmp/testProject/myProject/trunk/../localhostmodule1 name/a /li li class=none a href=../../tmp/testProject/myProject/trunk/../localhostmodule2 name/a /li ... where /tmp/testProject/ is the absolute path where is stored myProject/ on linux -- Any idea ? Maybe i should use something different in distributionManagement than urlfile:///url Thanks for your help -- 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: (MASSEMBLY-360) When using mulitple Spring dependencies, the files from META-INF (from the Spring jars) overwrite each other in an executable jar-with-dependencies.
[ http://jira.codehaus.org/browse/MASSEMBLY-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=171729#action_171729 ] Borys Marcelo Borches Herrera commented on MASSEMBLY-360: - I'm also having the same exception, it most likely to be an issue with TX or AOP parser than anything else. I've heard that adding the below MANIFEST entries should do the trick but nothing happened: manifestEntries Class-Path./Class-Path Require-Bundleorg.springframework.bundle.spring,org.springframework.bundle.spring.aop,org.springframework.bundle.spring.beans,org.springframework.bundle.spring.context,org.springframework.bundle.spring.context.support,org.springframework.bundle.spring.core,org.springframework.bundle.spring.web,org.springframework.bundle.spring.webmvc /Require-Bundle /manifestEntries any thoughts? I'm trying to use Spring + JPA with Hibernate as the EntityManager provider. When using mulitple Spring dependencies, the files from META-INF (from the Spring jars) overwrite each other in an executable jar-with-dependencies. Key: MASSEMBLY-360 URL: http://jira.codehaus.org/browse/MASSEMBLY-360 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Environment: Windows XP, Java 5 Reporter: Marielle Enderman I'm working on a Java 5 project with maven 2 and I need to deliver an executable jar file. In this project I'm using different Spring dependencies: dependency groupIdorg.springframework/groupId artifactIdspring-beans/artifactId version2.5.5/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-context/artifactId version2.5.5/version /dependency For maven packaging I'm using the maven-assembly plugin to create an executable jar with dependencies (using the jar-with-dependencies descriptor). Everything works fine, except that Spring's XSD files can't be found. At least: not all of them. The fact is: Every Spring JAR file contains a META-INF directory with files like spring.handlers and spring.schemas which contain list of locations of respectively namespace handlers and schemas. Unfortunately these files aren't merged during packaging so the META_INF of the executable JAR file only contains the last one added. This can result in errors like this: Example 1: The spring-context-2.5.xsd can't be found: WARN org.springframework.beans.factory.xml.XmlBeanDefinitionReader - Ignored XML validation warning org.xml.sax.SAXParseException: schema_reference.4: Failed to read schema document 'http://www.springframework.org/schema/context/spring-context-2.5.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of the document is not xsd:schema. Example 2: The NamespaceHandler for the spring context namespace can't be located: Exception in thread main org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.springframework.org/schema/context] When I manually merge the files, the executable JAR file works fine. I hope this problem can be solved. -- 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-427) Add a mojo parameter for using the new remote tagging for svn scm provider (to prevent issue with svn 1.5.0)
[ http://jira.codehaus.org/browse/MRELEASE-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=171732#action_171732 ] Pablo commented on MRELEASE-427: I have the same problem when executing mvn release:branch. It would be useful to add the -DremoteTagging argument also when making branches. Thank you. Add a mojo parameter for using the new remote tagging for svn scm provider (to prevent issue with svn 1.5.0) -- Key: MRELEASE-427 URL: http://jira.codehaus.org/browse/MRELEASE-427 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: scm Affects Versions: 2.0-beta-8 Environment: svn version 1.5.0 Reporter: Olivier Lamy Assignee: Olivier Lamy Priority: Critical Fix For: 2.0-beta-9 Due to an issue with svn 1.5.0, release plugin doesn't work. The scm (1.2) implements a new remote tagging mechanism as a workaround. -- 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-427) Add a mojo parameter for using the new remote tagging for svn scm provider (to prevent issue with svn 1.5.0)
[ http://jira.codehaus.org/browse/MRELEASE-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=171735#action_171735 ] Olivier Lamy commented on MRELEASE-427: --- please create a new issue! Add a mojo parameter for using the new remote tagging for svn scm provider (to prevent issue with svn 1.5.0) -- Key: MRELEASE-427 URL: http://jira.codehaus.org/browse/MRELEASE-427 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: scm Affects Versions: 2.0-beta-8 Environment: svn version 1.5.0 Reporter: Olivier Lamy Assignee: Olivier Lamy Priority: Critical Fix For: 2.0-beta-9 Due to an issue with svn 1.5.0, release plugin doesn't work. The scm (1.2) implements a new remote tagging mechanism as a workaround. -- 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-447) GitChangeLogCommand doesn't take care of any branch
[ http://jira.codehaus.org/browse/SCM-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-447. Assignee: Olivier Lamy Resolution: Duplicate duplicates SCM-453 GitChangeLogCommand doesn't take care of any branch --- Key: SCM-447 URL: http://jira.codehaus.org/browse/SCM-447 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.0 Reporter: Mark Struberg Assignee: Olivier Lamy the changelog command of the maven-scm-provider-gitexe doesn't consider any given branches but only work on the currently active branch. -- 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-453) changelog command doesn't support branches yet
[ http://jira.codehaus.org/browse/SCM-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated SCM-453: - Assignee: Olivier Lamy Fix Version/s: 1.3 changelog command doesn't support branches yet -- Key: SCM-453 URL: http://jira.codehaus.org/browse/SCM-453 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.2 Reporter: Mark Struberg Assignee: Olivier Lamy Fix For: 1.3 GitChangeLogCommand doesn't support branches 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] Closed: (SCM-454) GitChangelogCommand doesn't support tag ranges yet
[ http://jira.codehaus.org/browse/SCM-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-454. Resolution: Fixed fixed in [rev 761048|http://svn.apache.org/viewvc?rev=761048view=rev] snapshot deployed GitChangelogCommand doesn't support tag ranges yet -- Key: SCM-454 URL: http://jira.codehaus.org/browse/SCM-454 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.2 Reporter: Mark Struberg Assignee: Olivier Lamy Fix For: 1.3 Attachments: SCM-454.patch The current GitChangeLogCommand always uses --since and --until parameters for start and end version. Since those parameters may only be used for date ranges, we have to use the [start]..[end] syntax. -- 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-453) changelog command doesn't support branches yet
[ http://jira.codehaus.org/browse/SCM-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed SCM-453. Resolution: Fixed fixed in [rev 761048|http://svn.apache.org/viewvc?rev=761048view=rev] snapshot deployed changelog command doesn't support branches yet -- Key: SCM-453 URL: http://jira.codehaus.org/browse/SCM-453 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.2 Reporter: Mark Struberg Assignee: Olivier Lamy Fix For: 1.3 GitChangeLogCommand doesn't support branches 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] Created: (MRELEASE-433) Add parameter remoteTagging to release:branch (to prevent issue with svn 1.5.0)
Add parameter remoteTagging to release:branch (to prevent issue with svn 1.5.0) - Key: MRELEASE-433 URL: http://jira.codehaus.org/browse/MRELEASE-433 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.0-beta-9 Environment:svn version 1.5.0 Reporter: Pablo I have the same problem than [http://jira.codehaus.org/browse/MRELEASE-427] when executing mvn release:branch. It would be useful for me to add the -DremoteTagging argument also when making branches. Thank you. -- 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: (MWAR-111) Transitive dependencies of optional dependencies are included in WEB-INF/lib
[ http://jira.codehaus.org/browse/MWAR-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=171740#action_171740 ] Rich Taylor commented on MWAR-111: -- This is a serious issue for us as well. Each time we add a new dependency to our EAR, it is automatically put into our WAR module's WEB-INF/lib, leading to duplicate jars and classloading issues. It's very error prone to maintain a list of exclusions in the WAR's pom. Transitive dependencies of optional dependencies are included in WEB-INF/lib Key: MWAR-111 URL: http://jira.codehaus.org/browse/MWAR-111 Project: Maven 2.x WAR Plugin Issue Type: Bug Affects Versions: 2.0.2 Environment: Maven 2.0.7, JDK 1.6.0_01-b06, JavaEE 5 Reporter: Chris Lance Attachments: AbstractWarMojo.java, MWAR-111.patch, TestProject.zip I have an EAR project (TestEAR) which contains two modules: 1. A JAR module (TestJAR) which has one dependency: commons-lang 2.3 2. A WAR module (TestWAR) which uses [these instructions|http://maven.apache.org/plugins/maven-war-plugin/examples/war-manifest-guide.html] to declare a dependency on TestJAR so that TestJAR is included in TestWAR's manifest classpath, but not copied into WEB-INF/lib (i.e. declares the dependency optional). This works fine for TestJAR itself, but its transitive dependency (commons-lang 2.3) is still copied into WEB-INF/lib. I don't believe this is the correct behavior since all dependencies of a JAR packaged in the EAR must also be packaged in the EAR. So, all a WAR should have to do is put the transitive dependencies in its manifest classpath to inherit them. Basically: in a WAR, transitive dependencies of optional dependencies should inherit the optional flag. I have included a simple test project as an example. Unzip, cd TestProject, and mvn install. Look in TestEAR's target dir and you will see that commons-lang is included in the EAR. Then look in TestWAR's target dir and you will see that commons-lang is also included in both the manifest classpath and the WEB-INF/lib dir. -- 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-542) Source not found. in debug session with m2eclipse and jetty
[ http://jira.codehaus.org/browse/MECLIPSE-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnaud Heritier closed MECLIPSE-542. Resolution: Won't Fix MIE project in Jira was moved to sonatype's forge. You have to create your issue here : https://issues.sonatype.org/browse/MNGECLIPSE Source not found. in debug session with m2eclipse and jetty --- Key: MECLIPSE-542 URL: http://jira.codehaus.org/browse/MECLIPSE-542 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Environment: Version is unknown, my plugin shows Maven Integration for Eclipse 0.9.7.2009020909 I hope Maven 2.x Eclipse Plugin means Maven Integration for Eclipse Reporter: Janning Vygen Attachments: maven-debug-issue.txt Attached is exception log from eclispe, my jetty launch configuration and my debug launch configuration. When debugging source from the project itself is found but not from the Maven Dependencies Source code is available and downloaded. I can open it, set a breakpoint and the breakpoint gets triggered, it opens an editor shows the source code for less than half a second and then it shows Source not found / Edit Lookup Path. Funny that the hierarchy in Maven Dependencies in the package explorer is opened when i have Link with editor. So it seams to be found but overriden by someone -- 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-2720) Multiproject dependencies not accurate for project.compileClasspathElements when run from root project
[ http://jira.codehaus.org/browse/MNG-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=171746#action_171746 ] Gabriel Guerrero commented on MNG-2720: --- I have a problem with this fix, I have several projects, and I use and the ant plugin to run my app in debug mode, what i liked is that because the classes directories was included in the classpath I was able to run eclipse in debug mode for multi projects so I could change a classes in any of the projects and just run compile , know this doesnt work could it you guys add a flag to make it work the old way? Multiproject dependencies not accurate for project.compileClasspathElements when run from root project -- Key: MNG-2720 URL: http://jira.codehaus.org/browse/MNG-2720 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.4 Reporter: Jeff Genender Assignee: John Casey Fix For: 2.1.0, 3.0-alpha-3 In a plugin I wrote (jspc), needs the dependency jars. It asks for this with the request for the project.compileClasspathElements. In a multiproject environment, when each project is built individually, it seems correct. Example (when run with -X ina subproject dir) showing classpath: /Users/mbp/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar /Users/mbp/.m2/repository/taglibs/standard/1.1.2/standard-1.1.2.jar /Users/mbp/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar /Users/mbp/.m2/repository/tldtestapp/testexttld/1/testexttld-1.jar -NOTICE HERE - THIS IS AN ARTIFACT FROM ANOTHER SUBPROJECT /Users/mbp/.m2/repository/javax/servlet/jstl/1.1.2/jstl-1.1.2.jar] When it is run from the Top level/Root project...here is the output: Users/mbp/.m2/repository/javax/servlet/jsp-api/2.0/jsp-api-2.0.jar /Users/mbp/.m2/repository/javax/servlet/servlet-api/2.4/servlet-api-2.4.jar /Users/mbp/.m2/repository/taglibs/standard/1.1.2/standard-1.1.2.jar /Users/mbp/Desktop/jsp-example/TestTldProject/target/classes NOTICE - THE JAR IS NOT BEING ASKED FOR, BUT A CLASSES DIR INSTEAD /Users/mbp/.m2/repository/javax/servlet/jstl/1.1.2/jstl-1.1.2.jar] The second project has a dependency on the testexttld-1.jar because it contains tag libs which must be wrapped in a jar. When run from a top level, it uses the other project's classes directory instead of the JAR artifact. WIth JSPC and taglibs, this makes it so it cannot work. If I have a dependency on a jar, that jar should be the dependency as expected and not a classes directory. For full explanation and example see here: http://jira.codehaus.org/browse/MJSPC-4 -- 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: (MECLIPSE-543) custom properties not being evaluated before being referenced
custom properties not being evaluated before being referenced
-
Key: MECLIPSE-543
URL: http://jira.codehaus.org/browse/MECLIPSE-543
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Reporter: Vinh
The following setup is not being handled correctly by the plugin, although it
builds fine from the command-line. It seems to not evaluate the property
definitions before applying it to where the properties are referenced, both in
the current pom and child poms. The result is that I must hard-code the
version property throughout all my poms. This becomes cumbersome later on when
I must change the version property value.
project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;
properties
my.version1.0-SNAPSHOT/my.version
/properties
modelVersion4.0.0/modelVersion
groupIdcom.test/groupId
artifactIdcommon/artifactId
packagingpom/packaging
namecommon/name
version${my.version}/version
...
/project
--
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-2412) wurfl-pro sync
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=171752#action_171752 ] Filippo De Luca commented on MAVENUPLOAD-2412: -- What about this issue. is it accepted? wurfl-pro sync -- Key: MAVENUPLOAD-2412 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2412 Project: Maven Upload Requests Issue Type: Wish Reporter: Filippo De Luca net.sourceforge.net, mavens...@dev.wurflpro.com:/home/nexus/sonatype-work/nexus/storage/public-releases, rsync_ssh, Filippo De Luca, filippo.del...@wurflpro.it -- 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: (MNG-4112) Set property containing the currently executing maven version.
[ http://jira.codehaus.org/browse/MNG-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MNG-4112: --- Attachment: MNG-4112-maven-embedder.patch I was thinking to make the change directly in maven embedder. Here is a patch to add the version to a system property when maven starts. Set property containing the currently executing maven version. -- Key: MNG-4112 URL: http://jira.codehaus.org/browse/MNG-4112 Project: Maven 2 Issue Type: Improvement Reporter: Paul Gier Attachments: MNG-4112-maven-embedder.patch It would be helpful to have an easy way to access the current version of maven. This might be accomplished by setting a property like maven.version during startup that would be available to the pom and/or to plugins. This could be used to record what version of maven was used during the build to facilitate build reproducibility. -- 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-4112) Set property containing the currently executing maven version.
[ http://jira.codehaus.org/browse/MNG-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=171763#action_171763 ] Brett Porter commented on MNG-4112: --- yep, that looks exactly right - however, ISTR having that as a system property caused some grief. It would be better to inject it into the properties in the request after it is created - they are still available for interpolation. Combine that with an IT and I'd say commit away :) Set property containing the currently executing maven version. -- Key: MNG-4112 URL: http://jira.codehaus.org/browse/MNG-4112 Project: Maven 2 Issue Type: Improvement Reporter: Paul Gier Attachments: MNG-4112-maven-embedder.patch It would be helpful to have an easy way to access the current version of maven. This might be accomplished by setting a property like maven.version during startup that would be available to the pom and/or to plugins. This could be used to record what version of maven was used during the build to facilitate build reproducibility. -- 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
