[jira] Closed: (MNG-3757) Setting M2_HOME to nothing and running ant delets contents of the current folder
[ http://jira.codehaus.org/browse/MNG-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3757. - Assignee: Brett Porter Resolution: Fixed Setting M2_HOME to nothing and running ant delets contents of the current folder Key: MNG-3757 URL: http://jira.codehaus.org/browse/MNG-3757 Project: Maven 2 Issue Type: Bug Components: Bootstrap Build Affects Versions: 2.0.11, 2.1.0-M2, 3.0-alpha-1 Environment: OS X 10.5 Reporter: Oleg Gusakov Assignee: Brett Porter Priority: Minor Fix For: 2.0.11, 2.1.0-M2, 3.0-alpha-3 Actions: * check out 2.1.x branch into a folder * *cd* to that folder * *export M2_HOME=* * *ant* As a result - current folder contents are removed because when everything compiles and tests correctly, the script tries clean target folder, and with M2_HOME set to empty string, it cleans current folder. -- 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: (MECLIPSE-37) eclipse:eclipse should execute in a later phase than generate-sources
[ http://jira.codehaus.org/browse/MECLIPSE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barrie Treloar updated MECLIPSE-37: --- Fix Version/s: (was: 2.6) 3.0 This can't be done in Maven 2.0.x. May have to wait for Maven 2.1 or 3.0 eclipse:eclipse should execute in a later phase than generate-sources --- Key: MECLIPSE-37 URL: http://jira.codehaus.org/browse/MECLIPSE-37 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.0 Reporter: Mark Donszelmann Assignee: Arnaud Heritier Fix For: 3.0 Attachments: patch-eclipse-eclipse the eclipse:eclipse goal should run in a later phase than it currently does (generate-sources) as user defined plugins may add to the compileSourceRoots and testCompileSourceRoots. If it runs later, added paths will be written correctly to the .classpath. Suggested phase is test -- 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-415) settings stored in wrong project directory
[
http://jira.codehaus.org/browse/MECLIPSE-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barrie Treloar closed MECLIPSE-415.
---
Resolution: Cannot Reproduce
settings stored in wrong project directory
---
Key: MECLIPSE-415
URL: http://jira.codehaus.org/browse/MECLIPSE-415
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Dependencies resolution and build path
(.classpath), Core : Workspace settings
Affects Versions: 2.5, 2.5.1
Environment: all
Reporter: Richard van Nieuwenhoven
Assignee: Barrie Treloar
Fix For: 2.6
Attachments: executedProject.patch, pom.xml
When i store my projects in a directory which isn't my eclipse workspace.
If I define the workspace attribute to be able to read its settings,
when I call eclipse:eclipse, my projects settings are written in the
workspace and not in each project's directory.
this problem seems to be connected to the wrongly used executedProject
parameter and maven 2.0.9..
the wrong directory problem can be solved by giving the eclipseProjectDir a
default value ${basedir} .
Arnaud: i think you can safely remove much of the code in
EclipsePlugin.validate method where the eclipseProjectDir does not exist or
!eclipseProjectDir.equals( project.getBasedir() ) these cases will almoust
never work anymore (only for very very simple eclipse projects), and it is
certainly discouraged.
in the attached patch i have included the removal of the executedProject
parameter but not the code mentioned above, the strange thing i did not have
the time to solve is that testProject11 now fails (it survived the default
value but not the removal of the executedProject parameter)
--
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: (MECLIPSE-444) Included Resources break the classpath file and prevent eclipse from building
[
http://jira.codehaus.org/browse/MECLIPSE-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barrie Treloar updated MECLIPSE-444:
Fix Version/s: (was: 2.6)
2.7
Included Resources break the classpath file and prevent eclipse from building
-
Key: MECLIPSE-444
URL: http://jira.codehaus.org/browse/MECLIPSE-444
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Dependencies resolution and build path
(.classpath)
Affects Versions: 2.5.1
Reporter: Ian Boston
Assignee: Arnaud Heritier
Fix For: 2.7
In Apache Shingig we have more than one language using a set of resources
(PHP and Java), so the resources are stored on disk in a relative path.
In the jars we have
build
resources
resource
targetPathfeatures/targetPath
directory${basedir}/../../features/directory
/resource
resource
directory${basedir}/../../javascript//directory
targetPath/gadgets/files/targetPath
includes
include**/*.*/include
/includes
/resource
etc
which results in a .classpath
shroud:~/Caret/sakai22/devcode/shindig-trunk ieb$ more java/server/.classpath
classpath
classpathentry kind=src
path=/Users/ieb/Caret/sakai22/devcode/shindig-trunk/config
output=target/classes/containers/default including=container.js
excluding=**/*.java/
classpathentry kind=src
path=/Users/ieb/Caret/sakai22/devcode/shindig-trunk/features
output=target/classes/features excluding=**/*.java/
classpathentry kind=src
path=/Users/ieb/Caret/sakai22/devcode/shindig-trunk/javascript
output=target/classes/gadgets/files including=**/*.*
excluding=**/*.java/
classpathentry kind=output path=target/classes/
classpathentry kind=con path=org.eclipse.jdt.launching.JRE_CONTAINER/
classpathentry kind=var
path=M2_REPO/org/apache/abdera/abdera-core/0.4.0-incubating-SNAPSHOT/abdera-core-0.4.0-incubating-SNAPSHOT.jar/
classpathentry kind=var
path=M2_REPO/org/apache/abdera/abdera-i18n/0.4.0-incubating-SNAPSHOT/abdera-i18n-0.4.0-incubating-SNAPSHOT.jar/
The first 3 entries are invalid as they are outside the project space the
eclipse project.
Since this breaks the eclipse build, I am classifying this as a bug you
might want to reclassify.
The work around is simple, but it generating questions on the list and
resulting in people not wanting to use the eclipse 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] Updated: (MECLIPSE-466) application.xml generated incorrectly for 3rd party ejb modules
[ http://jira.codehaus.org/browse/MECLIPSE-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barrie Treloar updated MECLIPSE-466: Fix Version/s: (was: 2.6) 2.7 application.xml generated incorrectly for 3rd party ejb modules --- Key: MECLIPSE-466 URL: http://jira.codehaus.org/browse/MECLIPSE-466 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: WTP support Affects Versions: 2.5.1 Reporter: Siarhei Dudzin Fix For: 2.7 Attachments: test-project.tar.gz As you may know by default the project version is not added to the project name. In case I have 3rd party ejb modules from a maven repository (jboss seam for example) the version number for those modules is removed from the generated application.xml as well which breaks the WTP deployment: the server can't find the 3rd party ejb jar because it expects the jar also be without the version number. Looks like during generation of application.xml there is no distinction made between dependencies from projects and libraries. I included a test case. -- 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: (MECLIPSE-472) Bad dependencies (version list) in .classpath whereas compilation (and dependency:tree) use the rigth one
[
http://jira.codehaus.org/browse/MECLIPSE-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barrie Treloar updated MECLIPSE-472:
Fix Version/s: (was: 2.6)
2.7
Bad dependencies (version list) in .classpath whereas compilation (and
dependency:tree) use the rigth one
Key: MECLIPSE-472
URL: http://jira.codehaus.org/browse/MECLIPSE-472
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Dependencies resolution and build path
(.classpath)
Affects Versions: 2.5.1
Reporter: Olivier Lamy
Assignee: Arnaud Heritier
Priority: Critical
Fix For: 2.7
Attachments: screenshot-1.jpg, war_with_implicit_scopes.patch
Maven compilation and dependency:tree display
org/codehaus/plexus/plexus-component-api/1.0-alpha-20/plexus-component-api-1.0-alpha-20
Whereas the generated .classpath contains classpathentry kind=var
path=M2_REPO/org/codehaus/plexus/plexus-component-api/1.0-alpha-16/plexus-component-api-1.0-alpha-16.jar/
Related continuum dev email
http://continuum.markmail.org/message/6eiyt6vgdqycc4hm?q=
Step to reproduce :
{code}
svn co -r679899 https://svn.apache.org/repos/asf/continuum/trunk continuum
cd continuum mvn eclipse:eclipse grep plexus-compone
continuum-core/.classpath
.
classpathentry kind=var
path=M2_REPO/org/codehaus/plexus/plexus-component-api/1.0-alpha-16/plexus-component-api-1.0-alpha-16.jar/
{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] Updated: (MECLIPSE-104) Add the ability to specify source exclusions
[ http://jira.codehaus.org/browse/MECLIPSE-104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barrie Treloar updated MECLIPSE-104: Fix Version/s: (was: 2.6) 2.7 Add the ability to specify source exclusions Key: MECLIPSE-104 URL: http://jira.codehaus.org/browse/MECLIPSE-104 Project: Maven 2.x Eclipse Plugin Issue Type: New Feature Reporter: James Mitchell Assignee: Arnaud Heritier Priority: Minor Fix For: 2.7 Attachments: fix-eclipse-classpaths.sh, MECLIPSE-104.patch, srcExclusions-patch.zip When source files contain scm information (**/.svn/** or **/CVS/**), which is pretty much a given, there's currently no way to specify that those directories be excluded except through the GUI. This isn't so much of a problem except that the next time a change is needed and this plugin is ran, it will overwrite this exclusion and will force me to exclude it, by hand, again. The above case is the driving reason why I decided to get involved and help out. So, I have written everything (I think) that is needed for this enhancement including, adding to the javadoc, creating a new test that verifies this enhancement, and fully testing this with my own projects (many of them @ Struts). If there is anything else I need to do as far as site documentation, please tell me where it is and I'll add it. This is my first patch to Maven. If this sucks, please don't ignore it, just say 'it sucks, no thanks and I'll go about working on something else. Thanks so much for your attention. -- James Mitchell -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-415) settings stored in wrong project directory
[
http://jira.codehaus.org/browse/MECLIPSE-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158463#action_158463
]
Richard van Nieuwenhoven commented on MECLIPSE-415:
---
This request was on a far to short notice, and at the moment i do not have the
time to check if the trunk still has this behavior.
Please make sure in your test to use a multi module hierarchical project, they
are the ones with the most problems ;-)
And also please look into my note for Arnaud to remove unreachable codes, the
plugin is complicated as it is.
settings stored in wrong project directory
---
Key: MECLIPSE-415
URL: http://jira.codehaus.org/browse/MECLIPSE-415
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Dependencies resolution and build path
(.classpath), Core : Workspace settings
Affects Versions: 2.5, 2.5.1
Environment: all
Reporter: Richard van Nieuwenhoven
Assignee: Barrie Treloar
Fix For: 2.6
Attachments: executedProject.patch, pom.xml
When i store my projects in a directory which isn't my eclipse workspace.
If I define the workspace attribute to be able to read its settings,
when I call eclipse:eclipse, my projects settings are written in the
workspace and not in each project's directory.
this problem seems to be connected to the wrongly used executedProject
parameter and maven 2.0.9..
the wrong directory problem can be solved by giving the eclipseProjectDir a
default value ${basedir} .
Arnaud: i think you can safely remove much of the code in
EclipsePlugin.validate method where the eclipseProjectDir does not exist or
!eclipseProjectDir.equals( project.getBasedir() ) these cases will almoust
never work anymore (only for very very simple eclipse projects), and it is
certainly discouraged.
in the attached patch i have included the removal of the executedProject
parameter but not the code mentioned above, the strange thing i did not have
the time to solve is that testProject11 now fails (it survived the default
value but not the removal of the executedProject parameter)
--
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-714) When artifact not found on mirror the real site isn't checked
[ http://jira.codehaus.org/browse/MNG-714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158471#action_158471 ] Szczepan Faber commented on MNG-714: There are number reasons this is a valuable feature: -ability to implement simple fail-over system with two mirrors mirroring the same repo(s) -currently, if there are mirrors with the same value of mirrorOf, last mirror wins and previous mirrors are silently ignored. Not very nice... -some folks from my company have to change the settings file every time they go home because at home they don't have proxy. Quite annoying... Is it going to be released into maven? Is improving maven in the agenda of maven roadmap? When artifact not found on mirror the real site isn't checked - Key: MNG-714 URL: http://jira.codehaus.org/browse/MNG-714 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories Affects Versions: 2.0-beta-1 Reporter: Kenney Westerhof Assignee: Jason van Zyl Fix For: 3.x Attachments: MNG-714-maven-artifact-manager.patch Original Estimate: 3 hours Remaining Estimate: 3 hours I'm using the settings.xml mirror feature as a local cache. Periodically I upload my local repo to the webserver specified as mirror. When an artifact cannot be found on the mirror, the original site isn't checked (and possibly the rest of the sites). I'm not sure what the exact function of the mirror is (except caching?), but repo1 is checked often regardless of mirror presence, so I figure it's not meant to totally disable checking the central repo's. Simple reproduction: define a few mirrors in your settings.xml for central, central-plugins and snapshots, pointing to say file://tmp/empty/dir/. Stacktrace: [DEBUG] Error resolving artifact version from metadata. org.apache.maven.wagon.ResourceDoesNotExistException: Unable to locate resource in repository at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:81) at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:70) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:343) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifactMetadata(DefaultWagonManager.java:263) at org.apache.maven.artifact.metadata.AbstractVersionArtifactMetadata.retrieveFromRemoteRepository(AbstractVersionArtifactMetadata.java:93) at org.apache.maven.artifact.transform.AbstractVersionTransformation.retrieveFromRemoteRepository(AbstractVersionTransformation.java:171) at org.apache.maven.artifact.transform.AbstractVersionTransformation.resolveVersion(AbstractVersionTransformation.java:96) at org.apache.maven.artifact.transform.SnapshotTransformation.transformForResolve(SnapshotTransformation.java:43) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:95) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:63) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:290) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:274) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:81) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:186) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:70) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:197) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:185) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:156) at org.apache.maven.plugin.DefaultPluginManager.ensurePluginContainerIsComplete(DefaultPluginManager.java:544) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:479) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:334) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:378) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:351) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:337)
[jira] Commented: (MECLIPSE-415) settings stored in wrong project directory
[
http://jira.codehaus.org/browse/MECLIPSE-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158474#action_158474
]
Barrie Treloar commented on MECLIPSE-415:
-
Fair enough.
Building a multi-module test case to see if I can reproduce.
Hopefully I can deploy a SNAPSHOT and you can pull that down without having to
do a build.
I'm being overzealous as I want to cut a release.
My apologies.
settings stored in wrong project directory
---
Key: MECLIPSE-415
URL: http://jira.codehaus.org/browse/MECLIPSE-415
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Dependencies resolution and build path
(.classpath), Core : Workspace settings
Affects Versions: 2.5, 2.5.1
Environment: all
Reporter: Richard van Nieuwenhoven
Assignee: Barrie Treloar
Fix For: 2.6
Attachments: executedProject.patch, pom.xml
When i store my projects in a directory which isn't my eclipse workspace.
If I define the workspace attribute to be able to read its settings,
when I call eclipse:eclipse, my projects settings are written in the
workspace and not in each project's directory.
this problem seems to be connected to the wrongly used executedProject
parameter and maven 2.0.9..
the wrong directory problem can be solved by giving the eclipseProjectDir a
default value ${basedir} .
Arnaud: i think you can safely remove much of the code in
EclipsePlugin.validate method where the eclipseProjectDir does not exist or
!eclipseProjectDir.equals( project.getBasedir() ) these cases will almoust
never work anymore (only for very very simple eclipse projects), and it is
certainly discouraged.
in the attached patch i have included the removal of the executedProject
parameter but not the code mentioned above, the strange thing i did not have
the time to solve is that testProject11 now fails (it survived the default
value but not the removal of the executedProject parameter)
--
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-3807) Maven is not interpolatin Properties at plugin configuration
[
http://jira.codehaus.org/browse/MNG-3807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3807:
--
Fix Version/s: (was: 2.1.0-M2)
2.2.0-M1
Bump plexus container changes to 2.2, if not 3.0
Maven is not interpolatin Properties at plugin configuration
Key: MNG-3807
URL: http://jira.codehaus.org/browse/MNG-3807
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.9, 2.1.0-M1
Reporter: Marvin Froeder
Fix For: 2.2.0-M1
My plugin has a configuration like this:
{noformat}
/**
* My Properties.
*
* @parameter
*/
private Properties myProperties;
{noformat}
When I configure like this:
{noformat}
myProperties
property
namepropertyName1/name
value${buildnumber}/value !-- property injected on maven properties
by http://mojo.codehaus.org/buildnumber-maven-plugin/ --
property
/myProperties
{noformat}
Maven doesn't interpolate the buildnumber. But the value is available at
project.getProperties().
--
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: (MNG-3795) Add example pluginGroups snippet to conf/settings.xml in distribution
[
http://jira.codehaus.org/browse/MNG-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3795.
-
Assignee: Brett Porter
Resolution: Fixed
Fix Version/s: 3.0-alpha-1
looks good, I've applied it
Add example pluginGroups snippet to conf/settings.xml in distribution
---
Key: MNG-3795
URL: http://jira.codehaus.org/browse/MNG-3795
Project: Maven 2
Issue Type: Improvement
Components: Plugins and Lifecycle, Settings
Affects Versions: 2.0.9, 2.1.0-M1
Reporter: Benjamin Bentmann
Assignee: Brett Porter
Priority: Trivial
Fix For: 2.0.11, 2.1.0-M2, 3.0-alpha-1
Attachments: plugin-groups.patch
Unless there were reasons to hide {{pluginGroups}} from users, we should
consider to add some example snippet to the installation settings of the
distro. This settings file is often used as a starting point for a customized
user settings and its various example snippets usually save one from
searching the Maven site.
--
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-2045) Maven can't compile against sibling test-jar dependency in multiproject (Test Attached)
[ http://jira.codehaus.org/browse/MNG-2045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158479#action_158479 ] Brett Porter commented on MNG-2045: --- could this be considered fixed in 2.0.10 and a new issue opened for the classifier approach? Maven can't compile against sibling test-jar dependency in multiproject (Test Attached) --- Key: MNG-2045 URL: http://jira.codehaus.org/browse/MNG-2045 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.2 Environment: WinXP Reporter: Brian Fox Assignee: Brian Fox Fix For: 2.0.11 Attachments: it1021.tar.gz, mng-2045-ittest.zip, MNG-2045-maven-project-r577340.patch1, MNG-2045-maven-project-r577340.patch2, sample.zip I have 2 projects under a parent like so: --Parent --- sample-jar --- sample-jar-user sample-jar builds and installs a test-jar along with the normal jar. sample-jar-user depends on the test-jar at compile time. When I build from the parent folder, the build fails because it can't find the class. When I go to sample-jar-user and build, it works fine. In the attached test case, to reproduce: from the root folder, run mvn clean install - See it fail. cd sample-jar-user; mvn clean install - see it succeed. I remember reading somewhere that in multiprojects, maven attempts to locate the sibling classes in the source tree instead of using the jars from the repository. I'm guessing the problem is here that it's not looking in ../sample-jar/target/test-classes for this code, but really one should expect this to come from the repository. -- 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-3043) Allow 'mvn test' to work with test-jar dependencies in a reactor
[ http://jira.codehaus.org/browse/MNG-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3043: -- Affects Version/s: (was: 3.0) Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.x Allow 'mvn test' to work with test-jar dependencies in a reactor Key: MNG-3043 URL: http://jira.codehaus.org/browse/MNG-3043 Project: Maven 2 Issue Type: Bug Components: Dependencies, Reactor and workspace Affects Versions: 2.0.6, 2.0.7 Reporter: Kenney Westerhof Fix For: 2.0.x Basically the issue is demonstrated by MNG-2045, but instead of running 'mvn install', you run 'mvn test'. Test classes of dependencies should be resolved from the reactor, just as main classes, if there's no archive available. I'm not sure how to go about this. Specifying a dependency on something with typetest-jar/type, and having that dependency declare the maven-jar-plugin with the 'test-jar' goal is insufficient. Perhaps we can just add a standard classifier that maven is aware of, in this case 'tests'. The jar packaging would export this as a known classifier, and tells maven how it contributes to what classpath. Since test sources are a first class citizen, just as main sources are (they have the same phases, same elements in the pom (but differently named)). It seems logical to me that somehow the test classes should be made available to dependencies, if they declare a dependency with classifier 'tests'. -- 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: (MNG-2565) plugin version aren't taken from pluginManagement in a sub-sub-modules
[ http://jira.codehaus.org/browse/MNG-2565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2565. - Assignee: Brett Porter Resolution: Cannot Reproduce Fix Version/s: (was: Reviewed Pending Version Assignment) the multiple-versions-of-a-plugin question is addressed in other issues plugin version aren't taken from pluginManagement in a sub-sub-modules -- Key: MNG-2565 URL: http://jira.codehaus.org/browse/MNG-2565 Project: Maven 2 Issue Type: Bug Components: Inheritance and Interpolation Affects Versions: 2.0.5 Reporter: Emmanuel Venisse Assignee: Brett Porter Priority: Critical It works only for the first inheritence level -- 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-3885) Modules of Maven-Projects are deployed with Timestamp when uniqueVersion is set to false
[ http://jira.codehaus.org/browse/MNG-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Wegerhoff updated MNG-3885: Attachment: minimizedSETTINGS.xml minimizedPOM.xml Thanks for your response, i attached a minimized pom.xml as well as a minimized settings.xml that is used by out build-server. Modules of Maven-Projects are deployed with Timestamp when uniqueVersion is set to false Key: MNG-3885 URL: http://jira.codehaus.org/browse/MNG-3885 Project: Maven 2 Issue Type: Bug Components: Deployment Affects Versions: 2.0.8 Environment: Red Hat Linux, Maven 2.0.8, Java 1.6, Cruisecontrol Reporter: Matthias Wegerhoff Attachments: minimizedPOM.xml, minimizedSETTINGS.xml When deploying artifacts into local repository with cruisecontrol by using the following command: mvn -U -P mvn-profile ... -DuniqueVersion=false deploy The parent is always beeing deployed correctly, without timestamp as MODULE_VERSION-SNAPSHOT. But all Modules are beeing deployed with Timestamp. -- 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-2686) POM dependency scope auto-downgrades from provided to test
[ http://jira.codehaus.org/browse/MNG-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2686: -- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.x still seems to be an issue then POM dependency scope auto-downgrades from provided to test -- Key: MNG-2686 URL: http://jira.codehaus.org/browse/MNG-2686 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Reporter: Frank Cornelis Priority: Critical Fix For: 2.0.x My project has a dependency on: XXX:YYY:jar:1.0-SNAPSHOT (selected for null) with transitive dependency: commons-logging:commons-logging:jar:1.1:test and again triggering a transitive dependency on: javax.servlet:servlet-api:jar:2.3:test (selected for test) Later on the project also has a dependency: AAA:BBB-container:pom:1.0-SNAPSHOT:provided (selected for provided) I use this to represent the dependencies provided by the J2EE container in which the application will be deployed. This triggers via: tomcat:catalina:jar:5.5.15:provided (selected for provided) the following funny thing: javax.servlet:servlet-api:jar:2.4:provided (removed - nearer found: 2.3) Leaving me without servlet-api for the compile scope. -- 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-2811) issue description: 'Plugin dependencies override maven core artifacts causing NoClassDefFoundErrors'
[ http://jira.codehaus.org/browse/MNG-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158483#action_158483 ] Brett Porter commented on MNG-2811: --- David, do you still see this in recent versions of Maven? issue description: 'Plugin dependencies override maven core artifacts causing NoClassDefFoundErrors' - Key: MNG-2811 URL: http://jira.codehaus.org/browse/MNG-2811 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.4 Environment: OS agnostic, maven 2.0.4, jdk1.5 Reporter: David J. M. Karlsen Priority: Blocker Fix For: Reviewed Pending Version Assignment Attachments: 17artifactmultibulid.run1.log, 4artifact.filtered.log Usecase: wipe the local .m2 repo totally away. (rm -rf ~/.m2/repository) do a: mvn -X clean deploy site-deploy. Attached is the output from two different projects (one is a 4 artifact project - including the top pom, the other is a multibuild of 17 artifacts, also including top-pom). If I just re-run the mvn -X clean deploy site-deploy the builds will eventually succeed. I'll try to narrow down the pom's to pin down the failure with as little dependencies and plugins in action as possible - but this will take some time. I can be pinged at da...@codehaus.org or da...@davidkarlsen.com for re-running builds if needed. The logs are a little anonymized. -- 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: (MNG-2525) SNAPSHOT dependencies aren't found when repository has 'release' disabled and a version range is used
[ http://jira.codehaus.org/browse/MNG-2525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2525. - Assignee: Brett Porter Resolution: Duplicate Fix Version/s: (was: Reviewed Pending Version Assignment) SNAPSHOT dependencies aren't found when repository has 'release' disabled and a version range is used - Key: MNG-2525 URL: http://jira.codehaus.org/browse/MNG-2525 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Environment: Windows XP, Sun JDK 5.0 Update 7 Reporter: Nathan Beyer (Apache) Assignee: Brett Porter Priority: Critical When a repository is configured (POM, profiles, etc), 'releases' is disabled, 'snapshots' is enabled and a dependency uses a version range, the dependency fails to resolve. The dependency is found when an explicit version is used. The following can be used to recreate the issue. Setup the maven snapshot repository in an active profile like this: repository idapache.snapshots/id nameMaven Snapshots/name urlhttp://people.apache.org/maven-snapshot-repository/url releases enabledfalse/enabled /releases snapshots enabledtrue/enabled /snapshots /repository Check out the maven-install-plugin at revision 427494 (or any revision or other plugin that has a dependency that's a SNAPSHOT). Run a build (mvn package) and all dependencies should download. Modify the dependency in the POM to use a version range, instead of an explict version. For example, change the version 1.0-SNAPSHOT to [0,1), which includes the same version. Run another build (mvn package) and the dependency will fail to download. -- 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-3885) Modules of Maven-Projects are deployed with Timestamp when uniqueVersion is set to false
[ http://jira.codehaus.org/browse/MNG-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Wegerhoff updated MNG-3885: Attachment: minimizedPOM.xml Modules of Maven-Projects are deployed with Timestamp when uniqueVersion is set to false Key: MNG-3885 URL: http://jira.codehaus.org/browse/MNG-3885 Project: Maven 2 Issue Type: Bug Components: Deployment Affects Versions: 2.0.8 Environment: Red Hat Linux, Maven 2.0.8, Java 1.6, Cruisecontrol Reporter: Matthias Wegerhoff Attachments: minimizedPOM.xml, minimizedPOM.xml, minimizedSETTINGS.xml When deploying artifacts into local repository with cruisecontrol by using the following command: mvn -U -P mvn-profile ... -DuniqueVersion=false deploy The parent is always beeing deployed correctly, without timestamp as MODULE_VERSION-SNAPSHOT. But all Modules are beeing deployed with Timestamp. -- 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-3023) Reactor projects should be included in dependency resolution
[ http://jira.codehaus.org/browse/MNG-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3023: -- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1.0-M3 this constantly proves a nuisance - worth reviewing Reactor projects should be included in dependency resolution Key: MNG-3023 URL: http://jira.codehaus.org/browse/MNG-3023 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.7 Reporter: Mark Hobson Fix For: 2.1.0-M3 Attachments: patch.txt Dependency resolution for mojos with @requiresDependencyResolution should include the projects within the reactor. See attached it0122 for an example (numbered as such due to MNG-2994's it0121). -- 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: (MNG-2759) Resolving transitive dependencies of artefacts with classifiers fails
[ http://jira.codehaus.org/browse/MNG-2759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2759. - Assignee: Brett Porter Resolution: Won't Fix Fix Version/s: (was: Reviewed Pending Version Assignment) this just needs to be fixed in the linked issues Resolving transitive dependencies of artefacts with classifiers fails - Key: MNG-2759 URL: http://jira.codehaus.org/browse/MNG-2759 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Environment: Windows XP, Maven 2.0.4 Reporter: Fabian Bauschulte Assignee: Brett Porter Attachments: project.zip I have the following projects with subprojects projectA, projectB and projectC. projectA depends on projectB, projectC depends on projectB. All projects use classifiers: ... artifactIdprojectB/artifactId build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId configuration classifiersomeclassifier/classifier /configuration /plugin /plugins /build dependencies dependency groupIdtest/groupId artifactIdprojectB/artifactId version1.0.0/version classifiersomeclassifier/classifier /dependency /dependencies When running mvn clean install on the the parent works fine. But running mvn install only in projectC fails: C:\Data\maven-test\projectCmvn clean install [INFO] Scanning for projects... [INFO] [INFO] Building Unnamed - test:projectC:jar:1.0.0 [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean] [INFO] Deleting directory C:\Data\maven-test\projectC\target [INFO] Deleting directory C:\Data\maven-test\projectC\target\classes [INFO] Deleting directory C:\Data\maven-test\projectC\target\test-classes [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. Downloading: http://repo1.maven.org/maven2/test/projectB/1.0.0/projectB-1.0.0.pom [WARNING] Unable to get resource from repository central (http://repo1.maven.org/maven2) [INFO] [compiler:compile] Compiling 1 source file to C:\Daten\maven-test\projectC\target\classes [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Compilation failure C:\Data\maven-test\projectC\src\main\java\ClassC.java:[3,12] cannot find symbol symbol : class ClassA location: package test [INFO] -- 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: (MNG-2677) Plugin discovery not reactor aware
[ http://jira.codehaus.org/browse/MNG-2677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2677. - Assignee: Brett Porter Resolution: Duplicate Fix Version/s: (was: Reviewed Pending Version Assignment) see linked issue Plugin discovery not reactor aware -- Key: MNG-2677 URL: http://jira.codehaus.org/browse/MNG-2677 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle, Reactor and workspace Affects Versions: 2.0.4 Reporter: Kenney Westerhof Assignee: Brett Porter Regression of MNG-870 -- 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-3885) Modules of Maven-Projects are deployed with Timestamp when uniqueVersion is set to false
[ http://jira.codehaus.org/browse/MNG-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158491#action_158491 ] Brett Porter commented on MNG-3885: --- given these settings, I expect -DuniqueVersion=true|false to have no effect. So since the POM defines it with uniqueVersionfalse/uniqueVersion that should be honoured. Is that what is happening? Modules of Maven-Projects are deployed with Timestamp when uniqueVersion is set to false Key: MNG-3885 URL: http://jira.codehaus.org/browse/MNG-3885 Project: Maven 2 Issue Type: Bug Components: Deployment Affects Versions: 2.0.8 Environment: Red Hat Linux, Maven 2.0.8, Java 1.6, Cruisecontrol Reporter: Matthias Wegerhoff Attachments: minimizedPOM.xml, minimizedPOM.xml, minimizedSETTINGS.xml When deploying artifacts into local repository with cruisecontrol by using the following command: mvn -U -P mvn-profile ... -DuniqueVersion=false deploy The parent is always beeing deployed correctly, without timestamp as MODULE_VERSION-SNAPSHOT. But all Modules are beeing deployed with Timestamp. -- 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-2668) Plugin dependencies should be considered when the reactor creates the build order list
[ http://jira.codehaus.org/browse/MNG-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2668: -- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1.0-M2 Patch Submitted: [Yes] Plugin dependencies should be considered when the reactor creates the build order list -- Key: MNG-2668 URL: http://jira.codehaus.org/browse/MNG-2668 Project: Maven 2 Issue Type: Bug Components: Reactor and workspace Affects Versions: 2.0.4 Reporter: Vincent Massol Fix For: 2.1.0-M2 Attachments: MNG-2668-maven-project.patch, MNG-2668-maven-project.patch In one project, I am using the checkstyle plugin with a plugin dependency on a build-tools module that produces a jar. Maven doesn't recognize that this build-tools module must be built before the module using the checkstyle plugin which has this dependency. -- 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: (MNG-2578) Make it possible to set default versions for reporting-plugins (i.e. plugins under reporting)
[ http://jira.codehaus.org/browse/MNG-2578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2578. - Assignee: Brett Porter Resolution: Duplicate Fix Version/s: (was: Reviewed Pending Version Assignment) dupe of MNG-1931 Make it possible to set default versions for reporting-plugins (i.e. plugins under reporting) Key: MNG-2578 URL: http://jira.codehaus.org/browse/MNG-2578 Project: Maven 2 Issue Type: Improvement Components: POM Affects Versions: 2.0.4 Reporter: Jimisola Laursen Assignee: Brett Porter Make it possible to set default versions for reporting-plugins (i.e. plugins under reporting). dependencies have dependencyManagement and plugins have pluginManagement, but there doesn't seem to be anything for reportPluginManagement. Could be that I missed out on something, but I doubt it since I stumbled on this issue with aspectj-maven-plugin and it's aspectj-report (similar to javadoc). The same plugin is used under build and reporting. pluginManagement stated that version 1.0-beta-4-SNAPSHOT should be used, but it was only for build. Instead 1.0-beta-2 (not snapshot) was used for the report. This issue came up in the following thread in mojo-user: http://www.nabble.com/Problems-with-aspectj-maven-plugin-and-reporting-using-ajdoc-tf2060246.html#a6507979 -- 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-3228) Maven profile activation does not work when profile is defined in inherited 'parent' pom
[ http://jira.codehaus.org/browse/MNG-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3228: -- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1.0-M3 Maven profile activation does not work when profile is defined in inherited 'parent' pom Key: MNG-3228 URL: http://jira.codehaus.org/browse/MNG-3228 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.7 Reporter: tony nys Fix For: 2.1.0-M3 The goal is to activate a maven profile based on OS user name. When I create a standalone project with a profile activation, it works, however, when I define the profile in a parent pom, it is never activated. this works: ... profile idTONY/id activation property nameuser.name/name valueWINTONY/value /property /activation properties /properties So in this case, my profile is activated based on my OS user name [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'help'. [INFO] [INFO] Building Proj1 [INFO] task-segment: [help:active-profiles] (aggregator-style) [INFO] [INFO] [help:active-profiles] [INFO] Active Profiles for Project 'com.capgemini.be.proj1:parent:pom:4.0.2': The following profiles are active: - TONY (source: pom) -- However, if I now have the profiles definition in the parent pom, it doesn't work when I build a child project So the child project references the parent pom containing the profiles and the activation, but when it is built, the profile is not activated PARENT POM: ... profiles profile idTONY/id activation property nameuser.name/name valueWINTONY/value /property /activation properties ... CHILD POM (the one being built) project parent groupIdcom.capgemini.be.proj1/groupId artifactIdparent/artifactId version4.0.2/version /parent [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'help'. [INFO] [INFO] Building Proj1 Application [INFO] task-segment: [help:active-profiles] (aggregator-style) [INFO] [INFO] [help:active-profiles] [INFO] Active Profiles for Project 'com.capgemini.be.proj1:proj1-webapp:jar:4.0.2': There are no active profiles. -- 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-3228) Maven profile activation does not work when profile is defined in inherited 'parent' pom
[ http://jira.codehaus.org/browse/MNG-3228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158496#action_158496 ] Brett Porter commented on MNG-3228: --- see test attachment in MNG-3897 Maven profile activation does not work when profile is defined in inherited 'parent' pom Key: MNG-3228 URL: http://jira.codehaus.org/browse/MNG-3228 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.7 Reporter: tony nys Fix For: 2.1.0-M3 The goal is to activate a maven profile based on OS user name. When I create a standalone project with a profile activation, it works, however, when I define the profile in a parent pom, it is never activated. this works: ... profile idTONY/id activation property nameuser.name/name valueWINTONY/value /property /activation properties /properties So in this case, my profile is activated based on my OS user name [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'help'. [INFO] [INFO] Building Proj1 [INFO] task-segment: [help:active-profiles] (aggregator-style) [INFO] [INFO] [help:active-profiles] [INFO] Active Profiles for Project 'com.capgemini.be.proj1:parent:pom:4.0.2': The following profiles are active: - TONY (source: pom) -- However, if I now have the profiles definition in the parent pom, it doesn't work when I build a child project So the child project references the parent pom containing the profiles and the activation, but when it is built, the profile is not activated PARENT POM: ... profiles profile idTONY/id activation property nameuser.name/name valueWINTONY/value /property /activation properties ... CHILD POM (the one being built) project parent groupIdcom.capgemini.be.proj1/groupId artifactIdparent/artifactId version4.0.2/version /parent [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'help'. [INFO] [INFO] Building Proj1 Application [INFO] task-segment: [help:active-profiles] (aggregator-style) [INFO] [INFO] [help:active-profiles] [INFO] Active Profiles for Project 'com.capgemini.be.proj1:proj1-webapp:jar:4.0.2': There are no active profiles. -- 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: (MNG-3773) Activation by Property does not work if profile is in parent pom
[ http://jira.codehaus.org/browse/MNG-3773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3773. - Assignee: Brett Porter Resolution: Duplicate Fix Version/s: (was: 2.0.x) Activation by Property does not work if profile is in parent pom - Key: MNG-3773 URL: http://jira.codehaus.org/browse/MNG-3773 Project: Maven 2 Issue Type: Bug Components: Profiles Affects Versions: 2.0.9, 2.1.0-M1 Reporter: Christian Raschka Assignee: Brett Porter Priority: Minor If i have a parent pom with a profile like this: profile idesb/id activation property nametest/name valuetrue/value /property /activation i could not activate it using either: properties testtrue/test /properties or on CLI (mvn -Dtest=true) in the submodule. -- 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: (MNG-3897) Profile with jdk activation is not inherited from parent pom
[
http://jira.codehaus.org/browse/MNG-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3897.
-
Assignee: Brett Porter
Resolution: Duplicate
Fix Version/s: (was: 2.0.x)
Profile with jdk activation is not inherited from parent pom
Key: MNG-3897
URL: http://jira.codehaus.org/browse/MNG-3897
Project: Maven 2
Issue Type: Bug
Components: Profiles
Affects Versions: 2.0.9
Environment: Windows, JDK 1.6.0_07
Reporter: Anthony Whitford
Assignee: Brett Porter
Attachments: mvn-bug.zip
If I declare a profile in a parent pom with jdk activation, it isn't being
activated for projects that inherit the parent pom.
(Note that I think profiles in general are being inherited. I suspect this
issue is limited to jdk activation.)
I have attached a simple test project to prove the issue. If you run {{mvn
help:all-profiles}}, you can see that {{my.jdk16}} is not activated for the
module _my-app_ (but it should).
{noformat}
[INFO] [help:all-profiles]
[INFO] Listing Profiles for Project:
com.mycompany.app:mvn-bug:pom:1.0-SNAPSHOT
Profile Id: my.jdk16 (Active: true , Source: pom)
Listing Profiles for Project: com.mycompany.app:my-app:jar:1.0-SNAPSHOT
Profile Id: my.jdk16 (Active: false , Source: pom)
{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] Updated: (MNG-2807) ciManagement from parent is not merging with children
[
http://jira.codehaus.org/browse/MNG-2807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-2807:
--
Fix Version/s: (was: Reviewed Pending Version Assignment)
2.x
this is currently by design - will need to review it in light of a model change
ciManagement from parent is not merging with children
-
Key: MNG-2807
URL: http://jira.codehaus.org/browse/MNG-2807
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.4
Environment: linux jdk1.5.0_10 amd64
Reporter: Kelly Davis
Fix For: 2.x
If I define the following in my parent pom:
{code:xml}
ciManagement
systemcontinuum/system
urlhttp://blah/url
/ciManagement
{code}
and then in the child pom I have the following:
{code:xml}
ciManagement
notifiers
notifier
typemail/type
configuration
addressblah/address
/configuration
/notifier
/notifiers
/ciManagement
{code}
The ciManagement for the effective pom lacks the system and url properties
from the parent pom. Seems like it should be merging them but isn't. This
would helpful for reducing code duplication.
--
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-3057) properties not expanded in generated POMs when building A/B/C nested projects
[
http://jira.codehaus.org/browse/MNG-3057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-3057:
--
Fix Version/s: (was: 2.0.x)
2.1.0-M3
review as a popular issue
properties not expanded in generated POMs when building A/B/C nested projects
-
Key: MNG-3057
URL: http://jira.codehaus.org/browse/MNG-3057
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.7
Reporter: George Armhold
Fix For: 2.1.0-M3
Attachments: example.tar.gz, generated-poms.tar.gz,
InstallMojo.java.patch, InstallMojo.java.patch,
InstallMojo.quoteReplacement.patch, maven-install-parent.patch
Using Maven version: 2.0.8-SNAPSHOT, svn r547427.
I checked out and built 2.0.8 because I was interested in Jason van Zyl's
patch for MNG-2619- building from the middle pom of a
(parent,child,grandchild) heirarchy fails. The fix works for the most part,
but there still seems to be a problem with the poms that get generated during
the install goal. The poms that get installed into .m2/repository do not
have properties interpolated. If I run maven like:
$ mvn install -Dglobal-version=1.0.0
I get poms with the string ${global-version} embedded in the resulting poms
rather than what I specify on the command line (or in settings.xml). The
build works properly aside from this, and if I do mvn help:effective-pom
the properties are correctly interpolated.
I've attached a tarfile with an example A/B/C build structure that exhibits
this behavior, as well as the generated poms.
Many thanks for your attention.
--
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-3885) Modules of Maven-Projects are deployed with Timestamp when uniqueVersion is set to false
[ http://jira.codehaus.org/browse/MNG-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158501#action_158501 ] Matthias Wegerhoff commented on MNG-3885: - Defining uniqueVersionfalse/uniqueVersion in the projects pom.xml takes only effect on the parent but not on child-modules. No matter if i´m calling the deploy-goal with or without the parameter -DuniqueVerison=false Modules of Maven-Projects are deployed with Timestamp when uniqueVersion is set to false Key: MNG-3885 URL: http://jira.codehaus.org/browse/MNG-3885 Project: Maven 2 Issue Type: Bug Components: Deployment Affects Versions: 2.0.8 Environment: Red Hat Linux, Maven 2.0.8, Java 1.6, Cruisecontrol Reporter: Matthias Wegerhoff Attachments: minimizedPOM.xml, minimizedPOM.xml, minimizedSETTINGS.xml When deploying artifacts into local repository with cruisecontrol by using the following command: mvn -U -P mvn-profile ... -DuniqueVersion=false deploy The parent is always beeing deployed correctly, without timestamp as MODULE_VERSION-SNAPSHOT. But all Modules are beeing deployed with Timestamp. -- 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: (MNG-2446) parent Pom properties not resolved for module dependencies
[
http://jira.codehaus.org/browse/MNG-2446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-2446.
-
Assignee: Brett Porter
Resolution: Duplicate
Fix Version/s: (was: Reviewed Pending Version Assignment)
I believe this is covered by the linked issues.
parent Pom properties not resolved for module dependencies
---
Key: MNG-2446
URL: http://jira.codehaus.org/browse/MNG-2446
Project: Maven 2
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.0.4
Environment: WindowsXP/Linux - JDK 1.4 last version
Reporter: Jeremie Poutrin
Assignee: Brett Porter
Priority: Minor
Attachments: InstallMojo.quoteReplacement.patch,
maven-version-problem.zip
root-project -- root-pom.xml with version${my.version}/version
|---proj1 parentversion${my.version}/version/parent
|---proj2 parentversion${my.version}/version/parent
| |
| |-proj1 dependency
|---proj3 parentversion${my.version}/version/parent
if I compile from the root-project directory, all compile fine.
if I compile from the proj2 directory, maven2 resolve proj2-${my.version}
resolve proj1-${my.version}
but tries to resolve the parent version root-project-${my.version} but this
is not resolved.
--
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-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:all-tabpanel ] Brett Porter updated MNG-2720: -- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.1.0-M3 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 Fix For: 2.1.0-M3 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] Updated: (MNG-3018) pluginManagement configurations are not honoured when plugin is silently included
[ http://jira.codehaus.org/browse/MNG-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3018: -- Affects Version/s: 3.0-alpha-1 Fix Version/s: (was: Reviewed Pending Version Assignment) 3.0-alpha-3 pluginManagement configurations are not honoured when plugin is silently included - Key: MNG-3018 URL: http://jira.codehaus.org/browse/MNG-3018 Project: Maven 2 Issue Type: Bug Components: Embedding Affects Versions: 3.0-alpha-1 Reporter: Michael Semb Wever Fix For: 3.0-alpha-3 Read http://jira.codehaus.org/browse/MEVENIDE-532 In my top parent pom.xml i've define the maven-compiler-plugin configuration like: build pluginManagement plugins plugin artifactIdmaven-compiler-plugin/artifactId configuration source1.5/source target1.5/target encodingUTF-8/encoding /configuration /plugin ... since not all my subprojects require the plugin, and when they do they silently include the plugin, it makes more sense to define it within the pluginManagement tag. But when i use mevenide-netbeans all my projects are marked uncompilable since the maven embedder does not report the above defined configuration for the maven-compiler-plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3249) Profile resident POM element overrides do not effect inherited projects if the children have their own explicitly defined elements.
[ http://jira.codehaus.org/browse/MNG-3249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3249. - Resolution: Duplicate Fix Version/s: (was: Reviewed Pending Version Assignment) Profile resident POM element overrides do not effect inherited projects if the children have their own explicitly defined elements. --- Key: MNG-3249 URL: http://jira.codehaus.org/browse/MNG-3249 Project: Maven 2 Issue Type: Bug Components: Profiles Affects Versions: 2.0.7 Reporter: John Allen If i declare a profile in a base pom that overrides settings in the POM, those settings are only overridden in the base POM and not in the inherited children in a reactor build if the children also explicitly define their own values for those overridden settings. I almost didn't create this as you could argue that that is how children maintain control but I think the profile evaluation should be applied to each level of the hierarchy, as the inheritance model is built up, i.e. I expect the children to inherit the profile too, not just the application of that profile to it's ancestors state and thus that profile should applied to the child's model, after the rest of the child's inherited state has been established, and thus it should still override the child's settings. -- 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] Moved: (MASSEMBLY-376) baseDirectory tag unrecognised for assembly
[
http://jira.codehaus.org/browse/MASSEMBLY-376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter moved MNG-2707 to MASSEMBLY-376:
-
Affects Version/s: (was: 2.0.4)
Fix Version/s: (was: Reviewed Pending Version Assignment)
Component/s: (was: Plugins and Lifecycle)
Key: MASSEMBLY-376 (was: MNG-2707)
Project: Maven 2.x Assembly Plugin (was: Maven 2)
baseDirectory tag unrecognised for assembly
---
Key: MASSEMBLY-376
URL: http://jira.codehaus.org/browse/MASSEMBLY-376
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Environment: Windows XP
Reporter: Richard King
When I add the baseDirectorydir/baseDirectory tags I get the following
error:
The XML provided is part of a profile that is selected voa the command line.
Embedded error: Unrecognised tag: 'baseDirectory' (position: START_TAG seen
.../includeBaseDirectory\n baseDirectory... @7:18)
The xml is as follows:
assembly
idall/id
formats
formatdir/format
/formats
includeBaseDirectorytrue/includeBaseDirectory
baseDirectory${FATTOUSH_HOME}/baseDirectory
moduleSets
moduleSet
includes
includecom.cellectivity:account/include
includecom.cellectivity:administration/include
includecom.cellectivity:bet/include
includecom.cellectivity:casino/include
includecom.cellectivity:dating/include
includecom.cellectivity:image/include
includecom.cellectivity:portal/include
includecom.cellectivity:provisioning/include
includecom.cellectivity:registration/include
includecom.cellectivity:router/include
includecom.cellectivity:vendor/include
/includes
binaries
outputDirectorywebapps/${artifactId}/outputDirectory
includeDependenciestrue/includeDependencies
unpackfalse/unpack
/binaries
/moduleSet
moduleSet
includes
includecom.cellectivity:fattoush-app-administration/include
includecom.cellectivity:fattoush-agent-bet/include
includecom.cellectivity:fattoush-app-bet/include
includecom.cellectivity:fattoush-agent-spark/include
includecom.cellectivity:fattoush-app-dating/include
includecom.cellectivity:fattoush-app-provisioning/include
includecom.cellectivity:fattoush-app-registration/include
includecom.cellectivity:fattoush-app-account/include
includecom.cellectivity:fattoush-app-image/include
includecom.cellectivity:fattoush-product/include
includecom.cellectivity:fattoush-app-vendor/include
includecom.cellectivity:fattoush-app-portal/include
includecom.cellectivity:fattoush-app-casino/include
includecom.cellectivity:fattoush-app-partygaming/include
/includes
binaries
outputDirectorylib/outputDirectory
includeDependenciestrue/includeDependencies
unpackfalse/unpack
/binaries
/moduleSet
/moduleSets
/assembly
--
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-2940) Add a method to the embedder to list available versions of an artifact
[ http://jira.codehaus.org/browse/MNG-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158506#action_158506 ] Brett Porter commented on MNG-2940: --- Carlos, is this still needed? Add a method to the embedder to list available versions of an artifact -- Key: MNG-2940 URL: http://jira.codehaus.org/browse/MNG-2940 Project: Maven 2 Issue Type: New Feature Components: Embedding Affects Versions: 3.0 Reporter: Carlos Sanchez Assignee: Jason van Zyl Fix For: Reviewed Pending Version Assignment Attachments: patch.txt, patch.txt I've added a method following the style of the resolve method already present public void resolve( Artifact artifact, List remoteRepositories, ArtifactRepository localRepository ) throws ArtifactResolutionException, ArtifactNotFoundException -- 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: (MNG-2597) Profile in POM does not modify dependencies
[ http://jira.codehaus.org/browse/MNG-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2597. - Assignee: Brett Porter Resolution: Cannot Reproduce Fix Version/s: (was: Reviewed Pending Version Assignment) works for me in 2.1.0-M1 Profile in POM does not modify dependencies --- Key: MNG-2597 URL: http://jira.codehaus.org/browse/MNG-2597 Project: Maven 2 Issue Type: Bug Components: Profiles Affects Versions: 2.0.4 Reporter: Steven Coco Assignee: Brett Porter Attachments: artifact.zip When some plugin is declared in the main build with a given set of dependencies, some profile which also declares that plugin in its build section is not able to augment the dependencies: only the dependencies specified in the main build declaration are used. A test case is enclosed. To see the bug: copy the contents of one of broken-pom-1, broken-pom-2, or working-pom to the pom.xml file, and then Execute Maven on the POM's default goal. -- 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-2811) issue description: 'Plugin dependencies override maven core artifacts causing NoClassDefFoundErrors'
[ http://jira.codehaus.org/browse/MNG-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2811: -- Fix Version/s: (was: Reviewed Pending Version Assignment) issue description: 'Plugin dependencies override maven core artifacts causing NoClassDefFoundErrors' - Key: MNG-2811 URL: http://jira.codehaus.org/browse/MNG-2811 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.4 Environment: OS agnostic, maven 2.0.4, jdk1.5 Reporter: David J. M. Karlsen Priority: Blocker Attachments: 17artifactmultibulid.run1.log, 4artifact.filtered.log Usecase: wipe the local .m2 repo totally away. (rm -rf ~/.m2/repository) do a: mvn -X clean deploy site-deploy. Attached is the output from two different projects (one is a 4 artifact project - including the top pom, the other is a multibuild of 17 artifacts, also including top-pom). If I just re-run the mvn -X clean deploy site-deploy the builds will eventually succeed. I'll try to narrow down the pom's to pin down the failure with as little dependencies and plugins in action as possible - but this will take some time. I can be pinged at da...@codehaus.org or da...@davidkarlsen.com for re-running builds if needed. The logs are a little anonymized. -- 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-3402) MavenArtifactFilterManager needs to not filtering doxia-sink-api
[ http://jira.codehaus.org/browse/MNG-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3402: -- Fix Version/s: (was: 2.0.11) 2.1.0-M3 MavenArtifactFilterManager needs to not filtering doxia-sink-api Key: MNG-3402 URL: http://jira.codehaus.org/browse/MNG-3402 Project: Maven 2 Issue Type: Improvement Components: Artifacts and Repositories Affects Versions: 2.0.8 Reporter: Vincent Siveton Fix For: 2.1.0-M3 Attachments: MavenArtifactFilterManager.diff A plugin (like pdf-plugin) needs to use the most recent sink API and not the API embedded in maven. -- 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-3602) Schedule and release Doxia-1.1
[ http://jira.codehaus.org/browse/MNG-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3602: -- Summary: Schedule and release Doxia-1.1 (was: Schedule and release Doxia-1.0-beta-1) Schedule and release Doxia-1.1 -- Key: MNG-3602 URL: http://jira.codehaus.org/browse/MNG-3602 Project: Maven 2 Issue Type: Task Affects Versions: 2.0.10 Reporter: Lukas Theussl Fix For: 2.1.0-M3 See http://docs.codehaus.org/display/MAVEN/Doxia+Release+Plan -- 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-3602) Schedule and release Doxia-1.0-beta-1
[ http://jira.codehaus.org/browse/MNG-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3602: -- Fix Version/s: (was: 2.0.11) 2.1.0-M3 Schedule and release Doxia-1.0-beta-1 - Key: MNG-3602 URL: http://jira.codehaus.org/browse/MNG-3602 Project: Maven 2 Issue Type: Task Affects Versions: 2.0.10 Reporter: Lukas Theussl Fix For: 2.1.0-M3 See http://docs.codehaus.org/display/MAVEN/Doxia+Release+Plan -- 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: (MNG-2515) The Embedder does not work when started from a groovy script that is started from maven 2
[ http://jira.codehaus.org/browse/MNG-2515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2515. - Assignee: Brett Porter Resolution: Won't Fix Fix Version/s: (was: Reviewed Pending Version Assignment) I expect only running the embedder for the current version of Maven, once available, will work unless you fork which can probably be handled separately The Embedder does not work when started from a groovy script that is started from maven 2 - Key: MNG-2515 URL: http://jira.codehaus.org/browse/MNG-2515 Project: Maven 2 Issue Type: Bug Components: Embedding Affects Versions: 2.0-alpha-1 Environment: Windows XP, JDK 1.5, Maven 2.0.4 Reporter: Christian Domsch Assignee: Brett Porter Attachments: embedder-it-test.zip The deploymentserver:changestage plugin starts a groovy script that again starts a maven 2.1-SNAPSHOT embedder. This fails due to classloading issues because the classloader for the groovy script contains a thread context classloader a s a parent. This parent classloader contains all classes from the maven 2.0.4 process that started the plugin. The embedder now fails to start because the parent classloader contains conflicting classes from 2.0.4 while the embedder is 2.1-SNAPSHOT. The test case in the zip contains the source for the deploymentserver-mojo and the projects that this mojo should operate on. To start the test, install the mojo, and start maven in the productA project with mvn deploymentserver:changestage. For this to work the settings.xml must contain pluginGroups pluginGroupinnowake.lifecycle.deployment.engine.plugin/pluginGroup /pluginGroups The zip also contains the groovy jars to be copied in the local repository. Greetings, Christian. -- 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-3885) Modules of Maven-Projects are deployed with Timestamp when uniqueVersion is set to false
[ http://jira.codehaus.org/browse/MNG-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158510#action_158510 ] Brett Porter commented on MNG-3885: --- do your child modules declare a repository as well? Modules of Maven-Projects are deployed with Timestamp when uniqueVersion is set to false Key: MNG-3885 URL: http://jira.codehaus.org/browse/MNG-3885 Project: Maven 2 Issue Type: Bug Components: Deployment Affects Versions: 2.0.8 Environment: Red Hat Linux, Maven 2.0.8, Java 1.6, Cruisecontrol Reporter: Matthias Wegerhoff Attachments: minimizedPOM.xml, minimizedPOM.xml, minimizedSETTINGS.xml When deploying artifacts into local repository with cruisecontrol by using the following command: mvn -U -P mvn-profile ... -DuniqueVersion=false deploy The parent is always beeing deployed correctly, without timestamp as MODULE_VERSION-SNAPSHOT. But all Modules are beeing deployed with Timestamp. -- 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-374) unable to conect to repository
unable to conect to repository -- Key: MSITE-374 URL: http://jira.codehaus.org/browse/MSITE-374 Project: Maven 2.x Site Plugin Issue Type: Bug Components: site:deploy Affects Versions: 2.0-beta-7 Environment: Windows visa professionnal french eclipse plugin Reporter: Jean-Philippe Gravel Unable to connect to remote repository using sftp or scp. Conecting to shell.sourceforge.net. Tried to connect using Putty before the using mvn site:deploy without success. Tried to connect using ssh in Cygwin and then copied the file known_hosts to C:\Users\jpgravel\.ssh without success too. * Note that my private key have been exported to the OpenSSH format using Putty. The following error occurs: Using private key: C:\Users\jpgravel\.ssh\sourceforge_priv sftp://web.sourceforge.net/home/groups/b/bt/btb/htdocs - Session: Disconnecting sftp://web.sourceforge.net/home/groups/b/bt/btb/htdocs - Session: Disconnected [ERROR] The following mojo encountered an error while executing: Group-Id: org.apache.maven.plugins Artifact-Id: maven-site-plugin Version: 2.0-beta-7 Mojo: deploy brought in via: Direct invocation While building project: Group-Id: net.sf.btb Artifact-Id: bridge Version: 1.1.0 From file: C:\Users\jpgravel\workspace\java\BridgeToBabylon\pom.xml Reason: Error uploading site When run wih -e I get the following exception: org.apache.maven.wagon.providers.ssh.knownhost.UnknownHostException: The host was not known and was not accepted by the configuration: web.sourceforge.net at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:178) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143) at org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:106) at org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:579) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149) at org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223) at org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1) at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904) at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176) at org.apache.maven.cli.MavenCli.main(MavenCli.java:63) at org.apache.maven.cli.MavenCli.main(MavenCli.java:52) Caused by: com.jcraft.jsch.JSchException: reject HostKey: web.sourceforge.net at com.jcraft.jsch.Session.checkHost(Unknown Source) at com.jcraft.jsch.Session.connect(Unknown Source) at com.jcraft.jsch.Session.connect(Unknown Source) at org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:158) ... 17 more Error stacktrace: org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-site-plugin:2.0-beta-7:deploy': Mojo execution failed. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:505) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149) at org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223) at org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1) at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904) at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:176) at
[jira] Closed: (MNG-2711) Maven cannot share properties with other tools (e.g. ant)
[ http://jira.codehaus.org/browse/MNG-2711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2711. - Assignee: Brett Porter Resolution: Won't Fix Fix Version/s: (was: Reviewed Pending Version Assignment) Maven requires the properties in the POM so that it is self-contained in the repository. I suggest using the Maven ant tasks to load the POM and retrieve the properties from there, making it your central storage. Maven cannot share properties with other tools (e.g. ant) - Key: MNG-2711 URL: http://jira.codehaus.org/browse/MNG-2711 Project: Maven 2 Issue Type: Improvement Components: POM, Profiles, Settings Affects Versions: 2.0.4 Reporter: Aaron Digulla Assignee: Brett Porter I have a project which is built with Ant *and* Maven. It installs/deploys a set of third party JARs to our inhouse repository. Basically, I'm using Ant to invoke Maven several times to install each JAR. In Ant, I can export the properties to a file but maven can't do this. Therefore, I have to define all properties at least twice. I suggest to add a new element propertyFiles to the POM, Profiles and settings.xml where you can specify a list of files to be read. If a property is defined twice, the latest definition should win (unlike Ant), so you can control the properties using profiles. -- 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-2478) add filtered resource directories to super POM
[ http://jira.codehaus.org/browse/MNG-2478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2478: -- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.2.0-M1 add filtered resource directories to super POM -- Key: MNG-2478 URL: http://jira.codehaus.org/browse/MNG-2478 Project: Maven 2 Issue Type: New Feature Components: POM Affects Versions: 2.0.4 Environment: any Reporter: Jörg Hohwiller Fix For: 2.2.0-M1 The super POM contains default folders for resources that are NOT filtered (src/main/resources and src/test/resources). If one (additionally) needs a filtered resources folder, it needs to override the default and therefore has to add all default folders if he does NOT want to loose the defaults. To make this easier my suggestion is to add filtered resource folders to the super POM. This should also fit to the philosophy of maven that aims to have defaults and only declare as little custom configuration as needed. My personal favorite for the foldernames would be templates but to make things more obvious to the user maybe filtered-resources would be better. Actually I do not care to much about the name... So the resources in the super POM should look like this: resources resource directorysrc/main/resources/directory /resource !-- BEGIN: addition -- resource directorysrc/main/filtered-resources/directory filteringtrue/filtering /resource !-- END: addition -- /resources testResources testResource directorysrc/test/resources/directory /testResource !-- BEGIN: addition -- testResource directorysrc/test/filtered-resources/directory filteringtrue/filtering /testResource !-- END: addition -- /testResources -- 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-2605) Profiles in profiles.xml are active by default
[ http://jira.codehaus.org/browse/MNG-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2605: -- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.x Profiles in profiles.xml are active by default -- Key: MNG-2605 URL: http://jira.codehaus.org/browse/MNG-2605 Project: Maven 2 Issue Type: Bug Components: Profiles Affects Versions: 2.0.4 Environment: windows 2000 Reporter: Attila Mezei-Horvati Fix For: 2.0.x Attachments: my-app.zip Profile specification on command line is ignored and all profiles are active. How to reproduce: - open attachment - extract to folder - type: cd my-app - type: mvn help:active-profiles -Pproduction - you get the following: The following profiles are active: - skipunittest (source: profiles.xml) - test (source: profiles.xml) - production (source: profiles.xml) - you should get: The following profiles are active: - production (source: profiles.xml) thanks, Attila -- 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-264) prepare mojo calls package, not install
[ http://jira.codehaus.org/browse/MRELEASE-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158512#action_158512 ] David J. M. Karlsen commented on MRELEASE-264: -- Here is a thread which show's how this is a problem when using the dependency plugin w/ a dependency from the reactor build: http://www.nabble.com/release%3Aprepare-amusement-with-the-dependency-plugin-td21063104.html prepare mojo calls package, not install - Key: MRELEASE-264 URL: http://jira.codehaus.org/browse/MRELEASE-264 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-4 Reporter: Stefan Behnel The prepare mojo calls mvn package for the build after adapting the POM versions. This results in build failures if the project has interdependencies between modules (a rather common case). The problem is that the new version has not been deployed so far, so the required module artifacts are not yet available from the repository. The mojo should call mvn install to make artifacts available to the running build process. -- 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: (MNG-2970) Improve mvn script for CI builds: mavenrc_pre / mavenrc_post
[ http://jira.codehaus.org/browse/MNG-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2970. - Assignee: Brett Porter Resolution: Won't Fix Fix Version/s: (was: Reviewed Pending Version Assignment) there is already a .mavenrc in the unix scripts, just no post. However it rarely needs cleanup like the windows bath files do - do you have a use case for a post script? Improve mvn script for CI builds: mavenrc_pre / mavenrc_post Key: MNG-2970 URL: http://jira.codehaus.org/browse/MNG-2970 Project: Maven 2 Issue Type: Improvement Components: Command Line Affects Versions: 2.0.6 Reporter: Vincent Siveton Assignee: Brett Porter CI builds need specific settings like environment or specific OS tasks. Some ideas to improve the mvn script: * add a setenv script before calling maven * add a pre/post hook scripts between maven call -- 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-2480) Support for different types of version ranges in dependencies
[ http://jira.codehaus.org/browse/MNG-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2480: -- Fix Version/s: (was: Reviewed Pending Version Assignment) 3.x Support for different types of version ranges in dependencies - Key: MNG-2480 URL: http://jira.codehaus.org/browse/MNG-2480 Project: Maven 2 Issue Type: Improvement Components: Dependencies Affects Versions: 2.0.4 Environment: n/a Reporter: Peter Monks Fix For: 3.x G'day, It would be ideal if Maven supported different types of dependency version ranges, to allow for more flexible dependency version resolution. For example, if I was the provider of an open source library I might like to be able to state that my code is dependent on some other library, and in the dependency version section be able to say that it's been tested with one or two specific versions (say [1.1,1.2]), but should theoretically work over a range of versions (say [1.1,2.0) ). In this example the two version ranges might be called the soft range and the hard range (or certified and uncertified or whatever - the idea is what's important, not the terminology). Currently many of the poms for open source libraries in the public Maven repositories specify precise version numbers which invariably causes version mismatches (which then tickles bug MNG-2123, but that's another story...). I suspect that one of the reasons that open source teams do this is because they've only tested their code against one version of each library they're dependent upon, so it's understandable that they don't want to put a wider range of version numbers in their poms. But this increases the changes of a version number mismatch which forces the ultimate consumer of the library (and its dependencies) to manually fiddle with poms until the various version number ranges overlap. If it were possible to specify hard vs soft version number ranges in the poms directly, then open source providers may have more incentive to be more permissive in their version number ranges, while still making it clear which versions of their dependencies they've actually tested against. Cheers, Peter -- 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: (MNG-2550) ClassNotFoundException and NoClassDefFoundError when running plugin
[ http://jira.codehaus.org/browse/MNG-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2550. - Assignee: Brett Porter Resolution: Not A Bug Fix Version/s: (was: Reviewed Pending Version Assignment) from what I can tell, this was a commons issue, not a Maven issue ClassNotFoundException and NoClassDefFoundError when running plugin --- Key: MNG-2550 URL: http://jira.codehaus.org/browse/MNG-2550 Project: Maven 2 Issue Type: Bug Components: Plugins and Lifecycle Affects Versions: 2.0.4 Reporter: Joost den Boer Assignee: Brett Porter I created a plugin which runs a small application which does some parsing, logging and serializing. When running the plugin I get ClassNotFoundExceptions and NoClassDefFoundErrors. The application used BeanUtils (1.7). Somewhere in that package a Log instance is created, but the classloader cannot find org.apache.log4j.Logger and an NoClassDefFoundError is thrown. The application serializes objects to a file using the ObjectOutputStream and ObjectInputStream. Serializing to a file works fine. Serializing from file to an Object throws a ClassNotFoundException because the base classloader does not know any object from any dependency. Both errors are caused by the classloader not knowing any of the dependend packages of the Maven project in which the plugin is used or on which the plugin depends. I tried several solutions: using my own URLClassLoader extention and using ClassWorld and creating a new ClassRealm. To both I added all project.RuntimeClasspathElements. These solutions fixed some problems but not all. In some cases the original classloader is still used (by included packages like org.apache.common.logging or by base java classes like java.io.ObjectInputStream) and that classloaded does not know my project classes and dependend packages. Can't maven itself not just include all dependend packages of the project (and plugin) on the classpath so you don't have to do that yourself inside the plugin ? I searched for similar bugs and found some but they are all fixed and closed in older maven version. Can someone please help me with this issue ? Here part of the stacktrace. As you can see, the ObjectInputStream uses Class.forName() which resolves to the RealmClassLoader, but not to my MyURLClassLoader instance. java.lang.ClassNotFoundException: nl.eid.aegon.rpf.parser.model.ClassDescription at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274) at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:274) at org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:584) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1543) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1465) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1698) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1304) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349) Here the stacktrace for the NoClassDefFoundError. It starts when I try to log something in the application using org.apache.common.logging. The only way I could solve this was to put the log4j package in the Maven lib directory, but this is not a prefered solution. The log4j.jar is a dependend package and should be included on the classpath by the classloader. [INFO] [INFO] Trace java.lang.ExceptionInInitializerError at nl.eid.replatforming_framework.parser.Parser.parse(Parser.java:45) at nl.eid.replatforming_framework.maven.RunAllMojo.runAll(RunAllMojo.java:404) at nl.eid.replatforming_framework.maven.RunAllMojo.execute(RunAllMojo.java:139) at
[jira] Closed: (MNG-3034) Import a profile into a POM
[ http://jira.codehaus.org/browse/MNG-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-3034. - Assignee: Brett Porter Resolution: Won't Fix Fix Version/s: (was: Reviewed Pending Version Assignment) is specific use case is unlikely to be addressed, however full-fledged mix-ins are expected for the POM in a future version. You might also look at Don Brown's itblast plugin that helps with this use case. Import a profile into a POM --- Key: MNG-3034 URL: http://jira.codehaus.org/browse/MNG-3034 Project: Maven 2 Issue Type: Improvement Components: Profiles Affects Versions: 2.0.6 Reporter: Paul Spencer Assignee: Brett Porter I am finding that profiles are very powerful. As I make more use of them across projects, many of which are unrelated, I find myself copying a profile from one POM to another. Placing profiles in a POM the is extended is impractical because each change to a profile in the POM will prompt a release cycle of the POM and every project that extends the POM. Related thread: http://www.mail-archive.com/us...@maven.apache.org/msg67252.html Below is how I would expect to use profile importing. *** * POM of project which imports the profiles cargo_tomcat_remote and * cargo_jetty_remote and selenium-integration-test. *** project ... groupIdcom.foo.applications/groupId artifactIdwebapp_1/artifactId ... profiles profile idcargo_tomcat_remote/id groupIdcom.foo.profiles/groupId artifactIdcargo/artifactId version1.0/version activation ... /activation /profile profile idcargo_jetty_remote/id groupIdcom.foo.profiles/groupId artifactIdcargo/artifactId version1.0/version !-- used activation rules in imported profile -- ... /profile profile idselenium-integration-test/id groupIdcom.foo.profiles/groupId artifactIdselenium/artifactId version1.0/version !-- used activation rules in imported profile -- ... /profile /project *** * POM of project which defines 2 profiles, cargo_tomcat_remote and * cargo_jetty_remote. *** project ... groupIdcom.foo.profiles/groupId artifactIdcargo/artifactId version1.0/version ... profiles profile idcargo_tomcat_remote/id ... /profile profile idcargo_jetty_remote/id activation ... /activation /profile /project Paul Spencer -- 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: (MNG-369) run yourkit over m2 again
[ http://jira.codehaus.org/browse/MNG-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-369. Assignee: Brett Porter Resolution: Won't Fix Fix Version/s: (was: Reviewed Pending Version Assignment) we need to constantly monitor this, not just do a once off. John recently did some work in this area. run yourkit over m2 again - Key: MNG-369 URL: http://jira.codehaus.org/browse/MNG-369 Project: Maven 2 Issue Type: Task Components: Performance Reporter: Brett Porter Assignee: Brett Porter Priority: Trivial re-run yourkit over the majority of operations and unit tests to verify we have managed to keep the app without any memory leaks. -- 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-1439) Organization Object Model (OOM)
[ http://jira.codehaus.org/browse/MNG-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1439: -- Fix Version/s: (was: Reviewed Pending Version Assignment) 3.x another use case for mixins? Organization Object Model (OOM) Key: MNG-1439 URL: http://jira.codehaus.org/browse/MNG-1439 Project: Maven 2 Issue Type: New Feature Components: Design, Patterns Best Practices, POM Reporter: Jason van Zyl Priority: Trivial Fix For: 3.x Would be cool to start capturing organizational information and just use a reference from projects to the OOM. -- 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-1440) Developer Object Model (DOM)
[ http://jira.codehaus.org/browse/MNG-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1440: -- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.2.0-M1 Component/s: POM this one seems well worth splitting out in a revision of the POM since inheritance is rarely granular enough to express it properly. Developer Object Model (DOM) Key: MNG-1440 URL: http://jira.codehaus.org/browse/MNG-1440 Project: Maven 2 Issue Type: New Feature Components: Design, Patterns Best Practices, POM Reporter: Jason van Zyl Priority: Trivial Fix For: 2.2.0-M1 Would be cool to be able to reference a developer by id from any POM and get their full range of 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: (MNG-2866) MavenProject objects of dependencies should be made available
[ http://jira.codehaus.org/browse/MNG-2866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2866: -- Fix Version/s: (was: Reviewed Pending Version Assignment) 3.x review with Mercury MavenProject objects of dependencies should be made available - Key: MNG-2866 URL: http://jira.codehaus.org/browse/MNG-2866 Project: Maven 2 Issue Type: Improvement Components: Dependencies Affects Versions: 2.0.4 Reporter: Kohsuke Kawaguchi Fix For: 3.x Maven parses POM files of dependency jars recursively by using MavenMetadataSource.retrieve(). It needs to do so to find out the transitive dependencies. But currently, the parsed MavenProject object is immediately thrown away after dependency list is fetched from it. POM files contain various useful information, so I'd like Maven to keep MavenProject somewhere so that I can access it from my plugin. Possible use cases include: - find out all the licenses used in your dependency and generate a 3rd-party-license.txt - use information in POM to perform custom packaging -- 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-3885) Modules of Maven-Projects are deployed with Timestamp when uniqueVersion is set to false
[ http://jira.codehaus.org/browse/MNG-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158518#action_158518 ] Matthias Wegerhoff commented on MNG-3885: - No, they lust define their parent: parent artifactIdexample/artifactId groupIdde.myCompany/groupId versiontrunk-SNAPSHOT/version relativePath../pom.xml/relativePath /parent Do I have to add an seperate profile/distributionManagement section in every child-pom? Modules of Maven-Projects are deployed with Timestamp when uniqueVersion is set to false Key: MNG-3885 URL: http://jira.codehaus.org/browse/MNG-3885 Project: Maven 2 Issue Type: Bug Components: Deployment Affects Versions: 2.0.8 Environment: Red Hat Linux, Maven 2.0.8, Java 1.6, Cruisecontrol Reporter: Matthias Wegerhoff Attachments: minimizedPOM.xml, minimizedPOM.xml, minimizedSETTINGS.xml When deploying artifacts into local repository with cruisecontrol by using the following command: mvn -U -P mvn-profile ... -DuniqueVersion=false deploy The parent is always beeing deployed correctly, without timestamp as MODULE_VERSION-SNAPSHOT. But all Modules are beeing deployed with Timestamp. -- 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-3885) Modules of Maven-Projects are deployed with Timestamp when uniqueVersion is set to false
[ http://jira.codehaus.org/browse/MNG-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3885: -- Attachment: MNG-3885.zip I can't reproduce the problem. See attached test case Modules of Maven-Projects are deployed with Timestamp when uniqueVersion is set to false Key: MNG-3885 URL: http://jira.codehaus.org/browse/MNG-3885 Project: Maven 2 Issue Type: Bug Components: Deployment Affects Versions: 2.0.8 Environment: Red Hat Linux, Maven 2.0.8, Java 1.6, Cruisecontrol Reporter: Matthias Wegerhoff Attachments: minimizedPOM.xml, minimizedPOM.xml, minimizedSETTINGS.xml, MNG-3885.zip When deploying artifacts into local repository with cruisecontrol by using the following command: mvn -U -P mvn-profile ... -DuniqueVersion=false deploy The parent is always beeing deployed correctly, without timestamp as MODULE_VERSION-SNAPSHOT. But all Modules are beeing deployed with Timestamp. -- 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-1439) Organization Object Model (OOM)
[ http://jira.codehaus.org/browse/MNG-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1439: -- Component/s: POM Organization Object Model (OOM) Key: MNG-1439 URL: http://jira.codehaus.org/browse/MNG-1439 Project: Maven 2 Issue Type: New Feature Components: Design, Patterns Best Practices, POM Reporter: Jason van Zyl Priority: Trivial Fix For: 3.x Would be cool to start capturing organizational information and just use a reference from projects to the OOM. -- 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] Reopened: (MNG-2970) Improve mvn script for CI builds: mavenrc_pre / mavenrc_post
[ http://jira.codehaus.org/browse/MNG-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton reopened MNG-2970: -- I think we need leave it open for the discussion. The use case was to do a clean staging of a webapp into Tomcat: - prehook: shutdown Tomcat, install latest Tomcat, remove DB schema - maven: build project and deploy it into Tomcat - posthook: install DB schema, configure webapp and Tomcat, restart Tomcat. Improve mvn script for CI builds: mavenrc_pre / mavenrc_post Key: MNG-2970 URL: http://jira.codehaus.org/browse/MNG-2970 Project: Maven 2 Issue Type: Improvement Components: Command Line Affects Versions: 2.0.6 Reporter: Vincent Siveton Assignee: Brett Porter CI builds need specific settings like environment or specific OS tasks. Some ideas to improve the mvn script: * add a setenv script before calling maven * add a pre/post hook scripts between maven call -- 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-2735) Remove all application logging from DefaultMaven downward
[ http://jira.codehaus.org/browse/MNG-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2735: -- Fix Version/s: (was: Reviewed Pending Version Assignment) 3.x Remove all application logging from DefaultMaven downward - Key: MNG-2735 URL: http://jira.codehaus.org/browse/MNG-2735 Project: Maven 2 Issue Type: Task Components: Embedding Reporter: Jason van Zyl Assignee: Jason van Zyl Fix For: 3.x All the logging methods in DefaultMaven need to be removed and replaced with monitoring/eventing calls. -- 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: (MNG-2479) add support for optional 'packagingName' element in dependency blocks
[ http://jira.codehaus.org/browse/MNG-2479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2479. - Resolution: Won't Fix Fix Version/s: (was: Reviewed Pending Version Assignment) the call for this seems to have evaporated over the past couple of years as the EE plugins have become capable at naming their dependencies. It's unlikely we'll modify the dependency model significantly in the near future due to the implications for the repository. add support for optional 'packagingName' element in dependency blocks - Key: MNG-2479 URL: http://jira.codehaus.org/browse/MNG-2479 Project: Maven 2 Issue Type: New Feature Components: Dependencies Affects Versions: 2.0.4 Reporter: Ian Springer The various deployment artifact types (war, ear, sar, etc.) package their dependencies within the target archive during the package phase. For example, the war plugin includes jar dependencies within WEB-INF/lib, and the ear plugin includes jar and J2EE dependencies at the top level. Sometimes it is not desirable to package the dependencies with their full Maven-repo-style names (i.e. artifactName-version.xar). In particular, the version component is often not desired. Currently, some plugins provide a way to rename these dependency artifacts when they are packaged (e.g. the ear plugin), and others do not (e.g. the war plugin), making it necessary to use an antrun or dependency plugin hack to rename the artifacts as desired. I think it would be much nicer if there was a standard way to specify a packaging name (or whatever other name makes sense) for a dependency in its dependency block in the pom. Then all plugins that package their dependencies could leverage this standard setting. Here is an example of a war dependency declared in an ear pom: dependency groupIdorg.jboss.on/groupId artifactIdon-enterprise-gui-portal/artifactId version2.0-SNAPSHOT/version typewar/type packagingNameon-portal/packagingName /dependency This would cause the war to be bundled in the ear with the filename on-portal.war, instead of the default on-enterprise-gui-portal-2.0-SNAPSHOT.war. -- 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: (MNG-2613) Unresolved dependencies in intermediate projects when using dependencyManagement tag in multi-module builds
[ http://jira.codehaus.org/browse/MNG-2613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2613. - Assignee: Brett Porter Resolution: Incomplete Fix Version/s: (was: Reviewed Pending Version Assignment) not enough info to reproduce Unresolved dependencies in intermediate projects when using dependencyManagement tag in multi-module builds --- Key: MNG-2613 URL: http://jira.codehaus.org/browse/MNG-2613 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.5 Environment: maven-2.0.5-SNAPSHOT-20060917.124500 Reporter: Joseph Marques Assignee: Brett Porter I have a nested project with the follow structure: root/intermediate1/intermediate2/leaf In this setup, each child level is a module of the parent, and each child's POM derives from the parent POM. If I execute 'mvn help:effective-pom' at root or leaf, it works fine. However, the following error message will be thrown when I try to validate the POM at any intermediate level: Validation Messages: [0] 'dependencies.dependency.version' is missing for DEP_1 [...] 'dependencies.dependency.version' is missing for DEP_... [N] 'dependencies.dependency.version' is missing for DEP_N Reason: Failed to validate POM [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Failed to validate POM at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:370) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:283) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:120) at org.apache.maven.cli.MavenCli.main(MavenCli.java:263) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to validate POM at org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:941) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:752) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:423) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:520) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:452) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:496) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:356) ... 11 more [INFO] [INFO] Total time: 1 second [INFO] Finished at: Sun Sep 17 10:33:24 EDT 2006 [INFO] Final Memory: 1M/127M [INFO] This doesn't just affect the help:effective-pom goal; it throws this error whenever it has to walk the dependency graph. So, for instance, I can't execute 'mvn install' or 'mvn grafo:grafo'. -- 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-2546) Allow plugin executions in the super-init phase before reactor sorting of modules build order
[ http://jira.codehaus.org/browse/MNG-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2546: -- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.2.0-M1 this was recently discussed again on Maven dev for a different use case Allow plugin executions in the super-init phase before reactor sorting of modules build order --- Key: MNG-2546 URL: http://jira.codehaus.org/browse/MNG-2546 Project: Maven 2 Issue Type: Improvement Components: Reactor and workspace Affects Versions: 2.0.4 Reporter: Binyan Assignee: Jason van Zyl Fix For: 2.2.0-M1 Attachments: MNG-2546-maven-core.patch As seen here, http://www.nabble.com/How-to-execute-a-plugin-prior-to-the-reactor-sorting--tf2062739.html#a5682349. I also have the need to bind my maven-pde-plugin to a phase before the reactor sorting of project build order happens. My plugin is being developed to build eclipse plugins, features, fragments, update sites and products. Right now I can build plugins and features. However the order has to constantly be managed by the user taking information from the eclipse descriptors and adding it to the pom file. For plugin projects I can bind to a phase before the compile phase and dynamically analyze the eclipse plugin descriptors and add the necessary dependencies/resources to the MavenProject instance and all is well. For feature projects, I also can dynamically analyze the eclipse feature descriptor and add the necessary resources to the MavenProject instance. However, features depend on other plugins, fragments and features. While I can dynamicaly add the plugins, fragments and features to the MavenProject as dependencies they are not taken into context as the reactor has already computed the sorting order. What would be perfect is if there was a super-init phase that plugins could bind to and be executed in before the normal declared lifecycle happened. Therefore no matter what the lifecycle was, the super-init phase would be available. Then plugins could do things like augmenting the super-pom with build #'s/identifiers, dependencies, dynamic projects, etc all before maven gets going. That would solve the problem myself and others have as well as be 100% backwards compatible. This super-init phase (please pick a better name) would e available to reactor and non-reactor builds. A more specific fix would be to allow plugins to ask the reactor to reevaluate the build order. -- 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-2970) Improve mvn script for CI builds: mavenrc_pre / mavenrc_post
[ http://jira.codehaus.org/browse/MNG-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158527#action_158527 ] Brett Porter commented on MNG-2970: --- usually this would be done within Maven itself - is that a possibility? Improve mvn script for CI builds: mavenrc_pre / mavenrc_post Key: MNG-2970 URL: http://jira.codehaus.org/browse/MNG-2970 Project: Maven 2 Issue Type: Improvement Components: Command Line Affects Versions: 2.0.6 Reporter: Vincent Siveton Assignee: Brett Porter CI builds need specific settings like environment or specific OS tasks. Some ideas to improve the mvn script: * add a setenv script before calling maven * add a pre/post hook scripts between maven call -- 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: (MNG-2528) updatePolicy always does not work for repositories with releases, at least not for transitive dependencies
[ http://jira.codehaus.org/browse/MNG-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2528. - Assignee: Brett Porter Resolution: Won't Fix Fix Version/s: (was: Reviewed Pending Version Assignment) Releases in Maven are, by definition, unchanging. The always flag is to check for new releases (like it looks for new snapshots), not modifications to the existing one. updatePolicy always does not work for repositories with releases, at least not for transitive dependencies -- Key: MNG-2528 URL: http://jira.codehaus.org/browse/MNG-2528 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Reporter: Arne Degenring Assignee: Brett Porter Released versions normally should be final. Once deployed, they should not be upgraded. That's what snapshot versions are for. Anyway, Maven *does* allow to overwrite an existing version in the repository by re-deploying it. Therefore, to make builds repeatable and reproducable, Maven should check for updates even of released versions, not only snapshot versions. I tried to use the following setting: repositories repository releases enabledtrue/enabled updatePolicyalways/updatePolicy /releases ... My project A has a dependency to version 5.0-SNAPSHOT of a JAR B. That JAR B has a dependency to version 1.6 of another JAR C. In my local repository there's an outdated version 1.6 of JAR C (i.e. version 1.6 has been redeployed after a bug has been found). The problem is: During my build of project A Maven is looking for an update of JAR B, but NOT of JAR C. This problem was originally discussed on http://www.nabble.com/-m2--Updates-of-transitive-dependencies-not-working--tf2158398.html -- 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: (MNG-2758) Circular Dependency which shouldn't be
[ http://jira.codehaus.org/browse/MNG-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2758. - Assignee: Brett Porter Resolution: Won't Fix Fix Version/s: (was: Reviewed Pending Version Assignment) Maven has a single lifecycle - it isn't usual to compile an artifact in one step, then come back to package it. IT's intended you can run the package step in one hit. You should split the application POM into two projects so the distribution is separate. Circular Dependency which shouldn't be -- Key: MNG-2758 URL: http://jira.codehaus.org/browse/MNG-2758 Project: Maven 2 Issue Type: Bug Components: Dependencies Reporter: Andrew Franklin Assignee: Brett Porter Attachments: circular-test-case.tar.gz I've got a situation where Maven is telling me I have a circular dependency that should be resolved. Let's say I've got applicationArtifact which provides an interface which I want to consume at compile time in an artifact called pluginArtifact. When applicationArtifact is ready to be packaged, I want to include pluginArtifact in the libs as a runtime dependency. ie. artifactIdapplicationArtifact/artifactId dependencies dependency artifactIdpluginArtifact/artifactId scoperuntime/scope /dependency /dependencies artifactIdpluginArtifact/artifactId dependencies dependency artifactIdapplicationArtifact/artifactId scopecompile/scope !-- such that we can use the common interface -- /dependency /dependencies Maven won't compile the above as it cites a circular dependency. This should work because of the following valid order: 1) compile applicationArtifact (ignore pluginArtifact because it's scoped at Runtime) 2) compile pluginArtifact (include a compile time reference to applicationArtifact) 3) package applicationArtifact (which drags in pluginArtifact) I should also mention the circular dependency comes about because I have a parent pom to these 2 projects which defines them each as modules... ie. artifactIdparentProject/artifactId modules moduleapplicationArtifact/module modulepluginArtifact/module /modules -- 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: (MNG-2627) properties substitutions in exists
[
http://jira.codehaus.org/browse/MNG-2627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-2627.
-
Assignee: Brett Porter
Resolution: Duplicate
Fix Version/s: (was: Reviewed Pending Version Assignment)
properties substitutions in exists
--
Key: MNG-2627
URL: http://jira.codehaus.org/browse/MNG-2627
Project: Maven 2
Issue Type: Bug
Components: Profiles
Affects Versions: 2.0.4
Reporter: Gilles Scokart
Assignee: Brett Porter
The substitution of properties doens't seems to work inside the exists tag in
the pom.xml.
{code}
profiles
profile
activation
file
exists${share}/exists
/file
/activation
build
/build
/profile
/profiles
properties
shareu:\SCOKART_Gilles\Public/share
/properties
{code}
Doesn't seems to work (the profile is not activated),
while :
{code}
profiles
profile
activation
file
existsu:\SCOKART_Gilles\Public/exists
/file
/activation
build
/build
/profile
/profiles
properties
shareu:\SCOKART_Gilles\Public/share
/properties
{code}
activate the profile.
--
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: (MNG-2590) NPE when listed POM repository is missing the id element
[ http://jira.codehaus.org/browse/MNG-2590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2590. - Assignee: Brett Porter Resolution: Cannot Reproduce Fix Version/s: (was: Reviewed Pending Version Assignment) in 2.1.0-M1, a proper error message is given NPE when listed POM repository is missing the id element -- Key: MNG-2590 URL: http://jira.codehaus.org/browse/MNG-2590 Project: Maven 2 Issue Type: Bug Components: Bootstrap Build Affects Versions: 2.0.4 Environment: OS-X 10.4.8 JDK 1.5.0_06 Reporter: Brian Topping Assignee: Brett Porter Priority: Minor I created a remote repository as such: repositories repository nameBrian's Repo/name urlhttp://brian/repository//url /repository /repositories This results in an NPE: java.lang.NullPointerException at org.apache.maven.wagon.repository.Repository.hashCode(Repository.java:239) at java.util.HashMap.hash(HashMap.java:264) at java.util.HashMap.containsKey(HashMap.java:342) at java.util.HashSet.contains(HashSet.java:182) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:964) at org.apache.maven.project.DefaultMavenProjectBuilder.assembleLineage(DefaultMavenProjectBuilder.java:1176) at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:674) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:416) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:192) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) This is because the id element is missing. The schema should be updated such that the id element is mandatory. -- 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: (MNG-1995) filtering element in pom.xml ignore properties
[
http://jira.codehaus.org/browse/MNG-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-1995.
-
Assignee: Shane Isbell
Resolution: Fixed
Fix Version/s: (was: 3.x)
3.0-alpha-1
filtering element in pom.xml ignore properties
--
Key: MNG-1995
URL: http://jira.codehaus.org/browse/MNG-1995
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Environment: Maven 2.0.1
Reporter: Daniel Kulp
Assignee: Shane Isbell
Fix For: 3.0-alpha-1
jvanzyl you can mention it0091 as the test case
The following pom.xml does not end up filtering the resources:
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;
modelVersion4.0.0/modelVersion
groupIdorg.objectweb.celtix/groupId
artifactIdtest/artifactId
packagingjar/packaging
version1.0/version
nameTest/name
properties
filter.resourcestrue/filter.resources
/properties
build
resources
resource
directorysrc/main/resources/directory
includes
include**/include
/includes
filtering${filter.resources}/filtering
/resource
/resources
/build
/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: (MECLIPSE-230) Classpath entries to be marked exported
[ http://jira.codehaus.org/browse/MECLIPSE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158531#action_158531 ] Henrik Larne commented on MECLIPSE-230: --- I am using Eclipse with the Mobile Tools for Java plugin and have the same problem with my compile scoped dependencies not beeing marked exported in the .classpath file. The philosophy of Maven is that the project should be completely described by the pom. The pom has full support for scoping a projects dependencies and I therefore think that the default behavior should be to add the exported=true tag to the .classpath file for all dependencies with compile or runtime scope. If there are eclipse plugins that does not work well with this, they should probably be revised. I have done a patch to the maven-eclipse-plugin version 2.5.1 and 2.6-SNAPSHOT that adds the exported tag to all the dependencies that have scope compile or runtime and are not referenced projects. Please consider adding this to the trunk of the plugin and possibly also the version 2.5.2. Both patches are attached to this issue. Classpath entries to be marked exported --- Key: MECLIPSE-230 URL: http://jira.codehaus.org/browse/MECLIPSE-230 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.1 Reporter: Vlad Skarzhevskyy Assignee: fabrizio giustina Generated .classpath entries of kind var need to be marked exported by default so that referenced projects have visibility to them. Or provide an option to specifiy that that entries should be exported. Example: classpathentry kind=var path=M2_REPO/mx4j/mx4j/3.0.1/mx4j-3.0.1.jar/ should me made... classpathentry exported=true kind=var path=M2_REPO/mx4j/mx4j/3.0.1/mx4j-3.0.1.jar/ -- 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-2970) Improve mvn script for CI builds: mavenrc_pre / mavenrc_post
[ http://jira.codehaus.org/browse/MNG-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158532#action_158532 ] Vincent Siveton commented on MNG-2970: -- Do you mean by developing a plugin? We have already a deploy plugin for the build but scripts are better for the admin tasks IMHO (I mean for an admin guy). This use case is similar to the SVN hooks Improve mvn script for CI builds: mavenrc_pre / mavenrc_post Key: MNG-2970 URL: http://jira.codehaus.org/browse/MNG-2970 Project: Maven 2 Issue Type: Improvement Components: Command Line Affects Versions: 2.0.6 Reporter: Vincent Siveton Assignee: Brett Porter CI builds need specific settings like environment or specific OS tasks. Some ideas to improve the mvn script: * add a setenv script before calling maven * add a pre/post hook scripts between maven call -- 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: (MECLIPSE-230) Classpath entries to be marked exported
[ http://jira.codehaus.org/browse/MECLIPSE-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henrik Larne updated MECLIPSE-230: -- Attachment: exported_classpath_2.5.1.patch exported_classpath_trunk.patch Patch that adds the exported=true to the .classpath files for compile and runtime scoped dependencies that are not referenced projects for both trunk and 2.5.1 Classpath entries to be marked exported --- Key: MECLIPSE-230 URL: http://jira.codehaus.org/browse/MECLIPSE-230 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Components: Core : Dependencies resolution and build path (.classpath) Affects Versions: 2.1 Reporter: Vlad Skarzhevskyy Assignee: fabrizio giustina Attachments: exported_classpath_2.5.1.patch, exported_classpath_trunk.patch Generated .classpath entries of kind var need to be marked exported by default so that referenced projects have visibility to them. Or provide an option to specifiy that that entries should be exported. Example: classpathentry kind=var path=M2_REPO/mx4j/mx4j/3.0.1/mx4j-3.0.1.jar/ should me made... classpathentry exported=true kind=var path=M2_REPO/mx4j/mx4j/3.0.1/mx4j-3.0.1.jar/ -- 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: (MNG-2688) Cannot filter system properties in 2.0.4
[
http://jira.codehaus.org/browse/MNG-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-2688.
-
Assignee: Brett Porter
Resolution: Cannot Reproduce
Fix Version/s: (was: Reviewed Pending Version Assignment)
working in 2.1.0-M1
Cannot filter system properties in 2.0.4
Key: MNG-2688
URL: http://jira.codehaus.org/browse/MNG-2688
Project: Maven 2
Issue Type: Bug
Components: Bootstrap Build
Affects Versions: 2.0.4
Environment: Windows XP, sp2
Reporter: Chad Ellison
Assignee: Brett Porter
I would like to filter a system property, so that a property within my
application.properties files is replaced at runtime. The instructions at
http://maven.apache.org/guides/getting-started/index.html#How%20do%20I%20filter%20resource%20files?
are not working.
Specifically, in my application.propertiies file I have a variable defined
command.line.prop=${command.line.prop} and then when I run...
mvn process-resources -Dcommand.line.prop=hello again
... I would expect the property to be replaced by hello again, but it is
not. It is worth noting that Java variables like ${java.version} are also not
filtered.
--
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: (MNG-2518) maven site error
[ http://jira.codehaus.org/browse/MNG-2518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2518. - Assignee: Brett Porter Resolution: Cannot Reproduce Fix Version/s: (was: Reviewed Pending Version Assignment) should be working now maven site error Key: MNG-2518 URL: http://jira.codehaus.org/browse/MNG-2518 Project: Maven 2 Issue Type: Bug Components: Command Line Affects Versions: 2.0.4 Environment: Maven version: 2.0.4 Reporter: Radu Marian Assignee: Brett Porter While trying to follow this step from http://maven.apache.org/guides/getting-started/index.html: mvn site --- Downloading: http://repo1.maven.org/maven2/org/apache/maven/scm/maven-scm-provid er-svn-commons/1.0-beta-3/maven-scm-provider-svn-commons-1.0-beta-3.pom [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: org.apache.maven.scm:maven-scm-provider-svn-commons Reason: Error getting POM for 'org.apache.maven.scm:maven-scm-provider-svn-commo ns' from the repository: Error transferring file org.apache.maven.scm:maven-scm-provider-svn-commons:pom:1.0-beta-3 from the specified remote repositories: central (http://repo1.maven.org/maven2), apache.snapshots (http://svn.apache.org/maven-snapshot-repository), snapshots (http://snapshots.maven.codehaus.org/maven2) [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 20 seconds [INFO] Finished at: Mon Aug 21 13:23:15 EDT 2006 [INFO] Final Memory: 4M/8M [INFO] -- 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: (MNG-3000) Property substitution not possible in filter element if from profile
[
http://jira.codehaus.org/browse/MNG-3000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-3000.
-
Assignee: Brett Porter
Resolution: Cannot Reproduce
Fix Version/s: (was: Reviewed Pending Version Assignment)
working in 2.1.0-M1
Property substitution not possible in filter element if from profile
--
Key: MNG-3000
URL: http://jira.codehaus.org/browse/MNG-3000
Project: Maven 2
Issue Type: Bug
Components: Bootstrap Build
Affects Versions: 2.0.6
Reporter: Paul Benedict
Assignee: Brett Porter
Based on a profile, I want to enable a property.
profiles
profile
idmyprofile/id
properties
envdev/env
/properties
/profile
/profiles
And then use this property in a common filter path:
build
filters
filtersrc/main/filters/${env}.properties/filter
/filters
/build
The filter path only completes if I have a standalone properties element
outside of a profile. With that removed and a profile activated, the property
is not found.
--
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: (MNG-2506) Problem with maven 2 with multiproject
[ http://jira.codehaus.org/browse/MNG-2506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2506. - Assignee: Brett Porter Resolution: Incomplete Fix Version/s: (was: Reviewed Pending Version Assignment) t looks like a POM problem. It will be impossible to diagnose without the actual POMs. Problem with maven 2 with multiproject -- Key: MNG-2506 URL: http://jira.codehaus.org/browse/MNG-2506 Project: Maven 2 Issue Type: Bug Components: General Affects Versions: 2.0.4 Environment: Linux (Ubuntu 6.06) kernel 2.6.15-26 on AMD Sempron 2500+ Reporter: Sergio Rafael Gianazza Assignee: Brett Porter I have a project that looks like this: First/ First/pom.xml First/Second First/Second/pom.xml First/Second/Project First/Second/Project/pom.xml First/Third First/Third/pom.xml and when i try to package my project ( a war proyect) it throws: GroupId: First ArtifactId: Second Version: 0.1 Reason: Unable to download the artifact from any repository Every parent has its modules, and every module has his parent setted. I don't know if this is a pom problem or a maven problem. Thanks. -- 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-2521) Using JDK 1.5+ annotations for mojos metadata
[ http://jira.codehaus.org/browse/MNG-2521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2521: -- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.x Using JDK 1.5+ annotations for mojos metadata - Key: MNG-2521 URL: http://jira.codehaus.org/browse/MNG-2521 Project: Maven 2 Issue Type: New Feature Components: Multiple Language Support Affects Versions: 2.0-alpha-1, 2.0.4, 2.0.5 Reporter: Yoav Landman Assignee: Jason van Zyl Fix For: 2.x Attachments: format-maven-plugin-plugin.diff, format-maven-plugin-tools-java5.diff, maven-plugin-plugin-postcompile.diff, maven-plugin-tools-anno.patch, maven-plugin-tools-annotations.tar.gz, maven-plugin-tools-java5.diff, maven-plugin-tools-java5.tar.gz The attached patch contains a plugin-tool that allows writing annotatd mojos using JDK 1.5 annotations instead of doclet comments. It is was created from (my) sf.net project https://sourceforge.net/projects/mvn-anno-mojo/. -- 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-2598) profile element in POM should support overriding project.build.directory
[
http://jira.codehaus.org/browse/MNG-2598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-2598:
--
Fix Version/s: (was: Reviewed Pending Version Assignment)
2.x
profile element in POM should support overriding project.build.directory
Key: MNG-2598
URL: http://jira.codehaus.org/browse/MNG-2598
Project: Maven 2
Issue Type: Improvement
Components: Profiles
Affects Versions: 2.0.4
Reporter: Ian Springer
Fix For: 2.x
I am trying to set up a 'dev' build profile that, when enabled, will cause my
j2ee artifacts to be built directly to exploded j2ee deployment dirs, instead
of target/classes/. The purpose is to make the everyday development process
more efficient by skipping a number of time-consuming intermediate mvn steps
(i.e. jarring artifacts, copying the jars to the local repo, then unjarring
the artifacts to their deploy locations).
The intuitive way to achieve this is to override 'project.build.directory'
and/or 'project.build.outputDirectory' in a profile; e.g.:
profile
...
build
outputDirectory${jboss.home}/server/default/deploy/my.ear/my-exploded-ejb.jar
/build
...
/profile
Unfortunately, profiles currently do not allow one to override either
'project.build.directory' or 'project.build.outputDirectory'. Please change
Maven to allow profiles to override these props. Otherwise, I can't see any
other way to achieve what my team needs to do to have a practical build/dev
infrastructure.
Thanks,
Ian
--
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: (MNG-2470) uniqueVersion not inherited in child projects
[ http://jira.codehaus.org/browse/MNG-2470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2470. - Assignee: Brett Porter Resolution: Duplicate Fix Version/s: (was: Reviewed Pending Version Assignment) uniqueVersion not inherited in child projects - Key: MNG-2470 URL: http://jira.codehaus.org/browse/MNG-2470 Project: Maven 2 Issue Type: Bug Components: Inheritance and Interpolation Affects Versions: 2.0.4 Environment: Linux Reporter: korebantic Assignee: Brett Porter My parent project defines the following: distributionManagement snapshotRepository idYo/id nameYo Repository/name urlscp://yo/home/maven/www/url uniqueVersionfalse/uniqueVersion /snapshotRepository /distributionManagement When I run the following command in the child project: mvn help:effective-pom I get the following results: ... distributionManagement snapshotRepository idYo/id nameYo Repository/name urlscp://yo/home/maven/www/url /snapshotRepository /distributionManagement ... It looks like inheritence is ignoring the uniqueVersion element. This is also verified, when I run mvn deploy -- the parent project installs a non-timestamped version in the remote repository, but the child project installs a timestamped version. -- 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-2970) Improve mvn script for CI builds: mavenrc_pre / mavenrc_post
[ http://jira.codehaus.org/browse/MNG-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=158541#action_158541 ] Brett Porter commented on MNG-2970: --- this can so easily be added by a wrapper script I'm not sure of the value... but it's a simple thing so if you want to add it in the same way as exists in the batch files, go for it :) Improve mvn script for CI builds: mavenrc_pre / mavenrc_post Key: MNG-2970 URL: http://jira.codehaus.org/browse/MNG-2970 Project: Maven 2 Issue Type: Improvement Components: Command Line Affects Versions: 2.0.6 Reporter: Vincent Siveton Assignee: Brett Porter CI builds need specific settings like environment or specific OS tasks. Some ideas to improve the mvn script: * add a setenv script before calling maven * add a pre/post hook scripts between maven call -- 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: (MNG-2816) Pom without xsd import is not validated
[ http://jira.codehaus.org/browse/MNG-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2816. - Resolution: Duplicate Fix Version/s: (was: Reviewed Pending Version Assignment) Pom without xsd import is not validated --- Key: MNG-2816 URL: http://jira.codehaus.org/browse/MNG-2816 Project: Maven 2 Issue Type: Improvement Components: Bootstrap Build Affects Versions: 2.0.4 Reporter: Kristoffer Moum I added a dependency to a module a couple of days ago. I did it just a tad too quickly (copy and paste from dependency management), and forgot to enclose with the dependency tag, i.e. I had the following structure: dependencies groupIdorg.springframework/groupId artifactIdspring-web/artifactId /dependencies So - what happened when I did an mvn install the dependency was ignored rather than producing an error message as the pom was actually valid xml. It would be nice to have some defaulting of xsd if none was specified. -- 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: (MNG-2853) Nondeploying wars
[ http://jira.codehaus.org/browse/MNG-2853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2853. - Assignee: Brett Porter Resolution: Won't Fix Fix Version/s: (was: Reviewed Pending Version Assignment) use the deploy plugin's skip parameter Nondeploying wars - Key: MNG-2853 URL: http://jira.codehaus.org/browse/MNG-2853 Project: Maven 2 Issue Type: Improvement Components: General Affects Versions: 2.0.5 Environment: all Reporter: Rafal Rusin Assignee: Brett Porter It would be great to add pissibility to not deploy specified files to remote repository. For example, if you are building ear application, which consists of several wars, when you deploy stuff, those wars are deployed unnecesarily. And sometimes they consume a lot of space, especially when you do subsequent releases. So in pom, there should be something like deploymentlocal | any/deployment at the top level. I can add a support for this if you want. Regards -- 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: (MNG-2659) possible to create an infinite loop in processing a POM
[
http://jira.codehaus.org/browse/MNG-2659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-2659.
-
Resolution: Duplicate
Fix Version/s: (was: Reviewed Pending Version Assignment)
possible to create an infinite loop in processing a POM
---
Key: MNG-2659
URL: http://jira.codehaus.org/browse/MNG-2659
Project: Maven 2
Issue Type: Bug
Components: Inheritance and Interpolation
Affects Versions: 2.0.4
Reporter: Brett Porter
If you define a property like this:
{code:xml}
properties
http.port${http.port}/http.port
/properties
{code}
The interpolator *correctly* identifies that this will cause a loop and
throws an Exception.
However, if you define it with some indirection, eg:
{code:xml}
properties
http.port${foo}/http.port
foo${http.port}/foo
/properties
{code}
This causes an infinite loop, where it should be detected and the same
exception thrown as above.
--
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-2693) Error executing post-site: java.util.MissingResourceException: Can't find bundle for base name site-plugin, locale en
[ http://jira.codehaus.org/browse/MNG-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2693: -- Fix Version/s: (was: Reviewed Pending Version Assignment) 3.0-alpha-3 may be fixed by now, needs review Error executing post-site: java.util.MissingResourceException: Can't find bundle for base name site-plugin, locale en - Key: MNG-2693 URL: http://jira.codehaus.org/browse/MNG-2693 Project: Maven 2 Issue Type: Bug Components: Sites Reporting Affects Versions: 2.0-alpha-1 Reporter: Stepan Roh Fix For: 3.0-alpha-3 I use Maven 2.1 embedder - if I build it from current SVN HEAD of maven-components (together with all components), I get this exception if I try to execute post-site: Caused by: org.apache.maven.reactor.MavenExecutionException: Error executing project within the reactor at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:214) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:797) ... 19 more Caused by: java.util.MissingResourceException: Can't find bundle for base name site-plugin, locale en at org.codehaus.plexus.i18n.DefaultI18N.cacheBundle(DefaultI18N.java:394) at org.codehaus.plexus.i18n.DefaultI18N.getBundle(DefaultI18N.java:157) at org.codehaus.plexus.i18n.DefaultI18N.getString(DefaultI18N.java:206) at org.apache.maven.plugins.site.AbstractSiteMojo.populateReportsMenu(AbstractSiteMojo.java:400) at org.apache.maven.plugins.site.AbstractSiteRenderingMojo.locateDocuments(AbstractSiteRenderingMojo.java:587) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:113) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:438) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:391) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:178) ... 21 more If I try revision 480835, it works. I see that there are some classworlds and container changes since that revision, so it can be related to that. -- 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-2643) Unlimited number of version digits
[ http://jira.codehaus.org/browse/MNG-2643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2643: -- Fix Version/s: (was: Reviewed Pending Version Assignment) 3.x Unlimited number of version digits Key: MNG-2643 URL: http://jira.codehaus.org/browse/MNG-2643 Project: Maven 2 Issue Type: Improvement Components: Dependencies Affects Versions: 2.0.4 Reporter: Jonas Olsson Fix For: 3.x Currently Maven only handles three digit versions, but that seems to be an artificial limit, not a technical one. Couldn't the version ordering/comparison be extend to an arbitrary number of digits? -- 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-2916) Default message and profile help messages
[ http://jira.codehaus.org/browse/MNG-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2916: -- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.2.0-M1 Component/s: (was: Plugin Requests) POM Default message and profile help messages - Key: MNG-2916 URL: http://jira.codehaus.org/browse/MNG-2916 Project: Maven 2 Issue Type: New Feature Components: POM Reporter: Mark Proctor Assignee: Brian Fox Fix For: 2.2.0-M1 IT would be good to have a pom default message that is displayed when no goals are given. Further to that we should be able to annotate profiles to provide help information. Ideally the default message will also include the list of profiles that can be querried with the help command -- 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: (MNG-2946) Module-by-Profile seems to break plugin dependencies
[ http://jira.codehaus.org/browse/MNG-2946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2946. - Assignee: Brett Porter Resolution: Duplicate Fix Version/s: (was: Reviewed Pending Version Assignment) Module-by-Profile seems to break plugin dependencies Key: MNG-2946 URL: http://jira.codehaus.org/browse/MNG-2946 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.6 Environment: jdk1.4 Reporter: Daniel Takai Assignee: Brett Porter Using Module-by-Profile i ran into a problem with dependencies. My pom looks like this: profiles profile iddefault/id activation activeByDefaulttrue/activeByDefault /activation modules modulemodule1/module modulemodule2/module modulemodule3/module /modules /profile profile idintegration/id modules modulemodule1/module modulemodule2/module modulemodule3/module moduleintegration/module /modules /profile /profiles The integration module runs the integration tests. The integration module contain an antrun plugin. Running the build on the integration module only works fine. Running it from the parent project using the integration profile breaks the build. The problem is that the plugin dependencies are not accessible to the ant build files (and therefore, i suppose, to the 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] Moved: (MSANDBOX-41) Generic external report plugin
[ http://jira.codehaus.org/browse/MSANDBOX-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2660 to MSANDBOX-41: --- Affects Version/s: (was: 2.0.4) Fix Version/s: (was: Reviewed Pending Version Assignment) Component/s: (was: Sites Reporting) (was: Plugin Requests) Key: MSANDBOX-41 (was: MNG-2660) Project: Maven 2.x Sandbox (was: Maven 2) Generic external report plugin -- Key: MSANDBOX-41 URL: http://jira.codehaus.org/browse/MSANDBOX-41 Project: Maven 2.x Sandbox Issue Type: New Feature Reporter: Dave Syer Attachments: external-report.zip A very simple plugin to add an external report (e.g. junit html report) to the project reports. This is really trivial (if anyone wants some code that does it ask), but would be quite valuable to many people. Example: reporting plugins plugin groupIdorg.apache.maven/groupId artifactIdmaven-external-report-plugin/artifactId configuration nameJUnit Report/name descriptionJUnit test results for this project/description basejunit-reports/base /configuration /plugin /plugins /reporting This generates a link in the project reports to junit-reports/index.html, which has to be populated elsewhere (e.g. by an ant task). -- 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-2727) Fix Logging in threadsafe components
[ http://jira.codehaus.org/browse/MNG-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2727: -- Fix Version/s: (was: Reviewed Pending Version Assignment) 3.x Fix Logging in threadsafe components Key: MNG-2727 URL: http://jira.codehaus.org/browse/MNG-2727 Project: Maven 2 Issue Type: Task Components: Embedding Reporter: Jason van Zyl Assignee: Jason van Zyl Fix For: 3.x -- 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-2305) only first active proxy considered/used
[ http://jira.codehaus.org/browse/MNG-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-2305: -- Affects Version/s: 2.1.0-M1 Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.x still a problem in 2.1.0-M1 only first active proxy considered/used --- Key: MNG-2305 URL: http://jira.codehaus.org/browse/MNG-2305 Project: Maven 2 Issue Type: Bug Components: General Affects Versions: 2.0.4, 2.1.0-M1 Environment: WIN2K JDK 1.5.0_06 proxy:81 for both http and https Reporter: Franz Fehringer Fix For: 2.0.x Attachments: settings.xml With the attached settings.xml all https connects fail (doing mvn -U). If i reverse the order (https first http second) all http connects fail. Questions: Does https tunneling over http proxies work at all with Maven2 (sending HTTP CONNECT remote address to the proxy is needed)? Why is the Java system configuration (in Application Data\Sun\Java\Deployment\deployment.properties) not used to detect proxies? -- 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: (MNG-2896) ${basedir} used in a repository url does not work for parent pom lookup
[
http://jira.codehaus.org/browse/MNG-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-2896.
-
Assignee: Brett Porter
Resolution: Won't Fix
Fix Version/s: (was: Reviewed Pending Version Assignment)
Maven's inheritance model means that interpolation occurs after inheritance, so
it is not set at this stage of the project processing.
You can use relativePath for the parent to be located in the right location.
${basedir} used in a repository url does not work for parent pom lookup
---
Key: MNG-2896
URL: http://jira.codehaus.org/browse/MNG-2896
Project: Maven 2
Issue Type: Wish
Components: POM
Affects Versions: 2.0.5
Reporter: Stefano Bagnara
Assignee: Brett Porter
I use something like this to store locally the dependencies.
-
repository
idparent-james-stage-m1/id
nameJames stage repository/name
urlfile://${basedir}/stage/url
layoutlegacy/layout
releases
enabledtrue/enabled
checksumPolicyignore/checksumPolicy
/releases
snapshots
enabledtrue/enabled
checksumPolicyignore/checksumPolicy
/snapshots
/repository
Everything works fine but the parent resolution: my main pom.xml has a parent
and it is not looked up in this repository.
Well, it is lookedup, but ${basedir} is not expanded and this way the lookup
does not work.
If I replace the ${basedir} with my full path everything works fine, but I
cannot obviously do that as the local repository is part of the svn tree (by
our choice to not use remote repositories).
Furthermore: is there a variable to be used instead of ${basedir} that always
reference to its own pom.xml folder? I ask this because I have multiple
modules inside this project and I had to add another repository to this pom
using file://${basedir}/../stage (notice the ..) so that submodules will use
the same repository for the lookups, but this sound like an hack.
--
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: (MNG-2488) Version range does not select latest version present in local repository unless used in offline mode
[ http://jira.codehaus.org/browse/MNG-2488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2488. - Assignee: Brett Porter Resolution: Not A Bug Fix Version/s: (was: Reviewed Pending Version Assignment) Version range does not select latest version present in local repository unless used in offline mode - Key: MNG-2488 URL: http://jira.codehaus.org/browse/MNG-2488 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Environment: Linux 2.6.8-1-686-smp #1 SMP Thu Nov 25 04:55:00 UTC 2004 i686 GNU/Linux Reporter: Stefan Seidel Assignee: Brett Porter When a version range for a dependency ist specified, M2 look in the given remote repositories only and ignores a newer version in the local repository. For example, I use the release plugin to release version 1.0.0 of artifact A (and deploy it to a remote repository), then move on locally to 1.0.1-SNAPSHOT. I continue developing this and do a mvn install because I do not necessarily want to deploy a snapshot immediately. If I then build a project B with dependency groupIdmygroup/groupId artifactIdA/artifactId version[1.0.0,)/version /dependency Maven will look in the remote repository and find version 1.0.0, but will ignore my locally installed 1.0.1-SNAPSHOT. However, when using offline mode (mvn -o package), 1.0.1-SNAPSHOT is used. Workarounds include using offline mode - thus excluding the possibility to retrieve changes in other dependencies, using a fixed version (not very helpful) or deploying each and every snapshot (not helpful because other developers do not need to see snapshots that I use for testing only). -- 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: (MNG-2457) NonProxyHost in Settings is often ignored
[ http://jira.codehaus.org/browse/MNG-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2457. - Assignee: Brett Porter Resolution: Incomplete Fix Version/s: (was: Reviewed Pending Version Assignment) this was addressed in Wagon. NonProxyHost in Settings is often ignored - Key: MNG-2457 URL: http://jira.codehaus.org/browse/MNG-2457 Project: Maven 2 Issue Type: Task Components: Settings Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4 Reporter: Denis Cabasson Assignee: Brett Porter The nonProxyHost list in the proxy settings is often ignored by plugins. What is the strategy to use with this nonProxyHost list? I think maven should rather ignore it, and then mark it as deprecated in settings description, or decide to use it, and implements its use in every needed plugin. Example issue in the wagon-ssh component: http://jira.codehaus.org/browse/WAGONSSH-51?page=all -- 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] Moved: (MSITE-375) Site plugin NO locale
[ http://jira.codehaus.org/browse/MSITE-375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2453 to MSITE-375: - Fix Version/s: (was: Reviewed Pending Version Assignment) Component/s: (was: Sites Reporting) Key: MSITE-375 (was: MNG-2453) Project: Maven 2.x Site Plugin (was: Maven 2) Site plugin NO locale - Key: MSITE-375 URL: http://jira.codehaus.org/browse/MSITE-375 Project: Maven 2.x Site Plugin Issue Type: Improvement Environment: N/A Reporter: David J. M. Karlsen Priority: Minor Attachments: site-plugin_no.properties Norwegian (bokmål - NO_nb) translation. I'll add info translation soon -- 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: (MNG-2476) Plugin give wrong Maven goal for installing Javadoc jar
[ http://jira.codehaus.org/browse/MNG-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2476. - Assignee: Brett Porter Resolution: Cannot Reproduce Fix Version/s: (was: Reviewed Pending Version Assignment) using type = javadoc gives the correct line for me Plugin give wrong Maven goal for installing Javadoc jar --- Key: MNG-2476 URL: http://jira.codehaus.org/browse/MNG-2476 Project: Maven 2 Issue Type: Bug Components: Dependencies Reporter: Tim Shadel Assignee: Brett Porter Priority: Minor The Eclipse plugin gives the following output when it cannot locate a remote -javadoc.jar file for a dependency 6/9/06 2:22:30 PM GMT-07:00: [WARN] Unable to get resource from repository central (http://repo1.maven.org/maven2) 6/9/06 2:22:30 PM GMT-07:00: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.springframework -DartifactId=spring \ -Dversion=2.0-m5 -Dpackaging=java-doc -Dfile=/path/to/file org.springframework:spring-2.0-m5.java-doc The part that is in error is -Dpackaging=java-doc. Instead it should read -Dpackaging=javadoc. The second version creates the right pattern for installation in the repository. The other one creates a .java-doc file instead (similar to the problem described in MNGECLIPSE-122). -- 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-1423) best practices: setting up multi-module build
[ http://jira.codehaus.org/browse/MNG-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1423: -- Fix Version/s: (was: Reviewed Pending Version Assignment) Documentation Deficit best practices: setting up multi-module build - Key: MNG-1423 URL: http://jira.codehaus.org/browse/MNG-1423 Project: Maven 2 Issue Type: Task Components: Design, Patterns Best Practices Reporter: Jason van Zyl Assignee: Jason van Zyl Priority: Trivial Fix For: Documentation Deficit Things to consider for a multi-module build are: o version management o release management Current I am (jvz) using the Geronimo build at Apache as an example of this. -- 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
