[jira] (MENFORCER-225) Add rules for mutually-exclusive profiles and banned profiles
[
https://jira.codehaus.org/browse/MENFORCER-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhijit Sarkar updated MENFORCER-225:
-
Attachment: site.patch
Add rules for mutually-exclusive profiles and banned profiles
-
Key: MENFORCER-225
URL: https://jira.codehaus.org/browse/MENFORCER-225
Project: Maven Enforcer Plugin
Issue Type: New Feature
Components: Rule API, Standard Rules
Affects Versions: 1.4
Reporter: Abhijit Sarkar
Fix For: 1.4.1
Attachments: enforcer-rules.patch, site.patch
I wrote 2 new enforces rules:
* The ability to specify a set of mutually-exclusive profiles (p1,p2:p1,p3
would mean p1 can't be active with either p2 or p3). This has been discussed
on [this
thread|http://stackoverflow.com/questions/24855678/enforce-exactly-one-of-two-maven-profiles]
on SO.
* The ability to ban profiles (the contrary of {{requireActiveProfile}}). p1,
p2 would mean neither p1 nor p2 can be active for this build.
Both of these rules support wildcards and consider inherited profiles as
well. I've attached a patch complete with unit test cases. {{mvn clean
install}} passes in local. These are built on v1.4 of the rules.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MENFORCER-225) Add rules for mutually-exclusive profiles and banned profiles
[
https://jira.codehaus.org/browse/MENFORCER-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhijit Sarkar updated MENFORCER-225:
-
Attachment: (was: site.patch)
Add rules for mutually-exclusive profiles and banned profiles
-
Key: MENFORCER-225
URL: https://jira.codehaus.org/browse/MENFORCER-225
Project: Maven Enforcer Plugin
Issue Type: New Feature
Components: Rule API, Standard Rules
Affects Versions: 1.4
Reporter: Abhijit Sarkar
Fix For: 1.4.1
Attachments: enforcer-rules.patch, site.patch
I wrote 2 new enforces rules:
* The ability to specify a set of mutually-exclusive profiles (p1,p2:p1,p3
would mean p1 can't be active with either p2 or p3). This has been discussed
on [this
thread|http://stackoverflow.com/questions/24855678/enforce-exactly-one-of-two-maven-profiles]
on SO.
* The ability to ban profiles (the contrary of {{requireActiveProfile}}). p1,
p2 would mean neither p1 nor p2 can be active for this build.
Both of these rules support wildcards and consider inherited profiles as
well. I've attached a patch complete with unit test cases. {{mvn clean
install}} passes in local. These are built on v1.4 of the rules.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-212) Failed to initialize ear modules: Unknown artifact type[mar] for addressing
[
https://jira.codehaus.org/browse/MEAR-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MEAR-212:
-
Fix Version/s: waiting-for-feedback
Failed to initialize ear modules: Unknown artifact type[mar] for addressing
---
Key: MEAR-212
URL: https://jira.codehaus.org/browse/MEAR-212
Project: Maven Ear Plugin
Issue Type: Bug
Affects Versions: 2.10
Reporter: David Hoffer
Fix For: waiting-for-feedback
I'm trying to generate and ear file but I'm getting the following message:
Failed to initialize ear modules: Unknown artifact type[mar] for addressing
(full debug stack trace is below)
However I don't have any mar artifacts in my dependencies. What I do have is
a war that has 4 mar files added as resources and I'm making a ear with the
skinny war feature.
Why would the ear plugin give this error when it has no nothing to do with
the mar resources in the war...or perhaps this error has nothing to do with
those resources, not sure.
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml
(default-generate-application-xml) on project coreservices-ear: Failed to
initialize ear modules: Unknown artifact type[mar] for addressing - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml
(default-generate-application-xml) on project coreservices-ear: Failed to
initialize ear modules
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
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:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
initialize ear modules
at
org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:260)
at
org.apache.maven.plugin.ear.GenerateApplicationXmlMojo.execute(GenerateApplicationXmlMojo.java:162)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: org.apache.maven.plugin.ear.UnknownArtifactTypeException: Unknown
artifact type[mar] for addressing
at
org.apache.maven.plugin.ear.EarModuleFactory.newEarModule(EarModuleFactory.java:88)
at
org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:250)
... 22 more
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-159) encoding when filtering resources
[ https://jira.codehaus.org/browse/MEAR-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MEAR-159: - Fix Version/s: (was: waiting-for-feedback) 2.10.1 encoding when filtering resources - Key: MEAR-159 URL: https://jira.codehaus.org/browse/MEAR-159 Project: Maven Ear Plugin Issue Type: Improvement Affects Versions: 2.8 Reporter: Alex Kaigorodov Fix For: 2.10.1 Attachments: maven-ear-plugin-2.10-test-project-resources-encoding.zip, maven-ear-plugin-test-project-resources-encoding.zip Resources of our ear project contain non-ascii characters. This xml-files in windows-1251. We use filtering resources when building ear. Building in the dev environment (Windows, file.encoding = Cp1251) goes well. The build at the CI-server (Linux, file.encoding = UTF-8) non-ascii characters in xml-files are replaced with a sequence of bytes 'efbfbd'. It would be convenient to be able to specify the encoding for the ear resources, similar to how we can do it in the maven-resources-plugin. Sample project attached. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-159) encoding when filtering resources
[ https://jira.codehaus.org/browse/MEAR-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise closed MEAR-159. Resolution: Fixed Assignee: Karl-Heinz Marbaise Fixed in [r1661423|http://svn.apache.org/r1661423]. encoding when filtering resources - Key: MEAR-159 URL: https://jira.codehaus.org/browse/MEAR-159 Project: Maven Ear Plugin Issue Type: Improvement Affects Versions: 2.8 Reporter: Alex Kaigorodov Assignee: Karl-Heinz Marbaise Fix For: 2.10.1 Attachments: maven-ear-plugin-2.10-test-project-resources-encoding.zip, maven-ear-plugin-test-project-resources-encoding.zip Resources of our ear project contain non-ascii characters. This xml-files in windows-1251. We use filtering resources when building ear. Building in the dev environment (Windows, file.encoding = Cp1251) goes well. The build at the CI-server (Linux, file.encoding = UTF-8) non-ascii characters in xml-files are replaced with a sequence of bytes 'efbfbd'. It would be convenient to be able to specify the encoding for the ear resources, similar to how we can do it in the maven-resources-plugin. Sample project attached. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MEAR-159) encoding when filtering resources
[
https://jira.codehaus.org/browse/MEAR-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=363725#comment-363725
]
Karl-Heinz Marbaise commented on MEAR-159:
--
Hi Alex, are you able to check an SNAPSHOT if the change is now doing what
intended to be. Based on your example project i can say it works.
If i check the original file:
{code}
$ hexdump src/main/application/META-INF/test.xml
000 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 31
010 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d 22 77 69
020 6e 64 6f 77 73 2d 31 32 35 31 22 3f 3e 0d 0a 3c
030 74 65 73 74 20 6e 61 6d 65 3d 22 d2 e5 f1 f2 22
040 2f 3e
042
{code}
and the created file with encoding set as in the example:
{code}
$ hexdump
target/maven-ear-plugin-test-project-resources-encoding-99.0/META-INF/test.xml
000 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 31
010 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d 22 77 69
020 6e 64 6f 77 73 2d 31 32 35 31 22 3f 3e 0d 0a 3c
030 74 65 73 74 20 6e 61 6d 65 3d 22 d2 e5 f1 f2 22
040 2f 3e
042
{code}
If i don't set the encoding in the pom file i will get a wrong result (which is
based on the default encoding):
{code}
$ hexdump
target/maven-ear-plugin-test-project-resources-encoding-99.0/META-INF/test.xml
000 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 31
010 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d 22 77 69
020 6e 64 6f 77 73 2d 31 32 35 31 22 3f 3e 0d 0a 3c
030 74 65 73 74 20 6e 61 6d 65 3d 22 ef bf bd ef bf
040 bd ef bf bd ef bf bd 22 2f 3e
04a
{code}
I have provided an development version which can be seen here:
{code}
Uploading:
https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-ear-plugin/2.11-SNAPSHOT/maven-ear-plugin-2.11-20150221.183218-97.jar
Uploaded:
https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-ear-plugin/2.11-SNAPSHOT/maven-ear-plugin-2.11-20150221.183218-97.jar
(90 KB at 31.9 KB/sec)
Uploading:
https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-ear-plugin/2.11-SNAPSHOT/maven-ear-plugin-2.11-20150221.183218-97.pom
Uploaded:
https://repository.apache.org/content/repositories/snapshots/org/apache/maven/plugins/maven-ear-plugin/2.11-SNAPSHOT/maven-ear-plugin-2.11-20150221.183218-97.pom
(10 KB at 4.1 KB/sec)
{code}
encoding when filtering resources
-
Key: MEAR-159
URL: https://jira.codehaus.org/browse/MEAR-159
Project: Maven Ear Plugin
Issue Type: Improvement
Affects Versions: 2.8
Reporter: Alex Kaigorodov
Assignee: Karl-Heinz Marbaise
Fix For: 2.10.1
Attachments:
maven-ear-plugin-2.10-test-project-resources-encoding.zip,
maven-ear-plugin-test-project-resources-encoding.zip
Resources of our ear project contain non-ascii characters. This xml-files in
windows-1251. We use filtering resources when building ear.
Building in the dev environment (Windows, file.encoding = Cp1251) goes well.
The build at the CI-server (Linux, file.encoding = UTF-8) non-ascii
characters in xml-files are replaced with a sequence of bytes 'efbfbd'.
It would be convenient to be able to specify the encoding for the ear
resources, similar to how we can do it in the maven-resources-plugin.
Sample project attached.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-479) Find duplicate properties
[ https://jira.codehaus.org/browse/MDEP-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl-Heinz Marbaise updated MDEP-479: - Fix Version/s: waiting-for-feedback Find duplicate properties - Key: MDEP-479 URL: https://jira.codehaus.org/browse/MDEP-479 Project: Maven Dependency Plugin Issue Type: New Feature Reporter: chibbe ... Fix For: waiting-for-feedback Would be good if a used property duplicated properties can be found as well. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MENFORCER-225) Add rules for mutually-exclusive profiles and banned profiles
Abhijit Sarkar created MENFORCER-225:
Summary: Add rules for mutually-exclusive profiles and banned
profiles
Key: MENFORCER-225
URL: https://jira.codehaus.org/browse/MENFORCER-225
Project: Maven Enforcer Plugin
Issue Type: New Feature
Components: Rule API, Standard Rules
Affects Versions: 1.4
Reporter: Abhijit Sarkar
Attachments: enforcer-rules.patch
I wrote 2 new enforces rules:
* The ability to specify a set of mutually-exclusive profiles (p1,p2:p1,p3
would mean p1 can't be active with either p2 or p3). This has been discussed on
[this
thread|http://stackoverflow.com/questions/24855678/enforce-exactly-one-of-two-maven-profiles]
on SO.
* The ability to ban profiles (the contrary of {{requireActiveProfile}}). p1,
p2 would mean neither p1 nor p2 can be active for this build.
Both of these rules support wildcards and consider inherited profiles as well.
I've attached a patch complete with unit test cases. {{mvn clean install}}
passes in local. These are built on v1.4 of the rules.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] [Commented] (MPOM-47) Source release assembly can't do tar.gz only
[ https://issues.apache.org/jira/browse/MPOM-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14330172#comment-14330172 ] Dennis Lundberg commented on MPOM-47: - Note that apache-source-release-assembly-descriptor-1.0.5 has not been released yet. I'll push for a release. Source release assembly can't do tar.gz only Key: MPOM-47 URL: https://issues.apache.org/jira/browse/MPOM-47 Project: Maven POMs Issue Type: Improvement Components: asf Reporter: Christopher Tubbs Fix For: ASF-17 The source-release-assembly execution of the maven-assembly-plugin doesn't offer any way to specify to build a tarball (tar.gz) only. By default, it builds a zip file. One can override the plugin execution to force it to build both a zip and a tarball, by setting sourceReleaseAssemblyDescriptor to source-release-zip-tar. However, there's no way to get it to build only the tarball, unless you do convoluted things like in [this example|http://search.maven.org/remotecontent?filepath=org/apache/accumulo/accumulo-project/1.5.0/accumulo-project-1.5.0.pom], or if you override the apache-release profile entirely. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (MCOMPILER-174) Maven compiler plugin excludes doesn't work all the time
[ https://jira.codehaus.org/browse/MCOMPILER-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=363716#comment-363716 ] Thomas Broyer commented on MCOMPILER-174: - MCOMPILER-26 got it right, but this was later reverted in MCOMPILER-98. Maven compiler plugin excludes doesn't work all the time -- Key: MCOMPILER-174 URL: https://jira.codehaus.org/browse/MCOMPILER-174 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 2.4, 2.5 Environment: N/A Reporter: Matthew Lavin When you set a source file as configuration excludes excludecom/you/example.java/exclude /excludes /configuration it doesn't pass the file in with the list of .java files to javac. However, it still passes in the ./src/ directory under the -sourcepath option to the javac command. Thus, javac still knows that the file exists and can try to compile it anyways under certain circumstances. The passing of ./src/ under -sourcepath is redundant anyways, as every single file to be compiled is passed (in my case, all 391 source files) to javac. The only possible result from passing ./src/ (or at least the only one I can think of) is that a file which is in your ./src/ directory yet excluded by the maven-compiler-plugin can still be seen (and compiled) by javac. This can cause inexplicable results and a lot of confusion since it operates in a counter-intuitive way. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-478) dependency:copy-dependencies always overwrites if prependGroupId is true
[
https://jira.codehaus.org/browse/MDEP-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MDEP-478:
-
Fix Version/s: 2.10.1
dependency:copy-dependencies always overwrites if prependGroupId is true
--
Key: MDEP-478
URL: https://jira.codehaus.org/browse/MDEP-478
Project: Maven Dependency Plugin
Issue Type: Bug
Components: copy, copy-dependencies
Affects Versions: 2.10
Reporter: Julius Davies
Priority: Minor
Fix For: 2.10.1
Attachments: copy-dependencies-2015-02-19.patch
dependency:copy-dependencies always overwrites if prependGroupId is true.
Before my patch:
{code}
[INFO] Copying
/home/julius/.m2/repository/commons-codec/commons-codec/1.6/commons-codec-1.6.jar
to /ear/APP-INF/lib/commons-codec.commons-codec-1.6.jar
{code}
After my patch:
{code}
[INFO] commons-codec:commons-codec:jar:1.6 already exists in destination.
{code}
I suspect this patch might also fix MDEP-294, MDEP-444 and MDEP-458.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MDEP-479) Find duplicate properties
[ https://jira.codehaus.org/browse/MDEP-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=363718#comment-363718 ] Karl-Heinz Marbaise commented on MDEP-479: -- Can you please describe what your problem is or what you like to have improved in a more detailed way...best would be to have an example project which show the problem / improvement etc. ? Find duplicate properties - Key: MDEP-479 URL: https://jira.codehaus.org/browse/MDEP-479 Project: Maven Dependency Plugin Issue Type: New Feature Reporter: chibbe ... Would be good if a used property duplicated properties can be found as well. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MCOMPILER-122) -sourcepath shall include resources
[ https://jira.codehaus.org/browse/MCOMPILER-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=363715#comment-363715 ] Thomas Broyer commented on MCOMPILER-122: - This is a bad idea IMO. First, annotation processors shouldn't depend on non-java inputs, because JSR-269 doesn't allow you to track dependencies of generated sources/classes/resources to anything else than elements: http://docs.oracle.com/javase/7/docs/api/javax/annotation/processing/Filer.html (File#getResource is rather meant to read resources that were previously generated by File#createResource, but should still be used with care). Also, including target/classes to sourcepath could lead to classes being compiled or recompiled when they shouldn't (when you have *.java files as resources but not sources). Fortunately, there'd be an easy workaround here: exclude *.java files from project.build.resources and use resources:copy-resources after the compile phase to copy the *.java files; that'd still be a hack if you ask me. -sourcepath shall include resources --- Key: MCOMPILER-122 URL: https://jira.codehaus.org/browse/MCOMPILER-122 Project: Maven Compiler Plugin Issue Type: Bug Affects Versions: 2.1 Reporter: Milos Kleint annotation processors which load non-Java resources from the sourcepath, will currently get only the src/main/java folder. Unfortunately just adding src/main/resources to -sourcepath does not suffice, due to a bug in javac: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6929404 see MCOMPILER-98 for more -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MDEP-478) dependency:copy-dependencies always overwrites if prependGroupId is true
[
https://jira.codehaus.org/browse/MDEP-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise closed MDEP-478.
Resolution: Fixed
Assignee: Karl-Heinz Marbaise
Fixed in [r1661356|http://svn.apache.org/r1661356]
Patch of Julius Davies applied. Thanks for the patch.
dependency:copy-dependencies always overwrites if prependGroupId is true
--
Key: MDEP-478
URL: https://jira.codehaus.org/browse/MDEP-478
Project: Maven Dependency Plugin
Issue Type: Bug
Components: copy, copy-dependencies
Affects Versions: 2.10
Reporter: Julius Davies
Assignee: Karl-Heinz Marbaise
Priority: Minor
Fix For: 2.10.1
Attachments: copy-dependencies-2015-02-19.patch
dependency:copy-dependencies always overwrites if prependGroupId is true.
Before my patch:
{code}
[INFO] Copying
/home/julius/.m2/repository/commons-codec/commons-codec/1.6/commons-codec-1.6.jar
to /ear/APP-INF/lib/commons-codec.commons-codec-1.6.jar
{code}
After my patch:
{code}
[INFO] commons-codec:commons-codec:jar:1.6 already exists in destination.
{code}
I suspect this patch might also fix MDEP-294, MDEP-444 and MDEP-458.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MENFORCER-225) Add rules for mutually-exclusive profiles and banned profiles
[
https://jira.codehaus.org/browse/MENFORCER-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhijit Sarkar updated MENFORCER-225:
-
Attachment: site.patch
Attached patch for rule usage.
Add rules for mutually-exclusive profiles and banned profiles
-
Key: MENFORCER-225
URL: https://jira.codehaus.org/browse/MENFORCER-225
Project: Maven Enforcer Plugin
Issue Type: New Feature
Components: Rule API, Standard Rules
Affects Versions: 1.4
Reporter: Abhijit Sarkar
Fix For: 1.4.1
Attachments: enforcer-rules.patch, site.patch
I wrote 2 new enforces rules:
* The ability to specify a set of mutually-exclusive profiles (p1,p2:p1,p3
would mean p1 can't be active with either p2 or p3). This has been discussed
on [this
thread|http://stackoverflow.com/questions/24855678/enforce-exactly-one-of-two-maven-profiles]
on SO.
* The ability to ban profiles (the contrary of {{requireActiveProfile}}). p1,
p2 would mean neither p1 nor p2 can be active for this build.
Both of these rules support wildcards and consider inherited profiles as
well. I've attached a patch complete with unit test cases. {{mvn clean
install}} passes in local. These are built on v1.4 of the rules.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MENFORCER-225) Add rules for mutually-exclusive profiles and banned profiles
[
https://jira.codehaus.org/browse/MENFORCER-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl-Heinz Marbaise updated MENFORCER-225:
--
Fix Version/s: 1.4.1
Add rules for mutually-exclusive profiles and banned profiles
-
Key: MENFORCER-225
URL: https://jira.codehaus.org/browse/MENFORCER-225
Project: Maven Enforcer Plugin
Issue Type: New Feature
Components: Rule API, Standard Rules
Affects Versions: 1.4
Reporter: Abhijit Sarkar
Fix For: 1.4.1
Attachments: enforcer-rules.patch
I wrote 2 new enforces rules:
* The ability to specify a set of mutually-exclusive profiles (p1,p2:p1,p3
would mean p1 can't be active with either p2 or p3). This has been discussed
on [this
thread|http://stackoverflow.com/questions/24855678/enforce-exactly-one-of-two-maven-profiles]
on SO.
* The ability to ban profiles (the contrary of {{requireActiveProfile}}). p1,
p2 would mean neither p1 nor p2 can be active for this build.
Both of these rules support wildcards and consider inherited profiles as
well. I've attached a patch complete with unit test cases. {{mvn clean
install}} passes in local. These are built on v1.4 of the rules.
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
[jira] (MEAR-212) Failed to initialize ear modules: Unknown artifact type[mar] for addressing
[
https://jira.codehaus.org/browse/MEAR-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=363726#comment-363726
]
David Hoffer commented on MEAR-212:
---
Yes that is what was the problem here, sorry I'm not able to provide a full
working project.
Failed to initialize ear modules: Unknown artifact type[mar] for addressing
---
Key: MEAR-212
URL: https://jira.codehaus.org/browse/MEAR-212
Project: Maven Ear Plugin
Issue Type: Bug
Affects Versions: 2.10
Reporter: David Hoffer
Fix For: waiting-for-feedback
I'm trying to generate and ear file but I'm getting the following message:
Failed to initialize ear modules: Unknown artifact type[mar] for addressing
(full debug stack trace is below)
However I don't have any mar artifacts in my dependencies. What I do have is
a war that has 4 mar files added as resources and I'm making a ear with the
skinny war feature.
Why would the ear plugin give this error when it has no nothing to do with
the mar resources in the war...or perhaps this error has nothing to do with
those resources, not sure.
{code}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml
(default-generate-application-xml) on project coreservices-ear: Failed to
initialize ear modules: Unknown artifact type[mar] for addressing - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-ear-plugin:2.10:generate-application-xml
(default-generate-application-xml) on project coreservices-ear: Failed to
initialize ear modules
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
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:606)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to
initialize ear modules
at
org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:260)
at
org.apache.maven.plugin.ear.GenerateApplicationXmlMojo.execute(GenerateApplicationXmlMojo.java:162)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: org.apache.maven.plugin.ear.UnknownArtifactTypeException: Unknown
artifact type[mar] for addressing
at
org.apache.maven.plugin.ear.EarModuleFactory.newEarModule(EarModuleFactory.java:88)
at
org.apache.maven.plugin.ear.AbstractEarMojo.execute(AbstractEarMojo.java:250)
... 22 more
{code}
--
This message was sent by Atlassian JIRA
(v6.1.6#6162)
