[jira] Commented: (MNG-3685) Dependency can't be resolved but has been found in the reactor.
[ http://jira.codehaus.org/browse/MNG-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199689#action_199689 ] Anthony Whitford commented on MNG-3685: --- I seem to be experiencing this problem with the latest Javadoc plugin. I would characterize the issue as a *Blocker*! > Dependency can't be resolved but has been found in the reactor. > --- > > Key: MNG-3685 > URL: http://jira.codehaus.org/browse/MNG-3685 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 >Reporter: Jörg Hohwiller > Fix For: 2.2.2 > > Attachments: sample-MNG-3685.tgz > > > Since I upgraded maven to 2.0.9, I get messages like the following endlessly: > Downloading: > http://m-m-m.sourceforge.net/repository/net/sf/m-m-m/mmm-util-core/1.0.2-SNAPSHOT/mmm-util-core-1.0.2-SNAPSHOT.jar > [WARNING] The dependency: net.sf.m-m-m:mmm-util-core:jar:1.0.2-SNAPSHOT can't > be resolved but has been found in the reactor. > This dependency has been excluded from the plugin execution. You should rerun > this mojo after executing mvn install. > This also happens, if someone checks out the project and does "mvn > eclipse:eclipse". The process still works but takes extraordinary long to > proceed because it scales about n^2 with n beiing the number of modules in > your reactor. > You should also take into account that "mvn install" aborts if some tests > fail. > Sorry to say so, but this behaviour of maven is absolutely inacceptable. I > hope there is a chance to fix this in the next release(s). Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAVADOC-276) Initial builds of a multi-module project fail
[
http://jira.codehaus.org/browse/MJAVADOC-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199687#action_199687
]
Anthony Whitford commented on MJAVADOC-276:
---
Is this related to MNG-3685 or MJAVADOC-116?
> Initial builds of a multi-module project fail
> -
>
> Key: MJAVADOC-276
> URL: http://jira.codehaus.org/browse/MJAVADOC-276
> Project: Maven 2.x Javadoc Plugin
> Issue Type: Bug
>Affects Versions: 2.6.1
> Environment: Java jdk1.6.0_16, Maven 2.2.1, Windows Vista 64-bit
> Java jdk1.6.0_05, Maven 2.0.9, Windows XP 32-bit
>Reporter: Anthony Whitford
>Priority: Blocker
> Attachments: bug.zip
>
>
> I ran into a problem using Maven Javadoc Plugin 2.6.1 right after I
> released... I went from version 1.15 to 1.16-SNAPSHOT, and my 1.16-SNAPSHOT
> build failed ({{mvn clean install site}}) because Javadoc fails when run from
> the top-level parent. When it is building _module A_, the javadoc complains
> that _module B_ and _module C_ are missing -- of course they are, they
> haven't been built yet. Note that running {{mvn clean install}} from _module
> A_ works fine -- the behavior is limited to running from the top-level parent
> -- AND, if you run a {{mvn install}} for _module B_ and _module C_, then you
> have given it what it needs and so you won't see the error.
> The attached example exhibits the problem. It was created from the
> _j2ee-simple_ archetype -- I only added the explicit javadoc plugin
> declaration to the top level pom to control the version being used. To
> recreate the problem, unzip and simply: {{mvn clean install site}}. You
> will get an error message like:
> {noformat}
> [INFO] Unable to find resource 'root.project.projects:logging:jar:1.0' in
> repository central (http://repo1.maven.org/maven2)
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> Missing:
> --
> 1) root.project.projects:logging:jar:1.0
> Try downloading the file manually from the project website.
> Then, install it using the command:
> mvn install:install-file -DgroupId=root.project.projects
> -DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
> Alternatively, if you host your own repository you can deploy the file
> there:
> mvn deploy:deploy-file -DgroupId=root.project.projects
> -DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
> -Durl=[url] -DrepositoryId=
> [id]
> Path to dependency:
> 1) root.project:primary-source:jar:1.0
> 2) root.project.projects:logging:jar:1.0
> --
> 1 required artifact is missing.
> for artifact:
> root.project:primary-source:jar:1.0
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> {noformat}
> As you can see, it seems to think that a submodule (in this case
> {{root.project.projects:logging:jar:1.0}}) is necessary to build the javadoc
> for the project... Since this is the first time that this is being built,
> the submodule does not exist (yet).
> I have replicated this problem on two different computing environments, so
> I'm convinced that the Maven version is not relevant.
> (It is unclear to me if this problem also existed with Javadoc 2.6, but I
> don't think so.)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MJAVADOC-276) Initial builds of a multi-module project fail
Initial builds of a multi-module project fail
-
Key: MJAVADOC-276
URL: http://jira.codehaus.org/browse/MJAVADOC-276
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.6.1
Environment: Java jdk1.6.0_16, Maven 2.2.1, Windows Vista 64-bit
Java jdk1.6.0_05, Maven 2.0.9, Windows XP 32-bit
Reporter: Anthony Whitford
Priority: Blocker
Attachments: bug.zip
I ran into a problem using Maven Javadoc Plugin 2.6.1 right after I released...
I went from version 1.15 to 1.16-SNAPSHOT, and my 1.16-SNAPSHOT build failed
({{mvn clean install site}}) because Javadoc fails when run from the top-level
parent. When it is building _module A_, the javadoc complains that _module B_
and _module C_ are missing -- of course they are, they haven't been built yet.
Note that running {{mvn clean install}} from _module A_ works fine -- the
behavior is limited to running from the top-level parent -- AND, if you run a
{{mvn install}} for _module B_ and _module C_, then you have given it what it
needs and so you won't see the error.
The attached example exhibits the problem. It was created from the
_j2ee-simple_ archetype -- I only added the explicit javadoc plugin declaration
to the top level pom to control the version being used. To recreate the
problem, unzip and simply: {{mvn clean install site}}. You will get an error
message like:
{noformat}
[INFO] Unable to find resource 'root.project.projects:logging:jar:1.0' in
repository central (http://repo1.maven.org/maven2)
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) root.project.projects:logging:jar:1.0
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=root.project.projects
-DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file there:
mvn deploy:deploy-file -DgroupId=root.project.projects
-DartifactId=logging -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file
-Durl=[url] -DrepositoryId=
[id]
Path to dependency:
1) root.project:primary-source:jar:1.0
2) root.project.projects:logging:jar:1.0
--
1 required artifact is missing.
for artifact:
root.project:primary-source:jar:1.0
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
{noformat}
As you can see, it seems to think that a submodule (in this case
{{root.project.projects:logging:jar:1.0}}) is necessary to build the javadoc
for the project... Since this is the first time that this is being built, the
submodule does not exist (yet).
I have replicated this problem on two different computing environments, so I'm
convinced that the Maven version is not relevant.
(It is unclear to me if this problem also existed with Javadoc 2.6, but I don't
think so.)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MCHANGES-149) -DfromDeveloperId does not work if developers are setted in the parent pom
[ http://jira.codehaus.org/browse/MCHANGES-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199672#action_199672 ] Alexandre Navarro commented on MCHANGES-149: Ok thanks. I will test it. > -DfromDeveloperId does not work if developers are setted in the parent pom > -- > > Key: MCHANGES-149 > URL: http://jira.codehaus.org/browse/MCHANGES-149 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: announcement >Affects Versions: 2.0 > Environment: Windows or Linux >Reporter: Alexandre Navarro > > -DfromDeveloperId does not work if developers are setted in the parent pom. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-20) Don't create empty jars
[ http://jira.codehaus.org/browse/MJAR-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199659#action_199659 ] Alexandre Navarro commented on MJAR-20: --- Some news of including this patch in the next release? Alexandre > Don't create empty jars > --- > > Key: MJAR-20 > URL: http://jira.codehaus.org/browse/MJAR-20 > Project: Maven 2.x Jar Plugin > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Carlos Sanchez >Priority: Minor > Attachments: MJAR-20-02.patch, MJAR-20.patch > > > Creating empty jars is confusing, it should just print a warning > use case: > parent pom attaching test jar, some subprojects may not have tests, why > create jars for them? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MCHANGES-173) Failed to generate report when version is not the last schedule.
[
http://jira.codehaus.org/browse/MCHANGES-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199654#action_199654
]
Christophe Lallement commented on MCHANGES-173:
---
Hi Dennis,
All release together we have more than 25 entries, but concerning the 1.3.0
just 2-3 issues.
So i'll do the test asap.
> Failed to generate report when version is not the last schedule.
>
>
> Key: MCHANGES-173
> URL: http://jira.codehaus.org/browse/MCHANGES-173
> Project: Maven 2.x Changes Plugin
> Issue Type: Bug
> Components: announcement, jira-report
>Affects Versions: 2.1
>Reporter: Christophe Lallement
>Priority: Critical
>
> We try to release a snapshot version (1.2.3-SNAPSHOT) but this version is not
> define as last release into JIRA version.
> into JIRA we have define version as this (by schedule order)
> * 1.3.0
> * 1.2.3
> * 1.2.2
>
> When we try to generate jira report for e version 1.2.3-SNAPSHOT we have this
> error: (i don't if it occurs during jira report or annoucement)
> PS: if i schedule 1.2.3 in first position into JIRa, it works fine.
> {code}...
> [DEBUG] Default ResourceManager initialization complete.
> [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
> [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
> [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
> [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Include
> [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
> [DEBUG] Created '20' parsers.
> [DEBUG] Velocimacro : initialization starting.
> [DEBUG] Velocimacro : allowInline = true : VMs can be defined inline in
> templates
> [DEBUG] Velocimacro : allowInlineToOverride = false : VMs defined inline may
> NOT replace previous VM definitions
> [DEBUG] Velocimacro : allowInlineLocal = false : VMs defined inline will be
> global in scope if allowed.
> [DEBUG] Velocimacro : autoload off : VM system will not automatically reload
> global library macros
> [DEBUG] Velocimacro : Velocimacro : initialization complete.
> [DEBUG] RuntimeInstance successfully initialized.
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-changes-plugin:2.1:announcement-generate' -->
> [DEBUG] (s) artifactId = feedapi
> [DEBUG] (f) basedir = C:\HOMEWARE\eclipse-341\workspace\feedapi
> [DEBUG] (s) developmentTeam = vol-domino-feedapi team
> [DEBUG] (s) finalName = feedapi-1.2.3-SNAPSHOT
> [DEBUG] (f) generateJiraAnnouncement = true
> [DEBUG] (s) groupId = ged.domino
> [DEBUG] (s) introduction = FeedAPI is a framework to send feed between
> component (In and Out process) with high frequency const
> aint
> [DEBUG] (f) jiraMerge = false
> [DEBUG] (f) jiraXML =
> C:\HOMEWARE\eclipse-341\workspace\feedapi\target\jira-announcement.xml
> [DEBUG] (f) maxEntries = 25
> [DEBUG] (s) outputDirectory =
> C:\HOMEWARE\eclipse-341\workspace\feedapi\target\announcement
> [DEBUG] (s) packaging = jar
> [DEBUG] (f) project = MavenProject: ged.domino:feedapi:1.2.3-SNAPSHOT @
> C:\HOMEWARE\eclipse-341\workspace\feedapi\pom.xml
> [DEBUG] (f) resolutionIds = Fixed
> [DEBUG] (f) settings = org.apache.maven.settings.setti...@1eb62b6
> [DEBUG] (f) statusIds = Closed
> [DEBUG] (f) template = feedapi-announcement.vm
> [DEBUG] (f) templateDirectory = our-announcements
> [DEBUG] (s) url = http://frontools/maven_site/domino-parent/feedapi
> [DEBUG] (s) version = 1.2.3-SNAPSHOT
> [DEBUG] (s) xmlPath =
> C:\HOMEWARE\eclipse-341\workspace\feedapi\src\changes\changes.xml
> [DEBUG] -- end configuration --
> [INFO] [changes:announcement-generate {execution: announcement-generate}]
> [DEBUG] JIRA lives at: https://jtbox.fr.world.socgen/jira
> [DEBUG] The JIRA URL https://jtbox.fr.world.socgen/jira/browse/TRAFEEDAPI
> doesn't include a pid, trying to extract it from JIRA.
> [DEBUG] Successfully reached JIRA.
> 26 ao¹t 2009 10:54:10 org.apache.commons.httpclient.HttpMethodBase
> getResponseBody
> ATTENTION: Going to buffer response body of large or unknown size. Using
> getResponseBodyAsStream instead is recommended.
> [DEBUG] Found the pid 10236 at
> https://jtbox.fr.world.socgen/jira/browse/TRAFEEDAPI
> [ERROR] maven-changes-plugin: None of the configured sortColumnNames 'null'
> are correct.
> [DEBUG] download jira issues from url
> https://jtbox.fr.world.socgen/jira/secure/IssueNavigator.jspa?view=rss&pid=10236&statusIds=
> &resolutionIds=1&tempMax=25&reset=true&decorator=none
> [INFO] Downloading from JIRA at:
> https://jtbox.fr.world.socgen/jira/secure/IssueNavigator.jspa?view=rss&pid=10236&statusIds=6&res
> lutionIds=1&tempMax=25&reset=true&decorator=none
> 26 ao¹t 2009 10:54:10 org.apache.commons.httpclient.HttpMe
[jira] Commented: (MJAR-132) Test jar is generated on mvn install or deploy when the type of artifact is pom (and herited by a parent pom)
[ http://jira.codehaus.org/browse/MJAR-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199652#action_199652 ] Alexandre Navarro commented on MJAR-132: You can close it because it is duplicate with http://jira.codehaus.org/browse/MJAR-20 > Test jar is generated on mvn install or deploy when the type of artifact is > pom (and herited by a parent pom) > - > > Key: MJAR-132 > URL: http://jira.codehaus.org/browse/MJAR-132 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Alexandre Navarro > Attachments: maven-jar-plugin-issue.zip > > > Test jar is generated on mvn install or deploy when the type of artifact is > pom (and herited by a parent pom). > I added jar plugin in a parent in my enterprise to force project to add test > jar but it is so painful to have test jar where there is no jar. > I let a sample to show the issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MECLIPSE-622) mvn eclipse:eclipse fails or doesn't generate proper .classpath when specifying the same resource directory with different filtering rules
[
http://jira.codehaus.org/browse/MECLIPSE-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Thivent closed MECLIPSE-622.
---
Resolution: Duplicate
> mvn eclipse:eclipse fails or doesn't generate proper .classpath when
> specifying the same resource directory with different filtering rules
> --
>
> Key: MECLIPSE-622
> URL: http://jira.codehaus.org/browse/MECLIPSE-622
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
> (.classpath)
>Affects Versions: 2.6, 2.7
> Environment: GNU/Linux (Ubuntu 9.10), Java 6u16, maven 2.2.1
>Reporter: Pascal Thivent
> Attachments: maven-eclipse-plugin-resources-testcase.zip
>
>
> Let's say I have a resource directory ({{src/main/resources}}) that contains
> properties and XML and want to filter {{.properties}} only. My pom.xml is
> setup as follow:
> {code:xml}
>
>
>
> src/main/resources
> true
>
> **/*.properties
>
>
>
> src/main/resources
> false
>
> **/*.properties
>
>
>
>
>
> org.apache.maven.plugins
> maven-eclipse-plugin
> 2.7
>
>
>
> {code}
> This works fine when running maven on the command line. However, when I run
> {{mvn eclipse:eclipse}} with the eclipse plugin 2.7, the build just fails:
> {code}
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Request to merge when 'filtering' is not identical. Original=resource
> src/main/resources: output=target/classes, include=[**/*.properties],
> exclude=[**/*.java], test=false, filtering=true, merging with=resource
> src/main/resources: output=target/classes, include=[],
> exclude=[**/*.properties|**/*.java], test=false, filtering=false
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 2 seconds
> [INFO] Finished at: Wed Nov 25 18:47:32 CET 2009
> [INFO] Final Memory: 8M/79M
> [INFO]
>
> {code}
> With the maven eclipse plugin version 2.6, the build passes but the
> {{.classpath}} doesn't contain the expected informations in the {{including}}
> attribute of the classpathentry {{src/main/resources}}, XML files are not
> included in the actual result:
> {{code:xml}}
>
>output="target/test-classes" including="**/*.java"/>
>
>including="**/*.properties" excluding="**/*.java"/>
>
>sourcepath="M2_REPO/junit/junit/3.8.1/junit-3.8.1-sources.jar"/>
>
>
> {{code}}
> I'm not really sure what the expected result should be (should the union of
> {{**/*.properties}} and all other files that are not {{**/*.properties}} be
> {{**/*.*}}?) but the actual result is not correct.
> Specifying sourceIncludes/sourcesExcludes (as documented
> [here|http://maven.apache.org/plugins/maven-eclipse-plugin/examples/specifying-source-path-inclusions-and-exclusions.html]
> doesn't help (and it's not clear to me if it's the right things to do).
> For now, I'm using the following setup (I've split filtered and non filtered
> resources into separate directories) as workaround:
> {{code:xml}}
>
>
> src/main/resources1
> true
>
> **/*.properties
>
>
>
> src/main/resources2
> false
>
> **/*.xml
>
>
>
> {{code}}
> But still, there is clearly a regression between versions prior to 2.7 and
> 2.7. I'm attaching a project allowing to reproduce this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-622) mvn eclipse:eclipse fails or doesn't generate proper .classpath when specifying the same resource directory with different filtering rules
mvn eclipse:eclipse fails or doesn't generate proper .classpath when specifying
the same resource directory with different filtering rules
--
Key: MECLIPSE-622
URL: http://jira.codehaus.org/browse/MECLIPSE-622
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: Core : Dependencies resolution and build path (.classpath)
Affects Versions: 2.6, 2.7
Environment: GNU/Linux (Ubuntu 9.10), Java 6u16, maven 2.2.1
Reporter: Pascal Thivent
Attachments: maven-eclipse-plugin-resources-testcase.zip
Let's say I have a resource directory ({{src/main/resources}}) that contains
properties and XML and want to filter {{.properties}} only. My pom.xml is setup
as follow:
{code:xml}
src/main/resources
true
**/*.properties
src/main/resources
false
**/*.properties
org.apache.maven.plugins
maven-eclipse-plugin
2.7
{code}
This works fine when running maven on the command line. However, when I run
{{mvn eclipse:eclipse}} with the eclipse plugin 2.7, the build just fails:
{code}
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Request to merge when 'filtering' is not identical. Original=resource
src/main/resources: output=target/classes, include=[**/*.properties],
exclude=[**/*.java], test=false, filtering=true, merging with=resource
src/main/resources: output=target/classes, include=[],
exclude=[**/*.properties|**/*.java], test=false, filtering=false
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 2 seconds
[INFO] Finished at: Wed Nov 25 18:47:32 CET 2009
[INFO] Final Memory: 8M/79M
[INFO]
{code}
With the maven eclipse plugin version 2.6, the build passes but the
{{.classpath}} doesn't contain the expected informations in the {{including}}
attribute of the classpathentry {{src/main/resources}}, XML files are not
included in the actual result:
{{code:xml}}
{{code}}
I'm not really sure what the expected result should be (should the union of
{{**/*.properties}} and all other files that are not {{**/*.properties}} be
{{**/*.*}}?) but the actual result is not correct.
Specifying sourceIncludes/sourcesExcludes (as documented
[here|http://maven.apache.org/plugins/maven-eclipse-plugin/examples/specifying-source-path-inclusions-and-exclusions.html]
doesn't help (and it's not clear to me if it's the right things to do).
For now, I'm using the following setup (I've split filtered and non filtered
resources into separate directories) as workaround:
{{code:xml}}
src/main/resources1
true
**/*.properties
src/main/resources2
false
**/*.xml
{{code}}
But still, there is clearly a regression between versions prior to 2.7 and 2.7.
I'm attaching a project allowing to reproduce this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-132) Test jar is generated on mvn install or deploy when the type of artifact is pom (and herited by a parent pom)
[ http://jira.codehaus.org/browse/MJAR-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199649#action_199649 ] Alexandre Navarro commented on MJAR-132: The problem exists also you package the parent pom. > Test jar is generated on mvn install or deploy when the type of artifact is > pom (and herited by a parent pom) > - > > Key: MJAR-132 > URL: http://jira.codehaus.org/browse/MJAR-132 > Project: Maven 2.x Jar Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Alexandre Navarro > Attachments: maven-jar-plugin-issue.zip > > > Test jar is generated on mvn install or deploy when the type of artifact is > pom (and herited by a parent pom). > I added jar plugin in a parent in my enterprise to force project to add test > jar but it is so painful to have test jar where there is no jar. > I let a sample to show the issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MCHANGES-136) Amend (HTML) docs to reflect new features introduced with release 2.1
[ http://jira.codehaus.org/browse/MCHANGES-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-136. Resolution: Not A Bug All xml elements and attributes are described on this page: http://maven.apache.org/plugins/maven-changes-plugin/changes.html > Amend (HTML) docs to reflect new features introduced with release 2.1 > - > > Key: MCHANGES-136 > URL: http://jira.codehaus.org/browse/MCHANGES-136 > Project: Maven 2.x Changes Plugin > Issue Type: Wish > Components: changes-report >Affects Versions: 2.1 >Reporter: Werner Guttmann >Priority: Minor > > Various sections should be updated to reflect e.g. the new features > introduced with release 2.1. This includes - amongst others - the new XML > artefacts added to and . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MCHANGES-152) page encoding ISO-8859-1 not definable
[ http://jira.codehaus.org/browse/MCHANGES-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-152. Resolution: Not A Bug > page encoding ISO-8859-1 not definable > -- > > Key: MCHANGES-152 > URL: http://jira.codehaus.org/browse/MCHANGES-152 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: changes-report >Affects Versions: 2.1 > Environment: Windows XP, Maven 2.09 >Reporter: Bruno Marti > Attachments: changes-report.zip, screenshot-1.jpg > > > Neither property > ISO-8859-1 > > nor ISO-8859-1 is > accepted for report generation (changes:changes-report). > German characters like 'äöü' are misinterpreted. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MCHANGES-135) JIRA links on changes report are broken
[ http://jira.codehaus.org/browse/MCHANGES-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-135. Resolution: Fixed Fix Version/s: 2.3 Assignee: Dennis Lundberg The URL to the issue tracker is dependent on both which issue tracker you use and also on which version of the issue tracker you use. For the version of JIRA that is at Codehaus you should use this configuration string: %URL%/%ISSUE% I have added that to the plugins own configuration, so that the link will be correct on the site in the next version. Added in [r884601|http://svn.apache.org/viewvc?view=revision&revision=884601]. > JIRA links on changes report are broken > --- > > Key: MCHANGES-135 > URL: http://jira.codehaus.org/browse/MCHANGES-135 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: changes-report >Affects Versions: 2.0 >Reporter: Martin Ellis >Assignee: Dennis Lundberg > Fix For: 2.3 > > > See the sample changes report for an example of what I mean: > http://maven.apache.org/plugins/maven-changes-plugin/changes-report.html > The link to MPJIRA-11 on this page is broken - it points to the following > page, which is an error message: > http://jira.codehaus.org/browse/ViewIssue.jspa?key=MPJIRA-11 > This appears to be because the issueLinkTemplate has an inappropriate default > value: > %URL%/ViewIssue.jspa?key=%ISSUE% > according to > http://maven.apache.org/plugins/maven-changes-plugin/changes-report-mojo.html > A default value of of %URL%/%ISSUE% would result in the following link, which > does work: > http://jira.codehaus.org/browse/MPJIRA-11 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MCHANGES-155) When an empty element is present in changes.xml the parser fails
[ http://jira.codehaus.org/browse/MCHANGES-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199605#action_199605 ] Martin Vysny commented on MCHANGES-155: --- I just wanted the "Issue 9966" text to appear as action description. The text is generated by the plugin so I thought that there is no need for a description in changes.xml. However, I learned that it's good to always have a description, even if it is just a name of the bug. > When an empty element is present in changes.xml the parser fails > -- > > Key: MCHANGES-155 > URL: http://jira.codehaus.org/browse/MCHANGES-155 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: announcement, changes-report >Affects Versions: 2.1 > Environment: maven 2.0.9, sun-jdk-6 x64 >Reporter: Martin Vysny > > With this changelog: > > > Some changelog > Martin Vyný > > > > > Foo > > > mvn changes:announcement-generate fails with > [ERROR] An error occured when parsing the changes.xml file: > org.codehaus.plexus.util.xml.pull.XmlPullParserException: expected START_TAG > or END_TAG not TEXT (position: TEXT seen ... type="update">Foo at > org.codehaus.plexus.util.xml.pull.MXParser.nextTag(MXParser.java:1083) > at > org.apache.maven.plugins.changes.model.io.xpp3.ChangesXpp3Reader.parseAction(ChangesXpp3Reader.java:388) > at > org.apache.maven.plugins.changes.model.io.xpp3.ChangesXpp3Reader.parseRelease(ChangesXpp3Reader.java:716) > at > org.apache.maven.plugins.changes.model.io.xpp3.ChangesXpp3Reader.parseBody(ChangesXpp3Reader.java:503) > at > org.apache.maven.plugins.changes.model.io.xpp3.ChangesXpp3Reader.parseChangesDocument(ChangesXpp3Reader.java:562) > at > org.apache.maven.plugins.changes.model.io.xpp3.ChangesXpp3Reader.read(ChangesXpp3Reader.java:1018) > at > org.apache.maven.plugins.changes.model.io.xpp3.ChangesXpp3Reader.read(ChangesXpp3Reader.java:1049) > at org.apache.maven.plugin.changes.ChangesXML.(ChangesXML.java:65) > at > org.apache.maven.plugin.announcement.AnnouncementMojo.execute(AnnouncementMojo.java:322) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] Creating announcement file from > /home/vyzivus/work/lsabpm/lsabpm-1.206.x/src/changes/changes.xml... > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Couldn't find the release '1.206.6' among the supplied releases. > changes-2.0 does not suffer from this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-149) -DfromDeveloperId does not work if developers are setted in the parent pom
[
http://jira.codehaus.org/browse/MCHANGES-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199603#action_199603
]
Dennis Lundberg commented on MCHANGES-149:
--
That needs to be
{noformat}
-Dchanges.fromDeveloperId=yourDeveloperId
{noformat}
if your are giving it as a command line parameter.
> -DfromDeveloperId does not work if developers are setted in the parent pom
> --
>
> Key: MCHANGES-149
> URL: http://jira.codehaus.org/browse/MCHANGES-149
> Project: Maven 2.x Changes Plugin
> Issue Type: Bug
> Components: announcement
>Affects Versions: 2.0
> Environment: Windows or Linux
>Reporter: Alexandre Navarro
>
> -DfromDeveloperId does not work if developers are setted in the parent pom.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCHANGES-182) Plugin seems to be tied to Sun JDK
[ http://jira.codehaus.org/browse/MCHANGES-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-182. Resolution: Duplicate > Plugin seems to be tied to Sun JDK > -- > > Key: MCHANGES-182 > URL: http://jira.codehaus.org/browse/MCHANGES-182 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: announcement >Affects Versions: 2.1 >Reporter: David J. M. Karlsen > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error getting reports from the plugin > 'org.apache.maven.plugins:maven-changes-plugin:2.1': Unable to load the mojo > 'org.apache.maven.plugins:maven-changes-plugin:2.1:announcement-mail' in the > plugin 'org.apache.maven.plugins:maven-changes-plugin'. A required class is > missing: com.sun.net.ssl.internal.ssl.Provider > [INFO] > > [INFO] For more information, run Maven with the -e switch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MCHANGES-173) Failed to generate report when version is not the last schedule.
[
http://jira.codehaus.org/browse/MCHANGES-173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199599#action_199599
]
Dennis Lundberg commented on MCHANGES-173:
--
You are probably hitting the limit of max 25 issues specified by the
"maxEntries" parameter. This limits the amount of issues that the plugin will
fetch from JIRA. If you have a lot of issues (more than 25) in your 1.3.0
release, this can happen.
Please try to increase the value of "maxEntries" in your configuration.
We should probably increase the default value from 25 to something higher.
> Failed to generate report when version is not the last schedule.
>
>
> Key: MCHANGES-173
> URL: http://jira.codehaus.org/browse/MCHANGES-173
> Project: Maven 2.x Changes Plugin
> Issue Type: Bug
> Components: announcement, jira-report
>Affects Versions: 2.1
>Reporter: Christophe Lallement
>Priority: Critical
>
> We try to release a snapshot version (1.2.3-SNAPSHOT) but this version is not
> define as last release into JIRA version.
> into JIRA we have define version as this (by schedule order)
> * 1.3.0
> * 1.2.3
> * 1.2.2
>
> When we try to generate jira report for e version 1.2.3-SNAPSHOT we have this
> error: (i don't if it occurs during jira report or annoucement)
> PS: if i schedule 1.2.3 in first position into JIRa, it works fine.
> {code}...
> [DEBUG] Default ResourceManager initialization complete.
> [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
> [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
> [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
> [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Include
> [DEBUG] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
> [DEBUG] Created '20' parsers.
> [DEBUG] Velocimacro : initialization starting.
> [DEBUG] Velocimacro : allowInline = true : VMs can be defined inline in
> templates
> [DEBUG] Velocimacro : allowInlineToOverride = false : VMs defined inline may
> NOT replace previous VM definitions
> [DEBUG] Velocimacro : allowInlineLocal = false : VMs defined inline will be
> global in scope if allowed.
> [DEBUG] Velocimacro : autoload off : VM system will not automatically reload
> global library macros
> [DEBUG] Velocimacro : Velocimacro : initialization complete.
> [DEBUG] RuntimeInstance successfully initialized.
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-changes-plugin:2.1:announcement-generate' -->
> [DEBUG] (s) artifactId = feedapi
> [DEBUG] (f) basedir = C:\HOMEWARE\eclipse-341\workspace\feedapi
> [DEBUG] (s) developmentTeam = vol-domino-feedapi team
> [DEBUG] (s) finalName = feedapi-1.2.3-SNAPSHOT
> [DEBUG] (f) generateJiraAnnouncement = true
> [DEBUG] (s) groupId = ged.domino
> [DEBUG] (s) introduction = FeedAPI is a framework to send feed between
> component (In and Out process) with high frequency const
> aint
> [DEBUG] (f) jiraMerge = false
> [DEBUG] (f) jiraXML =
> C:\HOMEWARE\eclipse-341\workspace\feedapi\target\jira-announcement.xml
> [DEBUG] (f) maxEntries = 25
> [DEBUG] (s) outputDirectory =
> C:\HOMEWARE\eclipse-341\workspace\feedapi\target\announcement
> [DEBUG] (s) packaging = jar
> [DEBUG] (f) project = MavenProject: ged.domino:feedapi:1.2.3-SNAPSHOT @
> C:\HOMEWARE\eclipse-341\workspace\feedapi\pom.xml
> [DEBUG] (f) resolutionIds = Fixed
> [DEBUG] (f) settings = org.apache.maven.settings.setti...@1eb62b6
> [DEBUG] (f) statusIds = Closed
> [DEBUG] (f) template = feedapi-announcement.vm
> [DEBUG] (f) templateDirectory = our-announcements
> [DEBUG] (s) url = http://frontools/maven_site/domino-parent/feedapi
> [DEBUG] (s) version = 1.2.3-SNAPSHOT
> [DEBUG] (s) xmlPath =
> C:\HOMEWARE\eclipse-341\workspace\feedapi\src\changes\changes.xml
> [DEBUG] -- end configuration --
> [INFO] [changes:announcement-generate {execution: announcement-generate}]
> [DEBUG] JIRA lives at: https://jtbox.fr.world.socgen/jira
> [DEBUG] The JIRA URL https://jtbox.fr.world.socgen/jira/browse/TRAFEEDAPI
> doesn't include a pid, trying to extract it from JIRA.
> [DEBUG] Successfully reached JIRA.
> 26 ao¹t 2009 10:54:10 org.apache.commons.httpclient.HttpMethodBase
> getResponseBody
> ATTENTION: Going to buffer response body of large or unknown size. Using
> getResponseBodyAsStream instead is recommended.
> [DEBUG] Found the pid 10236 at
> https://jtbox.fr.world.socgen/jira/browse/TRAFEEDAPI
> [ERROR] maven-changes-plugin: None of the configured sortColumnNames 'null'
> are correct.
> [DEBUG] download jira issues from url
> https://jtbox.fr.world.socgen/jira/secure/IssueNavigator.jspa?view=rss&pid=10236&statusIds=
> &resolutionIds=1&tempMax=25&reset=true&deco
[jira] Commented: (MCHANGES-155) When an empty element is present in changes.xml the parser fails
[ http://jira.codehaus.org/browse/MCHANGES-155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199598#action_199598 ] Dennis Lundberg commented on MCHANGES-155: -- The parser is generated by Modello. Will need to check there as well. Just out of curiosity, why would you want an action without a description. > When an empty element is present in changes.xml the parser fails > -- > > Key: MCHANGES-155 > URL: http://jira.codehaus.org/browse/MCHANGES-155 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: announcement, changes-report >Affects Versions: 2.1 > Environment: maven 2.0.9, sun-jdk-6 x64 >Reporter: Martin Vysny > > With this changelog: > > > Some changelog > Martin Vyný > > > > > Foo > > > mvn changes:announcement-generate fails with > [ERROR] An error occured when parsing the changes.xml file: > org.codehaus.plexus.util.xml.pull.XmlPullParserException: expected START_TAG > or END_TAG not TEXT (position: TEXT seen ... type="update">Foo at > org.codehaus.plexus.util.xml.pull.MXParser.nextTag(MXParser.java:1083) > at > org.apache.maven.plugins.changes.model.io.xpp3.ChangesXpp3Reader.parseAction(ChangesXpp3Reader.java:388) > at > org.apache.maven.plugins.changes.model.io.xpp3.ChangesXpp3Reader.parseRelease(ChangesXpp3Reader.java:716) > at > org.apache.maven.plugins.changes.model.io.xpp3.ChangesXpp3Reader.parseBody(ChangesXpp3Reader.java:503) > at > org.apache.maven.plugins.changes.model.io.xpp3.ChangesXpp3Reader.parseChangesDocument(ChangesXpp3Reader.java:562) > at > org.apache.maven.plugins.changes.model.io.xpp3.ChangesXpp3Reader.read(ChangesXpp3Reader.java:1018) > at > org.apache.maven.plugins.changes.model.io.xpp3.ChangesXpp3Reader.read(ChangesXpp3Reader.java:1049) > at org.apache.maven.plugin.changes.ChangesXML.(ChangesXML.java:65) > at > org.apache.maven.plugin.announcement.AnnouncementMojo.execute(AnnouncementMojo.java:322) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:616) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] Creating announcement file from > /home/vyzivus/work/lsabpm/lsabpm-1.206.x/src/changes/changes.xml... > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Couldn't find the release '1.206.6' among the supplied releases. > changes-2.0 does not suffer from this problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCHANGES-140) Create an announcement check mojo
[ http://jira.codehaus.org/browse/MCHANGES-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199596#action_199596 ] Dennis Lundberg commented on MCHANGES-140: -- I like this, it adds one more level of checking of the changes.xml file on top of what "changes-validate" already does. I would prefer to call the goal "changes-check" instead, because the "announcement-generate" goal works with more than just changes.xml files. It can fetch releases from JIRA as well. What do you think Justin? > Create an announcement check mojo > - > > Key: MCHANGES-140 > URL: http://jira.codehaus.org/browse/MCHANGES-140 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement > Components: announcement >Affects Versions: 2.1 >Reporter: Justin Edelson > Attachments: AnnouncementCheckMojo.java > > > I meant to submit this for inclusion in changes 2.1, but I guess I just > missed it (2.1.1maybe?). > We use the attached goal as part of release:prepare to ensure that the > changes.xml has correct content before a release is done > (changes:announcement-generate) is executed during release:perform. > It really does two things: > 1) Ensures that the current version is represented in the changes.xml file > (no special logic to do this, it's just in > AnnouncementMjojo.getLatestRelease()). > 2) Ensures that the current version's release date isn't "TBD" or "tbd". This > could be easily changed to be "in SVN" through configuration. If you want to > make this the default and I'll add config to our organizational pom to use > "tbd", fine with me. > Since using this goal, we've eliminated a cause of release failures, so > that's 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] Closed: (MCHANGES-153) For multi-module project, sending the email once for the project, not one email for each sub-module
[
http://jira.codehaus.org/browse/MCHANGES-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MCHANGES-153.
Resolution: Duplicate
> For multi-module project, sending the email once for the project, not one
> email for each sub-module
> ---
>
> Key: MCHANGES-153
> URL: http://jira.codehaus.org/browse/MCHANGES-153
> Project: Maven 2.x Changes Plugin
> Issue Type: New Feature
> Components: announcement
>Affects Versions: 2.1
> Environment: Maven 2.0.9
> Java 6
> WinXp
>Reporter: Jean-Paul GUIGUI
>
> When running the announcement plugin on multi-module projects, it is sending
> one mail by submodule.
> Should be able to configure this behaviour. We would like just one email for
> the whole project
> Hereunder a suggestion of working patch I have test locally:
> Into AnnouncementMailMojo.java:
> /**
>* If true, will generate the changes only for the root module in case
> of project with sub-modules.
>*
>* @parameter expression="${plugin.aggregate}" default-value = "true"
>*/
> private boolean aggregate;
> ...
> public void execute()
> throws MojoExecutionException
> {
> if (!project.isExecutionRoot() && aggregate) {
> // Execute only for the main module in case of project
> with sub-modules
> return;
> }
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MCHANGES-131) It would be nice if the announcement plugin bound to the validate phase to make sure changes.xml exists and has the proper versions in it.
[ http://jira.codehaus.org/browse/MCHANGES-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-131. Resolution: Not A Bug The announcement goals are not bound to any phase by default. That's because different users have different requirements for which phase, if any, they want them to be bound to. You can easily bind it yourself using an execution. You can also use the "changes:changes-validate" goal to verify that your changes.xml file is valid. > It would be nice if the announcement plugin bound to the validate phase to > make sure changes.xml exists and has the proper versions in it. > -- > > Key: MCHANGES-131 > URL: http://jira.codehaus.org/browse/MCHANGES-131 > Project: Maven 2.x Changes Plugin > Issue Type: Wish > Components: announcement >Reporter: Leif Nelson > > When using the announcement-generate goal in concert with the release plugin, > it would be nice if the announcement plugin was invoked in the validate > phase. When doing a release:prepare release:perform, the announcement plugin > will cause the build to fail "after" the poms have been committed and the > version has been tagged, if you forget to update the changes.xml file. If > the announcement plugin bound to the validate phase, it would be called > during the release:prepare step, and could force the release to fail during > validate (if changes.xml wasn't config'd right) "before" the commit/tagging > operations were completed. This would be a nice feature. :-) > Thanks! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCHANGES-187) If jiraMerge=true then releases that are only in JIRA will not be included in the announcement
[ http://jira.codehaus.org/browse/MCHANGES-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-187. Resolution: Fixed Fix Version/s: 2.3 Assignee: Dennis Lundberg Fixed in [r884570|http://svn.apache.org/viewvc?view=revision&revision=884570]. > If jiraMerge=true then releases that are only in JIRA will not be included in > the announcement > -- > > Key: MCHANGES-187 > URL: http://jira.codehaus.org/browse/MCHANGES-187 > Project: Maven 2.x Changes Plugin > Issue Type: Bug > Components: announcement >Affects Versions: 2.2 >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg > Fix For: 2.3 > > > The problem lies in AnnouncementMojo.mergeReleases() which will only work if > JIRA has the same versions as changes.xml. Versions that are only in JIRA > will be lost. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MCHANGES-187) If jiraMerge=true then releases that are only in JIRA will not be included in the announcement
If jiraMerge=true then releases that are only in JIRA will not be included in the announcement -- Key: MCHANGES-187 URL: http://jira.codehaus.org/browse/MCHANGES-187 Project: Maven 2.x Changes Plugin Issue Type: Bug Components: announcement Affects Versions: 2.2 Reporter: Dennis Lundberg The problem lies in AnnouncementMojo.mergeReleases() which will only work if JIRA has the same versions as changes.xml. Versions that are only in JIRA will be lost. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (MCHANGES-145) Make it possible to run the announcement goals only once for a multi-module project
[
http://jira.codehaus.org/browse/MCHANGES-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MCHANGES-145.
Resolution: Fixed
I opted for a different approach than the attached patch. This is based on the
same principle that has been used successfully in the Assembly Plugin. See
Brian's blog post about it
http://www.sonatype.com/people/2009/05/how-to-make-a-plugin-run-once-during-a-build/
A little refactoring was required to make it work for both
announcement-generate and announcement-mail goals.
Fixed in [r884563|http://svn.apache.org/viewvc?view=revision&revision=884563].
> Make it possible to run the announcement goals only once for a multi-module
> project
> ---
>
> Key: MCHANGES-145
> URL: http://jira.codehaus.org/browse/MCHANGES-145
> Project: Maven 2.x Changes Plugin
> Issue Type: New Feature
> Components: announcement
>Affects Versions: 2.1
> Environment: maven 2.0.9
> JDK 1.6.011
> WinXP
>Reporter: Jean-Paul GUIGUI
>Assignee: Dennis Lundberg
> Fix For: 2.3
>
> Attachments: MCHANGES-145-CORRECT.patch, MCHANGES-145.patch
>
>
> If the pom.xml is containing some sub-modules, the goal
> changes:announcement-mail is trying to send it for each module, and fail
> because it could not find the template.
>Announcement template
> C:\Dev\MyProject\SubmoduleA\target\announcement\announcement.vm not found...
> Should be possible to configure the pom to send only the email for the root
> project.
> Working with "mvn --non-recursive" option, but we need to be able to
> configure this behaviour into the pom.xml
> The same issue for the changes:announcement-generate, but it's only a warning
> and the build can finish successfully.
> Should include something like:
> /**
>* @parameter expression="${project}"
>**/
> private MavenProject mavenProject;
> /**
>* If true, will generate the changes only for the root module in case
> of project with sub-modules.
>*
>* @parameter expression="${plugin.aggregate}" default-value = "false"
>*/
> private boolean aggregate;
> public void execute() {
> if (!mavenProject.isExecutionRoot() && aggregate) {
> // Execute only for the main module in case of
> project with sub-modules
> return;
> }
>..
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MCHANGES-150) [regression] Report Sets not honored during site goal
[
http://jira.codehaus.org/browse/MCHANGES-150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199588#action_199588
]
Dennis Lundberg commented on MCHANGES-150:
--
I can confirm that this is a regression between versions 2.0 and 2.1 of Maven
Changes Plugin.
However it has nothing to do with whether you are invoking the report via the
"site" phase or if you run the "changes:changes-report". You can use the
following commands to verify it:
{noformat}
mvn org.apache.maven.plugins:maven-changes-plugin:2.0:changes-report
mvn org.apache.maven.plugins:maven-changes-plugin:2.1:changes-report
{noformat}
The first one will include the issue in the report, but the second one will not.
> [regression] Report Sets not honored during site goal
> -
>
> Key: MCHANGES-150
> URL: http://jira.codehaus.org/browse/MCHANGES-150
> Project: Maven 2.x Changes Plugin
> Issue Type: Bug
> Components: changes-report
>Affects Versions: 2.1
>Reporter: Paul Benedict
>Assignee: Brett Porter
> Attachments: changes.xml, MNG-4045-debug.txt, MNG-4045.zip
>
>
> I was locking down my Maven Changes Plugin version with the following config:
> {code}
>
>
> org.apache.maven.plugins
> maven-changes-plugin
> 2.1
>
>
>
> changes-report
>
>
>
>
>
> {code}
> And then I created the site and noticed the report was empty. The report
> markup was there, of course, but it generated like my changes.xml was blank.
> I could run changes:changes-report just fine. However, when I then removed
> the tag and tried site:site again, the report output was present as
> expected.
> Here's an interesting line from the debug output when is specified:
> {quote}[DEBUG] The following artifacts were filtered out for plugin:
> org.apache.maven.plugins:maven-changes-plugin:2.1 because they're already in
> the core of Maven:{quote}
> My theory is that because my plugin version has an exact match on the
> version, my specified plugin configuration is tossed. That certainly seems
> like a bug to me.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MCHANGES-186) Issue links for JIRA are broken when using the %URL% token
[
http://jira.codehaus.org/browse/MCHANGES-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg closed MCHANGES-186.
Resolution: Fixed
Fix Version/s: 2.3
Assignee: Dennis Lundberg
Fixed in [r884559|http://svn.apache.org/viewvc?view=rev&revision=884559].
> Issue links for JIRA are broken when using the %URL% token
> --
>
> Key: MCHANGES-186
> URL: http://jira.codehaus.org/browse/MCHANGES-186
> Project: Maven 2.x Changes Plugin
> Issue Type: Bug
> Components: changes-report
>Affects Versions: 2.2
>Reporter: Dennis Lundberg
>Assignee: Dennis Lundberg
> Fix For: 2.3
>
>
> The fix for MCHANGES-166 included a small change that broke this. See
> http://jira.codehaus.org/browse/MCHANGES-166?focusedCommentId=184918&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_184918
> {quote}
> The private method parseIssueLink(...) should remove only the trailing slash
> from the URL if one exists. This prevents cases where we miss to give a
> trailing slash in the issueManagement.url.
> {quote}
> This part of the patch should not have been committed. The documentation for
> the issueLinkTemplatePerSystem parameter states:
> {quote}
> %URL%: this is computed by getting the / value from the
> POM, and removing the last '/' and everything that comes after it.
> {quote}
> After the patch this is no longer true. This breaks issue links to JIRA if
> you have a configuration like this:
> {code:xml}
>
> JIRA
> http://jira.mycompany.com/browse/PRODUCT
>
>
>
>
> org.apache.maven.plugins
> maven-changes-plugin
> 2.2
>
>
> %URL%/%ISSUE%
>
>
>
>
>
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHANGES-145) Make it possible to run the announcement goals only once for a multi-module project
[
http://jira.codehaus.org/browse/MCHANGES-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MCHANGES-145:
-
Fix Version/s: 2.3
Assignee: Dennis Lundberg
Issue Type: New Feature (was: Bug)
Summary: Make it possible to run the announcement goals only once for
a multi-module project (was: Error when trying to send email for multi-module
projects)
> Make it possible to run the announcement goals only once for a multi-module
> project
> ---
>
> Key: MCHANGES-145
> URL: http://jira.codehaus.org/browse/MCHANGES-145
> Project: Maven 2.x Changes Plugin
> Issue Type: New Feature
> Components: announcement
>Affects Versions: 2.1
> Environment: maven 2.0.9
> JDK 1.6.011
> WinXP
>Reporter: Jean-Paul GUIGUI
>Assignee: Dennis Lundberg
> Fix For: 2.3
>
> Attachments: MCHANGES-145-CORRECT.patch, MCHANGES-145.patch
>
>
> If the pom.xml is containing some sub-modules, the goal
> changes:announcement-mail is trying to send it for each module, and fail
> because it could not find the template.
>Announcement template
> C:\Dev\MyProject\SubmoduleA\target\announcement\announcement.vm not found...
> Should be possible to configure the pom to send only the email for the root
> project.
> Working with "mvn --non-recursive" option, but we need to be able to
> configure this behaviour into the pom.xml
> The same issue for the changes:announcement-generate, but it's only a warning
> and the build can finish successfully.
> Should include something like:
> /**
>* @parameter expression="${project}"
>**/
> private MavenProject mavenProject;
> /**
>* If true, will generate the changes only for the root module in case
> of project with sub-modules.
>*
>* @parameter expression="${plugin.aggregate}" default-value = "false"
>*/
> private boolean aggregate;
> public void execute() {
> if (!mavenProject.isExecutionRoot() && aggregate) {
> // Execute only for the main module in case of
> project with sub-modules
> return;
> }
>..
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (MINSTALL-71) localRepositoryPath ignored
[
http://jira.codehaus.org/browse/MINSTALL-71?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rémi Perrot closed MINSTALL-71.
---
Resolution: Fixed
Fix Version/s: 2.3
I test with 2.3 version and it works as intended
> localRepositoryPath ignored
> ---
>
> Key: MINSTALL-71
> URL: http://jira.codehaus.org/browse/MINSTALL-71
> Project: Maven 2.x Install Plugin
> Issue Type: Bug
> Components: install:install-file
>Affects Versions: 2.2
> Environment: Windows XP
> Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
> Java version: 1.6.0_16
> Java home: C:\Program Files\Java\jdk1.6.0_16\jre
> Default locale: fr_FR, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>Reporter: Rémi Perrot
> Fix For: 2.3
>
>
> Using CLI I want to install an artifact in an other repository than the on
> defined in my settings.xml. Here is the command line I use :
> mvn -X org.apache.maven.plugins:maven-install-plugin:2.2:install-file
> -DlocalRepositoryPath=D:\RPE_WS\fake_repo -Dfile=inst_test-0.0.1.jar
> -DpomFile=pom.xml -DcreateChecksum=true
> where D:\RPE_WS\fake_repo is an empty directory
> The last part of the output is:
> ...
> [DEBUG] Configuring mojo
> 'org.apache.maven.plugins:maven-install-plugin:2.2:inst
> all-file' -->
> [DEBUG] (f) createChecksum = true
> [DEBUG] (f) file = D:\RPE_WS\mvn_install_test\inst_test-0.0.1.jar
> [DEBUG] (f) generatePom = false
> [DEBUG] (f) localRepository = Repository[local|file://C:\Documents and
> Setting
> s\gt218354\.m2\repository]
> [DEBUG] (s) localRepositoryPath = D:\RPE_WS\fake_repo
> [DEBUG] (f) pomFile = D:\RPE_WS\mvn_install_test\pom.xml
> [DEBUG] (f) repositoryLayout = default
> [DEBUG] -- end configuration --
> [INFO] [install:install-file {execution: default-cli}]
> [INFO] Installing D:\RPE_WS\mvn_install_test\inst_test-0.0.1.jar to
> C:\Documents
> and Settings\userid\.m2\repository\com\plop\test\inst_test\0.0.1\inst_test-0
> .0.1.jar
> [INFO] Creating Checksums...
> [DEBUG] Installing checksum for C:\Documents and
> Settings\userid\.m2\repository\com\plop\test\inst_test\0.0.1\inst_test-0.0.1.jar
> [INFO] Installing D:\RPE_WS\mvn_install_test\pom.xml to C:\Documents and
> Setting
> s\userid\.m2\repository\com\plop\test\inst_test\0.0.1\inst_test-0.0.1.pom
> [INFO] Creating Checksums...
> [DEBUG] Installing checksum for C:\Documents and Settings\userid\.m2\repositor
> y\com\plop\test\inst_test\0.0.1\inst_test-0.0.1.pom
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> [INFO] Total time: < 1 second
> [INFO] Finished at: Thu Nov 26 12:02:57 CET 2009
> [INFO] Final Memory: 3M/6M
> [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: (MINSTALL-71) localRepositoryPath ignored
localRepositoryPath ignored
---
Key: MINSTALL-71
URL: http://jira.codehaus.org/browse/MINSTALL-71
Project: Maven 2.x Install Plugin
Issue Type: Bug
Components: install:install-file
Affects Versions: 2.2
Environment: Windows XP
Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200)
Java version: 1.6.0_16
Java home: C:\Program Files\Java\jdk1.6.0_16\jre
Default locale: fr_FR, platform encoding: Cp1252
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
Reporter: Rémi Perrot
Using CLI I want to install an artifact in an other repository than the on
defined in my settings.xml. Here is the command line I use :
mvn -X org.apache.maven.plugins:maven-install-plugin:2.2:install-file
-DlocalRepositoryPath=D:\RPE_WS\fake_repo -Dfile=inst_test-0.0.1.jar
-DpomFile=pom.xml -DcreateChecksum=true
where D:\RPE_WS\fake_repo is an empty directory
The last part of the output is:
...
[DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-install-plugin:2.2:inst
all-file' -->
[DEBUG] (f) createChecksum = true
[DEBUG] (f) file = D:\RPE_WS\mvn_install_test\inst_test-0.0.1.jar
[DEBUG] (f) generatePom = false
[DEBUG] (f) localRepository = Repository[local|file://C:\Documents and Setting
s\gt218354\.m2\repository]
[DEBUG] (s) localRepositoryPath = D:\RPE_WS\fake_repo
[DEBUG] (f) pomFile = D:\RPE_WS\mvn_install_test\pom.xml
[DEBUG] (f) repositoryLayout = default
[DEBUG] -- end configuration --
[INFO] [install:install-file {execution: default-cli}]
[INFO] Installing D:\RPE_WS\mvn_install_test\inst_test-0.0.1.jar to C:\Documents
and Settings\userid\.m2\repository\com\plop\test\inst_test\0.0.1\inst_test-0
.0.1.jar
[INFO] Creating Checksums...
[DEBUG] Installing checksum for C:\Documents and
Settings\userid\.m2\repository\com\plop\test\inst_test\0.0.1\inst_test-0.0.1.jar
[INFO] Installing D:\RPE_WS\mvn_install_test\pom.xml to C:\Documents and Setting
s\userid\.m2\repository\com\plop\test\inst_test\0.0.1\inst_test-0.0.1.pom
[INFO] Creating Checksums...
[DEBUG] Installing checksum for C:\Documents and Settings\userid\.m2\repositor
y\com\plop\test\inst_test\0.0.1\inst_test-0.0.1.pom
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: < 1 second
[INFO] Finished at: Thu Nov 26 12:02:57 CET 2009
[INFO] Final Memory: 3M/6M
[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] Commented: (MNG-4354) DefaultArtifactResolver has problems when used with multiple repos
[ http://jira.codehaus.org/browse/MNG-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199542#action_199542 ] Nicolas Dumoulin commented on MNG-4354: --- I can confirm this annoying bug. For instance, our fix is to use our proxy as a mirro of the central repo. > DefaultArtifactResolver has problems when used with multiple repos > -- > > Key: MNG-4354 > URL: http://jira.codehaus.org/browse/MNG-4354 > Project: Maven 2 > Issue Type: Bug > Components: Bootstrap & Build >Affects Versions: 2.2.1 > Environment: N/A >Reporter: Hasan Ceylan >Priority: Blocker > Attachments: maven.patch > > > DefaultArtifactResolver attaches the repositories to artifacts (AFAIK) to > optimize the repo look ups. > Here I have a case > 1) An artifact dependens on org.eclipse.equniox:app:1.2.0 > 2) org.eclipse.equinox:app depends on > org.eclipse.equinox:registry:[3.4.0,4.0.0) > 3) Both central repo and custom corporate repo has > org.eclipse.equinox:registry > 4) central repo has outdated versions > 3.2.1-R32x_v20060814 > 3.3.0-v20070522 > 5) DefaultArtifactResolver for optimization attaches central repo (last one > wins) > 6) Central repo neither satisfies the version range nor - even if it did - > has the latest version > 7) dependency is not satisfied > 8) Build halts > Attached patch is a dirty hack to disable signle repo downloand and checks > all the repositories. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
