[jira] (MSITE-694) When maven.site.skip=true, mvn site:jar doesn't skip the generation of the jar
Ramón Rial created MSITE-694: Summary: When maven.site.skip=true, mvn site:jar doesn't skip the generation of the jar Key: MSITE-694 URL: https://jira.codehaus.org/browse/MSITE-694 Project: Maven 2.x and 3.x Site Plugin Issue Type: Bug Affects Versions: 3.3, 3.2, 3.1 Environment: No relevance Reporter: Ramón Rial Priority: Minor Attachments: minimal-site-jar.zip site:jar uses maven.site.skip only to avoid launch the site:site, but generates the -site.jar file with META-INF information. I've attached a minimal Maven project to test this. You can launch it to test with maven-site-plugin version 3.3: mvn -Dmaven.skip.test=true clean site:jar You can also launch with: mvn -Dsite.version=3.1 -Dmaven.skip.test=true clean site:jar where site.version is the version of the maven-site-plugin to test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-694) When maven.site.skip=true, mvn site:jar doesn't skip the generation of the jar
[ https://jira.codehaus.org/browse/MSITE-694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ramón Rial updated MSITE-694: - Attachment: minimal-site-jar.zip The minimal project to test the problem > When maven.site.skip=true, mvn site:jar doesn't skip the generation of the jar > -- > > Key: MSITE-694 > URL: https://jira.codehaus.org/browse/MSITE-694 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug >Affects Versions: 3.1, 3.2, 3.3 > Environment: No relevance >Reporter: Ramón Rial >Priority: Minor > Attachments: minimal-site-jar.zip > > > site:jar uses maven.site.skip only to avoid launch the site:site, but > generates the -site.jar file with META-INF information. > I've attached a minimal Maven project to test this. > You can launch it to test with maven-site-plugin version 3.3: > mvn -Dmaven.skip.test=true clean site:jar > You can also launch with: > mvn -Dsite.version=3.1 -Dmaven.skip.test=true clean site:jar > where site.version is the version of the maven-site-plugin to test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRESOURCES-174) Loose encoding when filter resource
[ https://jira.codehaus.org/browse/MRESOURCES-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=328393#comment-328393 ] Emeric MARTINEAU commented on MRESOURCES-174: - Hi, I look if easy to make a patch. For this new feature, the class org.apache.maven.model.PatternSet (part as Maven-Model) need to update cause include/exclude are String. Actually, you cannot attach an encoding to each include/exclude. Step for this feature is : - submit a patch for Maven-Model (to update org.apache.maven.model.PatternSet), - submit a patch for Maven-Filtering (to use the new org.apache.maven.model.Resource < PatternSet), - submit a patch for Maven-Ressource-Plugin (to use nex maven filtering). I don't know if it's possible to submit a patch for all or if submit one patch for each. Regards, > Loose encoding when filter resource > --- > > Key: MRESOURCES-174 > URL: https://jira.codehaus.org/browse/MRESOURCES-174 > Project: Maven 2.x Resources Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: Maven 3.0.4 >Reporter: Lefebvre JF > > When filtering resource the build.source.encoding is taken enven if there are > multiple encoding for properties, xml, ... > Why do not use api to detect the original encoding ? > http://code.google.com/p/juniversalchardet/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-159) Add goal recommend which will only warn but never fail a build
[
https://jira.codehaus.org/browse/MENFORCER-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=328409#comment-328409
]
Mirko Friedenhagen commented on MENFORCER-159:
--
* LOL, sometimes a fluffy finger is sufficient, so this would the loving part
:-).
* You are right that this may be achieved with two execution blocks as well,
but this is the same for failsafe: most of the stuff failsafe does could be
done with surefire.
* Execution blocks with their IDs and their linkage to lifecycles are IMO more
complicated than having to different mojos which may even be invoked from the
CLI. And the messages are a bit different, see {{createRuleMessage}} :-)
> Add goal recommend which will only warn but never fail a build
> --
>
> Key: MENFORCER-159
> URL: https://jira.codehaus.org/browse/MENFORCER-159
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Plugin
>Affects Versions: 1.3
>Reporter: Mirko Friedenhagen
> Attachments: recommend-mojo.patch
>
>
> In our company's parent POM we define a lot of rules, some of which are
> controversial or may not be easily fulfilled. The patch I attach defines a
> new goal "recommend" which will always warn but never fail. It's
> configuration is done by a new element {{recommendations}} which just holds a
> sequence of rules.
> I extracted most of EnforceMojo to AbstractEnforceMojo to avoid code
> duplication. I added an invoker test and all tests ran successfully.
> See https://github.com/apache/maven-enforcer/pull/4 as well for easier review.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-156) Upgrading maven-enforcer-plugin from 1.2 to 1.3 breaks maven-assembly-plugin
[ https://jira.codehaus.org/browse/MENFORCER-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Scholte updated MENFORCER-156: - Priority: Blocker (was: Major) change priority to blocker since there's no other workaround then using another version. > Upgrading maven-enforcer-plugin from 1.2 to 1.3 breaks maven-assembly-plugin > > > Key: MENFORCER-156 > URL: https://jira.codehaus.org/browse/MENFORCER-156 > Project: Maven 2.x Enforcer Plugin > Issue Type: Bug >Affects Versions: 1.3 > Environment: Ubuntu 12.04 fully patched / Maven 3.0.5 / Oracle Java > 1.7.0_25 >Reporter: Wolf Geldmacher >Assignee: Robert Scholte >Priority: Blocker > Fix For: 1.3.1 > > Attachments: extjars.xml, pom.xml > > > After upgrading m-e-p from 1.2 to 1.3 the maven-assembly-plugin generates the > following error: > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-assembly-plugin:2.4:single (assemble) on > project extjars: Execution assemble of goal > org.apache.maven.plugins:maven-assembly-plugin:2.4:single failed. > NullPointerException -> [Help 1] > Downgrading to m-e-p 1.2 makes the assembly work again. > Sample pom & assembly that expose the error attached. > When called via: > mvn -Dplugins.maven-enforcer-plugin.version=1.2 > a zip file is generated as expected, when called via > mvn -Dplugins.maven-enforcer-plugin.version=1.3 > (or without argument) you will get the NPE. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-159) Add goal recommend which will only warn but never fail a build
[
https://jira.codehaus.org/browse/MENFORCER-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=328446#comment-328446
]
Robert Scholte commented on MENFORCER-159:
--
I'd prefer the checkstyle approach where you can adjust the impact per rule and
when running check/enforce goal you can specify at which level the build should
fail. That would require a new enforcer-api, but I think it's worth it.
{quote}
"One Goal to Rule them all ({{enforcer:enforce}}), One Goal to find them
(MENFORCER-121), One Goal to bring them all and in the darkness bind them (...)"
{quote}
> Add goal recommend which will only warn but never fail a build
> --
>
> Key: MENFORCER-159
> URL: https://jira.codehaus.org/browse/MENFORCER-159
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Plugin
>Affects Versions: 1.3
>Reporter: Mirko Friedenhagen
> Attachments: recommend-mojo.patch
>
>
> In our company's parent POM we define a lot of rules, some of which are
> controversial or may not be easily fulfilled. The patch I attach defines a
> new goal "recommend" which will always warn but never fail. It's
> configuration is done by a new element {{recommendations}} which just holds a
> sequence of rules.
> I extracted most of EnforceMojo to AbstractEnforceMojo to avoid code
> duplication. I added an invoker test and all tests ran successfully.
> See https://github.com/apache/maven-enforcer/pull/4 as well for easier review.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MINSTALL-50) provide property filtering on .pom files placed in local repo
[
https://jira.codehaus.org/browse/MINSTALL-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Scholte updated MINSTALL-50:
---
Description:
When maven installs an artifact, it's pom is also copied into the artifact's
directory. Unfortunately, if the pom contains a property reference (e.g.
$\{myprop\}), this will not be replaced upon copying the pom file.
I've created a patch for the install plugin that switches on property filtering
by setting a mojo parameter "{{filteringEnabled}}". Since this defaults to
"{{false}}", backward compatibility is kept 100%.
Some implementation notes:
* the dirty work is done in {{FilteredProjectArtifactMetadata.java}}, the
property resolution code has been inspired by {{ResourcesMojo}}.
* I've added a unit test, that replaces ${basedir} with the value of a system
property.
* since "svn diff" does not handle binary files,
{{src/test/resources/unit/basic-install-test-with-filtering/target/maven-install-test-1.0-SNAPSHOT.jar}}
is not included in the patch. This file is the same as
{{src/test/resources/unit/basic-install-test/target/maven-install-test-1.0-SNAPSHOT.jar}}
Since my knowledge of Maven API is more than limited, there might be a more
elegant way to provide this feature ... but it works! I'd be happy to see this
in a future release of maven.
was:
When maven installs an artifact, it's pom is also copied into the artifact's
directory. Unfortunately, if the pom contains a property reference (e.g.
${myprop}), this will not be replaced upon copying the pom file.
I've created a patch for the install plugin that switches on property filtering
by setting a mojo parameter "filteringEnabled". Since this defaults to "false",
backward compatibility is kept 100%.
Some implementation notes:
* the dirty work is done in FilteredProjectArtifactMetadata.java, the property
resolution code has been inspired by ResourcesMojo.
* I've added a unit test, that replaces ${basedir} with the value of a system
property.
* since "svn diff" does not handle binary files,
src/test/resources/unit/basic-install-test-with-filtering/target/maven-install-test-1.0-SNAPSHOT.jar
is not included in the patch. This file is the same as
src/test/resources/unit/basic-install-test/target/maven-install-test-1.0-SNAPSHOT.jar
Since my knowledge of Maven API is more than limited, there might be a more
elegant way to provide this feature ... but it works! I'd be happy to see this
in a future release of maven.
> provide property filtering on .pom files placed in local repo
> -
>
> Key: MINSTALL-50
> URL: https://jira.codehaus.org/browse/MINSTALL-50
> Project: Maven 2.x Install Plugin
> Issue Type: New Feature
> Components: install:install
>Affects Versions: 2.3
> Environment: independent
>Reporter: Stefan Armbruster
> Attachments: MNG-maven-install.patch, MNG-maven-install.patch
>
>
> When maven installs an artifact, it's pom is also copied into the artifact's
> directory. Unfortunately, if the pom contains a property reference (e.g.
> $\{myprop\}), this will not be replaced upon copying the pom file.
> I've created a patch for the install plugin that switches on property
> filtering by setting a mojo parameter "{{filteringEnabled}}". Since this
> defaults to "{{false}}", backward compatibility is kept 100%.
> Some implementation notes:
> * the dirty work is done in {{FilteredProjectArtifactMetadata.java}}, the
> property resolution code has been inspired by {{ResourcesMojo}}.
> * I've added a unit test, that replaces ${basedir} with the value of a system
> property.
> * since "svn diff" does not handle binary files,
> {{src/test/resources/unit/basic-install-test-with-filtering/target/maven-install-test-1.0-SNAPSHOT.jar}}
> is not included in the patch. This file is the same as
> {{src/test/resources/unit/basic-install-test/target/maven-install-test-1.0-SNAPSHOT.jar}}
> Since my knowledge of Maven API is more than limited, there might be a more
> elegant way to provide this feature ... but it works! I'd be happy to see
> this in a future release of maven.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MENFORCER-159) Add goal recommend which will only warn but never fail a build
[
https://jira.codehaus.org/browse/MENFORCER-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=328449#comment-328449
]
Mirko Friedenhagen commented on MENFORCER-159:
--
Robert, I see your point and thought about this approach as well. However, it
will be much harder to get this backward compatible. After the first vote for
1.3 had to be canceled I fear broken custom rules :-)
> Add goal recommend which will only warn but never fail a build
> --
>
> Key: MENFORCER-159
> URL: https://jira.codehaus.org/browse/MENFORCER-159
> Project: Maven 2.x Enforcer Plugin
> Issue Type: New Feature
> Components: Plugin
>Affects Versions: 1.3
>Reporter: Mirko Friedenhagen
> Attachments: recommend-mojo.patch
>
>
> In our company's parent POM we define a lot of rules, some of which are
> controversial or may not be easily fulfilled. The patch I attach defines a
> new goal "recommend" which will always warn but never fail. It's
> configuration is done by a new element {{recommendations}} which just holds a
> sequence of rules.
> I extracted most of EnforceMojo to AbstractEnforceMojo to avoid code
> duplication. I added an invoker test and all tests ran successfully.
> See https://github.com/apache/maven-enforcer/pull/4 as well for easier review.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRESOURCES-174) Loose encoding when filter resource
[ https://jira.codehaus.org/browse/MRESOURCES-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=328462#comment-328462 ] Lefebvre JF commented on MRESOURCES-174: It is exactly what I want, thants a lot > Loose encoding when filter resource > --- > > Key: MRESOURCES-174 > URL: https://jira.codehaus.org/browse/MRESOURCES-174 > Project: Maven 2.x Resources Plugin > Issue Type: Bug >Affects Versions: 2.6 > Environment: Maven 3.0.4 >Reporter: Lefebvre JF > > When filtering resource the build.source.encoding is taken enven if there are > multiple encoding for properties, xml, ... > Why do not use api to detect the original encoding ? > http://code.google.com/p/juniversalchardet/ -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
