[jira] (MNG-1977) Global dependency exclusions
[ https://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342923#comment-342923 ] Oliver Siegmar commented on MNG-1977: - This issue and MNG-624 (which is even older) are two reasons why I switched to Gradle. > Global dependency exclusions > > > Key: MNG-1977 > URL: https://jira.codehaus.org/browse/MNG-1977 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: POM >Reporter: Kees de Kooter > Fix For: Issues to be reviewed for 4.x > > Attachments: global_excls_it-test_v2.patch, > global_excls_it-test_v3.patch, global_excls_maven3_v2.patch, > global_excls_maven3_v3.patch > > > I depend on some libraries, which in turn depend on something > (which in turn depend on something) that I don't want, because I declare > some other artifact in my pom.xml. > A concrete example: I don't want that the artifact "xerces" is imported in > my project because I declare to depend on "xercesImpl" which ships newer > libraries but with the same namespaces. > I guess I would need an "exclude transitive dependency at all", either > globally or from this and that artifact. I saw the tag, but it > forces me to be very verbose and have exact control on what is required by a > dependency. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNGSITE-195) Default folder layout documentation update
[
https://jira.codehaus.org/browse/MNGSITE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MNGSITE-195:
Description:
Based [on the discussion on the mailing
list|http://maven.40175.n5.nabble.com/maven-assembly-plugin-Maven-default-folder-layout-td5787276.html]
the folder layout should be changed according to the following:
src/main
* are files required during compile time (production)
** src/main/java
** src/main/resources
** src/main/filters
src/test
* are files required during test time (unit testing; based on naming
schema we could also have integration tests here)
** src/test/java
** src/test/resources
** src/test/filters
src/it
* are files required during integration tests (primarily for plugins)
src/assembly
* for assembly descriptors and appropriate filter property files.
src/config
* for configuration files.
src/main/filters
* Resource filter files
src/main/scripts
* Application/Library scripts
src/main/webapp
* Web application sources
src/site
* Maven Site
In the end this means currently only {{src/it}} must be added to the default
folder layout page.
{{src/config}} is currently under discussion
was:
Based [on the discussion on the mailing
list|http://maven.40175.n5.nabble.com/maven-assembly-plugin-Maven-default-folder-layout-td5787276.html]
the folder layout should be changed according to the following:
src/main
* are files required during compile time (production)
** src/main/java
** src/main/resources
** src/main/filters
src/test
* are files required during test time (unit testing; based on naming
schema we could also have integration tests here)
** src/test/java
** src/test/resources
** src/test/filters
src/it
* are files required during integration tests (primarily for plugins)
src/assembly
* for assembly descriptors and appropriate filter property files.
src/config
* for configuration files.
src/main/filters
* Resource filter files
src/main/scripts
* Application/Library scripts
src/main/webapp
* Web application sources
src/site
* Maven Site
> Default folder layout documentation update
> --
>
> Key: MNGSITE-195
> URL: https://jira.codehaus.org/browse/MNGSITE-195
> Project: Maven Project Web Site
> Issue Type: Improvement
>Reporter: Karl Heinz Marbaise
>Priority: Minor
>
> Based [on the discussion on the mailing
> list|http://maven.40175.n5.nabble.com/maven-assembly-plugin-Maven-default-folder-layout-td5787276.html]
> the folder layout should be changed according to the following:
> src/main
> * are files required during compile time (production)
> ** src/main/java
> ** src/main/resources
> ** src/main/filters
> src/test
> * are files required during test time (unit testing; based on naming
> schema we could also have integration tests here)
> ** src/test/java
> ** src/test/resources
> ** src/test/filters
> src/it
> * are files required during integration tests (primarily for plugins)
> src/assembly
> * for assembly descriptors and appropriate filter property files.
> src/config
> * for configuration files.
> src/main/filters
> * Resource filter files
> src/main/scripts
> * Application/Library scripts
> src/main/webapp
> * Web application sources
> src/site
> * Maven Site
> In the end this means currently only {{src/it}} must be added to the default
> folder layout page.
> {{src/config}} is currently under discussion
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNGSITE-195) Default folder layout documentation update
[ https://jira.codehaus.org/browse/MNGSITE-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Heinz Marbaise updated MNGSITE-195: Description: Based [on the discussion on the mailing list|http://maven.40175.n5.nabble.com/maven-assembly-plugin-Maven-default-folder-layout-td5787276.html] the folder layout should be changed according to the following: src/main * are files required during compile time (production) ** src/main/java ** src/main/resources ** src/main/filters src/test * are files required during test time (unit testing; based on naming schema we could also have integration tests here) ** src/test/java ** src/test/resources ** src/test/filters src/it * are files required during integration tests (primarily for plugins) src/assembly * for assembly descriptors and appropriate filter property files. src/config * for configuration files. src/main/filters * Resource filter files src/main/scripts * Application/Library scripts src/main/webapp * Web application sources src/site * Maven Site was: Based on the discussion on the mailing list the folder layout should be changed according to the following: src/main * are files required during compile time (production) ** src/main/java ** src/main/resources ** src/main/filters src/test * are files required during test time (unit testing; based on naming schema we could also have integration tests here) ** src/test/java ** src/test/resources ** src/test/filters src/it * are files required during integration tests (primarily for plugins) src/assembly * for assembly descriptors and appropriate filter property files. src/config * for configuration files. src/main/filters * Resource filter files src/main/scripts * Application/Library scripts src/main/webapp * Web application sources src/site * Maven Site > Default folder layout documentation update > -- > > Key: MNGSITE-195 > URL: https://jira.codehaus.org/browse/MNGSITE-195 > Project: Maven Project Web Site > Issue Type: Improvement >Reporter: Karl Heinz Marbaise >Priority: Minor > > Based [on the discussion on the mailing > list|http://maven.40175.n5.nabble.com/maven-assembly-plugin-Maven-default-folder-layout-td5787276.html] > the folder layout should be changed according to the following: > src/main > * are files required during compile time (production) > ** src/main/java > ** src/main/resources > ** src/main/filters > src/test > * are files required during test time (unit testing; based on naming > schema we could also have integration tests here) > ** src/test/java > ** src/test/resources > ** src/test/filters > src/it > * are files required during integration tests (primarily for plugins) > src/assembly > * for assembly descriptors and appropriate filter property files. > src/config > * for configuration files. > src/main/filters > * Resource filter files > src/main/scripts > * Application/Library scripts > src/main/webapp > * Web application sources > src/site > * Maven Site -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MNGSITE-195) Default folder layout documentation update
Karl Heinz Marbaise created MNGSITE-195: --- Summary: Default folder layout documentation update Key: MNGSITE-195 URL: https://jira.codehaus.org/browse/MNGSITE-195 Project: Maven Project Web Site Issue Type: Improvement Reporter: Karl Heinz Marbaise Priority: Minor Based on the discussion on the mailing list the folder layout should be changed according to the following: src/main * are files required during compile time (production) ** src/main/java ** src/main/resources ** src/main/filters src/test * are files required during test time (unit testing; based on naming schema we could also have integration tests here) ** src/test/java ** src/test/resources ** src/test/filters src/it * are files required during integration tests (primarily for plugins) src/assembly * for assembly descriptors and appropriate filter property files. src/config * for configuration files. src/main/filters * Resource filter files src/main/scripts * Application/Library scripts src/main/webapp * Web application sources src/site * Maven Site -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-185) Require Release Dependencies ignorant about aggregator build
[ https://jira.codehaus.org/browse/MENFORCER-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342917#comment-342917 ] Karl Heinz Marbaise commented on MENFORCER-185: --- See MENFORCER-186 which is exactly what you need. I'm currently working on such rule. > Require Release Dependencies ignorant about aggregator build > > > Key: MENFORCER-185 > URL: https://jira.codehaus.org/browse/MENFORCER-185 > Project: Maven Enforcer Plugin > Issue Type: Bug > Components: Standard Rules >Affects Versions: 1.3.1 >Reporter: Thomas Diesler > > If A depends on B it is ok for A-1.0.0-SNAPSHOT to have snapshot dependency > on B-1.0.0-SNAPSHOT if B was build before A during the same reactor build. > Using the requireReleaseDeps rule it seems that SNAPSHOTS are generally not > allowed even when they belong to the same project and were built during the > same reactor build. > We have a complex project with 100+ modules. I want to enforce that no module > has dependencies on project SNAPSHOTS that were not included in the build. In > such case A would use a stale version of B that happened to be available in > the local/remote maven repository. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-186) Create a rule for the reactor (RequireReactorSameVersion?)
[
https://jira.codehaus.org/browse/MENFORCER-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342916#comment-342916
]
Karl Heinz Marbaise commented on MENFORCER-186:
---
First working implementation [r1577707|http://svn.apache.org/r1577707].
> Create a rule for the reactor (RequireReactorSameVersion?)
> --
>
> Key: MENFORCER-186
> URL: https://jira.codehaus.org/browse/MENFORCER-186
> Project: Maven Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Affects Versions: 1.3.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 1.4
>
>
> It would be nice having a rule which checks the consitency of a multi-module
> build.
> Say having a build with modules like this:
> {code}
> +-- root (pom.xml)
> +--- m1 (pom.xml)
>+--- m11 (pom.xml)
>+--- m12 (pom.xml)
> +--- m2 (pom.xml)
>+--- m21 (pom.xml)
>+--- m21 (pom.xml)
> +--- m3 (pom.xml)
>+--- m31 (pom.xml)
>+--- m31 (pom.xml)
> +--- m4 (pom.xml)
> +--- m5 (pom.xml)
> {code}
> If you have for all modules the version 1.2.0-SNAPSHOT everything is fine.
> But what sometimes it happens that someone changes something and you will
> find things like the following:
> The module m21 (pom.xml) has a parent version of 1.1.0-SNAPSHOT instead of
> 1.2.0-SNAPSHOT which means maven will try to find this version in repository
> (you will get a warning during the build; But who reads warnings ;-))..
> Or other things having module interdependencies and it happens someone does
> something like this:
> In m4 a dependency is written like this:
> {code}
>
>TheGroup
>m21
>1.1.0-SNAPSHOT
>
> {code}
> which will usually build (except your SNAPSHOT's have been deleted before),
> but it is not correct. or better like this:
> {code}
>
>TheGroup
>m21
>1.1.0
>
> {code}
> This means it will be solved against a released version which usually is not
> the intention in such cases.
> So the rule should check if the groupId/artifactId belongs to the reactor and
> check the consistency of the version of the dependencies etc. Also the parent
> would be nice.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MWAR-311) Filtering of resources broken in version 2.4
Evan Brodie created MWAR-311: Summary: Filtering of resources broken in version 2.4 Key: MWAR-311 URL: https://jira.codehaus.org/browse/MWAR-311 Project: Maven WAR Plugin Issue Type: Bug Components: filtering Affects Versions: 2.4 Environment: mac os x 10.9.2, Maven 3.1.1, Maven 3.2.1 Reporter: Evan Brodie It appears that resource filtering by version 2.4 of the maven-war-plugin is broken. In filtered resource files in the generated WAR directory by Maven, only the properties specified by the Maven build itself (ie, properties hard-coded in pom.xml) will appear in the resources, but not those specified as filters inside of the tag of . However, the resources file that appear in target/classes will indeed have full filtering applied to it. This behaviour was working as of version 2.3 and earlier (as in, the app.properties file inside both the WAR and the classes directories will have filtering fully applied). I created a Github repo with a very simple code that can easily reproduce the bug, which reproduction steps and further description. Please check it out here: https://github.com/ecbrodie/mwp-filter-bug Until this bug is fixed, users like I that rely on filtering to be applied to their classpath resources are forced to use version 2.3 or earlier. This bug was reproduced on Mac OS X 10.9.2 using both Maven 3.1.1 and 3.2.1. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHANGES-321) Support usage of ExchangeWebServices for mail sending additional to smtp
[ https://jira.codehaus.org/browse/MCHANGES-321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342912#comment-342912 ] Dennis Lundberg commented on MCHANGES-321: -- Some day I hope to get to one of the things on my todo list for this plugin, and that is to extract the emailing functionality into a separate plugin. When that happens your contribution would be a nice addition. In it's current state there is too much going on in the announcement-mail mojo to be able to support another email system. > Support usage of ExchangeWebServices for mail sending additional to smtp > > > Key: MCHANGES-321 > URL: https://jira.codehaus.org/browse/MCHANGES-321 > Project: Maven Changes Plugin > Issue Type: Wish > Components: announcement >Reporter: Carsten Behring >Priority: Minor > > In our corporate environment, users are not allowed to use smtp for mail > sending, but the ExchangeWebServices are available for our ExchangeServer. > I made a small improvement to the code, to allow this, basically to allow to > choose via plugin parameter between "smtp" and "ews" mode. > Would it make sense for you to add this feature to the main code line of the > maven-changes-plugin ? (Or would it be better to keep this in a seperate > plugin, just used by us ?) -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHANGES-270) "announcement-generate" goal fails in multimodule project if "templateDirectory" is defined
[
https://jira.codehaus.org/browse/MCHANGES-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342911#comment-342911
]
Dennis Lundberg commented on MCHANGES-270:
--
You problem does not have anything to do with the {{templateDirectory}}
parameter. When you run:
{{mvn changes:announcement-generate}}
Maven will start by executing this on the parent project. That project doesn't
have any issue management system configured, which is why you get this error
message:
_No releases found in any of the configured issue management systems._
> "announcement-generate" goal fails in multimodule project if
> "templateDirectory" is defined
> ---
>
> Key: MCHANGES-270
> URL: https://jira.codehaus.org/browse/MCHANGES-270
> Project: Maven Changes Plugin
> Issue Type: Bug
> Components: announcement
>Affects Versions: 2.6
> Environment: Maven 3.0.3
>Reporter: Igor Bljahhin
>Priority: Critical
> Attachments: maven-changes-plugin-test.zip
>
>
> In my multimodule project only one submodule has changes.xml. If I run
> changes:announcement-generate from parent project, then it fails with error
> message
> [ERROR] ResourceManager : unable to find resource
> 'our-announcements/announcemen
> t.vm' in any resource loader.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-270) "announcement-generate" goal fails in multimodule project if "templateDirectory" is defined
[ https://jira.codehaus.org/browse/MCHANGES-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MCHANGES-270. Resolution: Not A Bug > "announcement-generate" goal fails in multimodule project if > "templateDirectory" is defined > --- > > Key: MCHANGES-270 > URL: https://jira.codehaus.org/browse/MCHANGES-270 > Project: Maven Changes Plugin > Issue Type: Bug > Components: announcement >Affects Versions: 2.6 > Environment: Maven 3.0.3 >Reporter: Igor Bljahhin >Priority: Critical > Attachments: maven-changes-plugin-test.zip > > > In my multimodule project only one submodule has changes.xml. If I run > changes:announcement-generate from parent project, then it fails with error > message > [ERROR] ResourceManager : unable to find resource > 'our-announcements/announcemen > t.vm' in any resource loader. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCHANGES-280) announcement generation broken in 2.7, possibly by velocity upgrade
[
https://jira.codehaus.org/browse/MCHANGES-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg reassigned MCHANGES-280:
Assignee: Dennis Lundberg
> announcement generation broken in 2.7, possibly by velocity upgrade
> ---
>
> Key: MCHANGES-280
> URL: https://jira.codehaus.org/browse/MCHANGES-280
> Project: Maven Changes Plugin
> Issue Type: Bug
> Components: announcement
>Affects Versions: 2.7
>Reporter: Benson Margulies
>Assignee: Dennis Lundberg
> Fix For: 2.10
>
>
> The following is not good at all:
> {noformat}[INFO] [changes:announcement-generate {execution: default-cli}]
> Apr 30, 2012 4:40:24 PM org.apache.commons.httpclient.HttpMethodBase
> getResponseBody
> WARNING: Going to buffer response body of large or unknown size. Using
> getResponseBodyAsStream instead is recommended.
> [ERROR] maven-changes-plugin: None of the configured sortColumnNames 'null'
> are correct.
> [INFO] Downloading from JIRA at:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?view=rss&pid=11212&statusIds=6&resolutionIds=1&tempMax=1000&reset=true&decorator=none
> [INFO] The JIRA version is '4.4.3'
> [INFO] Including issues from JIRA in announcement...
> [debug] Found 10 releases.
> [ERROR] ResourceManager : unable to find resource
> 'org/apache/maven/plugins/announcement.vm' in any resource loader.
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Resource not found.
> Embedded error: Template not found. (
> org/apache/maven/plugins/announcement.vm )
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 9 seconds
> [INFO] Finished at: Mon Apr 30 16:40:29 EDT 2012
> [INFO] Final Memory: 23M/81M{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-280) announcement generation broken in 2.7, possibly by velocity upgrade
[
https://jira.codehaus.org/browse/MCHANGES-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342910#comment-342910
]
Dennis Lundberg commented on MCHANGES-280:
--
I just realized that the JIRA URL for fetching the issues is in the issue
description...
Your failed attempt was for the Changes Plugin itself.
I think this started with
http://svn.apache.org/viewvc?view=revision&revision=r1379183 which I believe
broke things. I've reverted that change in plugins-parent until this plugin has
been fixed.
Here's the problem. In {{announcement-generate}} there are two parameters
involved: {{template}} and {{announcementFile}}. The first one is the Velocity
template. The second is the file that contains the result after interpolating
properties into the Velocity template. If the second is not specified, the
value of the first is used. There are two possible scenarios:
# {{announcementFile}} not specified
{{announcement.vm}} (the Velocity template available on the classpath) -->
{{announcement-generate}} --> {{target/announcement/announcement.vm}} (a text
file containing the finished announcement text)
# {{announcementFile=announcement.txt}}
{{announcement.vm}} (the Velocity template available on the classpath) -->
{{announcement-generate}} --> {{target/announcement/announcement.txt}} (a text
file containing the finished announcement text)
After this the {{announcement-mail}} goal takes over, and this is where things
start to fail. {{announcement-mail}} only cares about one parameter:
{{template}}, which in this case is *not* not the Velocity template, but in
fact the file that contains the result after interpolating properties into the
Velocity template. The default value for {{template}} is {{announcement.vm}}.
{{template}} not specified, {{announcementFile=announcement.txt}} as per
example 2 above (this was our configuration after r1379183)
{{announcement.vm}} (the Velocity template available on the classpath) -->
{{announcement-generate}} --> {{target/announcement/announcement.txt}} (a text
file containing the finished announcement text) --> {{announcement-mail}} -->
*Error:* {{file target/announcement/announcement.vm}} not found!
My conclusion is that this problem comes from an inappropriately named and
documented parameter. The solution is to rename the {{template}} parameter in
{{announcement-mail}} to {{announcementFile}}.
In {{announcement-generate}} there is a parameter called {{outputDirectory}}
which makes sense for that goal, because it which represents the directory
where the finished announcement is placed. The corresponding parameter in
{{announcement-mail}} is called {{templateOutputDirectory}}, which is wrong
twice: it is not the output directory of this goal and it does not contain a
template. It should be renamed to {{announcementDirectory}}.
> announcement generation broken in 2.7, possibly by velocity upgrade
> ---
>
> Key: MCHANGES-280
> URL: https://jira.codehaus.org/browse/MCHANGES-280
> Project: Maven Changes Plugin
> Issue Type: Bug
> Components: announcement
>Affects Versions: 2.7
>Reporter: Benson Margulies
> Fix For: 2.10
>
>
> The following is not good at all:
> {noformat}[INFO] [changes:announcement-generate {execution: default-cli}]
> Apr 30, 2012 4:40:24 PM org.apache.commons.httpclient.HttpMethodBase
> getResponseBody
> WARNING: Going to buffer response body of large or unknown size. Using
> getResponseBodyAsStream instead is recommended.
> [ERROR] maven-changes-plugin: None of the configured sortColumnNames 'null'
> are correct.
> [INFO] Downloading from JIRA at:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?view=rss&pid=11212&statusIds=6&resolutionIds=1&tempMax=1000&reset=true&decorator=none
> [INFO] The JIRA version is '4.4.3'
> [INFO] Including issues from JIRA in announcement...
> [debug] Found 10 releases.
> [ERROR] ResourceManager : unable to find resource
> 'org/apache/maven/plugins/announcement.vm' in any resource loader.
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Resource not found.
> Embedded error: Template not found. (
> org/apache/maven/plugins/announcement.vm )
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 9 seconds
> [INFO] Finished at: Mon Apr 30 16:40:29 EDT 2012
> [INFO] Final Memory: 23M/81M{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MCHANGES-280) announcement generation broken in 2.7, possibly by velocity upgrade
[
https://jira.codehaus.org/browse/MCHANGES-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dennis Lundberg updated MCHANGES-280:
-
Fix Version/s: 2.10
> announcement generation broken in 2.7, possibly by velocity upgrade
> ---
>
> Key: MCHANGES-280
> URL: https://jira.codehaus.org/browse/MCHANGES-280
> Project: Maven Changes Plugin
> Issue Type: Bug
> Components: announcement
>Affects Versions: 2.7
>Reporter: Benson Margulies
>Assignee: Dennis Lundberg
> Fix For: 2.10
>
>
> The following is not good at all:
> {noformat}[INFO] [changes:announcement-generate {execution: default-cli}]
> Apr 30, 2012 4:40:24 PM org.apache.commons.httpclient.HttpMethodBase
> getResponseBody
> WARNING: Going to buffer response body of large or unknown size. Using
> getResponseBodyAsStream instead is recommended.
> [ERROR] maven-changes-plugin: None of the configured sortColumnNames 'null'
> are correct.
> [INFO] Downloading from JIRA at:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?view=rss&pid=11212&statusIds=6&resolutionIds=1&tempMax=1000&reset=true&decorator=none
> [INFO] The JIRA version is '4.4.3'
> [INFO] Including issues from JIRA in announcement...
> [debug] Found 10 releases.
> [ERROR] ResourceManager : unable to find resource
> 'org/apache/maven/plugins/announcement.vm' in any resource loader.
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Resource not found.
> Embedded error: Template not found. (
> org/apache/maven/plugins/announcement.vm )
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 9 seconds
> [INFO] Finished at: Mon Apr 30 16:40:29 EDT 2012
> [INFO] Final Memory: 23M/81M{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MNG-1977) Global dependency exclusions
[ https://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=342902#comment-342902 ] Kees de Kooter commented on MNG-1977: - 8 years, 155 votes, 5 duplicates and 4 patches later I wonder: should I be proud or embarrassed that the issue is still unresolved? > Global dependency exclusions > > > Key: MNG-1977 > URL: https://jira.codehaus.org/browse/MNG-1977 > Project: Maven 2 & 3 > Issue Type: New Feature > Components: POM >Reporter: Kees de Kooter > Fix For: Issues to be reviewed for 4.x > > Attachments: global_excls_it-test_v2.patch, > global_excls_it-test_v3.patch, global_excls_maven3_v2.patch, > global_excls_maven3_v3.patch > > > I depend on some libraries, which in turn depend on something > (which in turn depend on something) that I don't want, because I declare > some other artifact in my pom.xml. > A concrete example: I don't want that the artifact "xerces" is imported in > my project because I declare to depend on "xercesImpl" which ships newer > libraries but with the same namespaces. > I guess I would need an "exclude transitive dependency at all", either > globally or from this and that artifact. I saw the tag, but it > forces me to be very verbose and have exact control on what is required by a > dependency. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-186) Create a rule for the reactor (RequireReactorSameVersion?)
[
https://jira.codehaus.org/browse/MENFORCER-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MENFORCER-186:
--
Description:
It would be nice having a rule which checks the consitency of a multi-module
build.
Say having a build with modules like this:
{code}
+-- root (pom.xml)
+--- m1 (pom.xml)
+--- m11 (pom.xml)
+--- m12 (pom.xml)
+--- m2 (pom.xml)
+--- m21 (pom.xml)
+--- m21 (pom.xml)
+--- m3 (pom.xml)
+--- m31 (pom.xml)
+--- m31 (pom.xml)
+--- m4 (pom.xml)
+--- m5 (pom.xml)
{code}
If you have for all modules the version 1.2.0-SNAPSHOT everything is fine.
But what sometimes it happens that someone changes something and you will find
things like the following:
The module m21 (pom.xml) has a parent version of 1.1.0-SNAPSHOT instead of
1.2.0-SNAPSHOT which means maven will try to find this version in repository
(you will get a warning during the build; But who reads warnings ;-))..
Or other things having module interdependencies and it happens someone does
something like this:
In m4 a dependency is written like this:
{code}
TheGroup
m21
1.1.0-SNAPSHOT
{code}
which will usually build (except your SNAPSHOT's have been deleted before), but
it is not correct. or better like this:
{code}
TheGroup
m21
1.1.0
{code}
This means it will be solved against a released version which usually is not
the intention in such cases.
So the rule should check if the groupId/artifactId belongs to the reactor and
check the consistency of the version of the dependencies etc. Also the parent
would be nice.
was:
It would be nice having a rule which checks the consitency of a multi-module
build.
Say having a build with modules like this:
{code}
+-- root (pom.xml)
+--- m1 (pom.xml)
+--- m11 (pom.xml)
+--- m12 (pom.xml)
+--- m2 (pom.xml)
+--- m21 (pom.xml)
+--- m21 (pom.xml)
+--- m3 (pom.xml)
+--- m31 (pom.xml)
+--- m31 (pom.xml)
+--- m4 (pom.xml)
+--- m5 (pom.xml)
{code}
If you have for all modules the version 1.2.0-SNAPSHOT everything is fine.
But what sometimes it happens that someone changes something and you will find
things like the following:
The module m21 (pom.xml) has no a parent version of 1.1.0-SNAPSHOT which means
maven will try to find this version in repository (you will get a warning
during the build; But who reads warnings ;-))..
Or other things having module interdependencies and it happens someone does
something like this:
In m4 a dependency is written like this:
{code}
TheGroup
m21
1.1.0-SNAPSHOT
{code}
which will usually build, but it is not correct. or better like this:
{code}
TheGroup
m21
1.1.0
{code}
This means it will be solved against the released version which usually is not
the intention in such cases.
So the rule should check if the groupId/artifactId belongs to the reactor and
check the consistency of the version of the dependencies etc. Also the parent
would be nice.
> Create a rule for the reactor (RequireReactorSameVersion?)
> --
>
> Key: MENFORCER-186
> URL: https://jira.codehaus.org/browse/MENFORCER-186
> Project: Maven Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Affects Versions: 1.3.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 1.4
>
>
> It would be nice having a rule which checks the consitency of a multi-module
> build.
> Say having a build with modules like this:
> {code}
> +-- root (pom.xml)
> +--- m1 (pom.xml)
>+--- m11 (pom.xml)
>+--- m12 (pom.xml)
> +--- m2 (pom.xml)
>+--- m21 (pom.xml)
>+--- m21 (pom.xml)
> +--- m3 (pom.xml)
>+--- m31 (pom.xml)
>+--- m31 (pom.xml)
> +--- m4 (pom.xml)
> +--- m5 (pom.xml)
> {code}
> If you have for all modules the version 1.2.0-SNAPSHOT everything is fine.
> But what sometimes it happens that someone changes something and you will
> find things like the following:
> The module m21 (pom.xml) has a parent version of 1.1.0-SNAPSHOT instead of
> 1.2.0-SNAPSHOT which means maven will try to find this version in repository
> (you will get a warning during the build; But who reads warnings ;-))..
> Or other things having module interdependencies and it happens someone does
> something like this:
> In m4 a dependency is written like this:
> {code}
>
>TheGroup
>m21
>1.1.0-SNAPSHOT
>
> {code}
> which will usually build (except your SNAPSHOT's have been deleted before),
> but it is not correct. or better like this:
> {code}
>
>Th
[jira] (MENFORCER-186) Create a rule for the reactor (RequireReactorSameVersion?)
[
https://jira.codehaus.org/browse/MENFORCER-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise updated MENFORCER-186:
--
Fix Version/s: 1.4
> Create a rule for the reactor (RequireReactorSameVersion?)
> --
>
> Key: MENFORCER-186
> URL: https://jira.codehaus.org/browse/MENFORCER-186
> Project: Maven Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Affects Versions: 1.3.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 1.4
>
>
> It would be nice having a rule which checks the consitency of a multi-module
> build.
> Say having a build with modules like this:
> {code}
> +-- root (pom.xml)
> +--- m1 (pom.xml)
>+--- m11 (pom.xml)
>+--- m12 (pom.xml)
> +--- m2 (pom.xml)
>+--- m21 (pom.xml)
>+--- m21 (pom.xml)
> +--- m3 (pom.xml)
>+--- m31 (pom.xml)
>+--- m31 (pom.xml)
> +--- m4 (pom.xml)
> +--- m5 (pom.xml)
> {code}
> If you have for all modules the version 1.2.0-SNAPSHOT everything is fine.
> But what sometimes it happens that someone changes something and you will
> find things like the following:
> The module m21 (pom.xml) has no a parent version of 1.1.0-SNAPSHOT which
> means maven will try to find this version in repository (you will get a
> warning during the build; But who reads warnings ;-))..
> Or other things having module interdependencies and it happens someone does
> something like this:
> In m4 a dependency is written like this:
> {code}
>
>TheGroup
>m21
>1.1.0-SNAPSHOT
>
> {code}
> which will usually build, but it is not correct. or better like this:
> {code}
>
>TheGroup
>m21
>1.1.0
>
> {code}
> This means it will be solved against the released version which usually is
> not the intention in such cases.
> So the rule should check if the groupId/artifactId belongs to the reactor and
> check the consistency of the version of the dependencies etc. Also the parent
> would be nice.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MENFORCER-186) Create a rule for the reactor (RequireReactorSameVersion?)
[
https://jira.codehaus.org/browse/MENFORCER-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Heinz Marbaise reassigned MENFORCER-186:
-
Assignee: Karl Heinz Marbaise
> Create a rule for the reactor (RequireReactorSameVersion?)
> --
>
> Key: MENFORCER-186
> URL: https://jira.codehaus.org/browse/MENFORCER-186
> Project: Maven Enforcer Plugin
> Issue Type: New Feature
> Components: Standard Rules
>Affects Versions: 1.3.1
>Reporter: Karl Heinz Marbaise
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 1.4
>
>
> It would be nice having a rule which checks the consitency of a multi-module
> build.
> Say having a build with modules like this:
> {code}
> +-- root (pom.xml)
> +--- m1 (pom.xml)
>+--- m11 (pom.xml)
>+--- m12 (pom.xml)
> +--- m2 (pom.xml)
>+--- m21 (pom.xml)
>+--- m21 (pom.xml)
> +--- m3 (pom.xml)
>+--- m31 (pom.xml)
>+--- m31 (pom.xml)
> +--- m4 (pom.xml)
> +--- m5 (pom.xml)
> {code}
> If you have for all modules the version 1.2.0-SNAPSHOT everything is fine.
> But what sometimes it happens that someone changes something and you will
> find things like the following:
> The module m21 (pom.xml) has no a parent version of 1.1.0-SNAPSHOT which
> means maven will try to find this version in repository (you will get a
> warning during the build; But who reads warnings ;-))..
> Or other things having module interdependencies and it happens someone does
> something like this:
> In m4 a dependency is written like this:
> {code}
>
>TheGroup
>m21
>1.1.0-SNAPSHOT
>
> {code}
> which will usually build, but it is not correct. or better like this:
> {code}
>
>TheGroup
>m21
>1.1.0
>
> {code}
> This means it will be solved against the released version which usually is
> not the intention in such cases.
> So the rule should check if the groupId/artifactId belongs to the reactor and
> check the consistency of the version of the dependencies etc. Also the parent
> would be nice.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
maven-jar-plugin:2.4 taking 15 minutes
Hi Team, OS - Ubuntu 12.04 TLS Issue:- 1) maven version - 3.2.1 - when i run plugin maven-jar-plugin:2.4 it completes in ~15 Minutes. 2) maven version - 2.2.1 - when i run plugin maven-jar-plugin:2.4 it completes in ~18 seconds. What could me the possible reason for maven 3.2.1 to be that slow? At the moment i have switched to maven 2.2.1 :-( Regards, vishal
