[jira] Commented: (MJAVADOC-116) Impossible to aggregate javadoc if snapshot never built
[
http://jira.codehaus.org/browse/MJAVADOC-116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126274
]
Antonio Petrelli commented on MJAVADOC-116:
---
Wendy, can you wait one day? I tried some days ago with Tiles and it didn't
work.
> Impossible to aggregate javadoc if snapshot never built
> ---
>
> Key: MJAVADOC-116
> URL: http://jira.codehaus.org/browse/MJAVADOC-116
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Damien Lecan
>Assignee: Vincent Siveton
> Fix For: 2.4
>
> Attachments: javadoc-plugin-test-case.zip, log.txt
>
>
> In a multi-module projet, I build an aggregated Javadoc for the site.
> The project is built with "mvn clean deploy site-deploy"
> When I add a new project, the next build always fails because the javadoc
> plugin can't find at least one snapshot for the new added module
> In the following example, I added a new module tele.persistance:pers-commons,
> which have never been built before.
> Maven tries to download it but it can't find it (never build before).
> {noformat} [INFO] [site:site]
> [WARNING] Unable to load parent project from repository: Could not find the
> model file '/continuum-folders/working-directory/116/../pom.xml'.
> [INFO] Skipped "About" report, file "index.html" already exists for the
> English version.
> [ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0
> [ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0
> [INFO] Generate "JavaDocs" report.
> [INFO] snapshot tele:commons:1.2.0-alpha-1-SNAPSHOT: checking for updates
> from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-data:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-api:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-commons:1.2.0-alpha-1-SNAPSHOT:
> checking for updates from mirror.snapshots
> Downloading:
> http://proxy/maven2-snapshots/repository/tele/persistance/pers-commons/1.2.0-alpha-1-SNAPSHOT/pers-commons-1.2.0-alpha-1-SNAPSHOT.jar
> [WARNING] Unable to get resource
> 'tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT' from repository
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=tele.persistance
> -DartifactId=pers-commons \
> -Dversion=1.2.0-alpha-1-SNAPSHOT -Dpackaging=jar
> -Dfile=/path/to/file
> Path to dependency:
> 1) tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> 2) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> {noformat}
> If I make an intermediate "install", everything works fine
--
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-3438) IIncompatibleClassChangeError
[
http://jira.codehaus.org/browse/MNG-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126275
]
Vincent Massol commented on MNG-3438:
-
re the scm it's
https://svn.xwiki.org/svnroot/xwiki/xwiki-platform/xwiki-applications/trunk/selenium
I'm now checking if it works in 2.0.8. It works in 2.1-SNAPSHOT though.
> IIncompatibleClassChangeError
> -
>
> Key: MNG-3438
> URL: http://jira.codehaus.org/browse/MNG-3438
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.9
>Reporter: Vincent Massol
> Fix For: 2.0.9
>
>
> This is happening with 2.0.9-SNAPSHOT built on 5th of March 2008:
> {noformat}
> [INFO]
>
> [INFO] Building XWiki Platform - Applications - Selenium
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> /Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target
> [INFO] [remote-resources:process {execution: xwiki-license-resources}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [WARNING] Attempting to build MavenProject instance for Artifact
> (com.xpn.xwiki.platform.tools:xwiki-xar-plugin:1.10-20080305.115158-11) of
> type: maven-plugin; constructing POM artifact instead.
> [INFO] [xwiki-xar:xar]
> [INFO] Generating package.xml descriptor at
> [/Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target/classes/package.xml]
> [FATAL ERROR] com.xpn.xwiki.tool.xar.XarMojo#execute() caused a linkage error
> (java.lang.IncompatibleClassChangeError) and may be out-of-date. Check the
> realms:
> [FATAL ERROR] Plugin realm =
> app0.child-container[com.xpn.xwiki.platform.tools:xwiki-xar-plugin]
> urls[0] =
> file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-plugin/1.10-SNAPSHOT/xwiki-xar-plugin-1.10-SNAPSHOT.jar
> urls[1] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> urls[2] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-9/plexus-archiver-1.0-alpha-9.jar
> urls[3] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-component-api/1.0-alpha-15/plexus-component-api-1.0-alpha-15.jar
> urls[4] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-classworlds/1.2-alpha-6/plexus-classworlds-1.2-alpha-6.jar
> urls[5] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-io/1.0-alpha-1/plexus-io-1.0-alpha-1.jar
> urls[6] = file:/Users/vmassol/.m2/repository/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar
> urls[7] =
> file:/Users/vmassol/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> [FATAL ERROR] Container realm = plexus.core
> urls[0] =
> file:/Applications/apache-maven-2.0.9-SNAPSHOT/lib/maven-2.0.9-SNAPSHOT-uber.jar
> urls[1] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> urls[2] =
> file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-handlers/1.9-SNAPSHOT/xwiki-xar-handlers-1.9-SNAPSHOT.jar
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.IncompatibleClassChangeError
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:318)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:242)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:673)
> at com.xpn.xwiki.tool.xar.XarMojo.performArchive(XarMojo.java:129)
> at com.xpn.xwiki.tool.xar.XarMojo.execute(XarMojo.java:90)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:507)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execu
[jira] Commented: (MNG-3438) IIncompatibleClassChangeError
[
http://jira.codehaus.org/browse/MNG-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126276
]
Vincent Massol commented on MNG-3438:
-
ok it fails with 2.0.8 too and I've confirmed again that it works with
2.1-SNAPSHOT.
> IIncompatibleClassChangeError
> -
>
> Key: MNG-3438
> URL: http://jira.codehaus.org/browse/MNG-3438
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.0.9
>Reporter: Vincent Massol
> Fix For: 2.0.9
>
>
> This is happening with 2.0.9-SNAPSHOT built on 5th of March 2008:
> {noformat}
> [INFO]
>
> [INFO] Building XWiki Platform - Applications - Selenium
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> /Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target
> [INFO] [remote-resources:process {execution: xwiki-license-resources}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [WARNING] Attempting to build MavenProject instance for Artifact
> (com.xpn.xwiki.platform.tools:xwiki-xar-plugin:1.10-20080305.115158-11) of
> type: maven-plugin; constructing POM artifact instead.
> [INFO] [xwiki-xar:xar]
> [INFO] Generating package.xml descriptor at
> [/Users/vmassol/dev/xwiki/trunks/xwiki-platform-applications/selenium/target/classes/package.xml]
> [FATAL ERROR] com.xpn.xwiki.tool.xar.XarMojo#execute() caused a linkage error
> (java.lang.IncompatibleClassChangeError) and may be out-of-date. Check the
> realms:
> [FATAL ERROR] Plugin realm =
> app0.child-container[com.xpn.xwiki.platform.tools:xwiki-xar-plugin]
> urls[0] =
> file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-plugin/1.10-SNAPSHOT/xwiki-xar-plugin-1.10-SNAPSHOT.jar
> urls[1] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> urls[2] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-archiver/1.0-alpha-9/plexus-archiver-1.0-alpha-9.jar
> urls[3] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-component-api/1.0-alpha-15/plexus-component-api-1.0-alpha-15.jar
> urls[4] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-classworlds/1.2-alpha-6/plexus-classworlds-1.2-alpha-6.jar
> urls[5] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-io/1.0-alpha-1/plexus-io-1.0-alpha-1.jar
> urls[6] = file:/Users/vmassol/.m2/repository/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar
> urls[7] =
> file:/Users/vmassol/.m2/repository/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
> [FATAL ERROR] Container realm = plexus.core
> urls[0] =
> file:/Applications/apache-maven-2.0.9-SNAPSHOT/lib/maven-2.0.9-SNAPSHOT-uber.jar
> urls[1] =
> file:/Users/vmassol/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
> urls[2] =
> file:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/tools/xwiki-xar-handlers/1.9-SNAPSHOT/xwiki-xar-handlers-1.9-SNAPSHOT.jar
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> [INFO]
>
> [INFO] Trace
> java.lang.IncompatibleClassChangeError
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:318)
> at
> org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:242)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:673)
> at com.xpn.xwiki.tool.xar.XarMojo.performArchive(XarMojo.java:129)
> at com.xpn.xwiki.tool.xar.XarMojo.execute(XarMojo.java:90)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:507)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute
[jira] Commented: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126280 ] gotama commented on MIDEA-102: -- Actually, I just tested Roman's code above - adding it to the latest 2.2-SNAPSHOT and the paths are correct for an idea project with the parent and modules at the same level. The modules paths are correctly relative using "../". Someone should throw that code in there, close this out and release 2.2. WFM. > CLONE -still broken - Module filepath is generated incorrectly > -- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- 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: (MJAVADOC-116) Impossible to aggregate javadoc if snapshot never built
[
http://jira.codehaus.org/browse/MJAVADOC-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damien Lecan updated MJAVADOC-116:
--
Attachment: javadoc-plugin-test-case with classifier use.zip
Here is a test case which reproduces problem with classifiers and aggregated
javadoc.
It is based on previous patch with following updates :
- javadoc version 2.4-SNAPSHOT
- build module 1 test jar ("test-jar" classifier)
- module 2 depends on module 1 jar AND test-jar. They have to be declared
together.
Try "mvn -DreleaseProfile=true clean deploy site-deploy", it will fail (maven
2.0.8)
Things to notice :
- with aggregate = false, it works
- in module 2, with exactly one of the 2 dependencies (jar OR test-jar), it
works (??)
Is it enough to reproduce bug ?
> Impossible to aggregate javadoc if snapshot never built
> ---
>
> Key: MJAVADOC-116
> URL: http://jira.codehaus.org/browse/MJAVADOC-116
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Damien Lecan
>Assignee: Vincent Siveton
> Fix For: 2.4
>
> Attachments: javadoc-plugin-test-case with classifier use.zip,
> javadoc-plugin-test-case.zip, log.txt
>
>
> In a multi-module projet, I build an aggregated Javadoc for the site.
> The project is built with "mvn clean deploy site-deploy"
> When I add a new project, the next build always fails because the javadoc
> plugin can't find at least one snapshot for the new added module
> In the following example, I added a new module tele.persistance:pers-commons,
> which have never been built before.
> Maven tries to download it but it can't find it (never build before).
> {noformat} [INFO] [site:site]
> [WARNING] Unable to load parent project from repository: Could not find the
> model file '/continuum-folders/working-directory/116/../pom.xml'.
> [INFO] Skipped "About" report, file "index.html" already exists for the
> English version.
> [ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0
> [ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0
> [INFO] Generate "JavaDocs" report.
> [INFO] snapshot tele:commons:1.2.0-alpha-1-SNAPSHOT: checking for updates
> from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-data:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-api:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-commons:1.2.0-alpha-1-SNAPSHOT:
> checking for updates from mirror.snapshots
> Downloading:
> http://proxy/maven2-snapshots/repository/tele/persistance/pers-commons/1.2.0-alpha-1-SNAPSHOT/pers-commons-1.2.0-alpha-1-SNAPSHOT.jar
> [WARNING] Unable to get resource
> 'tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT' from repository
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=tele.persistance
> -DartifactId=pers-commons \
> -Dversion=1.2.0-alpha-1-SNAPSHOT -Dpackaging=jar
> -Dfile=/path/to/file
> Path to dependency:
> 1) tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> 2) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> {noformat}
> If I make an intermediate "install", everything works fine
--
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: (MJAVADOC-116) Impossible to aggregate javadoc if snapshot never built
[
http://jira.codehaus.org/browse/MJAVADOC-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damien Lecan updated MJAVADOC-116:
--
Attachment: clean javadoc-plugin-test-case with classifier use.zip
Same test cas as before, but without any target folders.
> Impossible to aggregate javadoc if snapshot never built
> ---
>
> Key: MJAVADOC-116
> URL: http://jira.codehaus.org/browse/MJAVADOC-116
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Damien Lecan
>Assignee: Vincent Siveton
> Fix For: 2.4
>
> Attachments: clean javadoc-plugin-test-case with classifier use.zip,
> javadoc-plugin-test-case with classifier use.zip,
> javadoc-plugin-test-case.zip, log.txt
>
>
> In a multi-module projet, I build an aggregated Javadoc for the site.
> The project is built with "mvn clean deploy site-deploy"
> When I add a new project, the next build always fails because the javadoc
> plugin can't find at least one snapshot for the new added module
> In the following example, I added a new module tele.persistance:pers-commons,
> which have never been built before.
> Maven tries to download it but it can't find it (never build before).
> {noformat} [INFO] [site:site]
> [WARNING] Unable to load parent project from repository: Could not find the
> model file '/continuum-folders/working-directory/116/../pom.xml'.
> [INFO] Skipped "About" report, file "index.html" already exists for the
> English version.
> [ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0
> [ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0
> [INFO] Generate "JavaDocs" report.
> [INFO] snapshot tele:commons:1.2.0-alpha-1-SNAPSHOT: checking for updates
> from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-data:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-api:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-commons:1.2.0-alpha-1-SNAPSHOT:
> checking for updates from mirror.snapshots
> Downloading:
> http://proxy/maven2-snapshots/repository/tele/persistance/pers-commons/1.2.0-alpha-1-SNAPSHOT/pers-commons-1.2.0-alpha-1-SNAPSHOT.jar
> [WARNING] Unable to get resource
> 'tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT' from repository
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=tele.persistance
> -DartifactId=pers-commons \
> -Dversion=1.2.0-alpha-1-SNAPSHOT -Dpackaging=jar
> -Dfile=/path/to/file
> Path to dependency:
> 1) tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> 2) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> {noformat}
> If I make an intermediate "install", everything works fine
--
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-2979) Cross module dependencies for multi-module site
[ http://jira.codehaus.org/browse/MNG-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126284 ] Stepan Roh commented on MNG-2979: - I checked it with Maven 2.0.8 and it still does not work: "mvn site" fails, but "mvn compile site" runs OK. > Cross module dependencies for multi-module site > --- > > Key: MNG-2979 > URL: http://jira.codehaus.org/browse/MNG-2979 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0.5 > Environment: Linux 2.6.18-gentoo-r6 #2 SMP PREEMPT Wed Feb 28 > 10:25:50 CET 2007 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux >Reporter: Wally Wallou >Priority: Minor > Fix For: 2.0.x > > Attachments: gwttk-m2.zip, package.txt, site.txt > > > Considering a multi-module project A which declares two sub-projects > (modules) B and C. Having module C indicating in its POM a dependency against > module B. Compilation and packaging work great without having to install > module B in maven local repository, it locate module B for module C using > declared aggregation at top level project A. > But for site goals it does not work, that is to say when maven try to > generate site for module C it tells that module B artifact cannot be found. > So we have to install module B to be able to generate module C site, whereas > it is not necessary for compile or package goals. > I think it would be great if site goals behaves like compile and package with > aggregation. It would be more coherent, and avoid to have to run install just > for site goals. -- 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: (ARCHETYPE-145) Allow archetype:crawl to crawl only a specific part of the local repository
[
http://jira.codehaus.org/browse/ARCHETYPE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126285
]
Gert Vanthienen commented on ARCHETYPE-145:
---
Looks like you can already do this now by simple specifying a subdirectory of
the local repository as the {{repository}} parameter value. Something like:
{code}
org.apache.maven.plugins
maven-archetype-plugin
..
${settings.localRepository}/org/apache/servicemix/tooling
${project.build.directory}/archetype-catalog.xml
{code}
> Allow archetype:crawl to crawl only a specific part of the local repository
> ---
>
> Key: ARCHETYPE-145
> URL: http://jira.codehaus.org/browse/ARCHETYPE-145
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 2.0-alpha-2
>Reporter: Gert Vanthienen
>Priority: Minor
>
> The use case for this feature request would be to create a project-specific
> archetype catalog.
> Cfr.
> http://www.nabble.com/Tool-for-generating-an-archetype-catalog-to15799921s177.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: (MNG-428) Japanese message resource
[ http://jira.codehaus.org/browse/MNG-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126291 ] Ryuzo Yamamoto commented on MNG-428: I have reviewed this patch and I modify 2 point. - Added license header. - Modified Japanese period (last line) to dot. Please see a attachment "message_ja.properites.reviewed.patch". > Japanese message resource > - > > Key: MNG-428 > URL: http://jira.codehaus.org/browse/MNG-428 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0-beta-1 > Environment: N/A >Reporter: Takayoshi Kimura >Assignee: Brian Fox >Priority: Minor > Fix For: 2.0.9 > > Attachments: message_ja.properites.patch, > message_ja.properites.reviewed.patch > > > Now, we got message_ja.properties. -- 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-3414) Plexus bundled in Maven 2.1-SNAPSHOT built on 19 Feb 2008 introduced a regression in path handling
[
http://jira.codehaus.org/browse/MNG-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126300
]
Vincent Massol commented on MNG-3414:
-
John Casey said:
{quote}
I've been looking into that problem with the gwt plugin a bit more, and I found
that the code is actually trying to compensate for an un-quoted java path
itself.
Not sure why it'd do that, but when you add to that the fact that plexus-utils
now tries to quote the executable path and working directory, you get the mess
we're seeing.
In *nix environments, the single-quote means a literal string. Therefore, if
something has single-quotes around it and contains the " character, it is
presumed that that character is actually present in that path.
I'm not sure why he chose to wrap only the ${java.home}/bin directory in double
quotes, but it's not compatible with plexus-utils from recent releases (I'd say
> 1.4.5 or so, though I haven't looked for an exact revision).
I lost the link to the issue you filed with this problem, otherwise I'd report
this little bit of progress there.
{quote}
> Plexus bundled in Maven 2.1-SNAPSHOT built on 19 Feb 2008 introduced a
> regression in path handling
> --
>
> Key: MNG-3414
> URL: http://jira.codehaus.org/browse/MNG-3414
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.1-alpha-1
>Reporter: Vincent Massol
>
> Here's the error I get. This is working fine in an old 2.1 SNAPSHOT:
> {noformat}
> [INFO]
>
> [INFO] Building XWiki Products - Watch - GWT
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> /Users/vmassol/dev/xwiki/trunks/xwiki-product-watch/gwt/target
> [INFO] [dependency:unpack]
> [INFO] Configured Artifact: com.google.gwt:gwt-mac:1.3.3:zip
> [INFO] Unpacking
> /Users/vmassol/.m2/repository/com/google/gwt/gwt-mac/1.3.3/gwt-mac-1.3.3.zipto
> /tmp/xwiki/gwt
> with Includes null and excludes:null
> [INFO] [remote-resources:process]
> [INFO] [gwt:compile]
> Using classpath:
> /Users/vmassol/dev/xwiki/trunks/xwiki-product-watch/gwt/target/classes:/Users/vmassol/.m2/repository/com/google/gwt/gwt-servlet/1.3.3/gwt-servlet-1.3.3.jar:/Users/vmassol/.m2/repository/com/google/gwt/gwt-user/1.3.3/gwt-user-1.3.3.jar:/Users/vmassol/.m2/repository/gwt-widgets/gwt-widgets/0.1.3/gwt-widgets-0.1.3.jar:/Users/vmassol/.m2/repository/gwttk/gwttk/0.2.2/gwttk-0.2.2.jar:/Users/vmassol/.m2/repository/junit/junit/3.8.2/junit-3.8.2.jar:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/xwiki-web-gwt/1.3-SNAPSHOT/xwiki-web-gwt-1.3-SNAPSHOT.jar:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/xwiki-web-gwt/1.3-SNAPSHOT/xwiki-web-gwt-1.3-SNAPSHOT-sources.jar:/tmp/xwiki/gwt/gwt-mac-1.3.3/gwt-dev-linux.jar:/tmp/xwiki/gwt/gwt-mac-1.3.3/gwt-dev-mac.jar:/tmp/xwiki/gwt/gwt-mac-1.3.3/gwt-dev-windows.jar:/tmp/xwiki/gwt/gwt-mac-1.3.3/gwt-user.jar:/Users/vmassol/dev/xwiki/trunks/xwiki-product-watch/gwt/src/main/resources:/Users/vmassol/dev/xwiki/trunks/xwiki-product-watch/gwt/target/maven-shared-archive-resources:/Users/vmassol/dev/xwiki/trunks/xwiki-product-watch/gwt/src/main/java
> [INFO] Running GWTCompile with command:
> '"/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin"/java'
> -Xmx1024m -classpath
> /Users/vmassol/dev/xwiki/trunks/xwiki-product-watch/gwt/target/classes:/Users/vmassol/.m2/repository/com/google/gwt/gwt-servlet/1.3.3/gwt-servlet-1.3.3.jar:/Users/vmassol/.m2/repository/com/google/gwt/gwt-user/1.3.3/gwt-user-1.3.3.jar:/Users/vmassol/.m2/repository/gwt-widgets/gwt-widgets/0.1.3/gwt-widgets-0.1.3.jar:/Users/vmassol/.m2/repository/gwttk/gwttk/0.2.2/gwttk-0.2.2.jar:/Users/vmassol/.m2/repository/junit/junit/3.8.2/junit-3.8.2.jar:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/xwiki-web-gwt/1.3-SNAPSHOT/xwiki-web-gwt-1.3-SNAPSHOT.jar:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/xwiki-web-gwt/1.3-SNAPSHOT/xwiki-web-gwt-1.3-SNAPSHOT-sources.jar:/tmp/xwiki/gwt/gwt-mac-1.3.3/gwt-dev-linux.jar:/tmp/xwiki/gwt/gwt-mac-1.3.3/gwt-dev-mac.jar:/tmp/xwiki/gwt/gwt-mac-1.3.3/gwt-dev-windows.jar:/tmp/xwiki/gwt/gwt-mac-1.3.3/gwt-user.jar:/Users/vmassol/dev/xwiki/trunks/xwiki-product-watch/gwt/src/main/resources:/Users/vmassol/dev/xwiki/trunks/xwiki-product-watch/gwt/target/maven-shared-archive-resources:/Users/vmassol/dev/xwiki/trunks/xwiki-product-watch/gwt/src/main/java
> com.google.gwt.dev.GWTCompiler -logLevel WARN -style OBF -out
> /Users/vmassol/dev/xwiki/trunks/xwiki-product-watch/gwt/target/xwiki-watch-gwt-1.0-SNAPSHOT
> com.xpn.xwiki.watch.Watch
> org.codehaus.plexus.util.cli.CommandLineException: Error
[jira] Updated: (MNG-428) Japanese message resource
[ http://jira.codehaus.org/browse/MNG-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryuzo Yamamoto updated MNG-428: --- Attachment: message_ja.properites.reviewed.patch > Japanese message resource > - > > Key: MNG-428 > URL: http://jira.codehaus.org/browse/MNG-428 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0-beta-1 > Environment: N/A >Reporter: Takayoshi Kimura >Assignee: Brian Fox >Priority: Minor > Fix For: 2.0.9 > > Attachments: message_ja.properites.patch, > message_ja.properites.reviewed.patch > > > Now, we got message_ja.properties. -- 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-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126283 ] Piotr Tabor commented on MNG-1323: -- I wasn't able to repeat Jason's problems. I asked the dev group for help with repeating the issue and got no answer. Is any commiter able to promise that he will help me with checking/commiting this patch if I refactor it to work with current revisions (2.1 and 2.0.x) ? > Plugin extensions (dependencies) not resolved in reactor build > -- > > Key: MNG-1323 > URL: http://jira.codehaus.org/browse/MNG-1323 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Kenney Westerhof > Fix For: 2.0.10 > > Attachments: MNG-1323-components-2.0.x.diff, > MNG-1323-core-integration-testing-2.diff, > MNG-1323-core-integration-testing.diff, > MNG-1323-core-integration-tests-3.diff, MNG-1323-core-integration-tests.diff, > MNG1323-maven-core-2.1.diff > > > I've added a dependency on an Ant Task in > project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ > and run that anttask using the antrun plugin. > When run from the project dir itself it runs fine. > When running from the root of the project tree (reactor build, project one > level below root), > antrun bails out because the taskdef can't be found (not on classpath). > It looks like the dependency isn't resolved, or not added to the plugins' > classrealm. -- 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-3414) Plexus bundled in Maven 2.1-SNAPSHOT built on 19 Feb 2008 introduced a regression in path handling
[
http://jira.codehaus.org/browse/MNG-3414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent Massol closed MNG-3414.
---
Assignee: Vincent Massol
Resolution: Won't Fix
So I guess the solution if for the author of the GWT plugin to fix the
problem...
In the meantime I've found a workaround by specifying explicitely the
dependency on plexus-utils 1.4.2 (it doesn't work with 1.4.3 and above):
{noformat}
com.totsp.gwt
maven-googlewebtoolkit2-plugin
1.5.2
WARN
OBF
com.xpn.xwiki.watch/Watch.html
${java.io.tmpdir}/xwiki/gwt/${gwtArtifactId}-${gwtVersion}
com.xpn.xwiki.watch.Watch
-Xmx1024m
org.codehaus.plexus
plexus-utils
1.4.2
compile
{noformat}
Thanks for your help John.
> Plexus bundled in Maven 2.1-SNAPSHOT built on 19 Feb 2008 introduced a
> regression in path handling
> --
>
> Key: MNG-3414
> URL: http://jira.codehaus.org/browse/MNG-3414
> Project: Maven 2
> Issue Type: Bug
> Components: General
>Affects Versions: 2.1-alpha-1
>Reporter: Vincent Massol
>Assignee: Vincent Massol
>
> Here's the error I get. This is working fine in an old 2.1 SNAPSHOT:
> {noformat}
> [INFO]
>
> [INFO] Building XWiki Products - Watch - GWT
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> /Users/vmassol/dev/xwiki/trunks/xwiki-product-watch/gwt/target
> [INFO] [dependency:unpack]
> [INFO] Configured Artifact: com.google.gwt:gwt-mac:1.3.3:zip
> [INFO] Unpacking
> /Users/vmassol/.m2/repository/com/google/gwt/gwt-mac/1.3.3/gwt-mac-1.3.3.zipto
> /tmp/xwiki/gwt
> with Includes null and excludes:null
> [INFO] [remote-resources:process]
> [INFO] [gwt:compile]
> Using classpath:
> /Users/vmassol/dev/xwiki/trunks/xwiki-product-watch/gwt/target/classes:/Users/vmassol/.m2/repository/com/google/gwt/gwt-servlet/1.3.3/gwt-servlet-1.3.3.jar:/Users/vmassol/.m2/repository/com/google/gwt/gwt-user/1.3.3/gwt-user-1.3.3.jar:/Users/vmassol/.m2/repository/gwt-widgets/gwt-widgets/0.1.3/gwt-widgets-0.1.3.jar:/Users/vmassol/.m2/repository/gwttk/gwttk/0.2.2/gwttk-0.2.2.jar:/Users/vmassol/.m2/repository/junit/junit/3.8.2/junit-3.8.2.jar:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/xwiki-web-gwt/1.3-SNAPSHOT/xwiki-web-gwt-1.3-SNAPSHOT.jar:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/xwiki-web-gwt/1.3-SNAPSHOT/xwiki-web-gwt-1.3-SNAPSHOT-sources.jar:/tmp/xwiki/gwt/gwt-mac-1.3.3/gwt-dev-linux.jar:/tmp/xwiki/gwt/gwt-mac-1.3.3/gwt-dev-mac.jar:/tmp/xwiki/gwt/gwt-mac-1.3.3/gwt-dev-windows.jar:/tmp/xwiki/gwt/gwt-mac-1.3.3/gwt-user.jar:/Users/vmassol/dev/xwiki/trunks/xwiki-product-watch/gwt/src/main/resources:/Users/vmassol/dev/xwiki/trunks/xwiki-product-watch/gwt/target/maven-shared-archive-resources:/Users/vmassol/dev/xwiki/trunks/xwiki-product-watch/gwt/src/main/java
> [INFO] Running GWTCompile with command:
> '"/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin"/java'
> -Xmx1024m -classpath
> /Users/vmassol/dev/xwiki/trunks/xwiki-product-watch/gwt/target/classes:/Users/vmassol/.m2/repository/com/google/gwt/gwt-servlet/1.3.3/gwt-servlet-1.3.3.jar:/Users/vmassol/.m2/repository/com/google/gwt/gwt-user/1.3.3/gwt-user-1.3.3.jar:/Users/vmassol/.m2/repository/gwt-widgets/gwt-widgets/0.1.3/gwt-widgets-0.1.3.jar:/Users/vmassol/.m2/repository/gwttk/gwttk/0.2.2/gwttk-0.2.2.jar:/Users/vmassol/.m2/repository/junit/junit/3.8.2/junit-3.8.2.jar:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/xwiki-web-gwt/1.3-SNAPSHOT/xwiki-web-gwt-1.3-SNAPSHOT.jar:/Users/vmassol/.m2/repository/com/xpn/xwiki/platform/xwiki-web-gwt/1.3-SNAPSHOT/xwiki-web-gwt-1.3-SNAPSHOT-sources.jar:/tmp/xwiki/gwt/gwt-mac-1.3.3/gwt-dev-linux.jar:/tmp/xwiki/gwt/gwt-mac-1.3.3/gwt-dev-mac.jar:/tmp/xwiki/gwt/gwt-mac-1.3.3/gwt-dev-windows.jar:/tmp/xwiki/gwt/gwt-mac-1.3.3/gwt-user.jar:/Users/vmassol/dev/xwiki/trunks/xwiki-product-watch/gwt/src/main/resources:/Users/vmassol/dev/xwiki/trunks/xwiki-product-watch/gwt/target/maven-shared-archive-resources:/Users/vmassol/dev/xwiki/trunks/xwiki-product-watch/gwt/src/main/java
> com.google.gwt.dev.GWTCompiler -logLevel WARN -style OBF -out
> /Users/vmassol/dev/xwiki/trunks/xwiki-product-watch/gwt/target/xwiki-watch-gwt-1.0-SNAPSHOT
> com.xpn.xwiki.watch.Watch
> org.codehaus.plexus.util.cli.CommandLineException: Error while executing
> process.
> at
> org.codehaus
[jira] Commented: (MNG-2802) Concurrent-safe access to local Maven repository
[ http://jira.codehaus.org/browse/MNG-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126325 ] John Casey commented on MNG-2802: - To go any further than just ensuring the locking of resolver-status files (which are a sort of proto-metadata for the resolver to use that helps track unfound artifacts and adhere to an updateInterval for those), we'll need to modify the various Wagons, I think. Since these are file-oriented, they manage opening, writing to, and closing the files internally. One thing I might be able to do is try to manage a file lock on the main artifact file instead of the temp file that the wagon is using as its destination (which may not exist, so that could complicate things even further). Yet another approach might involve creating a lockfile, and managing a lock on that... I'll look into a couple of these strategies. I don't think it's optimal to bury the locking logic in the various wagons, as we're likely to run into concurrency problems again and again with each marginal wagon implementation. > Concurrent-safe access to local Maven repository > > > Key: MNG-2802 > URL: http://jira.codehaus.org/browse/MNG-2802 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Reporter: Stepan Roh >Assignee: John Casey > Fix For: 2.1 > > > It seems that access to local Maven repository is not concurrent-safe that is > multiple Mavens running in parallel may damage contents of local Maven > repository. It would be a nice improvement, because sharing of local > repository will lower the need for contacting any other repository. I know > that Maven proxy can be used, but that adds another layer which may > unnecessarily stress the machine it runs on. -- 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-3007) Resolving legacy dependency ignores transitive dependencies
[
http://jira.codehaus.org/browse/MNG-3007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dirk Olmes updated MNG-3007:
Attachment: pom.xml
I'm attaching a pom that can be used to demo the issue. Run it with an empty
repo, once without any profiles activated and once with the codehaus profile.
Output of dependency:tree when dependencies are resolved from central only:
{code}
[INFO] [dependency:tree]
[INFO] org.mule:MNG-3007:jar:1.0-SNAPSHOT
[INFO] \- org.codehaus.xfire:xfire-core:jar:1.2.6:compile
[INFO]+- javax.activation:activation:jar:1.1:compile
[INFO]+- javax.mail:mail:jar:1.4:compile
[INFO]+- wsdl4j:wsdl4j:jar:1.6.1:compile
[INFO]+- jaxen:jaxen:jar:1.1-beta-9:compile
[INFO]| +- xerces:xmlParserAPIs:jar:2.6.2:compile
[INFO]| \- xerces:xercesImpl:jar:2.6.2:compile
[INFO]+- stax:stax-api:jar:1.0.1:compile
[INFO]+- commons-codec:commons-codec:jar:1.3:compile
[INFO]+- org.apache.ws.commons:XmlSchema:jar:1.1:compile
[INFO]+- org.codehaus.woodstox:wstx-asl:jar:3.2.0:compile
[INFO]+- jdom:jdom:jar:1.0:compile
[INFO]+- commons-logging:commons-logging:jar:1.0.4:compile
[INFO]\- commons-httpclient:commons-httpclient:jar:3.0:compile
[INFO] \- junit:junit:jar:3.8.1:compile
{code}
Output of dependency:tree when dependencies are resolved from codehaus (legacy
layout) and from central:
{code}
[INFO] org.mule:MNG-3007:jar:1.0-SNAPSHOT
[INFO] \- org.codehaus.xfire:xfire-core:jar:1.2.6:compile
[INFO]+- javax.activation:activation:jar:1.1:compile
[INFO]+- javax.mail:mail:jar:1.4:compile
[INFO]+- wsdl4j:wsdl4j:jar:1.6.1:compile
[INFO]+- jaxen:jaxen:jar:1.1-beta-9:compile
[INFO]+- stax:stax-api:jar:1.0.1:compile
[INFO]+- commons-codec:commons-codec:jar:1.3:compile
[INFO]+- org.apache.ws.commons:XmlSchema:jar:1.1:compile
[INFO]+- org.codehaus.woodstox:wstx-asl:jar:3.2.0:compile
[INFO]+- jdom:jdom:jar:1.0:compile
[INFO]+- commons-logging:commons-logging:jar:1.0.4:compile
[INFO]\- commons-httpclient:commons-httpclient:jar:3.0:compile
[INFO] \- junit:junit:jar:3.8.1:compile
{code}
Note how jaxen has transitive dependencies in the first case and how it hasn't
in the second case. While both poms differ, they share the ones that appear as
transitive dependencies of jaxen in the first case above.
> Resolving legacy dependency ignores transitive dependencies
> ---
>
> Key: MNG-3007
> URL: http://jira.codehaus.org/browse/MNG-3007
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.0.6
>Reporter: Dirk Olmes
> Fix For: 2.0.x
>
> Attachments: pom.xml
>
>
> Trying to resolve a dependency from a repo with legacy layout
> (dist.codehaus.org) seems to ignore this dependency's transitive dependencies.
> I stumbled over this issue while building mule: the xfire module depends on
> jaxen which is available from dist.codehaus.org (legacy layout) and from
> central (m2 repo layout). For xfire we need to have dist.codehaus.org in the
> pom.
> When pulling jaxen from the legacy layout all transitive dependencies,
> although declared in the legacy pom, will not be included in this module's
> dependencies. If I happen to have jaxen already fetched from central into my
> local repo, the transitive dependencies will show up, causing the entire
> build to fail.
> IMHO the dependency resolution of m1 poms should consider that artifact's
> transitive dependencies as it is the case with m2 poms.
--
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-3379) Parallel resolution of artifacts
[ http://jira.codehaus.org/browse/MNG-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126329 ] John Casey commented on MNG-3379: - do we need to be concerned at all with file-locking in the repository with this? We have an issue open for concurrent writes into the local repo, MNG-2802, but I expect this to be more about concurrent Maven processes running on the same machine, rather than concurrent retrieval of artifacts within one process. This is mainly because the resolution process will probably not cause the type of file overlap that could cause problems, though in the case of metadata I can see how it might... > Parallel resolution of artifacts > > > Key: MNG-3379 > URL: http://jira.codehaus.org/browse/MNG-3379 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Don Brown >Assignee: Brett Porter > Attachments: parallel-resolution-2.diff, parallel-resolution-3.diff, > parallel-resolution.diff > > > Artifacts should be resolved in parallel, grouped by group id's to get around > the lack of synchronization in the local repository. The patch does the > following: > * Use a ThreadPoolExecutor to parallelize artifact resolution, but takes care > not to resolve multiple artifacts from the same group id simultaneously. > (requires Java 5) > * Makes the http wagon the default instead of the poor performing http-client > Disadvantages: > * Requires Java 5, but the backport jars could be substituted pretty easily > * Breaks some plugins due to commons-logging being in the Maven uber jar > (required by commons-httpclient), notably the apt plugin (maybe more should > use the isolatedRealm setting?) > * Screws up the progress monitor as multiple threads are updating it > Advantages: > * Much faster when combined with the http wagon (WAGON-98). I was seeing 40% > improvement on some test builds. -- 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-428) Japanese message resource
[ http://jira.codehaus.org/browse/MNG-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MNG-428. --- Assignee: Vincent Siveton (was: Brian Fox) Resolution: Fixed Applied! Thanks to have review it. > Japanese message resource > - > > Key: MNG-428 > URL: http://jira.codehaus.org/browse/MNG-428 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0-beta-1 > Environment: N/A >Reporter: Takayoshi Kimura >Assignee: Vincent Siveton >Priority: Minor > Fix For: 2.0.9 > > Attachments: message_ja.properites.patch, > message_ja.properites.reviewed.patch > > > Now, we got message_ja.properties. -- 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-3442) Add explicit resource bundle for English
Add explicit resource bundle for English Key: MNG-3442 URL: http://jira.codehaus.org/browse/MNG-3442 Project: Maven 2 Issue Type: Improvement Components: General Affects Versions: 2.0.8 Reporter: Vincent Siveton See MPIR-79 for some nice explanation. -- 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-3442) Add explicit resource bundle for English
[ http://jira.codehaus.org/browse/MNG-3442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MNG-3442. Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.0.9 fixed in r634311 > Add explicit resource bundle for English > > > Key: MNG-3442 > URL: http://jira.codehaus.org/browse/MNG-3442 > Project: Maven 2 > Issue Type: Improvement > Components: General >Affects Versions: 2.0.8 >Reporter: Vincent Siveton >Assignee: Vincent Siveton > Fix For: 2.0.9 > > > See MPIR-79 for some nice explanation. -- 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-3219) Create a CLIRR/JarDiff setup for 2.0.x and 2.1.x
[ http://jira.codehaus.org/browse/MNG-3219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-3219: --- Fix Version/s: (was: 2.0.9) 2.0.10 > Create a CLIRR/JarDiff setup for 2.0.x and 2.1.x > > > Key: MNG-3219 > URL: http://jira.codehaus.org/browse/MNG-3219 > Project: Maven 2 > Issue Type: New Feature > Components: Bootstrap & Build >Reporter: Jason van Zyl > Fix For: 2.0.10 > > > It may not only be for the core but also the plugin tools that have been > separated. -- 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-153) Active dependencies being unpacked but not listed as normal dependencies are not used by the reactor in determing build order
Active dependencies being unpacked but not listed as normal dependencies are
not used by the reactor in determing build order
-
Key: MDEP-153
URL: http://jira.codehaus.org/browse/MDEP-153
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: unpack
Affects Versions: 2.0
Reporter: James Carpenter
Assignee: Brian Fox
Priority: Critical
I have a multi-module build in which one child module is using the unpack goal
to expand the contents of a sibling module. Unfortunately, when building from
the parent level the reactor fails to consistently create an appropriate order
because the unpacked sibling artifact is not listed as a normal dependency.
(The sibling artifact being extracted happens to be an attached artifact, but
that is a lesser issue.)
=
Workaround:
Add a fake dependency at test scope which excludes all transitive dependencies
to the module which is unpacking the sibling artifact. This has the negative
side effect of slightly polluting the test classpath.
Within the sibling pom module with the unpack goal I have content similar to:
org.apache.maven.plugins
maven-dependency-plugin
process-resources
unpack
com.mycompany.myproject
module-A
${project.version}
zip
${project.build.directory}/expansiondirectory
com.mycompany.myproject
module-A
${project.version}
jar
test
*
*
Proposed solution:
1) Add support in maven for dependencies of "ghost" scope.
2) Some mechanism a plugin can use an injected component to affect reactor
build order.
Both of the above solutions are way to light in detail, to be of much use. I
only have shallow knowledge of how the reactor works with the artifact resolver
and other components to figure out build order. Therefore, I can't propose a
solid solution without spending more time digging around in the maven code.
The core maven developers can probably think of several solutions on the top of
their head.
==
Related JIRA: MDEP-106
==
Old Relevant Posting:
An old posting in the mailing list shows I'm not the only one to have
encountered this problem:
Link:
http://www.nabble.com/control-of-reactor-ordering-from-plugin-td7481761s177.html#a7481761
===
Subject: control of reactor ordering from plugin
by Brian E Fox Nov 21, 2006; 04:45pm :: Rate this Message: - Use ratings to
moderate (?)
Reply | Reply to Author | Print | View Threaded | Show Only this Message
This is a usability question but also dev related since the answer may
require/prompt changes to the dependency plugin.
I'm using assembly:attached to generate many different zip files that
package things I want to reuse. In this case, some data to be imported
into hsql for unit test purposes. This zip file occurs in a sub module
/data/modules. In /data/variants I have more assembly:attached things
that depend on the product of the rest of the builds. In otherwords, the
dependency tree effectively is: /data/variant[s] -> service jars ->
/data/module[s].
Since I'm using the dependency plugin to unpack/copy artifacts, these
zips are effectively dependencies but Maven doesn't know because the
[jira] Closed: (MAVENUPLOAD-1937) Upload JASIG CAS Client for Java 3.1.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1937. --- Assignee: Carlos Sanchez Resolution: Fixed Now synced from acegi repo > Upload JASIG CAS Client for Java 3.1.1 > -- > > Key: MAVENUPLOAD-1937 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1937 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Scott Battaglia >Assignee: Carlos Sanchez > > http://www.ja-sig.org/downloads/cas-clients/maven-upload-requests/cas-client-core-3.1.1-bundle.jar > http://www.jasig.org/products/cas/ > http://www.ja-sig.org/products/cas/about/index.html > I'm a developer on the JASIG CAS Client project and would like to use the > groupId org.jasig.cas -- 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-1934) gnu-hylafax 1.0.0-b2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1934. --- Assignee: Carlos Sanchez Resolution: Incomplete > gnu-hylafax 1.0.0-b2 > > > Key: MAVENUPLOAD-1934 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1934 > Project: maven-upload-requests > Issue Type: Task >Reporter: fabrizio giustina >Assignee: Carlos Sanchez > > the release is made up by 4 artifacts (4 upload bundles below) + 1 parent pom: > http://repository.openmindonline.it/_bundle-upload/gnu-hylafax-core-1.0.0-b2-bundle.jar > http://repository.openmindonline.it/_bundle-upload/gnu-hylafax-inet-ftp-1.0.0-b2-bundle.jar > http://repository.openmindonline.it/_bundle-upload/gnu-hylafax-pool-1.0.0-b2-bundle.jar > http://repository.openmindonline.it/_bundle-upload/gnu-hylafax-utils-1.0.0-b2-bundle.jar > http://repository.openmindonline.it/_bundle-upload/gnu-hylafax-1.0.0-b2.pom > Note that gnu-hylafax uses maven 2 to build, so these are official poms. > Groupid is "gnu-hylafax", which is not so good accorting maven convention, > but this is how artifacts are officially released. -- 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-1927) Please upload JCROM 1.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1927. --- Assignee: Carlos Sanchez Resolution: Fixed > Please upload JCROM 1.0 > --- > > Key: MAVENUPLOAD-1927 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1927 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Olafur Gauti Gudmundsson >Assignee: Carlos Sanchez > > http://jcrom.googlecode.com/files/jcrom-1.0-bundle.jar > http://jcrom.org (forwards to the google-code page for JCROM) > http://code.google.com/u/oli.gauti/ > I am the project owner, please upload. -- 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-1947) Please upload MessAdmin 4.1.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1947. --- Assignee: Carlos Sanchez Resolution: Fixed you need to setup a synced repo for next time > Please upload MessAdmin 4.1.1 > - > > Key: MAVENUPLOAD-1947 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1947 > Project: maven-upload-requests > Issue Type: Wish >Reporter: codehauser >Assignee: Carlos Sanchez > Attachments: MessAdmin-4.1.1-Bundles.zip > > > http://messadmin.sourceforge.net/maven2/4.1.1/MessAdmin-Core-4.1.1-bundle.jar > http://messadmin.sourceforge.net/maven2/4.1.1/MessAdmin-ClickStream-4.1.1-bundle.jar > http://messadmin.sourceforge.net/maven2/4.1.1/MessAdmin-JMX-4.1.1-bundle.jar > http://messadmin.sourceforge.net/maven2/4.1.1/MessAdmin-Serializable-4.1.1-bundle.jar > http://messadmin.sourceforge.net/maven2/4.1.1/MessAdmin-ServletStats-4.1.1-bundle.jar > http://messadmin.sourceforge.net/maven2/4.1.1/MessAdmin-SessionKiller-4.1.1-bundle.jar > http://messadmin.sourceforge.net/ > http://messadmin.sourceforge.net/#%5B%5BLicense%20%2F%20Contact%5D%5D > MessAdmin is a light-weigth and non-intrusive tool for monitoring Java > HttpSession. Please upload! -- 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-1946) Upload ImageInfo 1.9
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126354 ] Carlos Sanchez commented on MAVENUPLOAD-1946: - read http://maven.apache.org/guides/mini/guide-central-repository-upload.html > Upload ImageInfo 1.9 > > > Key: MAVENUPLOAD-1946 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1946 > Project: maven-upload-requests > Issue Type: New Feature >Reporter: Michael Osipov > > Version 1.9 contains important fixes. Upload is appreciated! -- 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-1945) I'm a dobo developer, please sync dobo into the repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1945. --- Assignee: Carlos Sanchez Resolution: Fixed > I'm a dobo developer, please sync dobo into the repository > -- > > Key: MAVENUPLOAD-1945 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1945 > Project: maven-upload-requests > Issue Type: Improvement >Reporter: Arif Rachim >Assignee: Carlos Sanchez > Attachments: dobo-1.0.jar > > > "net.sf.dobo","[EMAIL > PROTECTED]:/home/groups/d/do/dobo/htdocs/m2repo","rsync_ssh","Arif > Rachim","[EMAIL PROTECTED]",, > My name arif rachim, I'm a dobo developer, my email is [EMAIL PROTECTED] > Thank you. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2524) DefaultArtifactFactory.createDependencyArtifact sets scope to null
[
http://jira.codehaus.org/browse/MNG-2524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MNG-2524.
--
Assignee: Brian Fox
Resolution: Fixed
Fix Version/s: (was: 2.0.9)
2.0.8
Already fixed by Carlos in svn rev: 568659 (Maven 2.0.8)
> DefaultArtifactFactory.createDependencyArtifact sets scope to null
> --
>
> Key: MNG-2524
> URL: http://jira.codehaus.org/browse/MNG-2524
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.0.4
>Reporter: Adrian Sox
>Assignee: Brian Fox
>Priority: Trivial
> Fix For: 2.0.8
>
>
> There are four createDependencyArtifact methods in DefaultArtifactFactory,
> all of which take scope as an argument. One of the four fails to pass the
> scope into the createArtifact method.
> Specifically,
> public Artifact createDependencyArtifact( String groupId, String
> artifactId, VersionRange versionRange, String type,
>String classifier, String
> scope )
> {
> return createArtifact( groupId, artifactId, versionRange, type,
> classifier, null, null );
> }
> should be
> public Artifact createDependencyArtifact( String groupId, String
> artifactId, VersionRange versionRange, String type,
>String classifier, String
> scope )
> {
> return createArtifact( groupId, artifactId, versionRange, type,
> classifier, scope, null );
> }
--
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-1948) Upload Findbugs 1.2.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1948. --- Assignee: Carlos Sanchez Resolution: Fixed can you put it in some synced repo for next time? > Upload Findbugs 1.2.1 > - > > Key: MAVENUPLOAD-1948 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1948 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Garvin LeClaire >Assignee: Carlos Sanchez > > http://gleclaire.home.insightbb.com/findbugs/findbugsGUI-1.2.1-bundle.jar > http://gleclaire.home.insightbb.com/findbugs/findbugs-ant-1.2.1-bundle.jar > http://gleclaire.home.insightbb.com/findbugs/coreplugin-1.2.1-bundle.jar > http://gleclaire.home.insightbb.com/findbugs/annotations-1.2.1-bundle.jar > http://gleclaire.home.insightbb.com/findbugs/bcel-1.2.1-bundle.jar > http://mojo.codehaus.org/findbugs-maven-plugin/team-list.html > http://findbugs.sourceforge.net/manual/acknowledgments.html > Please upload the 1.2.1 version of Findbugs into the repository. I will need > these for further updates to the Maven findBugs plugins of which I am > developer. -- 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-1949) Upload Findbugs 1.3.2
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1949. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload Findbugs 1.3.2 > - > > Key: MAVENUPLOAD-1949 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1949 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Garvin LeClaire >Assignee: Carlos Sanchez > > http://gleclaire.home.insightbb.com/findbugs/findbugsGUI-1.3.2-bundle.jar > http://gleclaire.home.insightbb.com/findbugs/findbugs-ant-1.3.2-bundle.jar > http://gleclaire.home.insightbb.com/findbugs/coreplugin-1.3.2-bundle.jar > http://gleclaire.home.insightbb.com/findbugs/annotations-1.3.2-bundle.jar > http://gleclaire.home.insightbb.com/findbugs/bcel-1.3.2-bundle.jar > http://gleclaire.home.insightbb.com/findbugs/jsr305-1.3.2-bundle.jar > http://mojo.codehaus.org/findbugs-maven-plugin/team-list.html > http://findbugs.sourceforge.net/manual/acknowledgments.html > Please upload the 1.3.2 version of Findbugs into the repository. I will need > these for further updates to the Maven findBugs plugins of which I am > developer. -- 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: (ARCHETYPE-122) The defined artifact is not an archetype?
[ http://jira.codehaus.org/browse/ARCHETYPE-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126358 ] Geert Pante commented on ARCHETYPE-122: --- Fixed in 2.0-alpha-2. It took me a while to realize that you split up 'generate' from 'create', but mvn archetype:generate worked without complaining about the archetype. Good job. > The defined artifact is not an archetype? > - > > Key: ARCHETYPE-122 > URL: http://jira.codehaus.org/browse/ARCHETYPE-122 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes >Affects Versions: 2.0-alpha-1 > Environment: Maven version: 2.0.8 > Java version: 1.6.0 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: Geert Pante > Fix For: 2.0-alpha-3 > > Attachments: ebit-test-archetype-1.0-SNAPSHOT.jar, > ebit-test-archetype-1.0-SNAPSHOT.pom, ebit-test-archetype.zip > > > I'm using maven-archetype-plugin from > http://people.apache.org/~rafale/staging-repo/maven-archetype-plugin/. > I'm stuck trying to create a basic archetype. I created a POM with > packaging=maven-archetype and build extension > org.apache.maven.archetype:archetype-packaging:2.0-alpha-1. I put the > resources from > https://svn.apache.org/repos/asf/maven/archetype/tags/maven-archetype-2.0-alpha-1/archetype-common/src/test/archetypes/basic-1.0 > under src/main/resources and managed to package and install the archetype. > However, when I try to generate a new project from the archetype, I get: > -> The defined artifact is not an archetype > I see in the code that you first try to parse > META-INF/maven/archetype-metadata.xml, and then META-INF/maven/archetype.xml. > I assume that my archetype-metadata.xml is correct, but I'm not sure. I don't > need to have an archetype.xml, I guess... > See attachment for sample project, and full stack trace below: > E:\>mvn -e archetype:create -DarchetypeCatalog=local > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'archetype'. > [INFO] > > [INFO] Building Maven Default Project > [INFO]task-segment: [archetype:create] (aggregator-style) > [INFO] > > [INFO] Preparing archetype:create > [INFO] No goals needed for project - skipping > [INFO] Setting property: classpath.resource.loader.class => > 'org.codehaus.plexus > .velocity.ContextClassLoaderResourceLoader'. > [INFO] Setting property: velocimacro.messages.on => 'false'. > [INFO] Setting property: resource.loader => 'classpath'. > [INFO] Setting property: resource.manager.logwhenfound => 'false'. > [INFO] [archetype:create] > Choose archetype: > 1: local -> ebit-test-plugin (ebit-test-plugin) > 2: local -> ebit-test-archetype (ebit-test-archetype) > Choose a number: (1/2): 2 > [INFO] > > [DEBUG] Can not load old archetype > java.io.IOException: The META-INF/maven/archetype.xml descriptor cannot be > found. > at > org.apache.maven.archetype.common.DefaultArchetypeArtifactManager.getOldArchetypeDescriptorReader(DefaultArchetypeArtifactManager.java:589) > at > org.apache.maven.archetype.common.DefaultArchetypeArtifactManager.loadOldArchetypeDescriptor(DefaultArchetypeArtifactManager.java:542) > at > org.apache.maven.archetype.common.DefaultArchetypeArtifactManager.isOldArchetype(DefaultArchetypeArtifactManager.java:506) > at > org.apache.maven.archetype.common.DefaultArchetypeArtifactManager.isOldArchetype(DefaultArchetypeArtifactManager.java:271) > at > org.apache.maven.archetype.ui.DefaultArchetypeGenerationConfigurator.configureArchetype(DefaultArchetypeGenerationConfigurator.java:125) > at > org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execute(CreateProjectFromArchetypeMojo.java:167) > [ERROR] BUILD ERROR > [INFO] > > [INFO] The defined artifact is not an archetype > [INFO] > > [DEBUG] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: The defined artifact > is not an archetype > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564) > Caused by: org.apache.maven.plugin.MojoExecutionException: The defined > artifact is not an archetype > at > org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execute(CreateProjectFromArchetypeMojo.java:173) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447) > at > org.apache.maven.life
[jira] Closed: (MAVENUPLOAD-1950) Upload org.hibernate:hibernate:jar:3.2.6.ga to ibiblio
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1950. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload org.hibernate:hibernate:jar:3.2.6.ga to ibiblio > -- > > Key: MAVENUPLOAD-1950 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1950 > Project: maven-upload-requests > Issue Type: Task >Reporter: Christian Nelson >Assignee: Carlos Sanchez > > http://svn.carbonfive.com/public/maven-bundles/hibernate-3.2.6.ga-bundle.jar > http://www.hibernate.org/ > Relational Persistence for Java -- 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-1951) Javassist 3.7.ga
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1951. --- Assignee: Carlos Sanchez Resolution: Fixed > Javassist 3.7.ga > > > Key: MAVENUPLOAD-1951 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1951 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Howard M. Lewis Ship >Assignee: Carlos Sanchez > > http://labs.jboss.com/javassist/ -- 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-1952) Upload easyb artifacts
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1952. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload easyb artifacts > -- > > Key: MAVENUPLOAD-1952 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1952 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Rod Coffin >Assignee: Carlos Sanchez > > http://easyb.googlecode.com/files/easyb-0.7-bundle.jar > http://easyb.googlecode.com/files/easyb-dbunit-plugin-0.7-bundle.jar > http://easyb.googlecode.com/files/maven-easyb-plugin-0.7-bundle.jar > http://www.easyb.org > http://code.google.com/p/easyb/ > I am a developer on the easyb project and this can be verified at > http://code.google.com/p/easyb/ where I (username rfciii) am listed as one of > the project owners. -- 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: (MPLUGIN-82) Fix test for javadoc tools
Fix test for javadoc tools -- Key: MPLUGIN-82 URL: http://jira.codehaus.org/browse/MPLUGIN-82 Project: Maven 2.x Plugin Tools Issue Type: Task Reporter: Benjamin Bentmann Priority: Trivial Attachments: org.apache.maven.tools.plugin.javadoc.JavadocReportTest.txt, taglet-test.patch The POM javadoc-plugin-config.xml for the taglets test is hardcoded to use 1.0 of the maven-plugin-tools-javadoc. For now, i.e. before the artifact is available on central, the test simply fails. In the long term, you are testing the wrong artifact. Patch uses resource filtering to use current project version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1954) Upload Click 1.4 bundles
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1954. --- Assignee: Carlos Sanchez Resolution: Fixed next time you have to setup a synced repo > Upload Click 1.4 bundles > > > Key: MAVENUPLOAD-1954 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1954 > Project: maven-upload-requests > Issue Type: Task >Reporter: Malcolm Edgar >Assignee: Carlos Sanchez > > Please upload the following Click 1.4 maven bundles: > http://click.sourceforge.net/click-maven-bundle/click-1.4-bundle.jar > http://click.sourceforge.net/click-maven-bundle/click-nodeps-1.4-bundle.jar > http://click.sourceforge.net/click-maven-bundle/click-extras-1.4-bundle.jar > Thanks for your help > regards Malcolm Edgar -- 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-1953) Mockito upload request
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1953. --- Assignee: Carlos Sanchez Resolution: Fixed > Mockito upload request > -- > > Key: MAVENUPLOAD-1953 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1953 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Igor Czechowski >Assignee: Carlos Sanchez > > http://mockito.googlecode.com/svn/branches/1.1/maven/mockito-all-1.1-bundle.jar > http://code.google.com/p/mockito/ > http://code.google.com/u/iczechowski/ > I'm a project member in Mockito and want to use the org.mockito groupId > You can see my name listed in Project members section at > http://code.google.com/p/mockito/ and additionally at > http://code.google.com/u/iczechowski/ > This bundle has no external dependencies. -- 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-1955) upload xSocket 2.0-beta-1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126361 ] Carlos Sanchez commented on MAVENUPLOAD-1955: - please setup a synced repo http://maven.apache.org/guides/mini/guide-central-repository-upload.html > upload xSocket 2.0-beta-1 > - > > Key: MAVENUPLOAD-1955 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1955 > Project: maven-upload-requests > Issue Type: Wish >Reporter: greg > > please also upload the xSocket extensions > http://xsocket.sourceforge.net/download/xSocket-http-2.0-alpha-3-bundle.jar > http://xsocket.sourceforge.net/download/xSocket-multiplexed-2.0-alpha-3-bundle.jar > Thank you very much > Greg -- 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-1956) please upload DynamicJasper 2.0.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1956. --- Assignee: Carlos Sanchez Resolution: Fixed > please upload DynamicJasper 2.0.7 > - > > Key: MAVENUPLOAD-1956 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1956 > Project: maven-upload-requests > Issue Type: Wish >Reporter: Juan Manuel Alvarez >Assignee: Carlos Sanchez > > http://dynamicjasper.sourceforge.net/DynamicJasper-2.0.7-bundle.jar > http://dynamicjasper.sourceforge.net/ > http://dynamicjasper.sourceforge.net/team-list.html > I am DynamicJasper's project leader, please upload. > DynamicJasper (DJ) is an API that hides the complexity of Jasper Reports, it > helps developers to save time when designing simple/medium complexity reports > generating the layout of the report elements automatically. It creates > reports dynamically, defining at runtime the columns, column width (auto > width), groups, variables, fonts, charts, crosstabs, sub reports (that can > also be dynamic), page size and everything else that you can define at design > time. -- 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: (MRM-731) variable in url pom are not replaced.
[
http://jira.codehaus.org/browse/MRM-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126363
]
Joakim Erdfelt commented on MRM-731:
Which url line in the pom is that specified in?
We have a TestCase setup for expression evaluation (as a result of MRM-487 and
MRM-488), I'd like to use your pom.xml to further the testing.
See the following test case.
http://svn.apache.org/viewvc/maven/archiva/branches/archiva-1.0.x/archiva-base/archiva-repository-layer/src/test/java/org/apache/maven/archiva/repository/project/filters/ProjectModelExpressionExpanderTest.java?view=markup
{code}
/**
* [MRM-487] pom version is not resolved
* [MRM-488] properties in pom are not resolved (at least while browsing)
*
* This is to ensure that any expression within the pom is evaluated properly.
*/
public void testExpressionHell()
{code}
> variable in url pom are not replaced.
> -
>
> Key: MRM-731
> URL: http://jira.codehaus.org/browse/MRM-731
> Project: Archiva
> Issue Type: Bug
>Reporter: Benoit Decherf
>
> In my pom, the url of the project is :
>
> http:///docs/${project.groupId}/${project.artifactId}/${project.version}
> So I expect that archiva replace the ${} variables of this URL, but it
> doesn't :( .
--
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: (MASSEMBLY-293) not filtered in multimodule build, but are
not filtered in multimodule build, but are - Key: MASSEMBLY-293 URL: http://jira.codehaus.org/browse/MASSEMBLY-293 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-2 Environment: Windows XP Reporter: Torsten Reinhard Attachments: install.xml, update-db2.sh Filtering doesn´t work in a multimodule build if I use instead of - if I build the module separately, it works Shouldn´t the behaviour be the same? I have not looked into the code, but I expect one thing is collection the files (however the filelist is expressed), the other is filtering them. It seems, as the separation of functionality is mixed in here? See the attached file(s) as example. -- 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-3394) Plugin versions inherited via cannot be overriden by . section of sub modules
[ http://jira.codehaus.org/browse/MNG-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126364 ] John Casey commented on MNG-3394: - The code on that ModelDefaultsInjector impl seems nearly identical between 2.0.x/HEAD and 2.1/HEAD (slight formatting diffs), but the two behave dramatically different on this point. 2.1-SNAPSHOT allows local override of plugin version (in the build/plugins section), where 2.0.9-SNAPSHOT does not. I'm not sure where else pluginManagement comes into play (it probably shouldn't be in play at all once the project instance is built), but the difference must lie outside of the defaults injector... Sorry for the red herring. > Plugin versions inherited via cannot be overriden by > . section of sub modules > > > Key: MNG-3394 > URL: http://jira.codehaus.org/browse/MNG-3394 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.8 >Reporter: Benjamin Bentmann >Priority: Critical > Fix For: 2.0.9 > > Attachments: plugin-management-version.zip > > > See the comments in the module POM of the attached demo project for more > explanation. -- 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-153) Active dependencies being unpacked but not listed as normal dependencies are not used by the reactor in determing build order
[
http://jira.codehaus.org/browse/MDEP-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126366
]
Brian Fox commented on MDEP-153:
This will never be possible to fix with Maven 2.0.x, but it is one of the use
cases I discussed with John while putting together:
http://docs.codehaus.org/display/MAVEN/Atypical+Plugin+Use+Cases
> Active dependencies being unpacked but not listed as normal dependencies are
> not used by the reactor in determing build order
> -
>
> Key: MDEP-153
> URL: http://jira.codehaus.org/browse/MDEP-153
> Project: Maven 2.x Dependency Plugin
> Issue Type: Bug
> Components: unpack
>Affects Versions: 2.0
>Reporter: James Carpenter
>Assignee: Brian Fox
>Priority: Critical
>
> I have a multi-module build in which one child module is using the unpack
> goal to expand the contents of a sibling module. Unfortunately, when
> building from the parent level the reactor fails to consistently create an
> appropriate order because the unpacked sibling artifact is not listed as a
> normal dependency. (The sibling artifact being extracted happens to be an
> attached artifact, but that is a lesser issue.)
> =
> Workaround:
> Add a fake dependency at test scope which excludes all transitive
> dependencies to the module which is unpacking the sibling artifact. This has
> the negative side effect of slightly polluting the test classpath.
> Within the sibling pom module with the unpack goal I have content similar to:
>
>
>
> org.apache.maven.plugins
> maven-dependency-plugin
>
>
> process-resources
>
> unpack
>
>
>
>
>
>
>
> com.mycompany.myproject
>
> module-A
>
> ${project.version}
> zip
>
>
>
> ${project.build.directory}/expansiondirectory
>
>
>
>
>
>
>
> com.mycompany.myproject
> module-A
> ${project.version}
> jar
> test
>
>
> *
> *
>
>
>
>
>
> Proposed solution:
> 1) Add support in maven for dependencies of "ghost" scope.
> 2) Some mechanism a plugin can use an injected component to affect reactor
> build order.
> Both of the above solutions are way to light in detail, to be of much use. I
> only have shallow knowledge of how the reactor works with the artifact
> resolver and other components to figure out build order. Therefore, I can't
> propose a solid solution without spending more time digging around in the
> maven code. The core maven developers can probably think of several
> solutions on the top of their head.
> ==
> Related JIRA: MDEP-106
> ==
> Old Relevant Posting:
> An old posting in the mailing list shows I'm not the only one to have
> encountered this problem:
> Link:
> http://www.nabble.com/control-of-reactor-ordering-from-plugin-td7481761s177.html#a7481761
> ===
> Subject: control of reactor ordering from plugin
> by Brian E Fox Nov 21, 2006; 04:45pm :: Rate this Message: - Use ratings to
> moderate (?)
> Reply | Reply to Author | Print | View Threaded | Show Only this Message
> This is a usability question but also dev related since the answer may
> require/prompt changes to the dependency plugin.
>
> I'm using assembly:attached to generate many different zip files that
[jira] Updated: (MPLUGIN-82) Fix test for javadoc tools
[ http://jira.codehaus.org/browse/MPLUGIN-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MPLUGIN-82: - Attachment: taglet-test.patch Alternative to my first patch: Previously, I just used the default Maven resource filtering which will filter all expressions in the test POM, not just the single spot intended. A possible solution to this unwanted side-effect is using Ant to selectively filter tokens. > Fix test for javadoc tools > -- > > Key: MPLUGIN-82 > URL: http://jira.codehaus.org/browse/MPLUGIN-82 > Project: Maven 2.x Plugin Tools > Issue Type: Task >Reporter: Benjamin Bentmann >Priority: Trivial > Attachments: > org.apache.maven.tools.plugin.javadoc.JavadocReportTest.txt, > taglet-test.patch, taglet-test.patch > > > The POM javadoc-plugin-config.xml for the taglets test is hardcoded to use > 1.0 of the maven-plugin-tools-javadoc. For now, i.e. before the artifact is > available on central, the test simply fails. In the long term, you are > testing the wrong artifact. > Patch uses resource filtering to use current project version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPLUGIN-83) POM snippet for plugin usage via pluginManagement is missing container
POM snippet for plugin usage via pluginManagement is missing container
Key: MPLUGIN-83
URL: http://jira.codehaus.org/browse/MPLUGIN-83
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: Plugin Plugin
Reporter: Benjamin Bentmann
Priority: Trivial
Attachments: pluginmanagement.patch
Currently, plugin-info.html says:
{noformat}
org.codehaus.mojo
dummy-maven-plugin
1.0
...
{noformat}
but should be
{noformat}
org.codehaus.mojo
dummy-maven-plugin
1.0
...
{noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MIDEA-102) CLONE -still broken - Module filepath is generated incorrectly
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126372 ] Geoffrey De Smet commented on MIDEA-102: bq. Someone should throw that code in there, close this out and release 2.2. I couldn't agree more :) > CLONE -still broken - Module filepath is generated incorrectly > -- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- 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-2551) pom metadata file gets truncated during install into local repository
[ http://jira.codehaus.org/browse/MNG-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MNG-2551: --- Attachment: pom-good.xml I updated the pom so it works outside their corporation > pom metadata file gets truncated during install into local repository > - > > Key: MNG-2551 > URL: http://jira.codehaus.org/browse/MNG-2551 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 > Environment: Win XP, JDK 1.4 >Reporter: Sharmarke Aden > Fix For: 2.0.9 > > Attachments: pom-good.xml, pom.xml, shared-1.9.0.pom > > > When I attempt to install my project artifact to my local repository it seems > that sometimes an incomplete/truncated ".pom" is deployed to my local > repository. It's kind of weird because sometimes it happens and sometimes it > doesn't. Any thoughts as to what could cause this? Attached is my pom.xml and > the truncated pom meta data artifact deployed to my local repository. One > thing I found that's odd is that the size of the truncated pom generated is > consistently 4096 bytes. > p.s. my pom.xml is UTF-8 encoded and uses Unix style line delimiters. -- 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: (MPLUGIN-84) Update to Plexus Utils 1.5+
Update to Plexus Utils 1.5+
---
Key: MPLUGIN-84
URL: http://jira.codehaus.org/browse/MPLUGIN-84
Project: Maven 2.x Plugin Tools
Issue Type: Task
Reporter: Benjamin Bentmann
Priority: Trivial
Attachments: plexus-utils-1.5+.patch
maven-plugin-testing-harness and maven-plugin-tools-model use
{{ReaderFactory.newXmlReader()}} and hence are affected by PLXUTILS-60.
--
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-2551) pom metadata file gets truncated during install into local repository
[ http://jira.codehaus.org/browse/MNG-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MNG-2551. -- Assignee: Brian Fox Resolution: Cannot Reproduce Fix Version/s: (was: 2.0.9) I am not able to reproduce this issue on windows or ubuntu 7.10 w/java 1.6 and 2.0.9-SNAPSHOT. If this still occurs, please reopen with a sample project and instructions on how to reproduce it. > pom metadata file gets truncated during install into local repository > - > > Key: MNG-2551 > URL: http://jira.codehaus.org/browse/MNG-2551 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 > Environment: Win XP, JDK 1.4 >Reporter: Sharmarke Aden >Assignee: Brian Fox > Attachments: pom-good.xml, pom.xml, shared-1.9.0.pom > > > When I attempt to install my project artifact to my local repository it seems > that sometimes an incomplete/truncated ".pom" is deployed to my local > repository. It's kind of weird because sometimes it happens and sometimes it > doesn't. Any thoughts as to what could cause this? Attached is my pom.xml and > the truncated pom meta data artifact deployed to my local repository. One > thing I found that's odd is that the size of the truncated pom generated is > consistently 4096 bytes. > p.s. my pom.xml is UTF-8 encoded and uses Unix style line delimiters. -- 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: (MPLUGIN-85) Add missing whitespace between words on mojo description page
Add missing whitespace between words on mojo description page
-
Key: MPLUGIN-85
URL: http://jira.codehaus.org/browse/MPLUGIN-85
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: API
Reporter: Benjamin Bentmann
Priority: Trivial
Attachments: whitespace.patch
mymojo-mojo.html prints:
{noformat}
Invokes the execution of the lifecycle phase compileprior to executing itself.
{noformat}
Note the missing whitespace between "compile" and "prior".
--
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-3443) boolean values in the POM specified as expressions are not interpolated, result in value == false
boolean values in the POM specified as expressions are not interpolated, result in value == false - Key: MNG-3443 URL: http://jira.codehaus.org/browse/MNG-3443 Project: Maven 2 Issue Type: Bug Components: POM Affects Versions: 2.0.8, 2.1-alpha-1 Reporter: John Casey Attachments: interpolate-boolean-expression.zip The problem is the ModelReader generated by Modello uses something akin to Boolean.valueOf( element.getValue() ) to set boolean model values. If the value in XML is actually an expression, it is resolved to false and never interpolated. To correct this, we should consider revising Modelllo's generated reader architecture to use a two-stage approach: 1. Construct a raw structure of String: String and String: Collection associations (basically something like a perlish hash, IIRC) 2. Pass an arbitrary number of transformers over the raw structure to interpolate it (this includes path translation, etc. and should include a notion of transformation context to allow transformations to collaborate) 3. Construct the Model instance based on the transformed raw structure. This will incur a little extra transient overhead for model construction, but its effects should be mitigated through the caching strategies we employ for models and projects. -- 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-3443) boolean values in the POM specified as expressions are not interpolated, result in value == false
[ http://jira.codehaus.org/browse/MNG-3443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-3443: Affects Version/s: 2.0.9 > boolean values in the POM specified as expressions are not interpolated, > result in value == false > - > > Key: MNG-3443 > URL: http://jira.codehaus.org/browse/MNG-3443 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.8, 2.0.9, 2.1-alpha-1 >Reporter: John Casey > Attachments: interpolate-boolean-expression.zip > > > The problem is the ModelReader generated by Modello uses something akin to > Boolean.valueOf( element.getValue() ) to set boolean model values. If the > value in XML is actually an expression, it is resolved to false and never > interpolated. > To correct this, we should consider revising Modelllo's generated reader > architecture to use a two-stage approach: > 1. Construct a raw structure of String: String and String: Collection > associations (basically something like a perlish hash, IIRC) > 2. Pass an arbitrary number of transformers over the raw structure to > interpolate it (this includes path translation, etc. and should include a > notion of transformation context to allow transformations to collaborate) > 3. Construct the Model instance based on the transformed raw structure. > This will incur a little extra transient overhead for model construction, but > its effects should be mitigated through the caching strategies we employ for > models and projects. -- 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-3443) boolean values in the POM specified as expressions are not interpolated, result in value == false
[ http://jira.codehaus.org/browse/MNG-3443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MNG-3443: Attachment: interpolate-boolean-expression.zip Attaching a test case. See `mvn help:effective-pom`, or the effective-pom.txt file included in the zip, and pay particular attention to the repository with id "interpolated". > boolean values in the POM specified as expressions are not interpolated, > result in value == false > - > > Key: MNG-3443 > URL: http://jira.codehaus.org/browse/MNG-3443 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.8, 2.0.9, 2.1-alpha-1 >Reporter: John Casey > Attachments: interpolate-boolean-expression.zip > > > The problem is the ModelReader generated by Modello uses something akin to > Boolean.valueOf( element.getValue() ) to set boolean model values. If the > value in XML is actually an expression, it is resolved to false and never > interpolated. > To correct this, we should consider revising Modelllo's generated reader > architecture to use a two-stage approach: > 1. Construct a raw structure of String: String and String: Collection > associations (basically something like a perlish hash, IIRC) > 2. Pass an arbitrary number of transformers over the raw structure to > interpolate it (this includes path translation, etc. and should include a > notion of transformation context to allow transformations to collaborate) > 3. Construct the Model instance based on the transformed raw structure. > This will incur a little extra transient overhead for model construction, but > its effects should be mitigated through the caching strategies we employ for > models and projects. -- 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: (MJAVADOC-116) Impossible to aggregate javadoc if snapshot never built
[
http://jira.codehaus.org/browse/MJAVADOC-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Antonio Petrelli updated MJAVADOC-116:
--
Attachment: tiles-log.txt
Creating Javadocs with:
mvn javadoc:javadoc
does not work with Tiles:
http://svn.apache.org/repos/asf/tiles/framework/trunk/
Added tiles-log.txt as attachment.
> Impossible to aggregate javadoc if snapshot never built
> ---
>
> Key: MJAVADOC-116
> URL: http://jira.codehaus.org/browse/MJAVADOC-116
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Damien Lecan
>Assignee: Vincent Siveton
> Fix For: 2.4
>
> Attachments: clean javadoc-plugin-test-case with classifier use.zip,
> javadoc-plugin-test-case with classifier use.zip,
> javadoc-plugin-test-case.zip, log.txt, tiles-log.txt
>
>
> In a multi-module projet, I build an aggregated Javadoc for the site.
> The project is built with "mvn clean deploy site-deploy"
> When I add a new project, the next build always fails because the javadoc
> plugin can't find at least one snapshot for the new added module
> In the following example, I added a new module tele.persistance:pers-commons,
> which have never been built before.
> Maven tries to download it but it can't find it (never build before).
> {noformat} [INFO] [site:site]
> [WARNING] Unable to load parent project from repository: Could not find the
> model file '/continuum-folders/working-directory/116/../pom.xml'.
> [INFO] Skipped "About" report, file "index.html" already exists for the
> English version.
> [ERROR] VM #displayTree: error : too few arguments to macro. Wanted 2 got 0
> [ERROR] VM #menuItem: error : too few arguments to macro. Wanted 1 got 0
> [INFO] Generate "JavaDocs" report.
> [INFO] snapshot tele:commons:1.2.0-alpha-1-SNAPSHOT: checking for updates
> from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-data:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-api:1.2.0-alpha-1-SNAPSHOT: checking
> for updates from mirror.snapshots
> [INFO] snapshot tele.persistance:pers-commons:1.2.0-alpha-1-SNAPSHOT:
> checking for updates from mirror.snapshots
> Downloading:
> http://proxy/maven2-snapshots/repository/tele/persistance/pers-commons/1.2.0-alpha-1-SNAPSHOT/pers-commons-1.2.0-alpha-1-SNAPSHOT.jar
> [WARNING] Unable to get resource
> 'tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT' from repository
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=tele.persistance
> -DartifactId=pers-commons \
> -Dversion=1.2.0-alpha-1-SNAPSHOT -Dpackaging=jar
> -Dfile=/path/to/file
> Path to dependency:
> 1) tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> 2) tele.persistance:pers-commons:jar:1.2.0-alpha-1-SNAPSHOT
> --
> 1 required artifact is missing.
> for artifact:
> tele.persistance:pers-dao:jar:1.2.0-alpha-1-SNAPSHOT
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2),
> mirror.snapshots (http://proxy/maven2-snapshots/repository)
> {noformat}
> If I make an intermediate "install", everything works fine
--
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: (MPLUGIN-86) Test for empty mojo description in XDoc generator does not cover empty string
Test for empty mojo description in XDoc generator does not cover empty string - Key: MPLUGIN-86 URL: http://jira.codehaus.org/browse/MPLUGIN-86 Project: Maven 2.x Plugin Tools Issue Type: Bug Components: API Reporter: Benjamin Bentmann Priority: Trivial Attachments: empty-description.patch Testing for null is not sufficient. -- 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: (MPLUGIN-87) Replace "None" with something that is better understandable without context
Replace "None" with something that is better understandable without context
---
Key: MPLUGIN-87
URL: http://jira.codehaus.org/browse/MPLUGIN-87
Project: Maven 2.x Plugin Tools
Issue Type: Improvement
Reporter: Benjamin Bentmann
Priority: Trivial
Attachments: none-what.patch
"None" is quite saying nothing, giving rise to the question "None what?".
Especially the parameter details would become better readable if it would not
only print:
{noformat}
myParam:
None.
+ Type: java.lang.String
+ Required: no
{noformat}
Note: Patch does not update French bundle (Natives would get hurt if I tried
;-)).
--
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: (MPLUGIN-88) Fix punctuation for description of mojo attributes
Fix punctuation for description of mojo attributes
--
Key: MPLUGIN-88
URL: http://jira.codehaus.org/browse/MPLUGIN-88
Project: Maven 2.x Plugin Tools
Issue Type: Bug
Components: API
Reporter: Benjamin Bentmann
Priority: Trivial
Attachments: punctuation.patch
mymojo-mojo.html reads:
{noformat}
Invokes the execution of the lifecycle phase compileprior to executing itself..
{noformat}
Note the double period at the end of the sentence.
The patch proposes to consistently have the PluginXDocGenerator add punctuation
as required instead of letting the resource bundles deal with it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3394) Plugin versions inherited via cannot be overriden by . section of sub modules
[ http://jira.codehaus.org/browse/MNG-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126380 ] John Casey commented on MNG-3394: - The problem seems to be coming from the DefaultLifecycleExecutor.getMojoDescriptor(..) method. After parsing or otherwise acquiring a Plugin object for the task being invoked, it blindly injects pluginManagement values without first checking the project for a matching non-pluginManagement plugin entry...then, it passes the plugin off to the DefaultPluginManager.verifyPlugin(..) method, which from what I can tell would have done this in the correct order (including the project/build/plugins/plugin info over the pluginManagement info). I'm currently trying to figure out whether we can remove the project.injectPluginManagementInfo(..) call from DefaultLifecycleExecutor.getMojoDescriptor(..), to simplify things and restore some semblance of sanity. ;-) > Plugin versions inherited via cannot be overriden by > . section of sub modules > > > Key: MNG-3394 > URL: http://jira.codehaus.org/browse/MNG-3394 > Project: Maven 2 > Issue Type: Bug > Components: Inheritance and Interpolation >Affects Versions: 2.0.8 >Reporter: Benjamin Bentmann >Priority: Critical > Fix For: 2.0.9 > > Attachments: plugin-management-version.zip > > > See the comments in the module POM of the attached demo project for more > explanation. -- 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-102) CLONE -still broken - Module filepath is generated incorrectly
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126381 ] gotama commented on MIDEA-102: -- I would add it - but I'm new to this project so I don't know how to get permissions to check in code and what the official release process is. How do you become a committer? Also, someone should check out the ClassWorlds dependency for the tests. The tests fail because they are missing the ClassWorlds dependency. classworlds classworlds 1.1 test > CLONE -still broken - Module filepath is generated incorrectly > -- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- 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-102) CLONE -still broken - Module filepath is generated incorrectly
[ http://jira.codehaus.org/browse/MIDEA-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126383 ] Dennis Lundberg commented on MIDEA-102: --- Thanks for trying the patch. As I don't have a cygwin environment I have not been able to verify the patch. I'll have a look at the patch. > CLONE -still broken - Module filepath is generated incorrectly > -- > > Key: MIDEA-102 > URL: http://jira.codehaus.org/browse/MIDEA-102 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.1 > Environment: $ mvn -v > Maven version: 2.0.7 > Java version: 1.5.0_11 > OS name: "windows xp" version: "5.1" arch: "x86" > cygwin >Reporter: Joern Huxhorn >Assignee: Dennis Lundberg > Fix For: 2.2 > > Attachments: maven-idea-plugin-MIDEA-102.patch > > > I have a multi-module mvn project. > When I do an mvn idea:clean idea:idea, the following ProjectModuleManager > snippet in the top level .ipr is generated: > > > > >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/domain/gateway-domain.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/instruction-store/gateway-instruction-store.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/parser/gateway-parser.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/psrgeneration/gateway-psr-generation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/output/gateway-output.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/destination-resolver/gateway-destination-resolver.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/choreography/gateway-choreography.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/presentation/gateway-presentation.iml"/> >filepath="$PROJECT_DIR$/C:/dev/voca/gateway/assembly/gateway-assembly.iml"/> > > > The $PROJECT_DIR in this case is C:/dev/voca/gateway/. > But this path is being appended in a hard-coded fashion after the > $PROJECT_DIR entry. > The symptom in Intellij is the following error message: > Cannot load module: File > C:\dev\voca\gateway\C:\dev\voca\gateway\domain\gateway-domain.iml does not > exist > Would you like to remove the module from the project? > The workaround is to delete the extra appended file path from each module > entry in the above mentioned snippet. -- 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: (MPLUGIN-89) Restore compat with Java 1.4
Restore compat with Java 1.4 Key: MPLUGIN-89 URL: http://jira.codehaus.org/browse/MPLUGIN-89 Project: Maven 2.x Plugin Tools Issue Type: Task Components: API Reporter: Benjamin Bentmann Priority: Critical Attachments: java-1.4.patch Doesn't compile/run with Java 1.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: (MSITE-307) Site generation broken with multi-module property inheritence
Site generation broken with multi-module property inheritence
-
Key: MSITE-307
URL: http://jira.codehaus.org/browse/MSITE-307
Project: Maven 2.x Site Plugin
Issue Type: Bug
Components: inheritance
Affects Versions: 2.0-beta-6
Environment: Ubuntu 7.10, Maven 2.0.8
Reporter: Eric Ryan
Maven2 site plugin inheritence
I have a multi-module project with the following directory structure:
my-app
|
|---my-client-ui
| |
| |---pom.xml
|
|---my-core
| |
| |---pom.xml
|
|---my-common
| |
| |---pom.xml
|
|---pom.xml
I define properties such as ${myVersion}, ${myArtifactId}, ${myGroupId} in the
parent pom. These properties are used by the child poms to resolve the parent
pom (they are used in the tags). These properties are inherited by
the children (as expected) when running goals such as clean, package, or
install.
I start to see problems when I try to use the site plugin. I first run the
install goal to install my project's jars and poms into my local
repo(~/.m2/repository/). I then verify that the jars and poms are in my local
repo. When I try to run the site plugin it seems as though maven is unable to
interpret the properties defined in the parent pom. I receive the following
output for each module:
[INFO]
[INFO] Building my-client-ui
[INFO]task-segment: [site]
[INFO]
[INFO] [site:site]
Downloading:
http://repo1.maven.org/maven2/${myGroupId}/${myArtifactId}/${myVersion}/${myArtifactId}-${myVersion}.pom
[WARNING] Unable to load parent project from repository: Failed to validate POM
for project ${myGroupId}:${myArtifactId} at Artifact
[${myGroupId}:${myArtifactId}:pom:${myVersion}]
[INFO] Generating "Continuous Integration" report...
I've tried using site:deploy, site:run, and site:stage. In all cases I recieve
a sucessful build, but all sites generated contain broken links. (Note. parent
pom's distributionManagement site url=file:///home/eric/tmp)
When using site:deploy, there are two issues with the site. The first is that
none of the modules are listed for the project on the left hand side of the
screen. The second is that when I go to the Dependence Convergence section,
the links to my project's modules are broken. In example, the link to
my-client-ui incorrectly points to http://www.mycompany.com/my-client-ui when
it is in fact located at file:///home/eric/tmp/my-client-ui (Note.
http://www.mycompany.com is defined in the parent pom as the project's url).
site:run demonstrates the same problems as site:deploy.
When using site:stage -DstagingDirectory=/home/eric/tmp, there are again two
issues w/ the site. The first is the same, none of the modules are listed on
the left hand side of the screen. The second is also the same, except that the
links in the Dependency Convergence section now point to
file:///home/eric/localhost/home/eric/tmp/my-client-ui. This is incorrect
because the files are actually located at
file:///home/eric/tmp/localhost/home/eric/tmp/my-client-ui. It is missing the
tmp directory in the url string.
The only way I've been able to get the modules to be displayed on the left hand
side of the screen is using mvn -N site site:deploy. In this case, the links
point to the "correct" place (file:///home/eric/tmp/my-client-ui), but the
submodule's sites are never build because of the -N (non-recursive) flag.
Another thing to note is that the Dependency Convergence section is totally
missing from this site.
The only way I've been able to build a site with links that resolve properly is
if I remove all instances of properties in all of my poms and replace them with
hard coded values. In this case, the links for the modules do appear on the
left hand side of the screen. The downfall to this approach is that the links
in the Dependency Convergence section now point to
http://www.mycompany.com/my-client-ui.
>From my discussion with others on the Maven mailing list, it seems as though
>some other users are experiencing this same issue with site property
>inheritence.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3379) Parallel resolution of artifacts
[ http://jira.codehaus.org/browse/MNG-3379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126385 ] Don Brown commented on MNG-3379: No, you don't need to be worried about file-locking. The retrieval algorithm only retrieves artifacts from different groups in parallel, but ones from the same group in serial, which is where you would need file-locking. > Parallel resolution of artifacts > > > Key: MNG-3379 > URL: http://jira.codehaus.org/browse/MNG-3379 > Project: Maven 2 > Issue Type: New Feature > Components: Artifacts and Repositories >Affects Versions: 2.0.8 >Reporter: Don Brown >Assignee: Brett Porter > Attachments: parallel-resolution-2.diff, parallel-resolution-3.diff, > parallel-resolution.diff > > > Artifacts should be resolved in parallel, grouped by group id's to get around > the lack of synchronization in the local repository. The patch does the > following: > * Use a ThreadPoolExecutor to parallelize artifact resolution, but takes care > not to resolve multiple artifacts from the same group id simultaneously. > (requires Java 5) > * Makes the http wagon the default instead of the poor performing http-client > Disadvantages: > * Requires Java 5, but the backport jars could be substituted pretty easily > * Breaks some plugins due to commons-logging being in the Maven uber jar > (required by commons-httpclient), notably the apt plugin (maybe more should > use the isolatedRealm setting?) > * Screws up the progress monitor as multiple threads are updating it > Advantages: > * Much faster when combined with the http wagon (WAGON-98). I was seeing 40% > improvement on some test builds. -- 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: (MPLUGIN-90) Refactor makeValidHtml into PluginUtils for better reusage
Refactor makeValidHtml into PluginUtils for better reusage
--
Key: MPLUGIN-90
URL: http://jira.codehaus.org/browse/MPLUGIN-90
Project: Maven 2.x Plugin Tools
Issue Type: Improvement
Reporter: Benjamin Bentmann
Attachments: valid-html.patch
The current approach for MPLUGIN-43 and especially MPLUGIN-73 is suboptimal:
These changes are limited to the {{PluginXDocGenerator}} although other
components have similar needs (e.g. {{PluginReport}} from the
maven-plugin-plugin which needs to print the mojo description, too).
The patch suggests to move {{makeHtmlValid()}} and {{decodeJavadocTags()}} into
{{PluginUtils}} for better reusage among {{PluginXdocGenerator}} and
{{PluginReport}}. Alternatively, these functions could be employed by the
descriptor extractors instead of the report generators to beautify the strings
right at the beginning of their processing, making them out-of-the-box viewable
in beautified format for all consumers of the mojo descriptor.
--
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-3444) Set "Fix Version" for MNG-1508 to 2.0.5
Set "Fix Version" for MNG-1508 to 2.0.5 --- Key: MNG-3444 URL: http://jira.codehaus.org/browse/MNG-3444 Project: Maven 2 Issue Type: Sub-task Components: Documentation: General Reporter: Benjamin Bentmann Priority: Trivial According to the [release notes for 2.0.5|http://maven.apache.org/release-notes.html], the new lifecycle phase "process-test-classes" is present since Maven 2.0.5. It's definitively in Maven 2.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] Created: (MNG-3445) Document missing default lifecycle phases
Document missing default lifecycle phases - Key: MNG-3445 URL: http://jira.codehaus.org/browse/MNG-3445 Project: Maven 2 Issue Type: Sub-task Components: Documentation: Introductions Reporter: Benjamin Bentmann Priority: Trivial Attachments: missing-lifecycle-phases.patch Since [r233021|http://svn.apache.org/viewvc?view=rev&revision=233021] a phase "initialize" and since [r470432|http://svn.apache.org/viewvc?view=rev&revision=470432] a phase "process-test-classes" exist which are not yet documented. -- 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-3445) Document missing default lifecycle phases
[ http://jira.codehaus.org/browse/MNG-3445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126396 ] Benjamin Bentmann commented on MNG-3445: NOTE: The patch is incomplete, I have no precise understanding what "initialize" is intended for and hence can't provide doc for it. > Document missing default lifecycle phases > - > > Key: MNG-3445 > URL: http://jira.codehaus.org/browse/MNG-3445 > Project: Maven 2 > Issue Type: Sub-task > Components: Documentation: Introductions >Reporter: Benjamin Bentmann >Priority: Trivial > Attachments: missing-lifecycle-phases.patch > > > Since [r233021|http://svn.apache.org/viewvc?view=rev&revision=233021] a phase > "initialize" and since > [r470432|http://svn.apache.org/viewvc?view=rev&revision=470432] a phase > "process-test-classes" exist which are not yet documented. -- 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: (MPA-107) Add a new Jira project for Plugin Tools
Add a new Jira project for Plugin Tools --- Key: MPA-107 URL: http://jira.codehaus.org/browse/MPA-107 Project: Maven Project Administration Issue Type: Task Components: Issue Management Affects Versions: 2008-q1 Reporter: Vincent Siveton Maven project https://svn.apache.org/repos/asf/maven/plugin-tools/trunk Proposal for the Jira project MPLUGINTOOLS -- 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-3444) Set "Fix Version" for MNG-1508 to 2.0.5
[ http://jira.codehaus.org/browse/MNG-3444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3444: -- Issue Type: Bug (was: Sub-task) Parent: (was: MNG-1508) > Set "Fix Version" for MNG-1508 to 2.0.5 > --- > > Key: MNG-3444 > URL: http://jira.codehaus.org/browse/MNG-3444 > Project: Maven 2 > Issue Type: Bug > Components: Issue Management >Reporter: Benjamin Bentmann >Priority: Trivial > > According to the [release notes for > 2.0.5|http://maven.apache.org/release-notes.html], the new lifecycle phase > "process-test-classes" is present since Maven 2.0.5. It's definitively in > Maven 2.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] Moved: (MPA-108) Set "Fix Version" for MNG-1508 to 2.0.5
[ http://jira.codehaus.org/browse/MPA-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-3444 to MPA-108: --- Reporter: Brett Porter (was: Benjamin Bentmann) Component/s: (was: Documentation: General) Issue Management Key: MPA-108 (was: MNG-3444) Project: Maven Project Administration (was: Maven 2) > Set "Fix Version" for MNG-1508 to 2.0.5 > --- > > Key: MPA-108 > URL: http://jira.codehaus.org/browse/MPA-108 > Project: Maven Project Administration > Issue Type: Bug > Components: Issue Management >Reporter: Brett Porter >Priority: Trivial > > According to the [release notes for > 2.0.5|http://maven.apache.org/release-notes.html], the new lifecycle phase > "process-test-classes" is present since Maven 2.0.5. It's definitively in > Maven 2.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] Commented: (MPA-108) Set "Fix Version" for MNG-1508 to 2.0.5
[ http://jira.codehaus.org/browse/MPA-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126397 ] Brett Porter commented on MPA-108: -- I have also added you to the developers in JIRA. > Set "Fix Version" for MNG-1508 to 2.0.5 > --- > > Key: MPA-108 > URL: http://jira.codehaus.org/browse/MPA-108 > Project: Maven Project Administration > Issue Type: Bug > Components: Issue Management >Reporter: Brett Porter >Priority: Trivial > > According to the [release notes for > 2.0.5|http://maven.apache.org/release-notes.html], the new lifecycle phase > "process-test-classes" is present since Maven 2.0.5. It's definitively in > Maven 2.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: (MNG-1508) Need a process-test-classes phase
[ http://jira.codehaus.org/browse/MNG-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-1508: -- Fix Version/s: (was: 2.1-alpha-1) 2.0.5 > Need a process-test-classes phase > - > > Key: MNG-1508 > URL: http://jira.codehaus.org/browse/MNG-1508 > Project: Maven 2 > Issue Type: Improvement > Components: Design, Patterns & Best Practices >Affects Versions: 2.0 >Reporter: Mike Perham >Assignee: Kenney Westerhof > Fix For: 2.0.5 > > > The compile phase has a process-classes phase after it to do instrumentation. > The test-compile phase should have a similar phase after it also. -- 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: (MPA-108) Set "Fix Version" for MNG-1508 to 2.0.5
[ http://jira.codehaus.org/browse/MPA-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MPA-108. Resolution: Fixed > Set "Fix Version" for MNG-1508 to 2.0.5 > --- > > Key: MPA-108 > URL: http://jira.codehaus.org/browse/MPA-108 > Project: Maven Project Administration > Issue Type: Bug > Components: Issue Management >Reporter: Brett Porter >Priority: Trivial > > According to the [release notes for > 2.0.5|http://maven.apache.org/release-notes.html], the new lifecycle phase > "process-test-classes" is present since Maven 2.0.5. It's definitively in > Maven 2.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] Commented: (MPA-108) Set "Fix Version" for MNG-1508 to 2.0.5
[ http://jira.codehaus.org/browse/MPA-108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126398 ] Benjamin Bentmann commented on MPA-108: --- Hm, I see, lot's of new gizmos in JIRA ;-) > Set "Fix Version" for MNG-1508 to 2.0.5 > --- > > Key: MPA-108 > URL: http://jira.codehaus.org/browse/MPA-108 > Project: Maven Project Administration > Issue Type: Bug > Components: Issue Management >Reporter: Brett Porter >Priority: Trivial > > According to the [release notes for > 2.0.5|http://maven.apache.org/release-notes.html], the new lifecycle phase > "process-test-classes" is present since Maven 2.0.5. It's definitively in > Maven 2.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] Created: (MPA-109) Enable wiki renderer for MNG
Enable wiki renderer for MNG Key: MPA-109 URL: http://jira.codehaus.org/browse/MPA-109 Project: Maven Project Administration Issue Type: Wish Components: Issue Management Reporter: Benjamin Bentmann Priority: Trivial I'm not sure whether there is some deeper reason but the JIRA project MNG does not allow wiki-style markup in issue descriptions (see also [Wiki Renderer for MNG|http://www.nabble.com/Wiki-Renderer-for-MNG-to14649763s177.html#a14649763]. This renderer would allow users to create better readable issues. -- 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: (MPLUGIN-91) misleading icon on list of goals
misleading icon on list of goals Key: MPLUGIN-91 URL: http://jira.codehaus.org/browse/MPLUGIN-91 Project: Maven 2.x Plugin Tools Issue Type: Bug Components: Plugin Plugin Reporter: Tomasz Pik Priority: Minor There's a column on 'list of goals' report page, indicating if given goal is a report of not. And for those, that are not a report 'red alert' icon is used. This will lead users to confusion because this page generated for plugin providing many mojos that are not reports will look like JUnit report with many failures. Please, change it to something different. Maybe, instead of "report: yes/no" this column should be named 'mojo type' and current 'green' mojos will have 'report' there while current 'red' mojos will have 'executable' there? -- 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: (ARCHETYPE-146) Archetype Resources not being processed on Windows.
Archetype Resources not being processed on Windows. Key: ARCHETYPE-146 URL: http://jira.codehaus.org/browse/ARCHETYPE-146 Project: Maven Archetype Issue Type: Bug Components: Archetypes Affects Versions: 2.0-alpha-2 Environment: Windows XP Reporter: Rob Evans We created an archetype, built and installed it on a windows machine. When we used it on the same machine, the project was created but did not have the src/ directory. When we built it on a unix system and ran it on a windows box it worked properly. Looks like a problem processing the resources. Maybe a path issue? $ mvn --version Maven version: 2.0.7 Java version: 1.6.0_02 OS name: "windows xp" version: "5.1" arch: "x86" Define value for package: : d Confirm properties configuration: groupId: d artifactId: d version: d package: d Y: : [DEBUG] OldArchetype generation configuration confirmed [DEBUG] archetype.cci.struts: using locally installed snapshot [DEBUG] archetype.cci.struts: using locally installed snapshot [DEBUG] No found META-INF/maven/archetype-metadata.xml retrying with windows path [DEBUG] archetype.cci.struts: using locally installed snapshot [DEBUG] No found META-INF/maven/archetype-metadata.xml retrying with windows path [DEBUG] Found resource archetype-resources\pom.xml [DEBUG] Found resource archetype-resources\src\main\webapp\index.jsp [DEBUG] Found resource archetype-resources\src\main\webapp\WEB-INF\web.xml [DEBUG] Not resource META-INF\maven\archetype-metadata.xml [DEBUG] Not resource META-INF\maven\archetype.xml [DEBUG] Processing complete archetype app [DEBUG] Processing d [DEBUG] Processing pom C:\DOCUME~1\robevans\NX73F8~1\temp\d\pom.xml [DEBUG] Prosessing template archetype-resources\pom.xml [DEBUG] Merging into C:\DOCUME~1\robevans\NX73F8~1\temp\d\pom.xml [DEBUG] Processing filesets [DEBUG] Processing fileset src/main/webapp (Filtered-Flat) [**/*.jsp, **/*.xml -- ] [] [archetype-resources\pom.xml, archetype-resources\src\main\webapp\index.jsp, archetype-resources\src\main\webapp\WEB-INF\web.xml] [DEBUG] Processed 0 files [DEBUG] Processed d [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 11 seconds [INFO] Finished at: Thu Mar 06 21:05:31 GMT-02:00 2008 [INFO] Final Memory: 7M/13M [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] Created: (MNG-3446) Tweak lifecylce intro
Tweak lifecylce intro - Key: MNG-3446 URL: http://jira.codehaus.org/browse/MNG-3446 Project: Maven 2 Issue Type: Sub-task Components: Documentation: General Reporter: Benjamin Bentmann Priority: Trivial Attachments: lifecycle-docs.patch Fixed some technical errors, typos, style. -- 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: (MANTRUN-82) skip test
[ http://jira.codehaus.org/browse/MANTRUN-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Lambert closed MANTRUN-82. - Resolution: Fixed Fix Version/s: 1.2 It's working fine in 1.2-snapshot. Sorry for the confusion. > skip test > - > > Key: MANTRUN-82 > URL: http://jira.codehaus.org/browse/MANTRUN-82 > Project: Maven 2.x Antrun Plugin > Issue Type: Bug >Affects Versions: 1.1 > Environment: Windows, java version "1.5.0_11" >Reporter: Pascal Lambert >Priority: Minor > Fix For: 1.2 > > Attachments: build.xml, pom.xml, pom.xml > > > Given the attach pom.xml and build.xml config, I would have expect that > running "mvn install -DskipTests" would skip the execution of the ant test > target. Did I missed something? -- 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-3447) Enterprise Repository Architecture and Release Process
Enterprise Repository Architecture and Release Process -- Key: MNG-3447 URL: http://jira.codehaus.org/browse/MNG-3447 Project: Maven 2 Issue Type: Wish Components: Design, Patterns & Best Practices Reporter: sachin kamdar Priority: Minor We implemented Maven last year in our Organization, overall we are satisfied with the tool however, as we migrate more and more applications to Maven we are facing some daunting challenges. We have roughly 500 maven projects for 150 odd applications (ears), using the concept of Super POMS and Dependency Management to create a layer of abstraction for commonly used artifacts, plugins and properties However, despite of this abstraction we still have fairly deep dependency graph. And since we have component base Application Architecture the impact of a change in common, low level component which is not managed from Super Pom is huge. A change in the low level pom means we have to change entire pom hierarchies. In some cases it means changing upto 400 pom files. This issue has now become so contentious that we have created a Project to re-structure and re-architect Maven. As far as our Release Cycle goes, we release in test environment from which we go through the bug fixing cycle, once all the bugs are fixed then the artifacts are pushed into pre-prod and prod. Now because the artifact is released into Test envt, any code change for bug fixes will force a pom version change. This will trigger a change in the entire project hierarchy from core->ejb->war->ear. As a result our release cycles have become really slow. We are looking at options to reduce a) the impact of change in the low level artifact and b) ability to release quickly. We looked at version ranges as an options but it would only partly solved the problem, as we still get pinned versions into manifest files. Other alternative was to release snapshots into Test Environment. Only pitfall with this option is that once the bug fixing cycle is over we'll have to release and build again. This, at present is against our company policy but personally I don't see any fuss with it I was wondering if anyone has any recommendations for, 1. What is the recommended Maven Repository Architecture for Organizations with Application Architecture such as ours 2. Is there a 'best practice' for Releasing Maven Enterprise projects. (from dev->test->pre->prod->prod) 3. Is there a Dependency Graph type of tool (not like site - dependencies report) which can display 'what depends on me' for each and every artifact in the hierarchy? We use WebSphere on Linux and most of our projects have ear-->wars-->ejbs-->cores type of structure. We also have whole heap of business services deployed as ear-->ejb-->core, which gets used by other application. -- 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-2583) DefaultArtifact: Method getVersionRange returns null also if field version is already set! [SMALL PATCH ATTACHED]
[ http://jira.codehaus.org/browse/MNG-2583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126417 ] Martin Zeltner commented on MNG-2583: - I can reproduce the problem, so problem must be fixed. Just add the lines in method "getVersionRange". Cheers, Martin > DefaultArtifact: Method getVersionRange returns null also if field version is > already set! [SMALL PATCH ATTACHED] > - > > Key: MNG-2583 > URL: http://jira.codehaus.org/browse/MNG-2583 > Project: Maven 2 > Issue Type: Improvement > Components: Artifacts and Repositories >Affects Versions: 2.0-alpha-1 > Environment: Java5, WinXp >Reporter: Martin Zeltner >Assignee: Jason van Zyl > Fix For: 2.0.10 > > Attachments: patch_maven-artifact_made-getVersionRange-saver.patch > > > In class *org.apache.maven.artifact.DefaultArtifact* method *getVersionRange* > returns *null* altough the version field is already set. In attached patch I > check in method getVersionRange if versionRange is null if field version or > baseVersion is already set and then create the versionRange by using > version/baseVersion. By the way I've replaced HashMap with a LinkedHashMap to > remember the insertion order of meta data. > For those who don't see why this patch is needed can try binding the eclipse > plugin to a phase before the jar plugin is bound. The eclipse plugin uses the > org.apache.maven.artifact.resolver.DefaultArtifactCollector which is invoking > method setVersion of org.apache.maven.artifact.DefaultArtifact which will > erase field version range and cause a NullPointerException in plugin jar that > doesn't check if returned version range is null. > Cheers, > Martin -- 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
