[jira] Commented: (MNG-2651) POM interpolator treats ${pom.something} like ${something} and prefers system properties
[
http://jira.codehaus.org/browse/MNG-2651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_87052
]
Wayne Fay commented on MNG-2651:
This seems to be the root cause behind numerous other bugs posted in JIRA...
MNG-2288
MNG-2339
MNG-2486
MNG-2653
It is also the cause for quite a lot of emails on the Maven Users list over the
last year. :(
> POM interpolator treats ${pom.something} like ${something} and prefers system
> properties
>
>
> Key: MNG-2651
> URL: http://jira.codehaus.org/browse/MNG-2651
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Daniel Schulz
> Assigned To: Jason van Zyl
>
> The POM interpolator (RegexBasedModelInterpolator) removes all leading
> "pom.", "project." and "env." portions of an expression before evaluating it.
> then searching for values happens in the following order: system properties,
> project properties, pom bean properties.
> An example: Although ${pom.version} is more specific than ${version}, version
> wins. That's the problem in MNGECLIPSE-20.
> IMHO the interpolation strategy should be changed.
--
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: (MAVENUPLOAD-1372) hibernate 3.2.2.ga
hibernate 3.2.2.ga -- Key: MAVENUPLOAD-1372 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1372 Project: maven-upload-requests Issue Type: Task Reporter: Toshihiro Nakamura hibernate 3.2.2.ga -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1337) Upload of latest Findbugs (v. 1.1.3) artifacts to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_87039 ] Garvin LeClaire commented on MAVENUPLOAD-1337: -- I am still waiting for a response from Bill Pugh. This is a minor issue as I can resort to the same GroupID as I did for 1.1.0 The biggest dependency is ASM 3.0 is not in the repository. I see Jeff Jensen has put in a request to the ASM team to publish the 3.0 version. I will put in a similar request. Garvin > Upload of latest Findbugs (v. 1.1.3) artifacts to ibiblio > - > > Key: MAVENUPLOAD-1337 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1337 > Project: maven-upload-requests > Issue Type: Task >Reporter: Jon Christiansen > Attachments: findbugs113.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] Created: (MPLICENSE-3) JavaFileType does not work reliably (yet)
JavaFileType does not work reliably (yet) - Key: MPLICENSE-3 URL: http://jira.codehaus.org/browse/MPLICENSE-3 Project: maven-license-plugin Issue Type: Bug Reporter: Anthony Vito Attachments: maven-license-plugin_vito_patch.diff The summary was taken from Joakim Erdfelt svn log message of commit 465447. I have created an issue around it because I have a patch and the progress should be tracked. The patch adds a micro parser to detect the location of Java comments as well as an object to query comment locations. This allows for the failing unit tests to pass, as well as some more difficult unit tests that I created to assure correctness. I did not use JavaCC as the parser. Perhaps this is an exercise for the future. With the patch the plugin performs nicely for my needs, and I hope my work can help others. The patch is against revision 503477 the last change for the directory as of today. -- 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: (MGPG-2) Allow the selection of a particular signature
Allow the selection of a particular signature - Key: MGPG-2 URL: http://jira.codehaus.org/browse/MGPG-2 Project: Maven 2.x GPG Plugin Issue Type: Improvement Affects Versions: 1.0-alpha-2 Reporter: Jason van Zyl Folks could have many signature and want to use a particular one. -- 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-1682) Plugins do not honor the correct extension when run as a part of a multiproject build
[ http://jira.codehaus.org/browse/MNG-1682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez updated MNG-1682: Attachment: MNG-1682-ittest.patch I tok the example code and converted to an it test for https://svn.apache.org/repos/asf/maven/core-integration-testing/trunk/core-integration-tests/src/test/resources and I can't replicate there the problem, when I run install in parent pom it runs the assembly. I tested 2.0.4 and 2.0.5RC > Plugins do not honor the correct extension when run as a part of a > multiproject build > - > > Key: MNG-1682 > URL: http://jira.codehaus.org/browse/MNG-1682 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 > Environment: Windows NT; JDK 1.5 >Reporter: Nigel Magnay > Fix For: 2.1.x > > Attachments: MNG-1682-ittest.patch, ReactorProblem.tar.gz > > > I have a plugin with a component.xml described here. > I think the component.xml is correct - it certainly looks the > same as the plexus examples. > My project that uses this plugin works entirely correctly, *unless* it > is a part of a multiproject build, in which case it uses the wrong > extension. I don't know why this would be the case unless I've missed > something? > In same directory: > W:\kms\dev\apps\kms>mvn install > [INFO] Scanning for projects... > [INFO] > > [INFO] Building KMS Application Code > [INFO]task-segment: [install] > [INFO] > > [INFO] [cargo2:uberwar] > [INFO] [install:install] > [INFO] Installing W:\1244 - Knowledge Management System > (KMS)\dev\apps\kms\target\kms-2.0-SNAPSHOT.war to C:\Documents and > Settings\nig > el.magnay\.m2\repository\com\cswgroup\kms\kms\2.0-SNAPSHOT\kms-2.0-SNAPSHOT.war > [INFO] > > [INFO] BUILD SUCCESSFUL > [INFO] > > [INFO] Total time: 1 minute 9 seconds > [INFO] Finished at: Thu Nov 24 11:46:53 GMT 2005 > [INFO] Final Memory: 3M/6M > [INFO] > > As a part of a multiproject: > > [INFO] > > [INFO] Building KMS Application Code > [INFO]task-segment: [install] > [INFO] > > [INFO] [cargo2:uberwar] > [INFO] [install:install] > [INFO] Installing W:\1244 - Knowledge Management System > (KMS)\dev\apps\kms\target\kms-2.0-SNAPSHOT.war to C:\Documents and > Settings\nig > el.magnay\.m2\repository\com\cswgroup\kms\kms\2.0-SNAPSHOT\kms-2.0-SNAPSHOT.uberwar > > Config of plugin: > > > > org.apache.maven.lifecycle.mapping.LifecycleMapping > uberwar > > org.apache.maven.lifecycle.mapping.DefaultLifecycleMapping > > > >org.codehaus.cargo.maven2:cargo-maven2-plugin:uberwar > > > org.apache.maven.plugins:maven-install-plugin:install > > org.apache.maven.plugins:maven-deploy-plugin:deploy > > > > > org.apache.maven.artifact.handler.ArtifactHandler > uberwar > > org.apache.maven.artifact.handler.DefaultArtifactHandler > >uberwar > war >uberwar > > > > -- 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-2172) 's are not used when evaluating
[ http://jira.codehaus.org/browse/MNG-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_87033 ] John Allen commented on MNG-2172: - Been an age can this be looked at for 2.1? > 's are not used when evaluating > > - > > Key: MNG-2172 > URL: http://jira.codehaus.org/browse/MNG-2172 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation > Environment: 2.0.2-SNAPSHOT >Reporter: John Allen > Assigned To: Jason van Zyl > Fix For: 2.1.x > > > dep management is not honoured for plugins dep evaluation. > hm.. looks like inheritance, after investigating.. the > MavenMetaDataSource doesn't use the MavenProject.getDependencyManagement > jah.. found it. > NICE, estimate... 30 mins or 30 hrs? > 30 mins > the maven-project DefaultMavenProjectBuilder uses a different method > in the ArtifactResolved to resolve deps than the maven-core > DefaultPluginManager > but all the info is available.. -- 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: (MDEP-62) Ability to disallow groups of deps
[
http://jira.codehaus.org/browse/MDEP-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_87029
]
Brian Fox commented on MDEP-62:
---
hrm, interesting ok. This can be added in alpha-3
> Ability to disallow groups of deps
> --
>
> Key: MDEP-62
> URL: http://jira.codehaus.org/browse/MDEP-62
> Project: Maven 2.x Dependency Plugin
> Issue Type: New Feature
>Reporter: David Blevins
> Assigned To: Brian Fox
>
> There's a related issue MNG-2796 (http://jira.codehaus.org/browse/MNG-2796)
> involving some issue with using one pom ("server" parent pom) to depend on
> another pom ("container" parent pom). The desired effect is that any
> children modules of the container parent pom cannot depend on any children
> modules of the server parent pom. Having the server parent pom depend on the
> container parent pom is one way to ensure this cannot happen, but maybe
> considered a hack -- and I suppose it is when you consider that this only
> works if you control the poms of the deps that are "off limits".
> Brett has suggested adding explicit support for this so that groups of deps
> or individual deps could be marked as disallowed. That feature would
> definitely work as an alternate ensuring that nothing in the container group
> depends on anything in the server group.
--
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: (MDEP-62) Ability to disallow groups of deps
[
http://jira.codehaus.org/browse/MDEP-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_87026
]
Brett Porter commented on MDEP-62:
--
I'm thinking a goal in this plugin, bound to the first phase (validate), that
takes a list of banned artifacts (both g:a:v, g:a pairings and just plain
groups shuld be acceptable to ban), and fails the build if they are found.
> Ability to disallow groups of deps
> --
>
> Key: MDEP-62
> URL: http://jira.codehaus.org/browse/MDEP-62
> Project: Maven 2.x Dependency Plugin
> Issue Type: New Feature
>Reporter: David Blevins
> Assigned To: Brian Fox
>
> There's a related issue MNG-2796 (http://jira.codehaus.org/browse/MNG-2796)
> involving some issue with using one pom ("server" parent pom) to depend on
> another pom ("container" parent pom). The desired effect is that any
> children modules of the container parent pom cannot depend on any children
> modules of the server parent pom. Having the server parent pom depend on the
> container parent pom is one way to ensure this cannot happen, but maybe
> considered a hack -- and I suppose it is when you consider that this only
> works if you control the poms of the deps that are "off limits".
> Brett has suggested adding explicit support for this so that groups of deps
> or individual deps could be marked as disallowed. That feature would
> definitely work as an alternate ensuring that nothing in the container group
> depends on anything in the server group.
--
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: (MDEP-62) Ability to disallow groups of deps
Ability to disallow groups of deps
--
Key: MDEP-62
URL: http://jira.codehaus.org/browse/MDEP-62
Project: Maven 2.x Dependency Plugin
Issue Type: New Feature
Reporter: David Blevins
Assigned To: Brian Fox
There's a related issue MNG-2796 (http://jira.codehaus.org/browse/MNG-2796)
involving some issue with using one pom ("server" parent pom) to depend on
another pom ("container" parent pom). The desired effect is that any children
modules of the container parent pom cannot depend on any children modules of
the server parent pom. Having the server parent pom depend on the container
parent pom is one way to ensure this cannot happen, but maybe considered a hack
-- and I suppose it is when you consider that this only works if you control
the poms of the deps that are "off limits".
Brett has suggested adding explicit support for this so that groups of deps or
individual deps could be marked as disallowed. That feature would definitely
work as an alternate ensuring that nothing in the container group depends on
anything in the server group.
--
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: (MEV-498) javax.xml.ws:jaxws-api:2.1 is bad
[ http://jira.codehaus.org/browse/MEV-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_87021 ] Carlos Sanchez commented on MEV-498: that's what i did, but they changed it after sync, what can I do ? the only thing that can be done right now is upload the good jar as version 2.1-1, state in the pom description that it's a fix of 2.1 > javax.xml.ws:jaxws-api:2.1 is bad > - > > Key: MEV-498 > URL: http://jira.codehaus.org/browse/MEV-498 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid POM >Reporter: Dan Tran > > Sun just released jaxws 2.1 and the jaxws-api available at repo1.maven.org is > not the same with the Sun's one (both pom and the jar ) > I am working jaxws-maven-plugin and the generate code crash due to missing > interfaces > We can either sync the sun version over, or remove it from repo1 to remove > confusion > Here is the link to java.net repo > https://maven-repository.dev.java.net/nonav/repository/com.sun.xml.ws/ -- 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: (MAVENUPLOAD-1368) jung-1.7.6 upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1368. --- Assignee: Carlos Sanchez Resolution: Fixed > jung-1.7.6 upload request > - > > Key: MAVENUPLOAD-1368 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1368 > Project: maven-upload-requests > Issue Type: Task >Reporter: tom nelson > Assigned To: Carlos Sanchez > > http://jung.sourceforge.net/maven/jung-1.7.6-bundle.jar > http://jung.sourceforge.net > http://jung.sourceforge.net/team.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: (MAVENUPLOAD-1367) Uploading Whirlycache 0.7.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1367. --- Assignee: Carlos Sanchez Resolution: Fixed > Uploading Whirlycache 0.7.1 > --- > > Key: MAVENUPLOAD-1367 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1367 > Project: maven-upload-requests > Issue Type: New Feature >Reporter: Olivier Lamy > Assigned To: Carlos Sanchez > Attachments: whirlycache-0.7.1-upload-bundle.jar, > whirlycache-0.7.1-upload-bundle.jar > > > Whirlycache is an in memory java cache. > I need to add it as a provider in plexus-cache. > Thanks, > -- > Olivier -- 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: (MAVENUPLOAD-1366) c3p0 0.9.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1366. --- Assignee: Carlos Sanchez Resolution: Fixed > c3p0 0.9.1 > -- > > Key: MAVENUPLOAD-1366 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1366 > Project: maven-upload-requests > Issue Type: Task >Reporter: Mark Reynolds > Assigned To: Carlos Sanchez > > A new version was released a couple of weeks ago and no one has uploaded it > to the maven central repo yet, so here it is. I was unable to determine a > public scm URL. The one at sourceforge is empty, but that is what I provided > in the POM. -- 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: (MAVENUPLOAD-1371) JUnit-Toolkit 0.5 Upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1371. --- Assignee: Carlos Sanchez Resolution: Fixed > JUnit-Toolkit 0.5 Upload > > > Key: MAVENUPLOAD-1371 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1371 > Project: maven-upload-requests > Issue Type: Task >Reporter: Rupert Smith > Assigned To: Carlos Sanchez > Attachments: junit-toolkit-0.5-bundle.jar > > > http://internap.dl.sourceforge.net/sourceforge/junit-toolkit/junit-toolkit-0.5-bundle.jar > https://sourceforge.net/projects/junit-toolkit/ > https://sourceforge.net/project/memberlist.php?group_id=187767 > JUnit Toolkit enhances JUnit with performance testing, asymptotic behaviour > analysis, and concurrency testing. -- 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: (MAVENUPLOAD-1369) New PostgreSQL JDBC driver versions
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1369. --- Assignee: Carlos Sanchez Resolution: Fixed > New PostgreSQL JDBC driver versions > --- > > Key: MAVENUPLOAD-1369 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1369 > Project: maven-upload-requests > Issue Type: Task >Reporter: Oliver Siegmar > Assigned To: Carlos Sanchez > > http://www.siegmar.org/maven2/postgresql-8.0-318.jdbc3-bundle.jar > http://www.siegmar.org/maven2/postgresql-8.1-408.jdbc3-bundle.jar > http://www.siegmar.org/maven2/postgresql-8.2-504.jdbc3-bundle.jar > http://www.siegmar.org/maven2/postgresql-8.2-504.jdbc4-bundle.jar > http://jdbc.postgresql.org > http://jdbc.postgresql.org/who.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] Created: (MECLIPSE-226) Wrong Path (Last two directories of path missing) in .classpath and maven-eclipse.xml
Wrong Path (Last two directories of path missing) in .classpath and maven-eclipse.xml - Key: MECLIPSE-226 URL: http://jira.codehaus.org/browse/MECLIPSE-226 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.3 Environment: win32 Reporter: Alexander Dotor I call 'mvn eclipse:eclipse' for my project to create the necessary files. The project is an (already existing) Plugin-Project. Unfortunately an entry in the .classpath and the maven-eclipse.xml are wrong. In both cases the Name of the Eclipse-Project is missing. This is independent of using the eclipseProjectDir-Option and the pde-Option. The wrong line in .classpath: It should be: Wrong line in maven-eclipse.xml: Should be: Why is it including this directory in .classpath by an external path anyway? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-196) Release plugin needs a way to return the SCM urls to previously defined version after release (based on properties)
Release plugin needs a way to return the SCM urls to previously defined version
after release (based on properties)
---
Key: MRELEASE-196
URL: http://jira.codehaus.org/browse/MRELEASE-196
Project: Maven 2.x Release Plugin
Issue Type: Improvement
Environment: Any pom where SCM information is based on properties
Reporter: Mykel Alvis
My SCM urls are based on a well-defined pattern utilizing 1 or 2 properties and
the artifactId
When the release plugin runs, it overrides these properties with the expanded
SCM information, as expected.
However, when releasing a parent pom, this isn't an optimal situation. (My)
parent poms need to be released by altering the property sets, not changing the
SCM urls.
For example,
scm:svn:${sird.scm.url.ro}
scm:svn:${sird.scm.url.dev}
${sird.scm.url.view}
is based on
http://${sird.scm.host}/svnrepos/${sird.object.namespace}/${artifactId}/trunk
http://${sird.scm.host}/svnrepos/${sird.object.namespace}/${artifactId}/trunk
http://${sird.scm.host}/svnrepos/${sird.object.namespace}/${artifactId}/trunk
What I'd like is to be able to change the sird.scm.url.dev (for instance) to
some OTHER value, such as substituting a different url like
http://${sird.scm.host}/svnrepos/${sird.object.namespace}/${artifactId}/trunk
http://${sird.scm.host}/svnrepos/${sird.object.namespace}/${artifactId}/tags/${releaseTag}
blah
with some property called releaseTag set by the release plugin into my
property sets
and then having the release plugin just change the scm url to
...
scm:svn:${sird.scm.url.released}
...
I know at least a couple of other places that manage a large number of
artifacts like to do things like 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
[jira] Created: (MNG-2815) Parent POM defined profile dependencyManagement dependency version overrides child pom explicit dependency
Parent POM defined profile dependencyManagement dependency version overrides child pom explicit dependency -- Key: MNG-2815 URL: http://jira.codehaus.org/browse/MNG-2815 Project: Maven 2 Issue Type: Bug Components: General Affects Versions: 2.0.4 Environment: jdk 1.6 mvn 2.0.4 windows 2000 Reporter: Peter Lynch 1. Create parent pom with a profile activated on the jdk you are running maven with Inside the profile define a dependencyManagement/dependency to a jar explicitly stating a version. Assume in this example it is version 1.0 2. Create a child pom defining parent in step 1 as parent. In this child, define an explicit dependencies/dependency with the same artifactId and groupId as that profile/dependencyManagement/dependency defined in parent pom. Only difference being that in the child, the dependency version is set to 2.0. 3. Run mvn site and look at teh dependency report. The dependency report indicates the version of the dependency to be 1.0 ( the one defined in the parent pom profile. Expected behavior is that the explicit dependency defined in child should take precedence. -- 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: (NMAVEN-1) Failed to build plugins wtih csc 1.1.4322 (Microsoft)
Failed to build plugins wtih csc 1.1.4322 (Microsoft) - Key: NMAVEN-1 URL: http://jira.codehaus.org/browse/NMAVEN-1 Project: NMaven Issue Type: Bug Environment: Microsoft .NET Framework 1.1.4322 Reporter: Shane Isbell Priority: Minor This issue was submitted by Christophe Lallement on sf.net: -- i have this error when building nmaven-utility-settings i suppose it's because this sources is 2.0 compatible ? [INFO] task-segment: [install] [INFO] [INFO] [compile:initialize] [INFO] [resolver:resolve] [INFO] [settings:generate-settings] [INFO] [compile:generate-assembly-info] [INFO] NMAVEN-902-000: Generating Assembly Info: Language = C_SHARP [INFO] [compile:process-sources] [INFO] NMAVEN-904-002: Copying source files: From = C:\HOMEWARE\csharp\nmaven-plugins-0.13\scripts\..\nmaven-utility-settings\src\ main\csharp, To = C:\HOMEWARE\csharp\nmaven-plugins-0.13\scripts\..\nmaven-utility-settings\target\build-sources [INFO] [compile:process-test-sources] [INFO] NMAVEN-905-002: Copying test source files: From = C:\HOMEWARE\csharp\nmaven-plugins-0.13\scripts\..\nmaven-utility-settings \src\test\csharp, To = C:\HOMEWARE\csharp\nmaven-plugins-0.13\scripts\..\nmaven-utility-settings\target\build-test-sources [INFO] [resgen:copy-resources] [INFO] [resgen:generate] [INFO] [compile:compile] [INFO] NMAVEN-066-012: Found Vendor = Vendor = MICROSOFT, Vendor Version = 1.1.4322, Framework Version = 1.1.4322, Executable Path = [INFO] NMAVEN-068-003: Compiling Artifact: Vendor = MICROSOFT, Language = MICROSOFT, Assembly Name = C:\HOMEWARE\csharp\nmaven-plu gins-0.13\scripts\..\nmaven-utility-settings\target\SettingsGenerator.exe c:\HOMEWARE\csharp\nmaven-plugins-0.13\nmaven-utility-settings\target\build-sources\nmavenSettings.cs(24,8): error CS1518: Expecte d class, delegate, enum, interface, or struct c:\HOMEWARE\csharp\nmaven-plugins-0.13\nmaven-utility-settings\target\build-sources\nmavenSettings.cs(85,8): error CS1518: Expecte d class, delegate, enum, interface, or struct c:\HOMEWARE\csharp\nmaven-plugins-0.13\nmaven-utility-settings\target\build-sources\nmavenSettings.cs(132,8): error CS1518: Expect ed class, delegate, enum, interface, or struct c:\HOMEWARE\csharp\nmaven-plugins-0.13\nmaven-utility-settings\target\build-sources\nmavenSettings.cs(193,8): error CS1518: Expect ed class, delegate, enum, interface, or struct c:\HOMEWARE\csharp\nmaven-plugins-0.13\nmaven-utility-settings\target\build-sources\nmavenSettings.cs(228,8): error CS1518: Expect ed class, delegate, enum, interface, or struct [INFO] [ERROR] BUILD ERROR [INFO] [INFO] NMAVEN-900-004: Unable to Compile: Language = C_SHARP, Vendor = null, ArtifactType = exe, Source Directory = C:\HOMEWARE\cs harp\nmaven-plugins-0.13\scripts\..\nmaven-utility-settings\src\main\csharp Embedded error: NMAVEN-040-001: Could not execute: Command = csc /out:C:\HOMEWARE\csharp\nmaven-plugins-0.13\scripts\..\nmaven-uti lity-settings\target\SettingsGenerator.exe /target:exe /recurse:C:\HOMEWARE\csharp\nmaven-plugins-0.13\scripts\..\nmaven-utility-s ettings\target\build-sources\** /reference:C:\HOMEWARE\maven-2_local\org\nunit\nunit.framework\2.2.8.0\nunit.framework.dll /nologo /warnaserror-, Result = 1 [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] Reopened: (MRM-153) when used as a maven1 proxy, Archiva should handle relocation from maven2 poms
[
http://jira.codehaus.org/browse/MRM-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nicolas de loof reopened MRM-153:
-
This feature is broken by the use of DAV repository in place of the original
"/proxy" path.
in ProxiedDavServer :
if ( WebdavMethodUtil.isReadMethod( request.getRequest().getMethod() ) )
{
if ( !hasResource( request.getLogicalResource() ) )
{
fetchContentFromProxies( request );
}
}
davServer.process( request, response );
> The relocation is handled in fetchContentFromProxies( request ); but the
> relocated path is not reported in the request
The request can be updated, but this requires to convert the File object into a
path in the managed repository. I solved this by using :
File file = proxyRequestHandler.get( request.getLogicalResource(),
this.proxiedRepositories, this.managedRepository,
this.wagonProxy );
File baseDir = new File( this.managedRepository.getBasedir() );
String path = file.getAbsolutePath().substring(
baseDir.getAbsolutePath().length() );
request.getRequest().setPathInfo( path );
... but those absolutePath.substring don't look very clean. Is there any other
way to compute this Path from the File object and the managedRepository ? An
alternative would be to return a "RepositoryEntry" in place of a File, that
would contain both File and path.
> when used as a maven1 proxy, Archiva should handle relocation from maven2 poms
> --
>
> Key: MRM-153
> URL: http://jira.codehaus.org/browse/MRM-153
> Project: Archiva
> Issue Type: Improvement
> Environment: Archiva as a repository proxy for maven1
>Reporter: nicolas de loof
> Assigned To: Brett Porter
>Priority: Minor
> Fix For: 1.0
>
> Attachments: DefaultProxyManager.java.patch,
> DefaultProxyManager.java.patch, MRM-153-test.patch, MRM-153.patch,
> MRM-155.patch, patch.patch
>
>
> When a maven1 client asks for /servletapi/jars/servletapi-2.4.jar, Archiva
> converts path to the maven2 location of this artifact. As maven1 has no
> relocation support, the jar is required in the repo.
> Archiva can be more that a proxy : download the artifact POM, read relocation
> infos, and return the relocated jar.
> attached Patch add a new "applyRelocation" to DefaultProxyManager.
> I've tried this code with the servletapi example, but it may be bad designed
> as I just discovered maven / archiva APIs.
--
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: (MAVENUPLOAD-1371) JUnit-Toolkit 0.5 Upload
JUnit-Toolkit 0.5 Upload Key: MAVENUPLOAD-1371 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1371 Project: maven-upload-requests Issue Type: Task Reporter: Rupert Smith Attachments: junit-toolkit-0.5-bundle.jar http://internap.dl.sourceforge.net/sourceforge/junit-toolkit/junit-toolkit-0.5-bundle.jar https://sourceforge.net/projects/junit-toolkit/ https://sourceforge.net/project/memberlist.php?group_id=187767 JUnit Toolkit enhances JUnit with performance testing, asymptotic behaviour analysis, and concurrency testing. -- 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: (MAVENUPLOAD-1370) JUnit-Toolkit 0.5 Upload
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rupert Smith closed MAVENUPLOAD-1370. - Resolution: Fixed Made a mistake. > JUnit-Toolkit 0.5 Upload > > > Key: MAVENUPLOAD-1370 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1370 > Project: maven-upload-requests > Issue Type: Task >Reporter: Rupert Smith > Attachments: junit-toolkit-0.5-bundle.jar > > > http://internap.dl.sourceforge.net/sourceforge/junit-toolkit/junit-toolkit-0.5-bundle.jar > https://sourceforge.net/projects/junit-toolkit/ > https://sourceforge.net/project/memberlist.php?group_id=187767 > JUnit Toolkit enhances JUnit with performance testing, asymptotic behaviour > analysis, and concurrency testing. -- 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: (MAVENUPLOAD-1370) JUnit-Toolkit 0.5 Upload
JUnit-Toolkit 0.5 Upload Key: MAVENUPLOAD-1370 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1370 Project: maven-upload-requests Issue Type: Task Reporter: Rupert Smith Attachments: junit-toolkit-0.5-bundle.jar http://internap.dl.sourceforge.net/sourceforge/junit-toolkit/junit-toolkit-0.5-bundle.jar https://sourceforge.net/projects/junit-toolkit/ https://sourceforge.net/project/memberlist.php?group_id=187767 JUnit Toolkit enhances JUnit with performance testing, asymptotic behaviour analysis, and concurrency testing. -- 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: (MWAR-90) Documentation has a typo.
[ http://jira.codehaus.org/browse/MWAR-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MWAR-90. --- Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.1 Fixed > Documentation has a typo. > - > > Key: MWAR-90 > URL: http://jira.codehaus.org/browse/MWAR-90 > Project: Maven 2.x War Plugin > Issue Type: Bug >Reporter: Chris lutje Spelberg > Assigned To: Vincent Siveton > Fix For: 2.1 > > > At the page http://maven.apache.org/plugins/maven-war-plugin/usage.html the > example uses 'webAppDirectory' instead of 'webappDirectory': > > [...] > > > > org.apache.maven.plugins > maven-war-plugin > 2.0 > > > /sample/servlet/container/deploy/directory > > > > > > [...] > -- 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-2579) Let META-INF/maven/../pom.properties|pom.xml be generated in generate-resources
[ http://jira.codehaus.org/browse/MNG-2579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_87006 ] Alexander Klimetschek commented on MNG-2579: A BuildTimeStamp would be very cool as a property. Or something like the identifier suffix Maven uses to separate the different versions of a snapshot jar in the repositories, which uses timestamps too. > Let META-INF/maven/../pom.properties|pom.xml be generated in > generate-resources > --- > > Key: MNG-2579 > URL: http://jira.codehaus.org/browse/MNG-2579 > Project: Maven 2 > Issue Type: Improvement >Reporter: Kenney Westerhof > > Some applications use the META-INF/maven/../pom.properties to read the > application/jar version at runtime. > This file is generated in the package phase. > During unit tests, or running applications from the workspace (project tree), > these files > are not available, which causes problems. > Suggest to move the pom.(properties|xml) generating code in the > maven-jar-plugin to a separate > mojo that's bound to generate-resources. -- 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: (MNG-2814) OS name is only detected if lower cased
OS name is only detected if lower cased
---
Key: MNG-2814
URL: http://jira.codehaus.org/browse/MNG-2814
Project: Maven 2
Issue Type: Bug
Components: Profiles
Affects Versions: 2.0.4
Reporter: Graham Leggett
The following profile does not activate on MacosX:
activate-mac
Mac OS X
"Mac OS X" matches the value returned when querying ${os.name}.
If you lowercase the name, the profile is activated:
activate-mac
mac os x
This is counter intuitive, as one would expect the exact cut and pasted
(capitalised) ${os.name} value to work as an OS name in a 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] Created: (MAVENUPLOAD-1369) New PostgreSQL JDBC driver versions
New PostgreSQL JDBC driver versions --- Key: MAVENUPLOAD-1369 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1369 Project: maven-upload-requests Issue Type: Task Reporter: Oliver Siegmar http://www.siegmar.org/maven2/postgresql-8.0-318.jdbc3-bundle.jar http://www.siegmar.org/maven2/postgresql-8.1-408.jdbc3-bundle.jar http://www.siegmar.org/maven2/postgresql-8.2-504.jdbc3-bundle.jar http://www.siegmar.org/maven2/postgresql-8.2-504.jdbc4-bundle.jar http://jdbc.postgresql.org http://jdbc.postgresql.org/who.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] Commented: (SCM-278) NPE when running changelog
[
http://jira.codehaus.org/browse/SCM-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_86992
]
Ludovic Claude commented on SCM-278:
Adding the following lines to VssHistoryCommand.java takes care of this issue.
It works well for me, builds are now executed when there are modifications in
the VSS repository.
//Display only versions that fall within specified data range.
if ( startDate != null )
{
+ if (endDate == null)
+ {
+ endDate = new Date(); // = now
+ }
SimpleDateFormat sdf = new SimpleDateFormat( "dd/MM/",
Locale.ENGLISH );
String dateRange = sdf.format( endDate ) + "~" + sdf.format(
startDate );
command.createArgument().setValue( VssConstants.FLAG_VERSION_DATE +
dateRange );
}
return command;
> NPE when running changelog
> --
>
> Key: SCM-278
> URL: http://jira.codehaus.org/browse/SCM-278
> Project: Maven SCM
> Issue Type: Bug
> Components: maven-scm-provider-vss
> Environment: SourceSafe 6.0d, Win XP
>Reporter: Ludovic Claude
>
> Hello,
> I have the following error when I try to update an existing project with
> Continuum. The first checkout of the project works fine, but when I modify
> some sources in VSS, I get this error. Forcing the build a second time works
> fine, so it's not a showstopper bug.
> org.apache.maven.continuum.scm.ContinuumScmException: Error while update
> sources.
> at
> org.apache.maven.continuum.scm.DefaultContinuumScm.updateProject(DefaultContinuumScm.java:272)
> at
> org.apache.maven.continuum.core.action.UpdateWorkingDirectoryFromScmContinuumAction.execute(UpdateWorkingDirectoryFromScmContinuumAction.java:58)
> at
> org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:166)
> at
> org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:47)
> at
> org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:103)
> at java.lang.Thread.run(Thread.java:534)
> Caused by: org.apache.maven.scm.ScmException: Exception while executing SCM
> command.
> at
> org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:59)
> at
> org.apache.maven.scm.provider.vss.VssScmProvider.update(VssScmProvider.java:209)
> at
> org.apache.maven.scm.provider.AbstractScmProvider.update(AbstractScmProvider.java:386)
> at
> org.apache.maven.scm.provider.AbstractScmProvider.update(AbstractScmProvider.java:363)
> at
> org.apache.maven.continuum.scm.DefaultContinuumScm.updateProject(DefaultContinuumScm.java:242)
> ... 5 more
> Caused by: java.lang.NullPointerException
> at java.util.Calendar.setTime(Calendar.java:902)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:782)
> at java.text.SimpleDateFormat.format(SimpleDateFormat.java:775)
> at java.text.DateFormat.format(DateFormat.java:314)
> at
> org.apache.maven.scm.provider.vss.commands.changelog.VssHistoryCommand.buildCmdLine(VssHistoryCommand.java:114)
> at
> org.apache.maven.scm.provider.vss.commands.changelog.VssHistoryCommand.executeChangeLogCommand(VssHistoryCommand.java:52)
> at
> org.apache.maven.scm.command.changelog.AbstractChangeLogCommand.executeCommand(AbstractChangeLogCommand.java:91)
> at
> org.apache.maven.scm.command.update.AbstractUpdateCommand.executeCommand(AbstractUpdateCommand.java:63)
> at
> org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:55)
--
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-2812) Profile with an undefined os family activation should not activate
[
http://jira.codehaus.org/browse/MNG-2812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Venisse updated MNG-2812:
--
Fix Version/s: 2.1.x
2.0.6
> Profile with an undefined os family activation should not activate
> --
>
> Key: MNG-2812
> URL: http://jira.codehaus.org/browse/MNG-2812
> Project: Maven 2
> Issue Type: Bug
> Components: Profiles
>Affects Versions: 2.0.4, 2.1.x
>Reporter: Franz Allan Valencia See
> Fix For: 2.0.6, 2.1.x
>
>
> The following profile gets activated eventhough the os family is not the
> current os family
> {code:xml}
> ...
>
> bogus-profile
>
>
> bogus-family
>
>
>
> ...
> {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
