[jira] Created: (MENFORCER-124) Rule-scoped fail property
Rule-scoped fail property - Key: MENFORCER-124 URL: https://jira.codehaus.org/browse/MENFORCER-124 Project: Maven 2.x Enforcer Plugin Issue Type: New Feature Affects Versions: 1.0.1 Reporter: marko asplund The fail property is plugin configuration scoped. It would be useful to be able to set it separately per rule. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-781) Filter JVM's challenge to connect to debugger and print it to console even if redirectTestOutputToFile == true.
Filter JVM's challenge to connect to debugger and print it to console even if redirectTestOutputToFile == true. --- Key: SUREFIRE-781 URL: https://jira.codehaus.org/browse/SUREFIRE-781 Project: Maven Surefire Issue Type: Improvement Components: Maven Surefire Plugin Affects Versions: 2.10 Reporter: Ondrej Zizka We have come to an interesting problem with Arquillian. It starts a container instance from within the test. If one wants to start the server in debug mode with server=y,suspend=y then the JVM's notice that it's waiting for the debugger to connect is not shown to user. Instead, the test run looks like being stuck. This is quite confusing, especially in complex continuous integration use cases. I suggest to (optionally) filter test's output for these notices and print them to the console, even if redirectTestOutputToFile == true. ConsoleOutputFileReporter#writeMessage( byte[] b, int off, int len ) could be adjusted for this purpose. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-308) Should ask input for requiredProperty with defaultValue
[ https://jira.codehaus.org/browse/ARCHETYPE-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282059#comment-282059 ] vychtrle commented on ARCHETYPE-308: Ou my, I would so love to see this fixed... Doesn't make sense like this... It asks you first for artifactId, groupId, version and packaging then you have to say N to have a chance to change the custom properties from default values, BUT it asks you again for artifactId, groupId, version and packaging ... and then the properties finally ... > Should ask input for requiredProperty with defaultValue > --- > > Key: ARCHETYPE-308 > URL: https://jira.codehaus.org/browse/ARCHETYPE-308 > Project: Maven Archetype > Issue Type: Bug >Reporter: Grégory Joseph > Attachments: ARCHETYPE-200.patch > > > It seems that if a requiredProperty is defined with a defaultValue, the > generate mojo does not ask user input. In my opinion it should, just like it > does it for the version. > DefaultArchetypeFactory lines 156-168 seem to be the culprit and I'll attach > a patch that might fix this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-81) Request enhancement to pattern matching for warSourceIncludes/warSourceExcludes functionality (regular expressions?)
[
https://jira.codehaus.org/browse/MWAR-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282029#comment-282029
]
Nicolas Marcotte commented on MWAR-81:
--
That the workaround that motivating myself to write that patch since I moved
from atrocities like that:{code:xml}
**/A*.jar,**/B*.jar,**/C*.jar,**/M*.jar,**/O*.jar,
**/*P*.jar,**/R*.jar,**/a*.jar,**/b*.jar,**/c*.jar,
**/d*.jar,**/f*.jar,**/k*.jar,**/i*.jar,**/j*.jar,
**/l*.jar,**/m*.jar,**/r*.jar,**/sa*.jar,**/se*.jar,
**/v*.jar,**/x*.jar,
**/Struts-Layout.jar,**/struts-menu.jar,**/struts.jar
{code}
to
{code:xml}
**/*.jar,!**/*.SIRUS.jar
{code}
> Request enhancement to pattern matching for
> warSourceIncludes/warSourceExcludes functionality (regular expressions?)
>
>
> Key: MWAR-81
> URL: https://jira.codehaus.org/browse/MWAR-81
> Project: Maven 2.x WAR Plugin
> Issue Type: Wish
> Environment: n/a
>Reporter: Bryan Loofbourrow
>Priority: Minor
> Attachments: maven-war-plugin-2.1.1-NM.patch
>
>
> The Maven War Plugin currently permits choosing what files will wind up in
> the .war. It does this via two parameters, warSourceIncludes, and
> warSourceExcludes. The rule appears to be that the includes are computed,
> and a list of matches made, then that list is run against the excludes, and
> any matches taken out of the include list.
> The only wildcards that appear to be supported are *, **, and ?.
> That doesn't work well if you are packaging wars in ears, and therefore want
> to exclude all jars from the war, except for one or two that have to be in
> the war in order to run properly. "Exclude all but foo.jar and bar.jar" just
> doesn't translate well to "here's your simple include template, here's your
> simple exclude template" representation, at least with current wildcards.
> So this is a wish specifically for something to address the "exclude all but
> x, y, and z" need for war source includes/excludes, and a suggestion that it
> might be best to deprecate the warSourceIncludes/warSourceExcludes approach
> in favor of a single parameter that supports regular expressions instead.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-346) Directory name of root generated module
[
https://jira.codehaus.org/browse/ARCHETYPE-346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=282010#comment-282010
]
Fred Bricon commented on ARCHETYPE-346:
---
I'm interested in this feature too. I need the root directory to be named after
some pattern, similar to modules currently are (ex : ${rootArtifactId}-parent ).
Hervé, I believe modifying the archetype descriptor might be better suited for
tooling integration : no need to modify existing UI (I'm speaking for m2e) to
take advantage of such feature, as opposed to the generate plugin route.
Although we'd still need to embed the new archetype plugin.
If the proposed targetDirName were added as an optional attribute to the
descriptor, what would be the issue?
> Directory name of root generated module
> ---
>
> Key: ARCHETYPE-346
> URL: https://jira.codehaus.org/browse/ARCHETYPE-346
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Generator
>Affects Versions: 2.1
>Reporter: Gael Lalire
>Priority: Minor
>
> It seems that the root directory name have to be the ${artifactId}.
> I propose an addition in archetype-metadata.xml.
>
>
> So we can also remove the ${artifactId} in the name of root directory.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MWAR-9) WAR plugin should support minimal WARs for inclusion within an EAR
[ https://jira.codehaus.org/browse/MWAR-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MWAR-9: --- Attachment: (was: maven-war-plugin-2.1.1-NM.patch) > WAR plugin should support minimal WARs for inclusion within an EAR > -- > > Key: MWAR-9 > URL: https://jira.codehaus.org/browse/MWAR-9 > Project: Maven 2.x WAR Plugin > Issue Type: Improvement >Reporter: Mike Perham >Assignee: Stephane Nicoll > Fix For: 2.2 > > Attachments: AbstractWarMojo.patch > > > I noticed that when I build a WAR, I get a gigantic WEB-INF/lib with all my > deps. This is fine for a default but maven should also support "skeleton" > WARs which will be packaged within an EAR. We have EARs which package 3-4 > WARs each and to have the deps duplicated within each WAR means we cannot > have shared data (since the classes are loaded within each WAR's classloader, > rather than by the parent EAR's classloader). It also means 80MB EARs! :-) > It seems like two things need to happen: > 1) Add a "skeleton" flag which prevents copying any dependencies to > WEB-INF/lib. > 2) Instead generate a META-INF/MANIFEST.MF which has a Class-Path entry which > lists the relative locations of the dependencies within the parent EAR. > Fabrice has basically the same idea written down here. Starting with "- for > a War..." : > http://marc.theaimsgroup.com/?l=turbine-maven-user&m=112737860024530&w=2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4265) Properties in "system"-scope dependencies breaks transitive dependency resolution
[
https://jira.codehaus.org/browse/MNG-4265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281996#comment-281996
]
Sarah Gerweck commented on MNG-4265:
This is a really annoying issue.
> Properties in "system"-scope dependencies breaks transitive dependency
> resolution
> -
>
> Key: MNG-4265
> URL: https://jira.codehaus.org/browse/MNG-4265
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, Dependencies
>Affects Versions: 2.0.9, 2.0.10, 2.1.0-M1, 2.1.0, 2.2.0
>Reporter: Marc Wilhelm
> Fix For: Issues to be reviewed for 3.x
>
> Attachments: maven-properties-bug.tgz
>
>
> If a used dependency (see artifact "component" in the attached example)
> contains itself a system-scope dependency (here "${JAVA_HOME}/lib/tools.jar")
> with properties, all transitive dependencies are ignored by the following
> warning:
> {code:xml}
> [WARNING] POM for 'maven.bug:component:pom:0.0.1-SNAPSHOT:compile' is invalid.
> Its dependencies (if any) will NOT be available to the current build.
> {code}
> NOTE: The transitive dependencies are handled correctly when building from a
> (reactor) project, which builds both modules, the "component" and the "app".
> But it fails when trying to build the "app" isolated as single project.
> If running the sample project against maven (2.0.4 up to) 2.0.8 it works
> fine, without problems.
> Steps to reproduce:
> - extract sample project
> - ensure environment var JAVA_HOME is set properly
> - build top level project by "mvn clean install". This should build without
> warnings
> - change into sub folder "app"
> - build module "app" via "mvn clean install". You should get the warning
> about an invalid used pom.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-81) Request enhancement to pattern matching for warSourceIncludes/warSourceExcludes functionality (regular expressions?)
[
https://jira.codehaus.org/browse/MWAR-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=281986#comment-281986
]
Vincent Massol commented on MWAR-81:
Thanks Nicolas.
I had found a very bad workaround (but working):
{code}
WEB-INF/lib/xwiki-platform-oldcore-*.jar,WEB-INF/lib/batik-js-*.jar,WEB-INF/lib/commons-logging-*.jar,WEB-INF/lib/log4j-??.jar
{code}
> Request enhancement to pattern matching for
> warSourceIncludes/warSourceExcludes functionality (regular expressions?)
>
>
> Key: MWAR-81
> URL: https://jira.codehaus.org/browse/MWAR-81
> Project: Maven 2.x WAR Plugin
> Issue Type: Wish
> Environment: n/a
>Reporter: Bryan Loofbourrow
>Priority: Minor
> Attachments: maven-war-plugin-2.1.1-NM.patch
>
>
> The Maven War Plugin currently permits choosing what files will wind up in
> the .war. It does this via two parameters, warSourceIncludes, and
> warSourceExcludes. The rule appears to be that the includes are computed,
> and a list of matches made, then that list is run against the excludes, and
> any matches taken out of the include list.
> The only wildcards that appear to be supported are *, **, and ?.
> That doesn't work well if you are packaging wars in ears, and therefore want
> to exclude all jars from the war, except for one or two that have to be in
> the war in order to run properly. "Exclude all but foo.jar and bar.jar" just
> doesn't translate well to "here's your simple include template, here's your
> simple exclude template" representation, at least with current wildcards.
> So this is a wish specifically for something to address the "exclude all but
> x, y, and z" need for war source includes/excludes, and a suggestion that it
> might be best to deprecate the warSourceIncludes/warSourceExcludes approach
> in favor of a single parameter that supports regular expressions instead.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
