Re: Thoughts on MNG-3522
Having said that, I think having both before and after attributes will make configuration easier in some cases, but I still think all ordering can be expressed just with dependsOf (which is the same as after). Let's say you're not in control of the pom where the plugin binding is declared, which you want to add a binding before. Then it is not possible to add the dependsOn. One scenario would be a parent pom you're inheriting from. /Anders -- Regards, Igor On 2014-06-11, 15:44, Robert Scholte wrote: The dependsOn would only help if this execution should be done *after* another execution. However, I think we also need a solution for the *before* one, unless we say: just manage this by ordering your plugins. Keep in mind: what to do if executions are defined in the parent and you want to execute your plugin before and/or after these inherited executions? Thanks, Robert Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko i...@ifedorenko.com: Misconfigured execution order should be reported as build failer. I don't see how profiles make this problem more complicated. It maybe little tedious to configure, but I believe it is always possible to add dependsOn attribute to execution defined elsewhere. So in your example, the release profile will need to define execution with id of the final step and add dependsOf=id-of-sign-step. -- Regards, Igor On 2014-06-11, 15:17, Jörg Schaible wrote: Hi Igor, Igor Fedorenko wrote: More I think about it, less I like the idea of explicit order values. I think this will be rather inconvenient to setup and error prone to maintain. Initial setup will require some tooling to see executions in a particular case with their default ordering values. Not the end of the world, but somebody will have to implement the tooling and the users will know how to find it. More problematic will be ongoing changes to the project itself and its parents. When I need to add/remove executions in a parent, I will have to review all projects that inherit from it to ensure order is still correct. I work on a monster codebase with 600+ modules now, I just don't see how this is workable. If executions are enabled through a profile, especially rarely activated profile, configuring expected order becomes really cumbersome. Think of -Prelease profile, that adds gpg mojo to package phase... good luck troubleshooting why signed jars do not match their gpg signatures during the release. I think we need to find a way to make before/after hints work. I don't have a proposal yet, but I wonder, is this not the same problem as ordering modules in the reactor? When there are no dependencies, modules are built in their specified order, but the order changes when there are dependencies. please have a look at the latest comments on MNG-3522, because adding executions in a profile causes some edge cases, which should be defined in advance. Regards, Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-3522
Child modules can add configuration to mojo executions configured in parent pom. This isn't pretty, but works. And, to be clear, I am not saying we shouldn't implement before/after configuration, I think it will be convenient to have both. All I am saying only one is truly required. -- Regards, Igor On 2014-06-12, 2:23, Anders Hammar wrote: Having said that, I think having both before and after attributes will make configuration easier in some cases, but I still think all ordering can be expressed just with dependsOf (which is the same as after). Let's say you're not in control of the pom where the plugin binding is declared, which you want to add a binding before. Then it is not possible to add the dependsOn. One scenario would be a parent pom you're inheriting from. /Anders -- Regards, Igor On 2014-06-11, 15:44, Robert Scholte wrote: The dependsOn would only help if this execution should be done *after* another execution. However, I think we also need a solution for the *before* one, unless we say: just manage this by ordering your plugins. Keep in mind: what to do if executions are defined in the parent and you want to execute your plugin before and/or after these inherited executions? Thanks, Robert Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko i...@ifedorenko.com: Misconfigured execution order should be reported as build failer. I don't see how profiles make this problem more complicated. It maybe little tedious to configure, but I believe it is always possible to add dependsOn attribute to execution defined elsewhere. So in your example, the release profile will need to define execution with id of the final step and add dependsOf=id-of-sign-step. -- Regards, Igor On 2014-06-11, 15:17, Jörg Schaible wrote: Hi Igor, Igor Fedorenko wrote: More I think about it, less I like the idea of explicit order values. I think this will be rather inconvenient to setup and error prone to maintain. Initial setup will require some tooling to see executions in a particular case with their default ordering values. Not the end of the world, but somebody will have to implement the tooling and the users will know how to find it. More problematic will be ongoing changes to the project itself and its parents. When I need to add/remove executions in a parent, I will have to review all projects that inherit from it to ensure order is still correct. I work on a monster codebase with 600+ modules now, I just don't see how this is workable. If executions are enabled through a profile, especially rarely activated profile, configuring expected order becomes really cumbersome. Think of -Prelease profile, that adds gpg mojo to package phase... good luck troubleshooting why signed jars do not match their gpg signatures during the release. I think we need to find a way to make before/after hints work. I don't have a proposal yet, but I wonder, is this not the same problem as ordering modules in the reactor? When there are no dependencies, modules are built in their specified order, but the order changes when there are dependencies. please have a look at the latest comments on MNG-3522, because adding executions in a profile causes some edge cases, which should be defined in advance. Regards, Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-3522
Child modules can add configuration to mojo executions configured in parent pom. This isn't pretty, but works. That's not what I had in mind. I was talking about one plugin binding in the parent pom and then a different plugin binding in the child, which we want to be after the one in the parent. Then only having dependsOn wouldn't work in a case where we can't update the parent. And, to be clear, I am not saying we shouldn't implement before/after configuration, I think it will be convenient to have both. All I am saying only one is truly required. Not in the case I describe (I think). -- Regards, Igor On 2014-06-12, 2:23, Anders Hammar wrote: Having said that, I think having both before and after attributes will make configuration easier in some cases, but I still think all ordering can be expressed just with dependsOf (which is the same as after). Let's say you're not in control of the pom where the plugin binding is declared, which you want to add a binding before. Then it is not possible to add the dependsOn. One scenario would be a parent pom you're inheriting from. /Anders -- Regards, Igor On 2014-06-11, 15:44, Robert Scholte wrote: The dependsOn would only help if this execution should be done *after* another execution. However, I think we also need a solution for the *before* one, unless we say: just manage this by ordering your plugins. Keep in mind: what to do if executions are defined in the parent and you want to execute your plugin before and/or after these inherited executions? Thanks, Robert Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko i...@ifedorenko.com: Misconfigured execution order should be reported as build failer. I don't see how profiles make this problem more complicated. It maybe little tedious to configure, but I believe it is always possible to add dependsOn attribute to execution defined elsewhere. So in your example, the release profile will need to define execution with id of the final step and add dependsOf=id-of-sign-step. -- Regards, Igor On 2014-06-11, 15:17, Jörg Schaible wrote: Hi Igor, Igor Fedorenko wrote: More I think about it, less I like the idea of explicit order values. I think this will be rather inconvenient to setup and error prone to maintain. Initial setup will require some tooling to see executions in a particular case with their default ordering values. Not the end of the world, but somebody will have to implement the tooling and the users will know how to find it. More problematic will be ongoing changes to the project itself and its parents. When I need to add/remove executions in a parent, I will have to review all projects that inherit from it to ensure order is still correct. I work on a monster codebase with 600+ modules now, I just don't see how this is workable. If executions are enabled through a profile, especially rarely activated profile, configuring expected order becomes really cumbersome. Think of -Prelease profile, that adds gpg mojo to package phase... good luck troubleshooting why signed jars do not match their gpg signatures during the release. I think we need to find a way to make before/after hints work. I don't have a proposal yet, but I wonder, is this not the same problem as ordering modules in the reactor? When there are no dependencies, modules are built in their specified order, but the order changes when there are dependencies. please have a look at the latest comments on MNG-3522, because adding executions in a profile causes some edge cases, which should be defined in advance. Regards, Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-3522
Consider the following parent pom.xml snippet plugin groupIdfoo/groupId artifactIdbar/artifactId version1/version executions execution idmunchy/id phase.../phase goalsgoal.../goal/goals /execution /executions plugin then in the child I believe you can do plugin groupIdfoo/groupId artifactIdbar/artifactId version1/version executions execution dependsOn=some-other-plugin-execution idmunchy/id !-- the rest of configuration is inherited from parent -- /execution /executions plugin -- Regards, Igor On 2014-06-12, 16:19, Anders Hammar wrote: Child modules can add configuration to mojo executions configured in parent pom. This isn't pretty, but works. That's not what I had in mind. I was talking about one plugin binding in the parent pom and then a different plugin binding in the child, which we want to be after the one in the parent. Then only having dependsOn wouldn't work in a case where we can't update the parent. And, to be clear, I am not saying we shouldn't implement before/after configuration, I think it will be convenient to have both. All I am saying only one is truly required. Not in the case I describe (I think). -- Regards, Igor On 2014-06-12, 2:23, Anders Hammar wrote: Having said that, I think having both before and after attributes will make configuration easier in some cases, but I still think all ordering can be expressed just with dependsOf (which is the same as after). Let's say you're not in control of the pom where the plugin binding is declared, which you want to add a binding before. Then it is not possible to add the dependsOn. One scenario would be a parent pom you're inheriting from. /Anders -- Regards, Igor On 2014-06-11, 15:44, Robert Scholte wrote: The dependsOn would only help if this execution should be done *after* another execution. However, I think we also need a solution for the *before* one, unless we say: just manage this by ordering your plugins. Keep in mind: what to do if executions are defined in the parent and you want to execute your plugin before and/or after these inherited executions? Thanks, Robert Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko i...@ifedorenko.com: Misconfigured execution order should be reported as build failer. I don't see how profiles make this problem more complicated. It maybe little tedious to configure, but I believe it is always possible to add dependsOn attribute to execution defined elsewhere. So in your example, the release profile will need to define execution with id of the final step and add dependsOf=id-of-sign-step. -- Regards, Igor On 2014-06-11, 15:17, Jörg Schaible wrote: Hi Igor, Igor Fedorenko wrote: More I think about it, less I like the idea of explicit order values. I think this will be rather inconvenient to setup and error prone to maintain. Initial setup will require some tooling to see executions in a particular case with their default ordering values. Not the end of the world, but somebody will have to implement the tooling and the users will know how to find it. More problematic will be ongoing changes to the project itself and its parents. When I need to add/remove executions in a parent, I will have to review all projects that inherit from it to ensure order is still correct. I work on a monster codebase with 600+ modules now, I just don't see how this is workable. If executions are enabled through a profile, especially rarely activated profile, configuring expected order becomes really cumbersome. Think of -Prelease profile, that adds gpg mojo to package phase... good luck troubleshooting why signed jars do not match their gpg signatures during the release. I think we need to find a way to make before/after hints work. I don't have a proposal yet, but I wonder, is this not the same problem as ordering modules in the reactor? When there are no dependencies, modules are built in their specified order, but the order changes when there are dependencies. please have a look at the latest comments on MNG-3522, because adding executions in a profile causes some edge cases, which should be defined in advance. Regards, Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
Re: Thoughts on MNG-3522
Sorry, my bad. I meant the binding in the child to be BEFORE the one on the parent. I can't alter the declaration in the parent in my scenario as I'm not on control of it. /Anders (mobile) Den 12 jun 2014 22:19 skrev Anders Hammar and...@hammar.net: Child modules can add configuration to mojo executions configured in parent pom. This isn't pretty, but works. That's not what I had in mind. I was talking about one plugin binding in the parent pom and then a different plugin binding in the child, which we want to be after the one in the parent. Then only having dependsOn wouldn't work in a case where we can't update the parent. And, to be clear, I am not saying we shouldn't implement before/after configuration, I think it will be convenient to have both. All I am saying only one is truly required. Not in the case I describe (I think). -- Regards, Igor On 2014-06-12, 2:23, Anders Hammar wrote: Having said that, I think having both before and after attributes will make configuration easier in some cases, but I still think all ordering can be expressed just with dependsOf (which is the same as after). Let's say you're not in control of the pom where the plugin binding is declared, which you want to add a binding before. Then it is not possible to add the dependsOn. One scenario would be a parent pom you're inheriting from. /Anders -- Regards, Igor On 2014-06-11, 15:44, Robert Scholte wrote: The dependsOn would only help if this execution should be done *after* another execution. However, I think we also need a solution for the *before* one, unless we say: just manage this by ordering your plugins. Keep in mind: what to do if executions are defined in the parent and you want to execute your plugin before and/or after these inherited executions? Thanks, Robert Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko i...@ifedorenko.com: Misconfigured execution order should be reported as build failer. I don't see how profiles make this problem more complicated. It maybe little tedious to configure, but I believe it is always possible to add dependsOn attribute to execution defined elsewhere. So in your example, the release profile will need to define execution with id of the final step and add dependsOf=id-of-sign-step. -- Regards, Igor On 2014-06-11, 15:17, Jörg Schaible wrote: Hi Igor, Igor Fedorenko wrote: More I think about it, less I like the idea of explicit order values. I think this will be rather inconvenient to setup and error prone to maintain. Initial setup will require some tooling to see executions in a particular case with their default ordering values. Not the end of the world, but somebody will have to implement the tooling and the users will know how to find it. More problematic will be ongoing changes to the project itself and its parents. When I need to add/remove executions in a parent, I will have to review all projects that inherit from it to ensure order is still correct. I work on a monster codebase with 600+ modules now, I just don't see how this is workable. If executions are enabled through a profile, especially rarely activated profile, configuring expected order becomes really cumbersome. Think of -Prelease profile, that adds gpg mojo to package phase... good luck troubleshooting why signed jars do not match their gpg signatures during the release. I think we need to find a way to make before/after hints work. I don't have a proposal yet, but I wonder, is this not the same problem as ordering modules in the reactor? When there are no dependencies, modules are built in their specified order, but the order changes when there are dependencies. please have a look at the latest comments on MNG-3522, because adding executions in a profile causes some edge cases, which should be defined in advance. Regards, Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-3522
That's where the theoretical before attribute would be useful, right? Cheers, Paul On Thu, Jun 12, 2014 at 3:49 PM, Anders Hammar and...@hammar.net wrote: Sorry, my bad. I meant the binding in the child to be BEFORE the one on the parent. I can't alter the declaration in the parent in my scenario as I'm not on control of it. /Anders (mobile) Den 12 jun 2014 22:19 skrev Anders Hammar and...@hammar.net: Child modules can add configuration to mojo executions configured in parent pom. This isn't pretty, but works. That's not what I had in mind. I was talking about one plugin binding in the parent pom and then a different plugin binding in the child, which we want to be after the one in the parent. Then only having dependsOn wouldn't work in a case where we can't update the parent. And, to be clear, I am not saying we shouldn't implement before/after configuration, I think it will be convenient to have both. All I am saying only one is truly required. Not in the case I describe (I think). -- Regards, Igor On 2014-06-12, 2:23, Anders Hammar wrote: Having said that, I think having both before and after attributes will make configuration easier in some cases, but I still think all ordering can be expressed just with dependsOf (which is the same as after). Let's say you're not in control of the pom where the plugin binding is declared, which you want to add a binding before. Then it is not possible to add the dependsOn. One scenario would be a parent pom you're inheriting from. /Anders -- Regards, Igor On 2014-06-11, 15:44, Robert Scholte wrote: The dependsOn would only help if this execution should be done *after* another execution. However, I think we also need a solution for the *before* one, unless we say: just manage this by ordering your plugins. Keep in mind: what to do if executions are defined in the parent and you want to execute your plugin before and/or after these inherited executions? Thanks, Robert Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko i...@ifedorenko.com: Misconfigured execution order should be reported as build failer. I don't see how profiles make this problem more complicated. It maybe little tedious to configure, but I believe it is always possible to add dependsOn attribute to execution defined elsewhere. So in your example, the release profile will need to define execution with id of the final step and add dependsOf=id-of-sign-step. -- Regards, Igor On 2014-06-11, 15:17, Jörg Schaible wrote: Hi Igor, Igor Fedorenko wrote: More I think about it, less I like the idea of explicit order values. I think this will be rather inconvenient to setup and error prone to maintain. Initial setup will require some tooling to see executions in a particular case with their default ordering values. Not the end of the world, but somebody will have to implement the tooling and the users will know how to find it. More problematic will be ongoing changes to the project itself and its parents. When I need to add/remove executions in a parent, I will have to review all projects that inherit from it to ensure order is still correct. I work on a monster codebase with 600+ modules now, I just don't see how this is workable. If executions are enabled through a profile, especially rarely activated profile, configuring expected order becomes really cumbersome. Think of -Prelease profile, that adds gpg mojo to package phase... good luck troubleshooting why signed jars do not match their gpg signatures during the release. I think we need to find a way to make before/after hints work. I don't have a proposal yet, but I wonder, is this not the same problem as ordering modules in the reactor? When there are no dependencies, modules are built in their specified order, but the order changes when there are dependencies. please have a look at the latest comments on MNG-3522, because adding executions in a profile causes some edge cases, which should be defined in advance. Regards, Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional
Re: Thoughts on MNG-3522
I don't think this is a general use case. With the same parent, I believe this is a common example: plugin groupIdcom/groupId artifactIdacme/artifactId version2.3/version executions execution !-- before, because of plugin order -- idpre/id phase.../phase goalsgoal.../goal/goals /execution execution dependsOn=foo:bar#munchy idpost/id phase.../phase goalsgoal.../goal/goals /execution /executions plugin plugin groupIdfoo/groupId artifactIdbar/artifactId plugin In this case you MUST specify the foo:bar plugin as well. Quite a lot of tags compared to @before=foo:bar#munchy, but with the same result. One tricky thing: allowing both @before and @after may cause circular executions more often. Another interesting thing from Igors example: is it allowed to change the order of existing/inherited execution blocks? thanks, Robert Op Thu, 12 Jun 2014 22:43:04 +0200 schreef Igor Fedorenko i...@ifedorenko.com: Consider the following parent pom.xml snippet plugin groupIdfoo/groupId artifactIdbar/artifactId version1/version executions execution idmunchy/id phase.../phase goalsgoal.../goal/goals /execution /executions plugin then in the child I believe you can do plugin groupIdfoo/groupId artifactIdbar/artifactId version1/version executions execution dependsOn=some-other-plugin-execution idmunchy/id !-- the rest of configuration is inherited from parent -- /execution /executions plugin -- Regards, Igor On 2014-06-12, 16:19, Anders Hammar wrote: Child modules can add configuration to mojo executions configured in parent pom. This isn't pretty, but works. That's not what I had in mind. I was talking about one plugin binding in the parent pom and then a different plugin binding in the child, which we want to be after the one in the parent. Then only having dependsOn wouldn't work in a case where we can't update the parent. And, to be clear, I am not saying we shouldn't implement before/after configuration, I think it will be convenient to have both. All I am saying only one is truly required. Not in the case I describe (I think). -- Regards, Igor On 2014-06-12, 2:23, Anders Hammar wrote: Having said that, I think having both before and after attributes will make configuration easier in some cases, but I still think all ordering can be expressed just with dependsOf (which is the same as after). Let's say you're not in control of the pom where the plugin binding is declared, which you want to add a binding before. Then it is not possible to add the dependsOn. One scenario would be a parent pom you're inheriting from. /Anders -- Regards, Igor On 2014-06-11, 15:44, Robert Scholte wrote: The dependsOn would only help if this execution should be done *after* another execution. However, I think we also need a solution for the *before* one, unless we say: just manage this by ordering your plugins. Keep in mind: what to do if executions are defined in the parent and you want to execute your plugin before and/or after these inherited executions? Thanks, Robert Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko i...@ifedorenko.com: Misconfigured execution order should be reported as build failer. I don't see how profiles make this problem more complicated. It maybe little tedious to configure, but I believe it is always possible to add dependsOn attribute to execution defined elsewhere. So in your example, the release profile will need to define execution with id of the final step and add dependsOf=id-of-sign-step. -- Regards, Igor On 2014-06-11, 15:17, Jörg Schaible wrote: Hi Igor, Igor Fedorenko wrote: More I think about it, less I like the idea of explicit order values. I think this will be rather inconvenient to setup and error prone to maintain. Initial setup will require some tooling to see executions in a particular case with their default ordering values. Not the end of the world, but somebody will have to implement the tooling and the users will know how to find it. More problematic will be ongoing changes to the project itself and its parents. When I need to add/remove executions in a parent, I will have to review all projects that inherit from it to ensure order is still correct. I work on a monster codebase with 600+ modules now, I just don't see how this is workable. If executions are enabled through a profile, especially rarely activated profile, configuring expected order becomes really cumbersome. Think of -Prelease profile, that adds gpg mojo to package phase... good luck troubleshooting why signed jars do not match their gpg signatures during the release. I think we
Re: Thoughts on MNG-3522
yes, I agree before/after will likely be more convenient in some cases. -- Regards, Igor On 2014-06-12, 17:04, Robert Scholte wrote: I don't think this is a general use case. With the same parent, I believe this is a common example: plugin groupIdcom/groupId artifactIdacme/artifactId version2.3/version executions execution !-- before, because of plugin order -- idpre/id phase.../phase goalsgoal.../goal/goals /execution execution dependsOn=foo:bar#munchy idpost/id phase.../phase goalsgoal.../goal/goals /execution /executions plugin plugin groupIdfoo/groupId artifactIdbar/artifactId plugin In this case you MUST specify the foo:bar plugin as well. Quite a lot of tags compared to @before=foo:bar#munchy, but with the same result. One tricky thing: allowing both @before and @after may cause circular executions more often. Another interesting thing from Igors example: is it allowed to change the order of existing/inherited execution blocks? thanks, Robert Op Thu, 12 Jun 2014 22:43:04 +0200 schreef Igor Fedorenko i...@ifedorenko.com: Consider the following parent pom.xml snippet plugin groupIdfoo/groupId artifactIdbar/artifactId version1/version executions execution idmunchy/id phase.../phase goalsgoal.../goal/goals /execution /executions plugin then in the child I believe you can do plugin groupIdfoo/groupId artifactIdbar/artifactId version1/version executions execution dependsOn=some-other-plugin-execution idmunchy/id !-- the rest of configuration is inherited from parent -- /execution /executions plugin -- Regards, Igor On 2014-06-12, 16:19, Anders Hammar wrote: Child modules can add configuration to mojo executions configured in parent pom. This isn't pretty, but works. That's not what I had in mind. I was talking about one plugin binding in the parent pom and then a different plugin binding in the child, which we want to be after the one in the parent. Then only having dependsOn wouldn't work in a case where we can't update the parent. And, to be clear, I am not saying we shouldn't implement before/after configuration, I think it will be convenient to have both. All I am saying only one is truly required. Not in the case I describe (I think). -- Regards, Igor On 2014-06-12, 2:23, Anders Hammar wrote: Having said that, I think having both before and after attributes will make configuration easier in some cases, but I still think all ordering can be expressed just with dependsOf (which is the same as after). Let's say you're not in control of the pom where the plugin binding is declared, which you want to add a binding before. Then it is not possible to add the dependsOn. One scenario would be a parent pom you're inheriting from. /Anders -- Regards, Igor On 2014-06-11, 15:44, Robert Scholte wrote: The dependsOn would only help if this execution should be done *after* another execution. However, I think we also need a solution for the *before* one, unless we say: just manage this by ordering your plugins. Keep in mind: what to do if executions are defined in the parent and you want to execute your plugin before and/or after these inherited executions? Thanks, Robert Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko i...@ifedorenko.com: Misconfigured execution order should be reported as build failer. I don't see how profiles make this problem more complicated. It maybe little tedious to configure, but I believe it is always possible to add dependsOn attribute to execution defined elsewhere. So in your example, the release profile will need to define execution with id of the final step and add dependsOf=id-of-sign-step. -- Regards, Igor On 2014-06-11, 15:17, Jörg Schaible wrote: Hi Igor, Igor Fedorenko wrote: More I think about it, less I like the idea of explicit order values. I think this will be rather inconvenient to setup and error prone to maintain. Initial setup will require some tooling to see executions in a particular case with their default ordering values. Not the end of the world, but somebody will have to implement the tooling and the users will know how to find it. More problematic will be ongoing changes to the project itself and its parents. When I need to add/remove executions in a parent, I will have to review all projects that inherit from it to ensure order is still correct. I work on a monster codebase with 600+ modules now, I just don't see how this is workable. If executions are enabled through a profile, especially rarely activated profile, configuring expected order becomes really cumbersome. Think of -Prelease profile, that adds gpg mojo to package phase...
Re: Thoughts on MNG-3522
Hi Igor, Igor Fedorenko wrote: More I think about it, less I like the idea of explicit order values. I think this will be rather inconvenient to setup and error prone to maintain. Initial setup will require some tooling to see executions in a particular case with their default ordering values. Not the end of the world, but somebody will have to implement the tooling and the users will know how to find it. More problematic will be ongoing changes to the project itself and its parents. When I need to add/remove executions in a parent, I will have to review all projects that inherit from it to ensure order is still correct. I work on a monster codebase with 600+ modules now, I just don't see how this is workable. If executions are enabled through a profile, especially rarely activated profile, configuring expected order becomes really cumbersome. Think of -Prelease profile, that adds gpg mojo to package phase... good luck troubleshooting why signed jars do not match their gpg signatures during the release. I think we need to find a way to make before/after hints work. I don't have a proposal yet, but I wonder, is this not the same problem as ordering modules in the reactor? When there are no dependencies, modules are built in their specified order, but the order changes when there are dependencies. please have a look at the latest comments on MNG-3522, because adding executions in a profile causes some edge cases, which should be defined in advance. Regards, Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-3522
Misconfigured execution order should be reported as build failer. I don't see how profiles make this problem more complicated. It maybe little tedious to configure, but I believe it is always possible to add dependsOn attribute to execution defined elsewhere. So in your example, the release profile will need to define execution with id of the final step and add dependsOf=id-of-sign-step. -- Regards, Igor On 2014-06-11, 15:17, Jörg Schaible wrote: Hi Igor, Igor Fedorenko wrote: More I think about it, less I like the idea of explicit order values. I think this will be rather inconvenient to setup and error prone to maintain. Initial setup will require some tooling to see executions in a particular case with their default ordering values. Not the end of the world, but somebody will have to implement the tooling and the users will know how to find it. More problematic will be ongoing changes to the project itself and its parents. When I need to add/remove executions in a parent, I will have to review all projects that inherit from it to ensure order is still correct. I work on a monster codebase with 600+ modules now, I just don't see how this is workable. If executions are enabled through a profile, especially rarely activated profile, configuring expected order becomes really cumbersome. Think of -Prelease profile, that adds gpg mojo to package phase... good luck troubleshooting why signed jars do not match their gpg signatures during the release. I think we need to find a way to make before/after hints work. I don't have a proposal yet, but I wonder, is this not the same problem as ordering modules in the reactor? When there are no dependencies, modules are built in their specified order, but the order changes when there are dependencies. please have a look at the latest comments on MNG-3522, because adding executions in a profile causes some edge cases, which should be defined in advance. Regards, Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-3522
The dependsOn would only help if this execution should be done *after* another execution. However, I think we also need a solution for the *before* one, unless we say: just manage this by ordering your plugins. Keep in mind: what to do if executions are defined in the parent and you want to execute your plugin before and/or after these inherited executions? Thanks, Robert Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko i...@ifedorenko.com: Misconfigured execution order should be reported as build failer. I don't see how profiles make this problem more complicated. It maybe little tedious to configure, but I believe it is always possible to add dependsOn attribute to execution defined elsewhere. So in your example, the release profile will need to define execution with id of the final step and add dependsOf=id-of-sign-step. -- Regards, Igor On 2014-06-11, 15:17, Jörg Schaible wrote: Hi Igor, Igor Fedorenko wrote: More I think about it, less I like the idea of explicit order values. I think this will be rather inconvenient to setup and error prone to maintain. Initial setup will require some tooling to see executions in a particular case with their default ordering values. Not the end of the world, but somebody will have to implement the tooling and the users will know how to find it. More problematic will be ongoing changes to the project itself and its parents. When I need to add/remove executions in a parent, I will have to review all projects that inherit from it to ensure order is still correct. I work on a monster codebase with 600+ modules now, I just don't see how this is workable. If executions are enabled through a profile, especially rarely activated profile, configuring expected order becomes really cumbersome. Think of -Prelease profile, that adds gpg mojo to package phase... good luck troubleshooting why signed jars do not match their gpg signatures during the release. I think we need to find a way to make before/after hints work. I don't have a proposal yet, but I wonder, is this not the same problem as ordering modules in the reactor? When there are no dependencies, modules are built in their specified order, but the order changes when there are dependencies. please have a look at the latest comments on MNG-3522, because adding executions in a profile causes some edge cases, which should be defined in advance. Regards, Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-3522
FWIW, in my use of Spring Security, I am able to place a security check within a security filter chain using a before or after attribute. It makes relative positioning very easy. Cheers, Paul On Wed, Jun 11, 2014 at 2:44 PM, Robert Scholte rfscho...@apache.org wrote: The dependsOn would only help if this execution should be done *after* another execution. However, I think we also need a solution for the *before* one, unless we say: just manage this by ordering your plugins. Keep in mind: what to do if executions are defined in the parent and you want to execute your plugin before and/or after these inherited executions? Thanks, Robert Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko i...@ifedorenko.com: Misconfigured execution order should be reported as build failer. I don't see how profiles make this problem more complicated. It maybe little tedious to configure, but I believe it is always possible to add dependsOn attribute to execution defined elsewhere. So in your example, the release profile will need to define execution with id of the final step and add dependsOf=id-of-sign-step. -- Regards, Igor On 2014-06-11, 15:17, Jörg Schaible wrote: Hi Igor, Igor Fedorenko wrote: More I think about it, less I like the idea of explicit order values. I think this will be rather inconvenient to setup and error prone to maintain. Initial setup will require some tooling to see executions in a particular case with their default ordering values. Not the end of the world, but somebody will have to implement the tooling and the users will know how to find it. More problematic will be ongoing changes to the project itself and its parents. When I need to add/remove executions in a parent, I will have to review all projects that inherit from it to ensure order is still correct. I work on a monster codebase with 600+ modules now, I just don't see how this is workable. If executions are enabled through a profile, especially rarely activated profile, configuring expected order becomes really cumbersome. Think of -Prelease profile, that adds gpg mojo to package phase... good luck troubleshooting why signed jars do not match their gpg signatures during the release. I think we need to find a way to make before/after hints work. I don't have a proposal yet, but I wonder, is this not the same problem as ordering modules in the reactor? When there are no dependencies, modules are built in their specified order, but the order changes when there are dependencies. please have a look at the latest comments on MNG-3522, because adding executions in a profile causes some edge cases, which should be defined in advance. Regards, Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-3522
It is possible to amend inherited execution configuration, maven will use plugin GA and execution id to merge the configuration, and I assume it will or at least can merge dependsOn attribute. Having said that, I think having both before and after attributes will make configuration easier in some cases, but I still think all ordering can be expressed just with dependsOf (which is the same as after). -- Regards, Igor On 2014-06-11, 15:44, Robert Scholte wrote: The dependsOn would only help if this execution should be done *after* another execution. However, I think we also need a solution for the *before* one, unless we say: just manage this by ordering your plugins. Keep in mind: what to do if executions are defined in the parent and you want to execute your plugin before and/or after these inherited executions? Thanks, Robert Op Wed, 11 Jun 2014 21:31:23 +0200 schreef Igor Fedorenko i...@ifedorenko.com: Misconfigured execution order should be reported as build failer. I don't see how profiles make this problem more complicated. It maybe little tedious to configure, but I believe it is always possible to add dependsOn attribute to execution defined elsewhere. So in your example, the release profile will need to define execution with id of the final step and add dependsOf=id-of-sign-step. -- Regards, Igor On 2014-06-11, 15:17, Jörg Schaible wrote: Hi Igor, Igor Fedorenko wrote: More I think about it, less I like the idea of explicit order values. I think this will be rather inconvenient to setup and error prone to maintain. Initial setup will require some tooling to see executions in a particular case with their default ordering values. Not the end of the world, but somebody will have to implement the tooling and the users will know how to find it. More problematic will be ongoing changes to the project itself and its parents. When I need to add/remove executions in a parent, I will have to review all projects that inherit from it to ensure order is still correct. I work on a monster codebase with 600+ modules now, I just don't see how this is workable. If executions are enabled through a profile, especially rarely activated profile, configuring expected order becomes really cumbersome. Think of -Prelease profile, that adds gpg mojo to package phase... good luck troubleshooting why signed jars do not match their gpg signatures during the release. I think we need to find a way to make before/after hints work. I don't have a proposal yet, but I wonder, is this not the same problem as ordering modules in the reactor? When there are no dependencies, modules are built in their specified order, but the order changes when there are dependencies. please have a look at the latest comments on MNG-3522, because adding executions in a profile causes some edge cases, which should be defined in advance. Regards, Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-3522
Sounds fine to me. I'll update the ticket with a link to this thread and a
summary of the dependsOn feature discussed here.
Cheers,
Paul
On Sun, Jun 8, 2014 at 9:02 AM, Jason van Zyl ja...@takari.io wrote:
Agreed. Explicit order values are not good.
It should be like the reactor in which the order is the topologically
sorted list of projects. The executions in a phase should be the same,
specify your dependencies and let the core topologically sort the
executions and run them in the right order. I think an attribute like
dependsOn=${anotherExecutionId} is in an execution element is fine.
On Jun 8, 2014, at 9:42 AM, Igor Fedorenko i...@ifedorenko.com wrote:
More I think about it, less I like the idea of explicit order values. I
think this will be rather inconvenient to setup and error prone to
maintain.
Initial setup will require some tooling to see executions in a
particular case with their default ordering values. Not the end of the
world, but somebody will have to implement the tooling and the users
will know how to find it.
More problematic will be ongoing changes to the project itself
and its parents. When I need to add/remove executions in a parent, I
will have to review all projects that inherit from it to ensure order is
still correct. I work on a monster codebase with 600+ modules now, I
just don't see how this is workable.
If executions are enabled through a profile, especially rarely activated
profile, configuring expected order becomes really cumbersome.
Think of -Prelease profile, that adds gpg mojo to package phase...
good luck troubleshooting why signed jars do not match their gpg
signatures during the release.
I think we need to find a way to make before/after hints work. I don't
have a proposal yet, but I wonder, is this not the same problem as
ordering modules in the reactor? When there are no dependencies, modules
are built in their specified order, but the order changes when there are
dependencies.
--
Regards,
Igor
On 2014-06-05, 11:11, Paul Benedict wrote:
Igor, I can come up with three possible solutions which one I prefer.
1) Unspecified order plugins are all given highest precedence; specified
plugins come after.
2) Unspecified order plugins are all given lowest precedence; specified
plugins come before.
3) Unspecified order plugins are given a default precedence in steps of
100
(ordered by declaration); specified plugins can be before, middle,
after by
choosing the appropriate number.
I like #3. In your example, I would assign jarsigner precedence value
150
to fit between pack200:normalize and pack200:goal.
Cheers,
Paul
On Thu, Jun 5, 2014 at 9:38 AM, Paul Benedict pbened...@apache.org
wrote:
Good question. I haven't thought of that. In all the examples presented
thus far, the developer had control over all the id executions and
explicitly ordered them. This won't be the case all the time. What
happens
when you mix ordering and unspecified?
Cheers,
Paul
On Thu, Jun 5, 2014 at 9:12 AM, Igor Fedorenko i...@ifedorenko.com
wrote:
Mojo executions bound to in packaging type lifecycle mapping have
fixed
default-goal ids. To continue my Tycho pack200 example, I will
need
to insert jarsigner between pack200:normalize and pack200:pack goals.
If pack200:normalize and pack200:pack goals are bound to the default
lifecycle, can you explain how to achieve desired execution order with
ids?
--
Regards,
Igor
On 2014-06-05, 9:52, Paul Benedict wrote:
After giving it some more thought, I think interpolating the id is
less
disruptive than a new attribute. I am sure once POM 5 exists, there
will
be
an official way.
Lastly, I am not not a fan of the step-# naming because it's a
prefix
but
it is more descriptive; I would prefer to just simply allow the
developer
to suffix with a -# (dash number). Thoughts on which nomenclature is
better?
Cheers,
Paul
On Wed, Jun 4, 2014 at 10:59 AM, Igor Fedorenko i...@ifedorenko.com
wrote:
I am not sure xml attributes are necessary a hack. Whether to put
before/after hints into xml element or attribute is really a matter
of
taste, imho.
I don't want to restart the whole pom v 5 discussion again, but I
was
under impression we agreed to preserve format published to maven
repository but allow changes in the format used during the build.
Which
I believe implies that entire build section (or whaterver pom 5
will
end up using to represent build configuration) will be stripped out
of
pom.xml files before they are deployed.
So I think it is okay to use xml attributes to represent
before/after
hints today and we can decide to change this to something else when
we
get to pom 5.
--
Regards,
Igor
On 2014-06-04, 11:39, Paul Benedict wrote:
Thanks for your reply Jason.
So it seems there are some
Re: Thoughts on MNG-3522
More I think about it, less I like the idea of explicit order values. I think this will be rather inconvenient to setup and error prone to maintain. Initial setup will require some tooling to see executions in a particular case with their default ordering values. Not the end of the world, but somebody will have to implement the tooling and the users will know how to find it. More problematic will be ongoing changes to the project itself and its parents. When I need to add/remove executions in a parent, I will have to review all projects that inherit from it to ensure order is still correct. I work on a monster codebase with 600+ modules now, I just don't see how this is workable. If executions are enabled through a profile, especially rarely activated profile, configuring expected order becomes really cumbersome. Think of -Prelease profile, that adds gpg mojo to package phase... good luck troubleshooting why signed jars do not match their gpg signatures during the release. I think we need to find a way to make before/after hints work. I don't have a proposal yet, but I wonder, is this not the same problem as ordering modules in the reactor? When there are no dependencies, modules are built in their specified order, but the order changes when there are dependencies. -- Regards, Igor On 2014-06-05, 11:11, Paul Benedict wrote: Igor, I can come up with three possible solutions which one I prefer. 1) Unspecified order plugins are all given highest precedence; specified plugins come after. 2) Unspecified order plugins are all given lowest precedence; specified plugins come before. 3) Unspecified order plugins are given a default precedence in steps of 100 (ordered by declaration); specified plugins can be before, middle, after by choosing the appropriate number. I like #3. In your example, I would assign jarsigner precedence value 150 to fit between pack200:normalize and pack200:goal. Cheers, Paul On Thu, Jun 5, 2014 at 9:38 AM, Paul Benedict pbened...@apache.org wrote: Good question. I haven't thought of that. In all the examples presented thus far, the developer had control over all the id executions and explicitly ordered them. This won't be the case all the time. What happens when you mix ordering and unspecified? Cheers, Paul On Thu, Jun 5, 2014 at 9:12 AM, Igor Fedorenko i...@ifedorenko.com wrote: Mojo executions bound to in packaging type lifecycle mapping have fixed default-goal ids. To continue my Tycho pack200 example, I will need to insert jarsigner between pack200:normalize and pack200:pack goals. If pack200:normalize and pack200:pack goals are bound to the default lifecycle, can you explain how to achieve desired execution order with ids? -- Regards, Igor On 2014-06-05, 9:52, Paul Benedict wrote: After giving it some more thought, I think interpolating the id is less disruptive than a new attribute. I am sure once POM 5 exists, there will be an official way. Lastly, I am not not a fan of the step-# naming because it's a prefix but it is more descriptive; I would prefer to just simply allow the developer to suffix with a -# (dash number). Thoughts on which nomenclature is better? Cheers, Paul On Wed, Jun 4, 2014 at 10:59 AM, Igor Fedorenko i...@ifedorenko.com wrote: I am not sure xml attributes are necessary a hack. Whether to put before/after hints into xml element or attribute is really a matter of taste, imho. I don't want to restart the whole pom v 5 discussion again, but I was under impression we agreed to preserve format published to maven repository but allow changes in the format used during the build. Which I believe implies that entire build section (or whaterver pom 5 will end up using to represent build configuration) will be stripped out of pom.xml files before they are deployed. So I think it is okay to use xml attributes to represent before/after hints today and we can decide to change this to something else when we get to pom 5. -- Regards, Igor On 2014-06-04, 11:39, Paul Benedict wrote: Thanks for your reply Jason. So it seems there are some possibilities for this ticket: either interpreting the id to infer order (the patch) or stuffing this into an attribute (per Igor). Regarding the latter, the attribute route is clearly to avoid adding a new POM element, but aren't both a bit hackish? The desired solution, I think, would be to make this a POM element, but past discussions inform me that's clearly off the table. Cheers, Paul On Wed, Jun 4, 2014 at 10:20 AM, Jason van Zyl ja...@takari.io wrote: I'm opposed to random creation of a DAG for executions across all the phases. This just creates a giant mess. That said _within_ a given phase if there was a topological sorting of executions where one execution can state that it depends on another I think is reasonable. Definitive ordering within a phase, I think, is useful. On Jun 4, 2014, at 10:22 AM, Paul Benedict pbened...@apache.org wrote: I find that solution interesting
Re: Thoughts on MNG-3522
Agreed. Explicit order values are not good.
It should be like the reactor in which the order is the topologically sorted
list of projects. The executions in a phase should be the same, specify your
dependencies and let the core topologically sort the executions and run them in
the right order. I think an attribute like dependsOn=${anotherExecutionId}
is in an execution element is fine.
On Jun 8, 2014, at 9:42 AM, Igor Fedorenko i...@ifedorenko.com wrote:
More I think about it, less I like the idea of explicit order values. I
think this will be rather inconvenient to setup and error prone to
maintain.
Initial setup will require some tooling to see executions in a
particular case with their default ordering values. Not the end of the
world, but somebody will have to implement the tooling and the users
will know how to find it.
More problematic will be ongoing changes to the project itself
and its parents. When I need to add/remove executions in a parent, I
will have to review all projects that inherit from it to ensure order is
still correct. I work on a monster codebase with 600+ modules now, I
just don't see how this is workable.
If executions are enabled through a profile, especially rarely activated
profile, configuring expected order becomes really cumbersome.
Think of -Prelease profile, that adds gpg mojo to package phase...
good luck troubleshooting why signed jars do not match their gpg
signatures during the release.
I think we need to find a way to make before/after hints work. I don't
have a proposal yet, but I wonder, is this not the same problem as
ordering modules in the reactor? When there are no dependencies, modules
are built in their specified order, but the order changes when there are
dependencies.
--
Regards,
Igor
On 2014-06-05, 11:11, Paul Benedict wrote:
Igor, I can come up with three possible solutions which one I prefer.
1) Unspecified order plugins are all given highest precedence; specified
plugins come after.
2) Unspecified order plugins are all given lowest precedence; specified
plugins come before.
3) Unspecified order plugins are given a default precedence in steps of 100
(ordered by declaration); specified plugins can be before, middle, after by
choosing the appropriate number.
I like #3. In your example, I would assign jarsigner precedence value 150
to fit between pack200:normalize and pack200:goal.
Cheers,
Paul
On Thu, Jun 5, 2014 at 9:38 AM, Paul Benedict pbened...@apache.org wrote:
Good question. I haven't thought of that. In all the examples presented
thus far, the developer had control over all the id executions and
explicitly ordered them. This won't be the case all the time. What happens
when you mix ordering and unspecified?
Cheers,
Paul
On Thu, Jun 5, 2014 at 9:12 AM, Igor Fedorenko i...@ifedorenko.com
wrote:
Mojo executions bound to in packaging type lifecycle mapping have fixed
default-goal ids. To continue my Tycho pack200 example, I will need
to insert jarsigner between pack200:normalize and pack200:pack goals.
If pack200:normalize and pack200:pack goals are bound to the default
lifecycle, can you explain how to achieve desired execution order with
ids?
--
Regards,
Igor
On 2014-06-05, 9:52, Paul Benedict wrote:
After giving it some more thought, I think interpolating the id is less
disruptive than a new attribute. I am sure once POM 5 exists, there will
be
an official way.
Lastly, I am not not a fan of the step-# naming because it's a prefix
but
it is more descriptive; I would prefer to just simply allow the developer
to suffix with a -# (dash number). Thoughts on which nomenclature is
better?
Cheers,
Paul
On Wed, Jun 4, 2014 at 10:59 AM, Igor Fedorenko i...@ifedorenko.com
wrote:
I am not sure xml attributes are necessary a hack. Whether to put
before/after hints into xml element or attribute is really a matter of
taste, imho.
I don't want to restart the whole pom v 5 discussion again, but I was
under impression we agreed to preserve format published to maven
repository but allow changes in the format used during the build. Which
I believe implies that entire build section (or whaterver pom 5 will
end up using to represent build configuration) will be stripped out of
pom.xml files before they are deployed.
So I think it is okay to use xml attributes to represent before/after
hints today and we can decide to change this to something else when we
get to pom 5.
--
Regards,
Igor
On 2014-06-04, 11:39, Paul Benedict wrote:
Thanks for your reply Jason.
So it seems there are some possibilities for this ticket: either
interpreting the id to infer order (the patch) or stuffing this into
an
attribute (per Igor). Regarding the latter, the attribute route is
clearly
to avoid adding a new POM element, but aren't both a bit hackish? The
desired solution, I think, would be to make this a POM element, but
Re: Thoughts on MNG-3522
After giving it some more thought, I think interpolating the id is less disruptive than a new attribute. I am sure once POM 5 exists, there will be an official way. Lastly, I am not not a fan of the step-# naming because it's a prefix but it is more descriptive; I would prefer to just simply allow the developer to suffix with a -# (dash number). Thoughts on which nomenclature is better? Cheers, Paul On Wed, Jun 4, 2014 at 10:59 AM, Igor Fedorenko i...@ifedorenko.com wrote: I am not sure xml attributes are necessary a hack. Whether to put before/after hints into xml element or attribute is really a matter of taste, imho. I don't want to restart the whole pom v 5 discussion again, but I was under impression we agreed to preserve format published to maven repository but allow changes in the format used during the build. Which I believe implies that entire build section (or whaterver pom 5 will end up using to represent build configuration) will be stripped out of pom.xml files before they are deployed. So I think it is okay to use xml attributes to represent before/after hints today and we can decide to change this to something else when we get to pom 5. -- Regards, Igor On 2014-06-04, 11:39, Paul Benedict wrote: Thanks for your reply Jason. So it seems there are some possibilities for this ticket: either interpreting the id to infer order (the patch) or stuffing this into an attribute (per Igor). Regarding the latter, the attribute route is clearly to avoid adding a new POM element, but aren't both a bit hackish? The desired solution, I think, would be to make this a POM element, but past discussions inform me that's clearly off the table. Cheers, Paul On Wed, Jun 4, 2014 at 10:20 AM, Jason van Zyl ja...@takari.io wrote: I'm opposed to random creation of a DAG for executions across all the phases. This just creates a giant mess. That said _within_ a given phase if there was a topological sorting of executions where one execution can state that it depends on another I think is reasonable. Definitive ordering within a phase, I think, is useful. On Jun 4, 2014, at 10:22 AM, Paul Benedict pbened...@apache.org wrote: I find that solution interesting because, in a way, it kind of returns us to the days of Maven 1.x where you can run things pre/post goal. I am pretty sure Jason wanted to get rid of that perspective with this 2.x design, but maybe things are coming full circle? Cheers, Paul On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko i...@ifedorenko.com wrote: Yes, I was also thinking before/after as a way to solve this. We can probably use xml attributes without breaking compat with artifact consumers, so I think this can be done in Maven 3.x. -- Regards, Igor On 2014-06-04, 10:09, Robert Scholte wrote: Hi Paul, that's my understanding as well. But even in a single pom you can have issues. Consider 2 plugins, with both 2 goals and you want to run it like (phase=pre-integration-test) pluginA:preSomething pluginB:preStuff (phase=post-integration-test) pluginB:postStuff pluginA:postSomething Since plugins should be unique within the build-section, it's not possible to have a clean solution for this. Instead of the step-X solution of MNG-4727 I think you should be able to run it before or after a specified goal. We could think of using a convention for the execution-id, or define a new element in the pom-5.0.0 thanks, Robert Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict pbened...@apache.org: Anyone have thoughts on this ticket? There is a submitted patch, as the last comment says -- it's part of another ticket that was marked as duplicate. Though, I am a bit confused. I thought plugin execution was already defined by the sequential order listed in the POM. Am I incorrect? If so, I still don't know if that's good enough when using POM inheritance. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - A language that doesn’t affect the way you think about programming is not worth knowing. -- Alan Perlis - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-3522
I actually think the attributes are perfectly fine and won't interfere with anything. The attributes were always intended to be metadata about the elements and I think the use of instructing the core about how to order the executions falls into that category of use. On Jun 5, 2014, at 9:52 AM, Paul Benedict pbened...@apache.org wrote: After giving it some more thought, I think interpolating the id is less disruptive than a new attribute. I am sure once POM 5 exists, there will be an official way. Lastly, I am not not a fan of the step-# naming because it's a prefix but it is more descriptive; I would prefer to just simply allow the developer to suffix with a -# (dash number). Thoughts on which nomenclature is better? Cheers, Paul On Wed, Jun 4, 2014 at 10:59 AM, Igor Fedorenko i...@ifedorenko.com wrote: I am not sure xml attributes are necessary a hack. Whether to put before/after hints into xml element or attribute is really a matter of taste, imho. I don't want to restart the whole pom v 5 discussion again, but I was under impression we agreed to preserve format published to maven repository but allow changes in the format used during the build. Which I believe implies that entire build section (or whaterver pom 5 will end up using to represent build configuration) will be stripped out of pom.xml files before they are deployed. So I think it is okay to use xml attributes to represent before/after hints today and we can decide to change this to something else when we get to pom 5. -- Regards, Igor On 2014-06-04, 11:39, Paul Benedict wrote: Thanks for your reply Jason. So it seems there are some possibilities for this ticket: either interpreting the id to infer order (the patch) or stuffing this into an attribute (per Igor). Regarding the latter, the attribute route is clearly to avoid adding a new POM element, but aren't both a bit hackish? The desired solution, I think, would be to make this a POM element, but past discussions inform me that's clearly off the table. Cheers, Paul On Wed, Jun 4, 2014 at 10:20 AM, Jason van Zyl ja...@takari.io wrote: I'm opposed to random creation of a DAG for executions across all the phases. This just creates a giant mess. That said _within_ a given phase if there was a topological sorting of executions where one execution can state that it depends on another I think is reasonable. Definitive ordering within a phase, I think, is useful. On Jun 4, 2014, at 10:22 AM, Paul Benedict pbened...@apache.org wrote: I find that solution interesting because, in a way, it kind of returns us to the days of Maven 1.x where you can run things pre/post goal. I am pretty sure Jason wanted to get rid of that perspective with this 2.x design, but maybe things are coming full circle? Cheers, Paul On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko i...@ifedorenko.com wrote: Yes, I was also thinking before/after as a way to solve this. We can probably use xml attributes without breaking compat with artifact consumers, so I think this can be done in Maven 3.x. -- Regards, Igor On 2014-06-04, 10:09, Robert Scholte wrote: Hi Paul, that's my understanding as well. But even in a single pom you can have issues. Consider 2 plugins, with both 2 goals and you want to run it like (phase=pre-integration-test) pluginA:preSomething pluginB:preStuff (phase=post-integration-test) pluginB:postStuff pluginA:postSomething Since plugins should be unique within the build-section, it's not possible to have a clean solution for this. Instead of the step-X solution of MNG-4727 I think you should be able to run it before or after a specified goal. We could think of using a convention for the execution-id, or define a new element in the pom-5.0.0 thanks, Robert Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict pbened...@apache.org: Anyone have thoughts on this ticket? There is a submitted patch, as the last comment says -- it's part of another ticket that was marked as duplicate. Though, I am a bit confused. I thought plugin execution was already defined by the sequential order listed in the POM. Am I incorrect? If so, I still don't know if that's good enough when using POM inheritance. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - A
Re: Thoughts on MNG-3522
Mojo executions bound to in packaging type lifecycle mapping have fixed default-goal ids. To continue my Tycho pack200 example, I will need to insert jarsigner between pack200:normalize and pack200:pack goals. If pack200:normalize and pack200:pack goals are bound to the default lifecycle, can you explain how to achieve desired execution order with ids? -- Regards, Igor On 2014-06-05, 9:52, Paul Benedict wrote: After giving it some more thought, I think interpolating the id is less disruptive than a new attribute. I am sure once POM 5 exists, there will be an official way. Lastly, I am not not a fan of the step-# naming because it's a prefix but it is more descriptive; I would prefer to just simply allow the developer to suffix with a -# (dash number). Thoughts on which nomenclature is better? Cheers, Paul On Wed, Jun 4, 2014 at 10:59 AM, Igor Fedorenko i...@ifedorenko.com wrote: I am not sure xml attributes are necessary a hack. Whether to put before/after hints into xml element or attribute is really a matter of taste, imho. I don't want to restart the whole pom v 5 discussion again, but I was under impression we agreed to preserve format published to maven repository but allow changes in the format used during the build. Which I believe implies that entire build section (or whaterver pom 5 will end up using to represent build configuration) will be stripped out of pom.xml files before they are deployed. So I think it is okay to use xml attributes to represent before/after hints today and we can decide to change this to something else when we get to pom 5. -- Regards, Igor On 2014-06-04, 11:39, Paul Benedict wrote: Thanks for your reply Jason. So it seems there are some possibilities for this ticket: either interpreting the id to infer order (the patch) or stuffing this into an attribute (per Igor). Regarding the latter, the attribute route is clearly to avoid adding a new POM element, but aren't both a bit hackish? The desired solution, I think, would be to make this a POM element, but past discussions inform me that's clearly off the table. Cheers, Paul On Wed, Jun 4, 2014 at 10:20 AM, Jason van Zyl ja...@takari.io wrote: I'm opposed to random creation of a DAG for executions across all the phases. This just creates a giant mess. That said _within_ a given phase if there was a topological sorting of executions where one execution can state that it depends on another I think is reasonable. Definitive ordering within a phase, I think, is useful. On Jun 4, 2014, at 10:22 AM, Paul Benedict pbened...@apache.org wrote: I find that solution interesting because, in a way, it kind of returns us to the days of Maven 1.x where you can run things pre/post goal. I am pretty sure Jason wanted to get rid of that perspective with this 2.x design, but maybe things are coming full circle? Cheers, Paul On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko i...@ifedorenko.com wrote: Yes, I was also thinking before/after as a way to solve this. We can probably use xml attributes without breaking compat with artifact consumers, so I think this can be done in Maven 3.x. -- Regards, Igor On 2014-06-04, 10:09, Robert Scholte wrote: Hi Paul, that's my understanding as well. But even in a single pom you can have issues. Consider 2 plugins, with both 2 goals and you want to run it like (phase=pre-integration-test) pluginA:preSomething pluginB:preStuff (phase=post-integration-test) pluginB:postStuff pluginA:postSomething Since plugins should be unique within the build-section, it's not possible to have a clean solution for this. Instead of the step-X solution of MNG-4727 I think you should be able to run it before or after a specified goal. We could think of using a convention for the execution-id, or define a new element in the pom-5.0.0 thanks, Robert Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict pbened...@apache.org: Anyone have thoughts on this ticket? There is a submitted patch, as the last comment says -- it's part of another ticket that was marked as duplicate. Though, I am a bit confused. I thought plugin execution was already defined by the sequential order listed in the POM. Am I incorrect? If so, I still don't know if that's good enough when using POM inheritance. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - A language that doesn’t affect the way you think about
Re: Thoughts on MNG-3522
Good question. I haven't thought of that. In all the examples presented thus far, the developer had control over all the id executions and explicitly ordered them. This won't be the case all the time. What happens when you mix ordering and unspecified? Cheers, Paul On Thu, Jun 5, 2014 at 9:12 AM, Igor Fedorenko i...@ifedorenko.com wrote: Mojo executions bound to in packaging type lifecycle mapping have fixed default-goal ids. To continue my Tycho pack200 example, I will need to insert jarsigner between pack200:normalize and pack200:pack goals. If pack200:normalize and pack200:pack goals are bound to the default lifecycle, can you explain how to achieve desired execution order with ids? -- Regards, Igor On 2014-06-05, 9:52, Paul Benedict wrote: After giving it some more thought, I think interpolating the id is less disruptive than a new attribute. I am sure once POM 5 exists, there will be an official way. Lastly, I am not not a fan of the step-# naming because it's a prefix but it is more descriptive; I would prefer to just simply allow the developer to suffix with a -# (dash number). Thoughts on which nomenclature is better? Cheers, Paul On Wed, Jun 4, 2014 at 10:59 AM, Igor Fedorenko i...@ifedorenko.com wrote: I am not sure xml attributes are necessary a hack. Whether to put before/after hints into xml element or attribute is really a matter of taste, imho. I don't want to restart the whole pom v 5 discussion again, but I was under impression we agreed to preserve format published to maven repository but allow changes in the format used during the build. Which I believe implies that entire build section (or whaterver pom 5 will end up using to represent build configuration) will be stripped out of pom.xml files before they are deployed. So I think it is okay to use xml attributes to represent before/after hints today and we can decide to change this to something else when we get to pom 5. -- Regards, Igor On 2014-06-04, 11:39, Paul Benedict wrote: Thanks for your reply Jason. So it seems there are some possibilities for this ticket: either interpreting the id to infer order (the patch) or stuffing this into an attribute (per Igor). Regarding the latter, the attribute route is clearly to avoid adding a new POM element, but aren't both a bit hackish? The desired solution, I think, would be to make this a POM element, but past discussions inform me that's clearly off the table. Cheers, Paul On Wed, Jun 4, 2014 at 10:20 AM, Jason van Zyl ja...@takari.io wrote: I'm opposed to random creation of a DAG for executions across all the phases. This just creates a giant mess. That said _within_ a given phase if there was a topological sorting of executions where one execution can state that it depends on another I think is reasonable. Definitive ordering within a phase, I think, is useful. On Jun 4, 2014, at 10:22 AM, Paul Benedict pbened...@apache.org wrote: I find that solution interesting because, in a way, it kind of returns us to the days of Maven 1.x where you can run things pre/post goal. I am pretty sure Jason wanted to get rid of that perspective with this 2.x design, but maybe things are coming full circle? Cheers, Paul On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko i...@ifedorenko.com wrote: Yes, I was also thinking before/after as a way to solve this. We can probably use xml attributes without breaking compat with artifact consumers, so I think this can be done in Maven 3.x. -- Regards, Igor On 2014-06-04, 10:09, Robert Scholte wrote: Hi Paul, that's my understanding as well. But even in a single pom you can have issues. Consider 2 plugins, with both 2 goals and you want to run it like (phase=pre-integration-test) pluginA:preSomething pluginB:preStuff (phase=post-integration-test) pluginB:postStuff pluginA:postSomething Since plugins should be unique within the build-section, it's not possible to have a clean solution for this. Instead of the step-X solution of MNG-4727 I think you should be able to run it before or after a specified goal. We could think of using a convention for the execution-id, or define a new element in the pom-5.0.0 thanks, Robert Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict pbened...@apache.org: Anyone have thoughts on this ticket? There is a submitted patch, as the last comment says -- it's part of another ticket that was marked as duplicate. Though, I am a bit confused. I thought plugin execution was already defined by the sequential order listed in the POM. Am I incorrect? If so, I still don't know if that's good enough when using POM inheritance. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-3522
Igor, I can come up with three possible solutions which one I prefer. 1) Unspecified order plugins are all given highest precedence; specified plugins come after. 2) Unspecified order plugins are all given lowest precedence; specified plugins come before. 3) Unspecified order plugins are given a default precedence in steps of 100 (ordered by declaration); specified plugins can be before, middle, after by choosing the appropriate number. I like #3. In your example, I would assign jarsigner precedence value 150 to fit between pack200:normalize and pack200:goal. Cheers, Paul On Thu, Jun 5, 2014 at 9:38 AM, Paul Benedict pbened...@apache.org wrote: Good question. I haven't thought of that. In all the examples presented thus far, the developer had control over all the id executions and explicitly ordered them. This won't be the case all the time. What happens when you mix ordering and unspecified? Cheers, Paul On Thu, Jun 5, 2014 at 9:12 AM, Igor Fedorenko i...@ifedorenko.com wrote: Mojo executions bound to in packaging type lifecycle mapping have fixed default-goal ids. To continue my Tycho pack200 example, I will need to insert jarsigner between pack200:normalize and pack200:pack goals. If pack200:normalize and pack200:pack goals are bound to the default lifecycle, can you explain how to achieve desired execution order with ids? -- Regards, Igor On 2014-06-05, 9:52, Paul Benedict wrote: After giving it some more thought, I think interpolating the id is less disruptive than a new attribute. I am sure once POM 5 exists, there will be an official way. Lastly, I am not not a fan of the step-# naming because it's a prefix but it is more descriptive; I would prefer to just simply allow the developer to suffix with a -# (dash number). Thoughts on which nomenclature is better? Cheers, Paul On Wed, Jun 4, 2014 at 10:59 AM, Igor Fedorenko i...@ifedorenko.com wrote: I am not sure xml attributes are necessary a hack. Whether to put before/after hints into xml element or attribute is really a matter of taste, imho. I don't want to restart the whole pom v 5 discussion again, but I was under impression we agreed to preserve format published to maven repository but allow changes in the format used during the build. Which I believe implies that entire build section (or whaterver pom 5 will end up using to represent build configuration) will be stripped out of pom.xml files before they are deployed. So I think it is okay to use xml attributes to represent before/after hints today and we can decide to change this to something else when we get to pom 5. -- Regards, Igor On 2014-06-04, 11:39, Paul Benedict wrote: Thanks for your reply Jason. So it seems there are some possibilities for this ticket: either interpreting the id to infer order (the patch) or stuffing this into an attribute (per Igor). Regarding the latter, the attribute route is clearly to avoid adding a new POM element, but aren't both a bit hackish? The desired solution, I think, would be to make this a POM element, but past discussions inform me that's clearly off the table. Cheers, Paul On Wed, Jun 4, 2014 at 10:20 AM, Jason van Zyl ja...@takari.io wrote: I'm opposed to random creation of a DAG for executions across all the phases. This just creates a giant mess. That said _within_ a given phase if there was a topological sorting of executions where one execution can state that it depends on another I think is reasonable. Definitive ordering within a phase, I think, is useful. On Jun 4, 2014, at 10:22 AM, Paul Benedict pbened...@apache.org wrote: I find that solution interesting because, in a way, it kind of returns us to the days of Maven 1.x where you can run things pre/post goal. I am pretty sure Jason wanted to get rid of that perspective with this 2.x design, but maybe things are coming full circle? Cheers, Paul On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko i...@ifedorenko.com wrote: Yes, I was also thinking before/after as a way to solve this. We can probably use xml attributes without breaking compat with artifact consumers, so I think this can be done in Maven 3.x. -- Regards, Igor On 2014-06-04, 10:09, Robert Scholte wrote: Hi Paul, that's my understanding as well. But even in a single pom you can have issues. Consider 2 plugins, with both 2 goals and you want to run it like (phase=pre-integration-test) pluginA:preSomething pluginB:preStuff (phase=post-integration-test) pluginB:postStuff pluginA:postSomething Since plugins should be unique within the build-section, it's not possible to have a clean solution for this. Instead of the step-X solution of MNG-4727 I think you should be able to run it before or after a specified goal. We could think of using a convention for the execution-id, or define a new element in the pom-5.0.0 thanks, Robert Op Wed, 04 Jun 2014
Thoughts on MNG-3522
Anyone have thoughts on this ticket? There is a submitted patch, as the last comment says -- it's part of another ticket that was marked as duplicate. Though, I am a bit confused. I thought plugin execution was already defined by the sequential order listed in the POM. Am I incorrect? If so, I still don't know if that's good enough when using POM inheritance. Cheers, Paul
Re: Thoughts on MNG-3522
I haven't looked at the patch, but I know at least one case when it'd be nice to have explicit control over execution order within a build phase. Lets say you have two plugins, plugin-a with two goals a1 and a2, and plugin-b with goal b1. It is currently not possible to express the following execution order plugin-a:a1 plugin-b:b1 plugin-a:a2 Pack200 normalization, jar singing and pack200 packing during tycho build is real-world example where I had to artificially split pack200 normalization and pack goals between two plugins to workaround this limitation. -- Regards, Igor On 2014-06-04, 9:57, Paul Benedict wrote: Anyone have thoughts on this ticket? There is a submitted patch, as the last comment says -- it's part of another ticket that was marked as duplicate. Though, I am a bit confused. I thought plugin execution was already defined by the sequential order listed in the POM. Am I incorrect? If so, I still don't know if that's good enough when using POM inheritance. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-3522
Hi Paul, that's my understanding as well. But even in a single pom you can have issues. Consider 2 plugins, with both 2 goals and you want to run it like (phase=pre-integration-test) pluginA:preSomething pluginB:preStuff (phase=post-integration-test) pluginB:postStuff pluginA:postSomething Since plugins should be unique within the build-section, it's not possible to have a clean solution for this. Instead of the step-X solution of MNG-4727 I think you should be able to run it before or after a specified goal. We could think of using a convention for the execution-id, or define a new element in the pom-5.0.0 thanks, Robert Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict pbened...@apache.org: Anyone have thoughts on this ticket? There is a submitted patch, as the last comment says -- it's part of another ticket that was marked as duplicate. Though, I am a bit confused. I thought plugin execution was already defined by the sequential order listed in the POM. Am I incorrect? If so, I still don't know if that's good enough when using POM inheritance. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-3522
Yes, I do think plugins should have some sort of ordinal value associated to them. However, I am not sure if I like the proposed patch because it infers the order out of the plugin's id attribute (ex: step1, step2). Certainly such a feature could work, but it hits that wall in Maven development land: no one wants/can add new elements to the POM. Ideally, there would be another element, like order, to control this. Cheers, Paul On Wed, Jun 4, 2014 at 9:03 AM, Igor Fedorenko i...@ifedorenko.com wrote: I haven't looked at the patch, but I know at least one case when it'd be nice to have explicit control over execution order within a build phase. Lets say you have two plugins, plugin-a with two goals a1 and a2, and plugin-b with goal b1. It is currently not possible to express the following execution order plugin-a:a1 plugin-b:b1 plugin-a:a2 Pack200 normalization, jar singing and pack200 packing during tycho build is real-world example where I had to artificially split pack200 normalization and pack goals between two plugins to workaround this limitation. -- Regards, Igor On 2014-06-04, 9:57, Paul Benedict wrote: Anyone have thoughts on this ticket? There is a submitted patch, as the last comment says -- it's part of another ticket that was marked as duplicate. Though, I am a bit confused. I thought plugin execution was already defined by the sequential order listed in the POM. Am I incorrect? If so, I still don't know if that's good enough when using POM inheritance. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-3522
Yes, I was also thinking before/after as a way to solve this. We can probably use xml attributes without breaking compat with artifact consumers, so I think this can be done in Maven 3.x. -- Regards, Igor On 2014-06-04, 10:09, Robert Scholte wrote: Hi Paul, that's my understanding as well. But even in a single pom you can have issues. Consider 2 plugins, with both 2 goals and you want to run it like (phase=pre-integration-test) pluginA:preSomething pluginB:preStuff (phase=post-integration-test) pluginB:postStuff pluginA:postSomething Since plugins should be unique within the build-section, it's not possible to have a clean solution for this. Instead of the step-X solution of MNG-4727 I think you should be able to run it before or after a specified goal. We could think of using a convention for the execution-id, or define a new element in the pom-5.0.0 thanks, Robert Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict pbened...@apache.org: Anyone have thoughts on this ticket? There is a submitted patch, as the last comment says -- it's part of another ticket that was marked as duplicate. Though, I am a bit confused. I thought plugin execution was already defined by the sequential order listed in the POM. Am I incorrect? If so, I still don't know if that's good enough when using POM inheritance. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-3522
I find that solution interesting because, in a way, it kind of returns us to the days of Maven 1.x where you can run things pre/post goal. I am pretty sure Jason wanted to get rid of that perspective with this 2.x design, but maybe things are coming full circle? Cheers, Paul On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko i...@ifedorenko.com wrote: Yes, I was also thinking before/after as a way to solve this. We can probably use xml attributes without breaking compat with artifact consumers, so I think this can be done in Maven 3.x. -- Regards, Igor On 2014-06-04, 10:09, Robert Scholte wrote: Hi Paul, that's my understanding as well. But even in a single pom you can have issues. Consider 2 plugins, with both 2 goals and you want to run it like (phase=pre-integration-test) pluginA:preSomething pluginB:preStuff (phase=post-integration-test) pluginB:postStuff pluginA:postSomething Since plugins should be unique within the build-section, it's not possible to have a clean solution for this. Instead of the step-X solution of MNG-4727 I think you should be able to run it before or after a specified goal. We could think of using a convention for the execution-id, or define a new element in the pom-5.0.0 thanks, Robert Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict pbened...@apache.org: Anyone have thoughts on this ticket? There is a submitted patch, as the last comment says -- it's part of another ticket that was marked as duplicate. Though, I am a bit confused. I thought plugin execution was already defined by the sequential order listed in the POM. Am I incorrect? If so, I still don't know if that's good enough when using POM inheritance. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-3522
Maven 1.x was before my time :-) Can somebody recap the reasons ordering executions within a phase was decided harmful? -- Regards, Igor On 2014-06-04, 10:22, Paul Benedict wrote: I find that solution interesting because, in a way, it kind of returns us to the days of Maven 1.x where you can run things pre/post goal. I am pretty sure Jason wanted to get rid of that perspective with this 2.x design, but maybe things are coming full circle? Cheers, Paul On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko i...@ifedorenko.com wrote: Yes, I was also thinking before/after as a way to solve this. We can probably use xml attributes without breaking compat with artifact consumers, so I think this can be done in Maven 3.x. -- Regards, Igor On 2014-06-04, 10:09, Robert Scholte wrote: Hi Paul, that's my understanding as well. But even in a single pom you can have issues. Consider 2 plugins, with both 2 goals and you want to run it like (phase=pre-integration-test) pluginA:preSomething pluginB:preStuff (phase=post-integration-test) pluginB:postStuff pluginA:postSomething Since plugins should be unique within the build-section, it's not possible to have a clean solution for this. Instead of the step-X solution of MNG-4727 I think you should be able to run it before or after a specified goal. We could think of using a convention for the execution-id, or define a new element in the pom-5.0.0 thanks, Robert Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict pbened...@apache.org: Anyone have thoughts on this ticket? There is a submitted patch, as the last comment says -- it's part of another ticket that was marked as duplicate. Though, I am a bit confused. I thought plugin execution was already defined by the sequential order listed in the POM. Am I incorrect? If so, I still don't know if that's good enough when using POM inheritance. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Thoughts on MNG-3522
I'm opposed to random creation of a DAG for executions across all the phases. This just creates a giant mess. That said _within_ a given phase if there was a topological sorting of executions where one execution can state that it depends on another I think is reasonable. Definitive ordering within a phase, I think, is useful. On Jun 4, 2014, at 10:22 AM, Paul Benedict pbened...@apache.org wrote: I find that solution interesting because, in a way, it kind of returns us to the days of Maven 1.x where you can run things pre/post goal. I am pretty sure Jason wanted to get rid of that perspective with this 2.x design, but maybe things are coming full circle? Cheers, Paul On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko i...@ifedorenko.com wrote: Yes, I was also thinking before/after as a way to solve this. We can probably use xml attributes without breaking compat with artifact consumers, so I think this can be done in Maven 3.x. -- Regards, Igor On 2014-06-04, 10:09, Robert Scholte wrote: Hi Paul, that's my understanding as well. But even in a single pom you can have issues. Consider 2 plugins, with both 2 goals and you want to run it like (phase=pre-integration-test) pluginA:preSomething pluginB:preStuff (phase=post-integration-test) pluginB:postStuff pluginA:postSomething Since plugins should be unique within the build-section, it's not possible to have a clean solution for this. Instead of the step-X solution of MNG-4727 I think you should be able to run it before or after a specified goal. We could think of using a convention for the execution-id, or define a new element in the pom-5.0.0 thanks, Robert Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict pbened...@apache.org: Anyone have thoughts on this ticket? There is a submitted patch, as the last comment says -- it's part of another ticket that was marked as duplicate. Though, I am a bit confused. I thought plugin execution was already defined by the sequential order listed in the POM. Am I incorrect? If so, I still don't know if that's good enough when using POM inheritance. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - A language that doesn’t affect the way you think about programming is not worth knowing. -- Alan Perlis
Re: Thoughts on MNG-3522
Thanks for your reply Jason. So it seems there are some possibilities for this ticket: either interpreting the id to infer order (the patch) or stuffing this into an attribute (per Igor). Regarding the latter, the attribute route is clearly to avoid adding a new POM element, but aren't both a bit hackish? The desired solution, I think, would be to make this a POM element, but past discussions inform me that's clearly off the table. Cheers, Paul On Wed, Jun 4, 2014 at 10:20 AM, Jason van Zyl ja...@takari.io wrote: I'm opposed to random creation of a DAG for executions across all the phases. This just creates a giant mess. That said _within_ a given phase if there was a topological sorting of executions where one execution can state that it depends on another I think is reasonable. Definitive ordering within a phase, I think, is useful. On Jun 4, 2014, at 10:22 AM, Paul Benedict pbened...@apache.org wrote: I find that solution interesting because, in a way, it kind of returns us to the days of Maven 1.x where you can run things pre/post goal. I am pretty sure Jason wanted to get rid of that perspective with this 2.x design, but maybe things are coming full circle? Cheers, Paul On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko i...@ifedorenko.com wrote: Yes, I was also thinking before/after as a way to solve this. We can probably use xml attributes without breaking compat with artifact consumers, so I think this can be done in Maven 3.x. -- Regards, Igor On 2014-06-04, 10:09, Robert Scholte wrote: Hi Paul, that's my understanding as well. But even in a single pom you can have issues. Consider 2 plugins, with both 2 goals and you want to run it like (phase=pre-integration-test) pluginA:preSomething pluginB:preStuff (phase=post-integration-test) pluginB:postStuff pluginA:postSomething Since plugins should be unique within the build-section, it's not possible to have a clean solution for this. Instead of the step-X solution of MNG-4727 I think you should be able to run it before or after a specified goal. We could think of using a convention for the execution-id, or define a new element in the pom-5.0.0 thanks, Robert Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict pbened...@apache.org: Anyone have thoughts on this ticket? There is a submitted patch, as the last comment says -- it's part of another ticket that was marked as duplicate. Though, I am a bit confused. I thought plugin execution was already defined by the sequential order listed in the POM. Am I incorrect? If so, I still don't know if that's good enough when using POM inheritance. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - A language that doesn’t affect the way you think about programming is not worth knowing. -- Alan Perlis
Re: Thoughts on MNG-3522
I am not sure xml attributes are necessary a hack. Whether to put before/after hints into xml element or attribute is really a matter of taste, imho. I don't want to restart the whole pom v 5 discussion again, but I was under impression we agreed to preserve format published to maven repository but allow changes in the format used during the build. Which I believe implies that entire build section (or whaterver pom 5 will end up using to represent build configuration) will be stripped out of pom.xml files before they are deployed. So I think it is okay to use xml attributes to represent before/after hints today and we can decide to change this to something else when we get to pom 5. -- Regards, Igor On 2014-06-04, 11:39, Paul Benedict wrote: Thanks for your reply Jason. So it seems there are some possibilities for this ticket: either interpreting the id to infer order (the patch) or stuffing this into an attribute (per Igor). Regarding the latter, the attribute route is clearly to avoid adding a new POM element, but aren't both a bit hackish? The desired solution, I think, would be to make this a POM element, but past discussions inform me that's clearly off the table. Cheers, Paul On Wed, Jun 4, 2014 at 10:20 AM, Jason van Zyl ja...@takari.io wrote: I'm opposed to random creation of a DAG for executions across all the phases. This just creates a giant mess. That said _within_ a given phase if there was a topological sorting of executions where one execution can state that it depends on another I think is reasonable. Definitive ordering within a phase, I think, is useful. On Jun 4, 2014, at 10:22 AM, Paul Benedict pbened...@apache.org wrote: I find that solution interesting because, in a way, it kind of returns us to the days of Maven 1.x where you can run things pre/post goal. I am pretty sure Jason wanted to get rid of that perspective with this 2.x design, but maybe things are coming full circle? Cheers, Paul On Wed, Jun 4, 2014 at 9:19 AM, Igor Fedorenko i...@ifedorenko.com wrote: Yes, I was also thinking before/after as a way to solve this. We can probably use xml attributes without breaking compat with artifact consumers, so I think this can be done in Maven 3.x. -- Regards, Igor On 2014-06-04, 10:09, Robert Scholte wrote: Hi Paul, that's my understanding as well. But even in a single pom you can have issues. Consider 2 plugins, with both 2 goals and you want to run it like (phase=pre-integration-test) pluginA:preSomething pluginB:preStuff (phase=post-integration-test) pluginB:postStuff pluginA:postSomething Since plugins should be unique within the build-section, it's not possible to have a clean solution for this. Instead of the step-X solution of MNG-4727 I think you should be able to run it before or after a specified goal. We could think of using a convention for the execution-id, or define a new element in the pom-5.0.0 thanks, Robert Op Wed, 04 Jun 2014 15:57:08 +0200 schreef Paul Benedict pbened...@apache.org: Anyone have thoughts on this ticket? There is a submitted patch, as the last comment says -- it's part of another ticket that was marked as duplicate. Though, I am a bit confused. I thought plugin execution was already defined by the sequential order listed in the POM. Am I incorrect? If so, I still don't know if that's good enough when using POM inheritance. Cheers, Paul - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - A language that doesn’t affect the way you think about programming is not worth knowing. -- Alan Perlis - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
