[jira] Commented: (MSITE-293) Submodule inherit menu but this should not happend
[
http://jira.codehaus.org/browse/MSITE-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=171662#action_171662
]
Anthony Whitford commented on MSITE-293:
This needs to be in the pipeline to be fixed, otherwise we can't upgrade!
Pretty please... :D
> Submodule inherit menu but this should not happend
> --
>
> Key: MSITE-293
> URL: http://jira.codehaus.org/browse/MSITE-293
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: inheritance, site descriptor
>Affects Versions: 2.0-beta-6
> Environment: maven 2.0.8
> jdk 1.6
> windows
>Reporter: Andreas Höhmann
>Priority: Critical
> Attachments: MSITE-293.zip
>
>
> Projectstructur:
> {noformat}
> modul
> | pom.xml
> | src/site/site.xml
> | src/site/xdoc/index.xml
> +-- submodul 1
> | pom.xml
> | src/site/xdoc/index.xml
> +-- submodul 2
> | pom.xml
> | src/site/xdoc/index.xml
> {noformat}
> modul :: site.xml
> {code}
> ...
>
>
>
>
>
>
>
>
>
>
>
>
>
>href="http://lp2p067c:82/maven2/repositories/"; />
>
>
>
>
>
> ...
> {code}
> after "mvn clean install site" each submodules has a menu "Maven" ... but i
> want this only for the "main-modul".
> whats wrong?
> http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html
> ... Inheritance ... "By default, only the basic settings are inherited. From
> the body, only the links are inherited, and these accumulate to contain all
> the parents' site descriptor links."
--
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-398) Menus from the parent pom should not be inherited
Menus from the parent pom should not be inherited
-
Key: MSITE-398
URL: http://jira.codehaus.org/browse/MSITE-398
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: site descriptor
Affects Versions: 2.0, 2.0-beta-7, 2.0-beta-6
Environment: Windows, Java 6, Maven 2.09
Reporter: Anthony Whitford
Priority: Blocker
Attachments: maven-site-plugin-bug.zip
According to the *Inheritance* section from:
[http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html]
it says,
bq. By default, only the basic settings are inherited. From the body, only the
links are inherited, and these accumulate to contain all the parents' site
descriptor links.
Alas, this is not the case and this is a major problem. If I downgrade to
2.0-beta-5, the behavior is as expected. Using 2.0-beta-6, 2.0-beta-7, or 2.0,
makes the menus from the parent pom trickle into the inheriting project.
I have attached a sample project to illustrate this problem. The attached zip
contains 2 simple maven projects:
* parentpom -- represents a corporate parent pom with some site documentation
* multiproj -- represents a multiproject that inherits the parentpom.
If you edit _parentpom\pom.xml_ and change the version of the site plugin to
*2.0-beta-5*, then run {{mvn clean install site}} for both the {{parentpom}}
and then {{multiproj}}, you will see a fine site generated for _multiproj_.
Then, if you edit _parentpom\pom.xml_ and change the version of the site plugin
to *2.0* (the latest), then run {{mvn clean install site}} for both the
{{parentpom}} and then {{multiproj}}, you will see the site generated for
_multiproj_ contains menu links from the parent pom which should not have been
inherited.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4112) Set property containing the currently executing maven version.
[ http://jira.codehaus.org/browse/MNG-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=171660#action_171660 ] Brett Porter commented on MNG-4112: --- that's exactly what the runtimeinformation does. I misunderstood what Jason meant on the list by "making it work". If you're happy to settle for making a change to Maven, then putting maven.version into the context for interpolation and anything else that is going to grab it from the session is probably the right way to go. I had the feeling 3.x already has this, but 2.1 doesn't - would need to check though. > Set property containing the currently executing maven version. > -- > > Key: MNG-4112 > URL: http://jira.codehaus.org/browse/MNG-4112 > Project: Maven 2 > Issue Type: Improvement >Reporter: Paul Gier > > It would be helpful to have an easy way to access the current version of > maven. This might be accomplished by setting a property like "maven.version" > during startup that would be available to the pom and/or to plugins. This > could be used to record what version of maven was used during the build to > facilitate build reproducibility. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4112) Set property containing the currently executing maven version.
[ http://jira.codehaus.org/browse/MNG-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=171658#action_171658 ] Paul Gier commented on MNG-4112: I looked into it a bit, and I should be able to get the version the same way that it's retrieved when you run "mvn -version" from the command line. It gets the information from the maven core jar, so it wouldn't be dependent on the RuntimeInformation. I wasn't sure if it should be a system property, or should the scope of the property be more localized? The RuntimeInformation could be used in a goal in a plugin (maybe the buildnumber plugin?) to allow the version to be accessed in maven pre 3.0. > Set property containing the currently executing maven version. > -- > > Key: MNG-4112 > URL: http://jira.codehaus.org/browse/MNG-4112 > Project: Maven 2 > Issue Type: Improvement >Reporter: Paul Gier > > It would be helpful to have an easy way to access the current version of > maven. This might be accomplished by setting a property like "maven.version" > during startup that would be available to the pom and/or to plugins. This > could be used to record what version of maven was used during the build to > facilitate build reproducibility. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4112) Set property containing the currently executing maven version.
[ http://jira.codehaus.org/browse/MNG-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=171654#action_171654 ] Jason van Zyl commented on MNG-4112: Just test the property is present, don't bind it to the RuntimeInformation because it will be different in Maven 3.x. The property being available is cool, specifically getting it from the RuntimeInformation component is not. Shouldn't be source dependent. > Set property containing the currently executing maven version. > -- > > Key: MNG-4112 > URL: http://jira.codehaus.org/browse/MNG-4112 > Project: Maven 2 > Issue Type: Improvement >Reporter: Paul Gier > > It would be helpful to have an easy way to access the current version of > maven. This might be accomplished by setting a property like "maven.version" > during startup that would be available to the pom and/or to plugins. This > could be used to record what version of maven was used during the build to > facilitate build reproducibility. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4122) deploy:deploy-file over rights maven-metadata.xml
[ http://jira.codehaus.org/browse/MNG-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim McCaskey closed MNG-4122. - Resolution: Fixed Opened this in the wrong place. Opened it in the right place here: http://jira.codehaus.org/browse/MDEPLOY-99 > deploy:deploy-file over rights maven-metadata.xml > - > > Key: MNG-4122 > URL: http://jira.codehaus.org/browse/MNG-4122 > Project: Maven 2 > Issue Type: Bug > Components: Deployment >Affects Versions: 2.1.0 > Environment: Windows XP >Reporter: Jim McCaskey > > Using deploy:deploy-file to add multiple version of an artifact causes the > artifactId maven-metadata.xml file to be recreated new and the old contents > to be removed. Once done I am left with contents like this: > > com.pervasive.component > artifact-distribution > 4.0.2.11 > > > 4.0.2.11 > > 20090401013925 > > > This is using Maven 2.1.0 and maven-deploy-plugin 2.4. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4122) deploy:deploy-file over rights maven-metadata.xml
deploy:deploy-file over rights maven-metadata.xml - Key: MNG-4122 URL: http://jira.codehaus.org/browse/MNG-4122 Project: Maven 2 Issue Type: Bug Components: Deployment Affects Versions: 2.1.0 Environment: Windows XP Reporter: Jim McCaskey Using deploy:deploy-file to add multiple version of an artifact causes the artifactId maven-metadata.xml file to be recreated new and the old contents to be removed. Once done I am left with contents like this: com.pervasive.component artifact-distribution 4.0.2.11 4.0.2.11 20090401013925 This is using Maven 2.1.0 and maven-deploy-plugin 2.4. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEPLOY-99) deploy:deploy-file over rights maven-metadata.xml
deploy:deploy-file over rights maven-metadata.xml - Key: MDEPLOY-99 URL: http://jira.codehaus.org/browse/MDEPLOY-99 Project: Maven 2.x Deploy Plugin Issue Type: Bug Components: deploy:deploy-file Affects Versions: 2.4 Environment: Windows XP Reporter: Jim McCaskey Using deploy:deploy-file to add multiple version of an artifact causes the artifactId maven-metadata.xml file to be recreated new and the old contents to be removed. Once done I am left with contents like this: com.pervasive.component artifact-distribution 4.0.2.11 4.0.2.11 20090401013925 This is using Maven 2.1.0 and maven-deploy-plugin 2.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-4118) Execution order of report plugins is arbitrary if inheritance is involved
[ http://jira.codehaus.org/browse/MNG-4118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-4118: -- Fix Version/s: 2.1.1 confirmed. Further investigation is needed and the IT for 3808 enhanced. > Execution order of report plugins is arbitrary if inheritance is involved > - > > Key: MNG-4118 > URL: http://jira.codehaus.org/browse/MNG-4118 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle, Sites & Reporting >Affects Versions: 2.0.10, 2.1.0 > Environment: ubuntu 8.10 > maven 2.10 > /opt/development/tools/apache-maven-2.1.0/bin/mvn --version > Warning: JAVA_HOME environment variable is not set. > Apache Maven 2.1.0 (r755702; 2009-03-18 20:10:27+0100) > Java version: 1.6.0_10 > Java home: /usr/lib/jvm/java-6-sun-1.6.0.10/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.27-11-generic" arch: "i386" Family: "unix" >Reporter: Luca > Fix For: 2.1.1 > > Attachments: Regression.tgz, sitefull.log.tgz > > > this issue is the clone of http://jira.codehaus.org/browse/MNG-3808 > the output of > /opt/development/tools/apache-maven-2.1.0/bin/mvn clean install site -X > > sitefull.log > is in attachment with the whole project. > the command was executed in Regression/ComponentB > Feel free to ask more info! > 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] Closed: (MNG-4093) SNAPSHOT jars not correctly updated
[
http://jira.codehaus.org/browse/MNG-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-4093.
-
Resolution: Not A Bug
great, thanks
> SNAPSHOT jars not correctly updated
> ---
>
> Key: MNG-4093
> URL: http://jira.codehaus.org/browse/MNG-4093
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.10
>Reporter: Gin-Ting Chen
>Assignee: Brett Porter
>
> Occasionally I would get compilation errors after releasing a new SNAPSHOT
> dependency of a project.
> After some debugging I found that it was adding a -SNAPSHOT.jar to my
> classpath and not the actual timestamped jar.
> But I also found that, occasionally, I would get this:
> {code}
> -rw-r--r-- 1 tich tich 1482491 common-util-25-20090313.151759-9.jar
> -rw-r--r-- 1 tich tich 1482490 common-util-25-20090317.001243-13.jar
> -rw-r--r-- 1 tich tich 1482491 common-util-25-SNAPSHOT.jar
> {code}
> It seems that the SNAPSHOT downloading process *silently* fails to update the
> x-SNAPSHOT.jar.
> This behavior seems to occur randomly and can not be recovered from until you:
> * delete the corrupted local repository OR
> * release a new snapshot
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Work started: (MNG-4093) SNAPSHOT jars not correctly updated
[
http://jira.codehaus.org/browse/MNG-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MNG-4093 started by Brett Porter.
> SNAPSHOT jars not correctly updated
> ---
>
> Key: MNG-4093
> URL: http://jira.codehaus.org/browse/MNG-4093
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.10
>Reporter: Gin-Ting Chen
>Assignee: Brett Porter
>
> Occasionally I would get compilation errors after releasing a new SNAPSHOT
> dependency of a project.
> After some debugging I found that it was adding a -SNAPSHOT.jar to my
> classpath and not the actual timestamped jar.
> But I also found that, occasionally, I would get this:
> {code}
> -rw-r--r-- 1 tich tich 1482491 common-util-25-20090313.151759-9.jar
> -rw-r--r-- 1 tich tich 1482490 common-util-25-20090317.001243-13.jar
> -rw-r--r-- 1 tich tich 1482491 common-util-25-SNAPSHOT.jar
> {code}
> It seems that the SNAPSHOT downloading process *silently* fails to update the
> x-SNAPSHOT.jar.
> This behavior seems to occur randomly and can not be recovered from until you:
> * delete the corrupted local repository OR
> * release a new snapshot
--
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-4107) [regression] User settings can't override properties used for POM interpolation
[
http://jira.codehaus.org/browse/MNG-4107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MNG-4107:
--
Fix Version/s: 3.0-alpha-5
> [regression] User settings can't override properties used for POM
> interpolation
> ---
>
> Key: MNG-4107
> URL: http://jira.codehaus.org/browse/MNG-4107
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation
>Affects Versions: 3.0-alpha-3
>Reporter: Benjamin Bentmann
> Fix For: 3.0-alpha-5
>
>
> POM snippet:
> {code:xml}
>
> ${pomVsSettings}
>
>
>
> pom
>
> true
>
>
> pom
>
>
>
> {code}
> and in {{settings.xml}}:
> {code:xml}
>
>
> settings
>
> true
>
>
> settings
>
>
>
> {code}
> This ends up with pomVsSettingsInterpolated=pom instead of
> pomVsSettingsInterpolated=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] Commented: (MNG-4093) SNAPSHOT jars not correctly updated
[
http://jira.codehaus.org/browse/MNG-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=171632#action_171632
]
Gin-Ting Chen commented on MNG-4093:
Yes :) If I find some time I'll submit a proper patch to maven ant task for
this.
> SNAPSHOT jars not correctly updated
> ---
>
> Key: MNG-4093
> URL: http://jira.codehaus.org/browse/MNG-4093
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.10
>Reporter: Gin-Ting Chen
>Assignee: Brett Porter
>
> Occasionally I would get compilation errors after releasing a new SNAPSHOT
> dependency of a project.
> After some debugging I found that it was adding a -SNAPSHOT.jar to my
> classpath and not the actual timestamped jar.
> But I also found that, occasionally, I would get this:
> {code}
> -rw-r--r-- 1 tich tich 1482491 common-util-25-20090313.151759-9.jar
> -rw-r--r-- 1 tich tich 1482490 common-util-25-20090317.001243-13.jar
> -rw-r--r-- 1 tich tich 1482491 common-util-25-SNAPSHOT.jar
> {code}
> It seems that the SNAPSHOT downloading process *silently* fails to update the
> x-SNAPSHOT.jar.
> This behavior seems to occur randomly and can not be recovered from until you:
> * delete the corrupted local repository OR
> * release a new snapshot
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4112) Set property containing the currently executing maven version.
[ http://jira.codehaus.org/browse/MNG-4112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=171630#action_171630 ] Brett Porter commented on MNG-4112: --- from the thread on the ML, it sounded like it was acceptable usage to grab the RuntimeInformation component (but add an integration test to Maven to make sure it survives any future refactoring). > Set property containing the currently executing maven version. > -- > > Key: MNG-4112 > URL: http://jira.codehaus.org/browse/MNG-4112 > Project: Maven 2 > Issue Type: Improvement >Reporter: Paul Gier > > It would be helpful to have an easy way to access the current version of > maven. This might be accomplished by setting a property like "maven.version" > during startup that would be available to the pom and/or to plugins. This > could be used to record what version of maven was used during the build to > facilitate build reproducibility. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4120) Profile activation should be per module
[ http://jira.codehaus.org/browse/MNG-4120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=171631#action_171631 ] Brett Porter commented on MNG-4120: --- I'm not sure I understand - are you trying to activate based on an inherited profile? Can you attach a sample project that illustrates? > Profile activation should be per module > --- > > Key: MNG-4120 > URL: http://jira.codehaus.org/browse/MNG-4120 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies, POM >Affects Versions: 2.0.9 >Reporter: Karsten Tinnefeld > > In a multi-module-project, one might wish to run certain targets dependent on > the existance of some file or directory. > In a single-module-project, I'd say > do-if-file-exists > some/special/path > > This however does not work on a per-module base in a multi-module project, > but the profile is (de)activated depending on the situation on the run pom > only, and this is not even documented. > In my opinion, profile activation should be on a per-module basis. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4110) cyclic reference with 2.1.0 that doesn't matter with 2.0.10
[ http://jira.codehaus.org/browse/MNG-4110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-4110. - Assignee: Brett Porter Resolution: Won't Fix this is still correct. Consider if you had pmd:check bound to the lifecycle, then ran "mvn install". This would run in the parent, requiring the child to have run first, but the child obvious requires the parent to run first. You need to separate the parent into 2 - one that modules that need to use PMD can inherit from, and the common stuff that that parent and the build-tools module can inherit from. > cyclic reference with 2.1.0 that doesn't matter with 2.0.10 > --- > > Key: MNG-4110 > URL: http://jira.codehaus.org/browse/MNG-4110 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.1.0 > Environment: Linux >Reporter: Stephan Kleine >Assignee: Brett Porter > Attachments: maven-bugreport.tar.bz2 > > > The situation is that we have a parent pom.xml (projectA in the attachment) > which is the parent of every other project. One of the other projects is the > one where we define global configuration files for e.g. Checkstyle & PMD > checks (projectB in the attachment). > The cycle exists because projectA refers to projectB in the Checkstyle & PMD > plugin configuration and projectA is the parent of projectB. > IMHO this shouldn't matter (as it as with Maven 2.0.10 and earlier) because > projectA is only packaged as a pom and therefore the cycle isn't relevant. -- 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-4093) SNAPSHOT jars not correctly updated
[
http://jira.codehaus.org/browse/MNG-4093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=171628#action_171628
]
Brett Porter commented on MNG-4093:
---
cool - so, have you resolved the issue on your end such that it can be closed
here?
> SNAPSHOT jars not correctly updated
> ---
>
> Key: MNG-4093
> URL: http://jira.codehaus.org/browse/MNG-4093
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.10
>Reporter: Gin-Ting Chen
>Assignee: Brett Porter
>
> Occasionally I would get compilation errors after releasing a new SNAPSHOT
> dependency of a project.
> After some debugging I found that it was adding a -SNAPSHOT.jar to my
> classpath and not the actual timestamped jar.
> But I also found that, occasionally, I would get this:
> {code}
> -rw-r--r-- 1 tich tich 1482491 common-util-25-20090313.151759-9.jar
> -rw-r--r-- 1 tich tich 1482490 common-util-25-20090317.001243-13.jar
> -rw-r--r-- 1 tich tich 1482491 common-util-25-SNAPSHOT.jar
> {code}
> It seems that the SNAPSHOT downloading process *silently* fails to update the
> x-SNAPSHOT.jar.
> This behavior seems to occur randomly and can not be recovered from until you:
> * delete the corrupted local repository OR
> * release a new snapshot
--
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-3714) Allow specification of the toolchains.xml location on the command line
[ http://jira.codehaus.org/browse/MNG-3714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-3714: --- Attachment: toolchains.patch Oh, didn't search hard enough to find this one... proposed patch for trunk, comments welcome. > Allow specification of the toolchains.xml location on the command line > -- > > Key: MNG-3714 > URL: http://jira.codehaus.org/browse/MNG-3714 > Project: Maven 2 > Issue Type: Improvement > Components: Command Line >Affects Versions: 2.0.10 >Reporter: John Casey > Fix For: 2.2.0-M1 > > Attachments: toolchains.patch > > > Allowing CLI specification of the toolchains.xml file will allow more > flexible configurations in CI environments. -- 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-4121) Make path to toolschains.xml configurable
[ http://jira.codehaus.org/browse/MNG-4121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-4121. - Assignee: Brett Porter Resolution: Duplicate > Make path to toolschains.xml configurable > - > > Key: MNG-4121 > URL: http://jira.codehaus.org/browse/MNG-4121 > Project: Maven 2 > Issue Type: New Feature > Components: Command Line >Affects Versions: 2.1.0, 3.0-alpha-2 >Reporter: Benjamin Bentmann >Assignee: Brett Porter > > Right now, the path to the toolchains.xml is hard-coded to > ~/.m2/toolchains.xml. To improve flexibility and to enable integration > testing, we need a way to confgure the location of the toolchains.xml. -- 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-4121) Make path to toolschains.xml configurable
Make path to toolschains.xml configurable - Key: MNG-4121 URL: http://jira.codehaus.org/browse/MNG-4121 Project: Maven 2 Issue Type: New Feature Components: Command Line Affects Versions: 3.0-alpha-2, 2.1.0 Reporter: Benjamin Bentmann Right now, the path to the toolchains.xml is hard-coded to ~/.m2/toolchains.xml. To improve flexibility and to enable integration testing, we need a way to confgure the location of the toolchains.xml. -- 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: (MIDEA-119) sourceDirectory that's not direct children of the current directory doesn't get pick up when issuing maven idea:idea
[ http://jira.codehaus.org/browse/MIDEA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=171613#action_171613 ] Rama Notowidigdo commented on MIDEA-119: It's interesting you mentioned that but it's recommended on maven website, specially when you're migrating from ant that has been used for years to maven, radical changes is hard to do at one time and should be in phases. This would accomodate that. http://maven.apache.org/guides/mini/guide-using-one-source-directory.html > sourceDirectory that's not direct children of the current directory doesn't > get pick up when issuing maven idea:idea > > > Key: MIDEA-119 > URL: http://jira.codehaus.org/browse/MIDEA-119 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Reporter: Rama Notowidigdo > > When issuing mvn idea:idea with the following pom: > 4.0.0 > x > 1.0.0-SNAPSHOT > jar > > ../../build/java > > The module created doesn't pickup the source directory. > But it works fine if I"m pointing a directory that's a child directory from > the current dir: > When issuing mvn idea:idea with the following pom: > 4.0.0 > x > 1.0.0-SNAPSHOT > jar > > build/java > > build directory is the child of the current dir. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSOURCES-36) Source jar manifest should contain Specification and Implementation details
[ http://jira.codehaus.org/browse/MSOURCES-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier closed MSOURCES-36. - Resolution: Duplicate This is fixed by MSOURCES-42 > Source jar manifest should contain Specification and Implementation details > --- > > Key: MSOURCES-36 > URL: http://jira.codehaus.org/browse/MSOURCES-36 > Project: Maven 2.x Source Plugin > Issue Type: Bug >Reporter: SebbASF >Priority: Minor > Fix For: 2.1 > > > The javadoc jar manifest should contain Specification and Implementation > details, e.g.: > Implementation-Title: Commons SCXML > Implementation-Vendor: The Apache Software Foundation > Implementation-Vendor-Id: org.apache > Implementation-Version: 0.8 > Specification-Title: Commons SCXML > Specification-Vendor: The Apache Software Foundation > Specification-Version: 0.8 -- 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: (MSOURCES-42) Please add support for MavenArchiveConfiguration
[
http://jira.codehaus.org/browse/MSOURCES-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier closed MSOURCES-42.
-
Resolution: Fixed
Added an archive parameter similar to the jar and javadoc plugins.
> Please add support for MavenArchiveConfiguration
>
>
> Key: MSOURCES-42
> URL: http://jira.codehaus.org/browse/MSOURCES-42
> Project: Maven 2.x Source Plugin
> Issue Type: Wish
>Affects Versions: 2.0.4
> Environment: Maven version: 2.0.10
> Java version: 1.5.0_17
> OS name: "linux" version: "2.6.29" arch: "i386" Family: "unix"
>Reporter: Christian Schulte
>Assignee: Paul Gier
> Fix For: 2.1
>
>
> Almost any mojo using the plexus archiver has an 'archive' parameter to
> configure the archiver.
> {code}
> /**
> * The archive configuration to use.
> * See href="http://maven.apache.org/shared/maven-archiver/index.html";>Maven
> Archiver Reference.
> *
> * @parameter
> */
> private MavenArchiveConfiguration archive = new
> MavenArchiveConfiguration();
> {code}
> The source plugin should also have such functionality.
--
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-2410) Validator.nu HTML parser 1.2.0 to Maven repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=171610#action_171610 ] Chris Hubick commented on MAVENUPLOAD-2410: --- Note that there is no file at: http://repo1.maven.org/maven2/nu/validator/htmlparser/htmlparser/maven-metadata.xml This means that using a version dependency _range_ like: nu.validator.htmlparser htmlparser [1.1,1.2) compile Will yield an error "Failed to resolve artifact. No versions are present in the repository for the artifact with a range [1.1,1.2)". This is obviously less than ideal. > Validator.nu HTML parser 1.2.0 to Maven repo > > > Key: MAVENUPLOAD-2410 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2410 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Henri Sivonen > Attachments: htmlparser-1.2.0-bundle.jar > > > For reference, the previous version was MAVENUPLOAD-2186. > * Fixed an issue where under rare circumstances attribute values leaking > into element content. > * Fixed a bug where isindex processing added attributes to all elements > that were supposed to have no attributes. > * Implemented spec changes. (Too numerous to enumerate, but, as a > highlight, framesets parse much better now.) > * Moved to WebKit-style foster parenting. > * Changed the API for tree builder subclasses again due to new > constraints. If you have previously written your own tree builder subclass, > you need to change it. > * Fixed the bundled XML serializer. > * Made it possible to generate a C++ version that does not leak memory > from the Java source. > * Removed the C++ translator for the release. (Get it from SVN.) > * Fixed JavaDocs about XML violation policy defaults. > * Fixed the handling of spaces in attributes in the XML serializer. > * Made getElementById work with the DOM trees built by the parser. -- 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: (MEV-623) Wrong product in xmlpull
Wrong product in xmlpull Key: MEV-623 URL: http://jira.codehaus.org/browse/MEV-623 Project: Maven Evangelism Issue Type: Task Components: Problem with Jar Reporter: Joerg Schaible xmlpull:xmlpull contains normally the XmlPull API V1 of http://www.xmlpull.org implemented by the Xpp3 and kXML 2 parsers. This is true for the artifacts in version 1.1.2.1, 1.1.3.1 and 1.1.3.4a in central. However, version 1.1.3.4d_b4_min is something completely different. Although normally nothing is removed from the repo, I think this is really a different case, since: - the artifact is actually a version of xpp3:xpp3_min - the artifact does contain one half of an unknown version of the XmlPull classes - the POM claims a wrong license (Xpp3 parser is not public domain in contrast to the XmlPull API) - the artifact is not available from XmlPull homepage (http://www.xmlpull.org/v1/download/) - this artifact implies the availability of the "latest" version Don't know how this one could sneak in though. -- 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: (MSOURCES-33) provide configuration
[ http://jira.codehaus.org/browse/MSOURCES-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MSOURCES-33: -- Fix Version/s: 2.1 > provideconfiguration > > > Key: MSOURCES-33 > URL: http://jira.codehaus.org/browse/MSOURCES-33 > Project: Maven 2.x Source Plugin > Issue Type: Wish >Reporter: jianwu > Fix For: 2.1 > > -- 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: (MSOURCES-36) Source jar manifest should contain Specification and Implementation details
[ http://jira.codehaus.org/browse/MSOURCES-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier updated MSOURCES-36: -- Fix Version/s: 2.1 > Source jar manifest should contain Specification and Implementation details > --- > > Key: MSOURCES-36 > URL: http://jira.codehaus.org/browse/MSOURCES-36 > Project: Maven 2.x Source Plugin > Issue Type: Bug >Reporter: SebbASF >Priority: Minor > Fix For: 2.1 > > > The javadoc jar manifest should contain Specification and Implementation > details, e.g.: > Implementation-Title: Commons SCXML > Implementation-Vendor: The Apache Software Foundation > Implementation-Vendor-Id: org.apache > Implementation-Version: 0.8 > Specification-Title: Commons SCXML > Specification-Vendor: The Apache Software Foundation > Specification-Version: 0.8 -- 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: (MSOURCES-42) Please add support for MavenArchiveConfiguration
[
http://jira.codehaus.org/browse/MSOURCES-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MSOURCES-42:
--
Assignee: Paul Gier
Fix Version/s: 2.1
> Please add support for MavenArchiveConfiguration
>
>
> Key: MSOURCES-42
> URL: http://jira.codehaus.org/browse/MSOURCES-42
> Project: Maven 2.x Source Plugin
> Issue Type: Wish
>Affects Versions: 2.0.4
> Environment: Maven version: 2.0.10
> Java version: 1.5.0_17
> OS name: "linux" version: "2.6.29" arch: "i386" Family: "unix"
>Reporter: Christian Schulte
>Assignee: Paul Gier
> Fix For: 2.1
>
>
> Almost any mojo using the plexus archiver has an 'archive' parameter to
> configure the archiver.
> {code}
> /**
> * The archive configuration to use.
> * See href="http://maven.apache.org/shared/maven-archiver/index.html";>Maven
> Archiver Reference.
> *
> * @parameter
> */
> private MavenArchiveConfiguration archive = new
> MavenArchiveConfiguration();
> {code}
> The source plugin should also have such functionality.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-397) Artifact ###### has no file error.
[ http://jira.codehaus.org/browse/MSITE-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=171596#action_171596 ] Dennis Lundberg commented on MSITE-397: --- Can you please provide a full log of the output. At first glance it seems to have something to do with Maven Project Info Reports Plugin. > Artifact ## has no file error. > -- > > Key: MSITE-397 > URL: http://jira.codehaus.org/browse/MSITE-397 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: Windows xp, tomcat 5.5 server >Reporter: Damian Sinczak >Priority: Minor > > During 'mvn site' command on project i receive some strange errors. Their are > no critical, but they are still errors. > Console dump: > [ERROR] Artifact: org.apache.abdera:abdera-core:jar:0.4.0-incubating has no > file > . > [ERROR] Artifact: > org.apache.abdera:abdera-extensions-json:jar:0.4.0-incubating > has no file. > [ERROR] Artifact: > org.apache.abdera:abdera-extensions-main:jar:0.4.0-incubating > has no file. > [ERROR] Artifact: org.apache.abdera:abdera-i18n:jar:0.4.0-incubating has no > file > . > [ERROR] Artifact: org.apache.abdera:abdera-parser:jar:0.4.0-incubating has no > fi > le. > [ERROR] Artifact: org.apache.cxf:cxf-api:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-common-schemas:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-common-utilities:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-bindings-soap:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-bindings-xml:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-core:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-frontend-simple:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-rt-ws-addr:jar:2.2 has no file. > [ERROR] Artifact: org.apache.cxf:cxf-tools-common:jar:2.2 has no file. > [ERROR] Artifact: > org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0 > .2 has no file. > [ERROR] Artifact: > org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1 > .1 has no file. > [ERROR] Artifact: > org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.5 h > as no file. > [ERROR] Artifact: org.apache.geronimo.specs:geronimo-jaxws_2.1_spec:jar:1.0 > has > no file. > [ERROR] Artifact: org.apache.geronimo.specs:geronimo-servlet_2.5_spec:jar:1.2 > ha > s no file. > [ERROR] Artifact: > org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1 > has no file. > [ERROR] Artifact: > org.apache.geronimo.specs:geronimo-ws-metadata_2.0_spec:jar:1. > 1.2 has no file. > [ERROR] Artifact: org.apache.neethi:neethi:jar:2.0.4 has no file. > [ERROR] Artifact: org.apache.ws.commons.axiom:axiom-api:jar:1.2.7 has no file. > [ERROR] Artifact: org.apache.ws.commons.axiom:axiom-impl:jar:1.2.7 has no > file. > [ERROR] Artifact: org.apache.ws.commons.schema:XmlSchema:jar:1.4.4 has no > file. > [ERROR] Artifact: org.apache.xmlbeans:xmlbeans:jar:2.3.0 has no file. > [ERROR] Artifact: org.codehaus.jettison:jettison:jar:1.0.1 has no file. > [ERROR] Artifact: org.codehaus.woodstox:wstx-asl:jar:3.2.6 has no file. > [ERROR] Artifact: org.hibernate:ejb3-persistence:jar:1.0.1.GA has no file. > [ERROR] Artifact: org.hibernate:hibernate-commons-annotations:jar:3.0.0.ga > has n > o file. > [ERROR] Artifact: org.mortbay.jetty:jetty:jar:6.1.15 has no file. > [ERROR] Artifact: org.mortbay.jetty:jetty-util:jar:6.1.15 has no file. > [ERROR] Artifact: org.slf4j:slf4j-api:jar:1.3.1 has no file. > [ERROR] Artifact: org.slf4j:slf4j-jdk14:jar:1.3.1 has no file. > [ERROR] Artifact: org.springframework:spring-beans:jar:2.5.5 has no file. > [ERROR] Artifact: org.springframework:spring-context:jar:2.5.5 has no file. > [ERROR] Artifact: org.springframework:spring-core:jar:2.5.5 has no file. > [ERROR] Artifact: org.springframework:spring-web:jar:2.5.5 has no file. > [ERROR] Artifact: wsdl4j:wsdl4j:jar:1.6.2 has no file. > [ERROR] Artifact: xalan:xalan:jar:2.6.0 has no file. > [ERROR] Artifact: xerces:xercesImpl:jar:2.6.2 has no file. > [ERROR] Artifact: xerces:xmlParserAPIs:jar:2.6.2 has no file. > [ERROR] Artifact: xml-apis:xml-apis:jar:1.3.02 has no file. > [ERROR] Artifact: xml-resolver:xml-resolver:jar:1.2 has no file. > [ERROR] Artifact: xom:xom:jar:1.0 has no file. > [INFO] Generating "Project Team" report. > [INFO] Generating "Project License" report. > [INFO] Generating "Project Plugins" report. > [INFO] Generating "Maven Surefire Report" report. > [INFO] Generating "FindBugs Report" report. > [INFO] Using source root: > [INFO] C:\edys_workspace\edystok\target\classes > [INFO] Using test source root: > [INFO] C:\edys_workspace\edystok\target\test-classes > [INFO] No effort provided, using default eff
[jira] Commented: (MIDEA-119) sourceDirectory that's not direct children of the current directory doesn't get pick up when issuing maven idea:idea
[ http://jira.codehaus.org/browse/MIDEA-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=171595#action_171595 ] Dennis Lundberg commented on MIDEA-119: --- It's a bad idea to have a source directory that is outside of the projects base directory. This doesn't answer your request, but given this it's not like that this issue would be fixed. > sourceDirectory that's not direct children of the current directory doesn't > get pick up when issuing maven idea:idea > > > Key: MIDEA-119 > URL: http://jira.codehaus.org/browse/MIDEA-119 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Reporter: Rama Notowidigdo > > When issuing mvn idea:idea with the following pom: > 4.0.0 > x > 1.0.0-SNAPSHOT > jar > > ../../build/java > > The module created doesn't pickup the source directory. > But it works fine if I"m pointing a directory that's a child directory from > the current dir: > When issuing mvn idea:idea with the following pom: > 4.0.0 > x > 1.0.0-SNAPSHOT > jar > > build/java > > build directory is the child of the current dir. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MERCURY-107) Plugins should be sorted by artifactId in maven-metadata.xml
[ http://jira.codehaus.org/browse/MERCURY-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov closed MERCURY-107. Resolution: Fixed Fix Version/s: 1.0-alpha-6 Patch applied > Plugins should be sorted by artifactId in maven-metadata.xml > > > Key: MERCURY-107 > URL: http://jira.codehaus.org/browse/MERCURY-107 > Project: Mercury > Issue Type: Bug >Affects Versions: 1.0-alpha-5 >Reporter: Juven Xu >Assignee: Oleg Gusakov >Priority: Minor > Fix For: 1.0-alpha-6 > > Attachments: sort-plugin-md.patch > > > while using AddPluginOperation, the elements in maven-metadata.xml > should be sorted after this operation -- 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-4120) Profile activation should be per module
Profile activation should be per module --- Key: MNG-4120 URL: http://jira.codehaus.org/browse/MNG-4120 Project: Maven 2 Issue Type: Bug Components: Dependencies, POM Affects Versions: 2.0.9 Reporter: Karsten Tinnefeld In a multi-module-project, one might wish to run certain targets dependent on the existance of some file or directory. In a single-module-project, I'd say do-if-file-exists some/special/path This however does not work on a per-module base in a multi-module project, but the profile is (de)activated depending on the situation on the run pom only, and this is not even documented. In my opinion, profile activation should be on a per-module basis. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2420) Please add a com.sourcetohtml project to maven repository
Please add a com.sourcetohtml project to maven repository - Key: MAVENUPLOAD-2420 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2420 Project: Maven Upload Requests Issue Type: Wish Reporter: Jiri Celak Please add following line to https://svn.apache.org/repos/asf/maven/repository-tools/trunk/src/bin/synchronize/m2-sync/sync.csv "com.sourcetohtml","mavens...@web.sourceforge.net:/home/users/j/ji/jirkacelak/userweb/htdocs/maven2","rsync_ssh","Jiri Celak","j...@celak.net",, To prove I own the domain, please either go to http://www.whois.net/whois/sourcetohtml.com or to project web site http://www.sourcetohtml.com -- 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-397) Artifact ###### has no file error.
Artifact ## has no file error. -- Key: MSITE-397 URL: http://jira.codehaus.org/browse/MSITE-397 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0 Environment: Windows xp, tomcat 5.5 server Reporter: Damian Sinczak Priority: Minor During 'mvn site' command on project i receive some strange errors. Their are no critical, but they are still errors. Console dump: [ERROR] Artifact: org.apache.abdera:abdera-core:jar:0.4.0-incubating has no file . [ERROR] Artifact: org.apache.abdera:abdera-extensions-json:jar:0.4.0-incubating has no file. [ERROR] Artifact: org.apache.abdera:abdera-extensions-main:jar:0.4.0-incubating has no file. [ERROR] Artifact: org.apache.abdera:abdera-i18n:jar:0.4.0-incubating has no file . [ERROR] Artifact: org.apache.abdera:abdera-parser:jar:0.4.0-incubating has no fi le. [ERROR] Artifact: org.apache.cxf:cxf-api:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-common-schemas:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-common-utilities:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-bindings-soap:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-bindings-xml:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-core:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-databinding-jaxb:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-frontend-simple:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-rt-ws-addr:jar:2.2 has no file. [ERROR] Artifact: org.apache.cxf:cxf-tools-common:jar:2.2 has no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-activation_1.1_spec:jar:1.0 .2 has no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-annotation_1.0_spec:jar:1.1 .1 has no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-javamail_1.4_spec:jar:1.5 h as no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-jaxws_2.1_spec:jar:1.0 has no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-servlet_2.5_spec:jar:1.2 ha s no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1 has no file. [ERROR] Artifact: org.apache.geronimo.specs:geronimo-ws-metadata_2.0_spec:jar:1. 1.2 has no file. [ERROR] Artifact: org.apache.neethi:neethi:jar:2.0.4 has no file. [ERROR] Artifact: org.apache.ws.commons.axiom:axiom-api:jar:1.2.7 has no file. [ERROR] Artifact: org.apache.ws.commons.axiom:axiom-impl:jar:1.2.7 has no file. [ERROR] Artifact: org.apache.ws.commons.schema:XmlSchema:jar:1.4.4 has no file. [ERROR] Artifact: org.apache.xmlbeans:xmlbeans:jar:2.3.0 has no file. [ERROR] Artifact: org.codehaus.jettison:jettison:jar:1.0.1 has no file. [ERROR] Artifact: org.codehaus.woodstox:wstx-asl:jar:3.2.6 has no file. [ERROR] Artifact: org.hibernate:ejb3-persistence:jar:1.0.1.GA has no file. [ERROR] Artifact: org.hibernate:hibernate-commons-annotations:jar:3.0.0.ga has n o file. [ERROR] Artifact: org.mortbay.jetty:jetty:jar:6.1.15 has no file. [ERROR] Artifact: org.mortbay.jetty:jetty-util:jar:6.1.15 has no file. [ERROR] Artifact: org.slf4j:slf4j-api:jar:1.3.1 has no file. [ERROR] Artifact: org.slf4j:slf4j-jdk14:jar:1.3.1 has no file. [ERROR] Artifact: org.springframework:spring-beans:jar:2.5.5 has no file. [ERROR] Artifact: org.springframework:spring-context:jar:2.5.5 has no file. [ERROR] Artifact: org.springframework:spring-core:jar:2.5.5 has no file. [ERROR] Artifact: org.springframework:spring-web:jar:2.5.5 has no file. [ERROR] Artifact: wsdl4j:wsdl4j:jar:1.6.2 has no file. [ERROR] Artifact: xalan:xalan:jar:2.6.0 has no file. [ERROR] Artifact: xerces:xercesImpl:jar:2.6.2 has no file. [ERROR] Artifact: xerces:xmlParserAPIs:jar:2.6.2 has no file. [ERROR] Artifact: xml-apis:xml-apis:jar:1.3.02 has no file. [ERROR] Artifact: xml-resolver:xml-resolver:jar:1.2 has no file. [ERROR] Artifact: xom:xom:jar:1.0 has no file. [INFO] Generating "Project Team" report. [INFO] Generating "Project License" report. [INFO] Generating "Project Plugins" report. [INFO] Generating "Maven Surefire Report" report. [INFO] Generating "FindBugs Report" report. [INFO] Using source root: [INFO] C:\edys_workspace\edystok\target\classes [INFO] Using test source root: [INFO] C:\edys_workspace\edystok\target\test-classes [INFO] No effort provided, using default effort. [INFO] Adding Source Directory: C:\edys_workspace\edystok\src\main\java [INFO] No threshold provided, using default threshold. [INFO] Using FindBugs Version: 1.3.7 [INFO] No threshold provided, using default threshold. [INFO] No threshold provided, using default threshold. [INFO] Debugging is Off [INFO] No bug include filter. [INFO] No bug exclude filter. there are no other error, and build is successfull -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus
[jira] Commented: (MRRESOURCES-33) Have to specifiy the version number twice in a pom
[
http://jira.codehaus.org/browse/MRRESOURCES-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=171542#action_171542
]
Brett Porter commented on MRRESOURCES-33:
-
in this case, please consider a different property that you just need to set
once (see ${mavenVersion} in the Maven POM).
The release plugin (and to some extent the reactor) is not designed to cross
version boundaries in this way.
> Have to specifiy the version number twice in a pom
> --
>
> Key: MRRESOURCES-33
> URL: http://jira.codehaus.org/browse/MRRESOURCES-33
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: Improvement
>Affects Versions: 1.0-beta-2
> Environment: mvn 2.0.5
>Reporter: EJ Ciramella
>
> Currently, you have to specify the version number twice in a pom if you need
> to unpack a dependency.
>
> groupId:artifactId:version
>
> It'd be nice if you could just rely on the dependency tags for this instead.
--
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: (MRRESOURCES-33) Have to specifiy the version number twice in a pom
[
http://jira.codehaus.org/browse/MRRESOURCES-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=171533#action_171533
]
jieryn commented on MRRESOURCES-33:
---
My remote resources are outside the standard build, their unbundling is,
however, inside the main enterprise build (and is required to be, to be useful
at the enterprise level [20+ projects, 200+ modules)!
I'd really love to use ${project.version} however this variable does not get
interpolated the way I want it to when the pom is inherited. Instead of using
the ${project.version} for the master enterprise pom, where I am exploiting the
resource inside a element, it is resolved at the lowest level. Thus,
the ${project.version} is resolved as the child's version which is not
necessarily the same as the one for the resource.
Please reconsider/reopen this. Thanks!
> Have to specifiy the version number twice in a pom
> --
>
> Key: MRRESOURCES-33
> URL: http://jira.codehaus.org/browse/MRRESOURCES-33
> Project: Maven 2.x Remote Resources Plugin
> Issue Type: Improvement
>Affects Versions: 1.0-beta-2
> Environment: mvn 2.0.5
>Reporter: EJ Ciramella
>
> Currently, you have to specify the version number twice in a pom if you need
> to unpack a dependency.
>
> groupId:artifactId:version
>
> It'd be nice if you could just rely on the dependency tags for this instead.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SCM-453) changelog command doesn't support branches yet
changelog command doesn't support branches yet -- Key: SCM-453 URL: http://jira.codehaus.org/browse/SCM-453 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.2 Reporter: Mark Struberg GitChangeLogCommand doesn't support branches yet. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4117) PluginNotFoundException: Plugin could not be found in internal repository
[ http://jira.codehaus.org/browse/MNG-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=171527#action_171527 ] Jochen Hebbrecht commented on MNG-4117: --- I get it, you need 2 tags: AND > PluginNotFoundException: Plugin could not be found in internal repository > - > > Key: MNG-4117 > URL: http://jira.codehaus.org/browse/MNG-4117 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.1.0 > Environment: windows xp sp3 >Reporter: Jochen Hebbrecht > Attachments: error.log > > > Hi, > I'm having a strange problem with a maven-plugin. I'm not sure this is a bug, > it could be an incorrect configuration at my side too. > We use Archiva as an internal repository and in that repository, we stored a > custom maven-plugin (it's a fork on the maven-jdev-plugin, but it can only be > used in our company, so we're not reflecting it to the open source > community). But when we want to retreive the maven-plugin, we get the > following error (check the attachment: error.log). > You can actually see him retreiving the POM file from Archiva, and it tells > me: "Artifact resolved". But then I tries to download the JAR file from > repo1.maven.org, which isn't there of course and it never checks our internal > repository again :-(. > Any idea's what is going wrong here? Why does MVN download the POM from > Archiva, but not the JAR? > Regards, > Jochen -- 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-4117) PluginNotFoundException: Plugin could not be found in internal repository
[ http://jira.codehaus.org/browse/MNG-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jochen Hebbrecht closed MNG-4117. - Resolution: Fixed > PluginNotFoundException: Plugin could not be found in internal repository > - > > Key: MNG-4117 > URL: http://jira.codehaus.org/browse/MNG-4117 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.1.0 > Environment: windows xp sp3 >Reporter: Jochen Hebbrecht > Attachments: error.log > > > Hi, > I'm having a strange problem with a maven-plugin. I'm not sure this is a bug, > it could be an incorrect configuration at my side too. > We use Archiva as an internal repository and in that repository, we stored a > custom maven-plugin (it's a fork on the maven-jdev-plugin, but it can only be > used in our company, so we're not reflecting it to the open source > community). But when we want to retreive the maven-plugin, we get the > following error (check the attachment: error.log). > You can actually see him retreiving the POM file from Archiva, and it tells > me: "Artifact resolved". But then I tries to download the JAR file from > repo1.maven.org, which isn't there of course and it never checks our internal > repository again :-(. > Any idea's what is going wrong here? Why does MVN download the POM from > Archiva, but not the JAR? > Regards, > Jochen -- 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-4117) PluginNotFoundException: Plugin could not be found in internal repository
[ http://jira.codehaus.org/browse/MNG-4117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=171524#action_171524 ] Jochen Hebbrecht commented on MNG-4117: --- It wasn't a bug :-). mkleint helped me out on IRC. I forgot to configure the pluginRepository: MYCOMPANY-maven-repo-internal MYCOMPANY's Maven Repository http://mavenrepo.MYCOMPANY.be:8080/archiva/repository/internal However, I don't understand why I need to configure it, as it was already in my settings.xml? > PluginNotFoundException: Plugin could not be found in internal repository > - > > Key: MNG-4117 > URL: http://jira.codehaus.org/browse/MNG-4117 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.1.0 > Environment: windows xp sp3 >Reporter: Jochen Hebbrecht > Attachments: error.log > > > Hi, > I'm having a strange problem with a maven-plugin. I'm not sure this is a bug, > it could be an incorrect configuration at my side too. > We use Archiva as an internal repository and in that repository, we stored a > custom maven-plugin (it's a fork on the maven-jdev-plugin, but it can only be > used in our company, so we're not reflecting it to the open source > community). But when we want to retreive the maven-plugin, we get the > following error (check the attachment: error.log). > You can actually see him retreiving the POM file from Archiva, and it tells > me: "Artifact resolved". But then I tries to download the JAR file from > repo1.maven.org, which isn't there of course and it never checks our internal > repository again :-(. > Any idea's what is going wrong here? Why does MVN download the POM from > Archiva, but not the JAR? > Regards, > Jochen -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MPIR-150) the dependency report ignores mirrors
[
http://jira.codehaus.org/browse/MPIR-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=171522#action_171522
]
Julien HENRY commented on MPIR-150:
---
I have the same problem.
I have a corporate archiva mirror for central:
{code}
central
central
Central Mirror
http://pic-java-nce.sud.mycompany.fr:8090/archiva/repository/central
{code}
And also 2 additional repos declared in my pom.xml:
{code}
mycompany.corporate.release
mycompany Corporate Release Repository
http://pic-java-nce.sud.mycompany.fr:8090/archiva/repository/mycompany.corporate.release
true
false
mycompany.local.release
mycompany Local Release Repository
http://pic-java-nce.sud.mycompany.fr:8090/archiva/repository/release
true
false
{code}
Running:
{code}
mvn
org.apache.maven.plugins:maven-project-info-reports-plugin:2.1.1:dependencies -X
{code}
Takes 3 minutes 37 seconds with lots of:
{code}
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
http://repo1.maven.org/maven/ - Session: Opened
http://repo1.maven.org/maven/ - Session: Disconnecting
http://repo1.maven.org/maven/ - Session: Disconnected
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
http://people.apache.org/repo/m2-incubating-repository/ - Session: Opened
http://people.apache.org/repo/m2-incubating-repository/ - Session: Disconnecting
http://people.apache.org/repo/m2-incubating-repository/ - Session: Disconnected
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
http://repository.codehaus.org - Session: Opened
http://repository.codehaus.org - Session: Disconnecting
http://repository.codehaus.org - Session: Disconnected
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
http://repo1.maven.org/eclipse - Session: Opened
http://repo1.maven.org/eclipse - Session: Disconnecting
http://repo1.maven.org/eclipse - Session: Disconnected
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
http://repo1.maven.org/maven2 - Session: Opened
http://repo1.maven.org/maven2 - Session: Disconnecting
http://repo1.maven.org/maven2 - Session: Disconnected
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
http://ws.zones.apache.org/repository2 - Session: Opened
http://ws.zones.apache.org/repository2 - Session: Disconnecting
http://ws.zones.apache.org/repository2 - Session: Disconnected
{code}
Very blocking for me because some projects that use a lot of additional
repositories have their build taking more than 1 hour instead of less than 2
minutes after disabling dependency report.
The only workaround for my IC platform is to lock down plugin version to 2.0.1.
If you need more debug informations, fell free to ask.
> the dependency report ignores mirrors
> -
>
> Key: MPIR-150
> URL: http://jira.codehaus.org/browse/MPIR-150
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.1.1
>Reporter: Brian Fox
>
> The dependencies report takes forever and running debug i can see it's
> hitting the same repos over and over and bypassing my repository manager.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-337) site not reading properly with properties
[ http://jira.codehaus.org/browse/MSITE-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=171520#action_171520 ] Erlend Hamnaberg commented on MSITE-337: I can verify that this still occurs using 2.0 > site not reading properly with properties > - > > Key: MSITE-337 > URL: http://jira.codehaus.org/browse/MSITE-337 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Environment: Ubuntu 8.0.4, Windows XP, Sun JDK 1.6, Sun JDK 1.5 >Reporter: Leon >Priority: Critical > Attachments: project.tgz > > > The site goal does not read the correct properties from a parent pom if the > properties are used to set the version of the artifact. > For the attached project "mvn install" works but "mvn site" fails. -- 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-2419) eu.cedarsoft is outdated
eu.cedarsoft is outdated Key: MAVENUPLOAD-2419 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2419 Project: Maven Upload Requests Issue Type: Wish Reporter: Johannes Schneider It is no longer necessary to synchronize "eu.cedarsoft" since new bundles will only be released using "com.cedarsoft". The Bundle URL is outdated. Original issue: http://jira.codehaus.org/browse/MAVENUPLOAD-1705 -- 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-2418) Keys changed for com.cedarsoft (and eu.cedarsoft)
Keys changed for com.cedarsoft (and eu.cedarsoft) - Key: MAVENUPLOAD-2418 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2418 Project: Maven Upload Requests Issue Type: Task Reporter: Johannes Schneider I migrated my server (to nexus) and changed the keys. Therefore the synchronization failed for group com.cedarsoft and eu.cedarsoft. It is no longer necessary to synchronize "eu.cedarsoft" since new bundles will only be released using "com.cedarsoft". I will create another issue. The bundle URL has 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: (MERCURY-107) Plugins should be sorted by artifactId in maven-metadata.xml
Plugins should be sorted by artifactId in maven-metadata.xml Key: MERCURY-107 URL: http://jira.codehaus.org/browse/MERCURY-107 Project: Mercury Issue Type: Bug Affects Versions: 1.0-alpha-5 Reporter: Juven Xu Assignee: Oleg Gusakov Priority: Minor Attachments: sort-plugin-md.patch while using AddPluginOperation, the elements in maven-metadata.xml should be sorted after this operation -- 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
