[jira] Commented: (MNG-3719) [regression] plugin execution ordering no longer POM ordered in 2.0.9
[
http://jira.codehaus.org/browse/MNG-3719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164377#action_164377
]
Brett Porter commented on MNG-3719:
---
Yep, I already updated the docs :)
> [regression] plugin execution ordering no longer POM ordered in 2.0.9
> -
>
> Key: MNG-3719
> URL: http://jira.codehaus.org/browse/MNG-3719
> Project: Maven 2
> Issue Type: Bug
> Components: POM
>Affects Versions: 2.0.9, 2.0.10, 2.1.0-M1
> Environment: Maven 2.0.9, java version "1.5.0_13" Java(TM) 2 Runtime
> Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM)
> Client VM (build 1.5.0_13-120, mixed mode, sharing), OS X 10.4
>Reporter: Gary S. Weaver
>Assignee: Brett Porter
>Priority: Critical
> Fix For: 2.0.11, 2.1.0-M2
>
> Attachments: MNG-3719-maven-project.patch,
> plugin-execution-order-cant-be-defined-maven-2.0.9.tar.gz
>
>
> I extend my sincere apologies if there is a much easier way of doing this,
> but so far I haven't found any.
> There should be some way to ensure order of plugin executions through
> dependencies on other executions. See attached project for example, or see
> below for the applicable example in a pom.xml. When plugins are defined in
> pom.xml in the following manner to ensure correct execution order, they are
> not executed sequentially and there is no way to indicate dependencies, as
> would be expected (note- I'm not expecting that it interpret the "step 1...",
> ..., "step 5..." IDs, I'm only suggesting that either the plugins be executed
> in order that they are found in the XML (most intuitive) or that there be
> some concept of priority/ordinal added, or even perhaps (this would be most
> "ant-like") that plugin executions (and maybe even plugin goal executions) be
> allowed to define prequisite execution IDs to be run (even if they are IDs
> not defined in the pom, but maybe a parent pom, even though I don't need that
> right now).
> I know that this could be problematic if a plugin execution from one
> lifecycle phase depends on another from another lifecycle phase (and you
> could get into circular references that way that would have to be recognized
> during pom validation after loading/merging pom.xmls). However, not being
> able to at the very least define order of execution of different (or the
> same) plugin executions as noted below and in attached project makes it
> difficult to chain plugin executions that depend on each other, thereby
> reducing the practicality of the pom.xml and Maven 2.
> For example, these plugin executions cannot be ordered properly in Maven
> 2.0.9, since there appears to be no way to indicate dependencies of one
> execution on another:
> {code}
>
>
>
> org.apache.maven.plugins
> maven-compiler-plugin
>
> 1.5
> 1.5
>
>
>
>
> org.apache.maven.plugins
> maven-antrun-plugin
>
>
> step 1 - backup-original-web.xml-from-src
> generate-resources
>
> run
>
>
>
>
>
> file="${pom.basedir}/src/main/webapp/WEB-INF/web.xml"
> todir="${pom.basedir}/target/tmpwebxml/"/>
>
>
>
>
>
>
>
> org.codehaus.mojo
> jspc-maven-plugin
>
>
> step 2 - jspc
> generate-resources
>
> compile
>
>
>
>
>
>
>
>
>
> org.apache.pluto
> pluto-taglib
> 1.1.3
> jar
>
>
> javax.portlet
> portlet-api
> 1.0
> jar
>
>
> javax.servlet
> jstl
> 1.1.2
> jar
>
>
[jira] Closed: (MSITE-180) Missing url tag in (parent) pom make it ignore the site inheritence system
[ http://jira.codehaus.org/browse/MSITE-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSITE-180. - Assignee: Dennis Lundberg Resolution: Fixed Fix Version/s: 2.0 > Missing url tag in (parent) pom make it ignore the site inheritence system > -- > > Key: MSITE-180 > URL: http://jira.codehaus.org/browse/MSITE-180 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance >Affects Versions: 2.0-beta-5 >Reporter: Geoffrey De Smet >Assignee: Dennis Lundberg > Fix For: 2.0 > > Attachments: multi-module-project-with-inheritance.zip, > multi-module-project.zip > > > IF none of the poms (module or parent) don't have an url tag, like this: > > ... > ... > ... > > (It doesn't matter if they have url tags in scm, distribution etc) > THEN site inheritence quitely isn't applied, for example in the parent's > site.xml > > http://www.mavenblogs.org/"/> > > isn't inherited in the childe module's site. > proposed solutions: > - or fix it :) > - or document this wanted behaviour in the site plugin's documentation at > http://maven.apache.org/plugins/maven-site-plugin/howto.html > with something like > "Site inheritence only works if you have a url tag in your parent pom." > because this can cost people many hours - it did for me > But once site inheritence works, it's very nice though :) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3890) Transitive dependencies override explicitly set scope.
[ http://jira.codehaus.org/browse/MNG-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164356#action_164356 ] Benjamin Bentmann commented on MNG-3890: Applied your fix to the IT POM, thanks Torben! > Transitive dependencies override explicitly set scope. > -- > > Key: MNG-3890 > URL: http://jira.codehaus.org/browse/MNG-3890 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.9, 2.1.0-M1, 3.0-alpha-1 >Reporter: Stephan Kleine >Priority: Critical > Fix For: 2.0.11 > > Attachments: MMG-3890-core-it-suite.patch, testcase.tar.bz2 > > > Transitive dependencies override explicitly set scope. > E.g. a project A depends on "Hibernate" with default scope and a project B > depends on project A as well as on "Hibernate" for which it sets the scope > explicitly to "provided". Further an EAR project C depends on project B (see > the attached testcase). > Now I would expect that C does not contain any jars for Hibernate and its > dependencies since B explicitly set the scope to "provided". Sadly this is > not the case and C contains all hibernate jars. The only way around this I > have found is setting the scope to "provided" for Hibernate in A as well - > which is just a crude hack that produces other issues. > IMHO this is a bug because Maven should respect the overridden dependency > scope since the current way forces me to set the scope to provided in A which > is just wrong. > Please try to get this fixed for 2.10 or 2.1 since it's a real pita atm. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-3890) Transitive dependencies override explicitly set scope.
[
http://jira.codehaus.org/browse/MNG-3890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Torben S. Giesselmann updated MNG-3890:
---
Attachment: MMG-3890-core-it-suite.patch
The IT's POM can't be validated because it contains {{}} within a
comment. The patch replaces dashes with {{}} and the IT will run.
> Transitive dependencies override explicitly set scope.
> --
>
> Key: MNG-3890
> URL: http://jira.codehaus.org/browse/MNG-3890
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.0.9, 2.1.0-M1, 3.0-alpha-1
>Reporter: Stephan Kleine
>Priority: Critical
> Fix For: 2.0.11
>
> Attachments: MMG-3890-core-it-suite.patch, testcase.tar.bz2
>
>
> Transitive dependencies override explicitly set scope.
> E.g. a project A depends on "Hibernate" with default scope and a project B
> depends on project A as well as on "Hibernate" for which it sets the scope
> explicitly to "provided". Further an EAR project C depends on project B (see
> the attached testcase).
> Now I would expect that C does not contain any jars for Hibernate and its
> dependencies since B explicitly set the scope to "provided". Sadly this is
> not the case and C contains all hibernate jars. The only way around this I
> have found is setting the scope to "provided" for Hibernate in A as well -
> which is just a crude hack that produces other issues.
> IMHO this is a bug because Maven should respect the overridden dependency
> scope since the current way forces me to set the scope to provided in A which
> is just wrong.
> Please try to get this fixed for 2.10 or 2.1 since it's a real pita atm.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-112) Sign using a PKCS11 token
[ http://jira.codehaus.org/browse/MJAR-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=164334#action_164334 ] Frank Cornelis commented on MJAR-112: - Could someone apply the given patch please? When will maven-jar-plugin version 2.3 be released? > Sign using a PKCS11 token > - > > Key: MJAR-112 > URL: http://jira.codehaus.org/browse/MJAR-112 > Project: Maven 2.x Jar Plugin > Issue Type: New Feature > Components: sign >Affects Versions: 2.2 >Reporter: Frank Cornelis >Priority: Critical > Attachments: maven-jar-plugin-provider-class-arg.patch > > > For the moment one can only sign using a software keystore. But for > production builds your private key is often stored on some smart card device > like an eToken. It would be useful if you could configure the > maven-jar-plugin to run something similar to: > jarsigner -keystore NONE -storetype PKCS11 -providerClass > sun.security.pkcs11.SunPKCS11 -providerArg etoken.config the_jar_to_sign.jar > ALIAS_XYZ > Where my etoken.config file contains: > name=eToken > library=/usr/lib/libeTPkcs11.so -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
