Re: Manipulating the WAR directory before the WAR file gets built
That's interesting. Could you please fill something in JIRA with your use case and a sample? Thanks, Stéphane On 12/1/06, Simone Gianni [EMAIL PROTECTED] wrote: Hi all, I've developed a couple of plugin (one performs XML patches, the other builds a certain site structure). They both should work on the WAR directory structure, but before the WAR file is currently built. Apart from my specific needs, it could be quite common to need to perform some tasks (with an antrun for example) on the WAR directory structure before zipping it in the WAR file. Is there a way to hook these plugins (or any plugins) in between of the WAR plugin? In case, could it be a good idea to split the WAR plugin in two different goals so that it's possible to prepare the WAR directory structure and zip it in two different phases? Another option could be to use the WAR plugin to produce the directory structure (copying all the dependencies jars in place, doing war overlay etc..) and then use the assembly plugin (or antrun with a jar task :) ) to produce the final WAR file. Is this possible? Thanks, Simone - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Manipulating the WAR directory before the WAR file gets built
This sounds similar to my requirement of splitting the package phase into pre-package and package. Pre-package would assemble the exploded archive, whereas package would perform the archiving itself. This would allow other mojos to contribute to the archive assembly phase as you require. See http://www.mail-archive.com/dev@maven.apache.org/msg62286.html Mark On 04/12/06, Stephane Nicoll [EMAIL PROTECTED] wrote: That's interesting. Could you please fill something in JIRA with your use case and a sample? Thanks, Stéphane On 12/1/06, Simone Gianni [EMAIL PROTECTED] wrote: Hi all, I've developed a couple of plugin (one performs XML patches, the other builds a certain site structure). They both should work on the WAR directory structure, but before the WAR file is currently built. Apart from my specific needs, it could be quite common to need to perform some tasks (with an antrun for example) on the WAR directory structure before zipping it in the WAR file. Is there a way to hook these plugins (or any plugins) in between of the WAR plugin? In case, could it be a good idea to split the WAR plugin in two different goals so that it's possible to prepare the WAR directory structure and zip it in two different phases? Another option could be to use the WAR plugin to produce the directory structure (copying all the dependencies jars in place, doing war overlay etc..) and then use the assembly plugin (or antrun with a jar task :) ) to produce the final WAR file. Is this possible? Thanks, Simone - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Manipulating the WAR directory before the WAR file gets built
Yes, I've seen this thread as well. Sounds good to me even if we need strong use cases to create a new standard phase. Cheers, Stéphane On 12/4/06, Mark Hobson [EMAIL PROTECTED] wrote: This sounds similar to my requirement of splitting the package phase into pre-package and package. Pre-package would assemble the exploded archive, whereas package would perform the archiving itself. This would allow other mojos to contribute to the archive assembly phase as you require. See http://www.mail-archive.com/dev@maven.apache.org/msg62286.html Mark On 04/12/06, Stephane Nicoll [EMAIL PROTECTED] wrote: That's interesting. Could you please fill something in JIRA with your use case and a sample? Thanks, Stéphane On 12/1/06, Simone Gianni [EMAIL PROTECTED] wrote: Hi all, I've developed a couple of plugin (one performs XML patches, the other builds a certain site structure). They both should work on the WAR directory structure, but before the WAR file is currently built. Apart from my specific needs, it could be quite common to need to perform some tasks (with an antrun for example) on the WAR directory structure before zipping it in the WAR file. Is there a way to hook these plugins (or any plugins) in between of the WAR plugin? In case, could it be a good idea to split the WAR plugin in two different goals so that it's possible to prepare the WAR directory structure and zip it in two different phases? Another option could be to use the WAR plugin to produce the directory structure (copying all the dependencies jars in place, doing war overlay etc..) and then use the assembly plugin (or antrun with a jar task :) ) to produce the final WAR file. Is this possible? Thanks, Simone - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: Re: Manipulating the WAR directory before the WAR file gets built
Yes, I've seen this thread as well. Sounds good to me even if we need strong use cases to create a new standard phase. How about adding support for custom phases to the POM? That would allow developers and users to experiment with new phases and to build some experience with which ones are useful and which only look good but don't really work. Incidentially, I'd like to see a tool which can show me what phases there are and which plugin binds to which phase (in order to debug execution/dependency problems like https://jira.codehaus.org/browse/MSOURCES-11). Regards, -- Aaron Digulla - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
On 03/12/06, Jason van Zyl [EMAIL PROTECTED] wrote: What else would use it. I'm generally fine with things changing provided you have the magic three. And can you think of any adverse affects or conflicts with other phases. I can't think of any off the top of my head but adding a new lifecycle is not something we can ever take away once we do add it. I assume jetty:run-war doesn't count as the third then? ;) tomcat:exploded is another candidate for requiring pre-package phase rather than the full package. It would allow other mojos to contribute to the assembled package before it's archived. One example would be to produce an 'uberjar'. The dependency:unpack-dependencies plugin could be bound to the pre-package phase and then the jar plugin could then archive the result in the package phase. The only possible conflicting phases would be generate-sources and generate-resources, since these phases also allow some manipulation of the final package. Although I think this phase provides a unique extension point, since both those phases would be the wrong place to perform package assembly actions such as those detailed above. A related thread that also requires this functionality: http://www.mail-archive.com/dev@maven.apache.org/msg62255.html Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
On 03/12/06, Brett Porter [EMAIL PROTECTED] wrote: Pretty sure the issue already exists... should just be done IMO. Ah-ha, found it.. :) http://jira.codehaus.org/browse/MNG-2097 Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
Hi, As a side note it strikes me that the primary problem is that the war:war goal does a little too much in a single go during the packaging phase. Could the issue be solved by spreading the work of the war:war goal through the existing phases? Mike Horwitz On 12/4/06, Mark Hobson [EMAIL PROTECTED] wrote: On 03/12/06, Brett Porter [EMAIL PROTECTED] wrote: Pretty sure the issue already exists... should just be done IMO. Ah-ha, found it.. :) http://jira.codehaus.org/browse/MNG-2097 Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
Actually, before we jump into this, let's consider the use case at hand. While easily solved by pre-package at this point, we may find other needs. Currently, *-resources handles class path resources, which are required to be treated separately to the package because in many cases, such as a webapp, the package is not equal to the set of classpath resources (or equivalent for whatever other language is being dealt with). Here, we are processing 'resources' for the package (assembly, war, tomcat installation, etc). pre-package is basically just a different process-resources phase. So, instead of the addition to the 'pre-package' phase, should we consider generate-package-resources and process-package-resources phases prior to 'package' in the lifecycle? This would allow us to generalise the 'resource' lifecycle steps in the same way as for regular resources, and test resources, including adding 'packageResources/' to the POM as a replacement for the custom webResources configuration for the war plugin and as a way of introducing things to assemblies without the descriptor (allowing for more generalised descriptors as we recently discussed). Thoughts? - Brett On 04/12/2006, at 9:59 PM, Michael Horwitz wrote: Hi, As a side note it strikes me that the primary problem is that the war:war goal does a little too much in a single go during the packaging phase. Could the issue be solved by spreading the work of the war:war goal through the existing phases? Mike Horwitz On 12/4/06, Mark Hobson [EMAIL PROTECTED] wrote: On 03/12/06, Brett Porter [EMAIL PROTECTED] wrote: Pretty sure the issue already exists... should just be done IMO. Ah-ha, found it.. :) http://jira.codehaus.org/browse/MNG-2097 Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
On 04/12/06, Brett Porter [EMAIL PROTECTED] wrote: Actually, before we jump into this, let's consider the use case at hand. While easily solved by pre-package at this point, we may find other needs. Currently, *-resources handles class path resources, which are required to be treated separately to the package because in many cases, such as a webapp, the package is not equal to the set of classpath resources (or equivalent for whatever other language is being dealt with). Here, we are processing 'resources' for the package (assembly, war, tomcat installation, etc). pre-package is basically just a different process-resources phase. So, instead of the addition to the 'pre-package' phase, should we consider generate-package-resources and process-package-resources phases prior to 'package' in the lifecycle? This would allow us to generalise the 'resource' lifecycle steps in the same way as for regular resources, and test resources, including adding 'packageResources/' to the POM as a replacement for the custom webResources configuration for the war plugin and as a way of introducing things to assemblies without the descriptor (allowing for more generalised descriptors as we recently discussed). Sounds good; although in the case of a war, would executing up to the process-package-resources phase produce the fully exploded war? Or would the package resources only contain the web resources, omitting WEB-INF/**? My use-case would require the full exploded package as it would be archived. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
On 04/12/2006, at 10:24 PM, Mark Hobson wrote: Sounds good; although in the case of a war, would executing up to the process-package-resources phase produce the fully exploded war? Or would the package resources only contain the web resources, omitting WEB-INF/**? My use-case would require the full exploded package as it would be archived. Well, it would be like other archives. By default, it would pull them from the various added sources straight into the archive - src/main/ webapp, target/generated-package-resources, for example. However, it would be sensible for the war plugin to have an option that copied all of these into target/webapp-name (in the same way as war:webapp), and then using that as the single war resource directory to package. That's off the top of my head, not sure if it makes sense but seems consistent with how we do things elsewhere. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
On 04/12/06, Brett Porter [EMAIL PROTECTED] wrote: Well, it would be like other archives. By default, it would pull them from the various added sources straight into the archive - src/main/ webapp, target/generated-package-resources, for example. However, it would be sensible for the war plugin to have an option that copied all of these into target/webapp-name (in the same way as war:webapp), and then using that as the single war resource directory to package. Yes, it'd be hard to see how war overlaying could easily work without building the exploded war first. That's off the top of my head, not sure if it makes sense but seems consistent with how we do things elsewhere. My only problem would be that depending on the phase process-package-resources doesn't necessarily mean the exploded archive has been built. This may be the case for the war plugin, if it's been configured that way, but as you say other packagings pull items in dynamically. I'm not sure whether this still leaves a requirement for a pre-package phase to produce the full exploded archive? Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
Brett Porter wrote: Actually, before we jump into this, let's consider the use case at hand. While easily solved by pre-package at this point, we may find other needs. To take these suggestions even further, perhaps the idea of a fixed set of phases is too limiting. An alternative would be to number phases, from (say) 0 to 1000, with the current named phases as aliases for 100, 200, etc. Then it's easy for plugins which need it to slip in an extra phase. I've lost count of the number of times I've told people on #maven that there is no way to ensure that a particular execution runs between phases X and Y. Admittedly, there's a bug which means that execution order isn't preserved within a phase, and fixing that would ameliorate this. Anyway, I'm fully expected to be shouted down, and told that this will only lead to confusion; however, I think it's worth considering. Cheers, Richard -- Richard van der Hoff [EMAIL PROTECTED] Telephony Gateways Project Manager Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
Pretty sure we've shouted it down with reasons before, hopefully the archives will be of some assistance :) - Brett On 05/12/2006, at 12:08 AM, Richard van der Hoff wrote: Brett Porter wrote: Actually, before we jump into this, let's consider the use case at hand. While easily solved by pre-package at this point, we may find other needs. To take these suggestions even further, perhaps the idea of a fixed set of phases is too limiting. An alternative would be to number phases, from (say) 0 to 1000, with the current named phases as aliases for 100, 200, etc. Then it's easy for plugins which need it to slip in an extra phase. I've lost count of the number of times I've told people on #maven that there is no way to ensure that a particular execution runs between phases X and Y. Admittedly, there's a bug which means that execution order isn't preserved within a phase, and fixing that would ameliorate this. Anyway, I'm fully expected to be shouted down, and told that this will only lead to confusion; however, I think it's worth considering. Cheers, Richard -- Richard van der Hoff [EMAIL PROTECTED] Telephony Gateways Project Manager Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
On 4 Dec 2006, at 14:08, Richard van der Hoff wrote: Brett Porter wrote: Actually, before we jump into this, let's consider the use case at hand. While easily solved by pre-package at this point, we may find other needs. To take these suggestions even further, perhaps the idea of a fixed set of phases is too limiting. That's an insight that can count! An alternative would be to number phases, from (say) 0 to 1000, with the current named phases as aliases for 100, 200, etc. Then it's easy for plugins which need it to slip in an extra phase. Now that's scary. I just got the shivers. Perhaps the idea of a fixed build lifecycle is a bit too limiting, itself? There are more problems with it than this (where do I link object code from C++?). This is just a symptom … Our development team has the same feeling with JSF, by the way … Lifecycles seemed like a good idea … was a pattern that had popularity … tried it out, beat it to dead … didn't cut it? The Maven 1 pre / post approach wasn't ideal either, and was left behind for something better … Consider that the declarative and open Ant depends, where the tool calculates the correct order in which to execute tasks, uhm, Mojo's, is stable and works. I do have the impression that this approach can be used with existing Mojo-based plugins with little change, and that the gripes with this architecture can be solved (and I have some ideas on how to merge it into the Maven philosophy). Sounds like Maven 3, or at least 2 1/2. though … I suggest not rocking the boat too hard at this time. I've lost count of the number of times I've told people on #maven that there is no way to ensure that a particular execution runs between phases X and Y. Admittedly, there's a bug which means that execution order isn't preserved within a phase, and fixing that would ameliorate this. Anyway, I'm fully expected to be shouted down, and told that this will only lead to confusion; however, I think it's worth considering. Cheers, Richard -- Richard van der Hoff [EMAIL PROTECTED] Telephony Gateways Project Manager Tel: +44 (0) 845 666 7778 http://www.mxtelecom.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
Richard, I love this idea and hate it at the same time. The idea of using numbers, as I'm sure has been pointed out before, just seems awful. But I understand what you are driving at. If there was a way to register named phases with the numbers that would be better. OTOH, wouldn't it be better just to allow the list of phases to be specified in settings.xml? Ralph Richard van der Hoff wrote: Brett Porter wrote: Actually, before we jump into this, let's consider the use case at hand. While easily solved by pre-package at this point, we may find other needs. To take these suggestions even further, perhaps the idea of a fixed set of phases is too limiting. An alternative would be to number phases, from (say) 0 to 1000, with the current named phases as aliases for 100, 200, etc. Then it's easy for plugins which need it to slip in an extra phase. I've lost count of the number of times I've told people on #maven that there is no way to ensure that a particular execution runs between phases X and Y. Admittedly, there's a bug which means that execution order isn't preserved within a phase, and fixing that would ameliorate this. Anyway, I'm fully expected to be shouted down, and told that this will only lead to confusion; however, I think it's worth considering. Cheers, Richard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
On 4 Dec 06, at 9:59 AM 4 Dec 06, Ralph Goers wrote: Richard, I love this idea and hate it at the same time. The idea of using numbers, as I'm sure has been pointed out before, just seems awful. But I understand what you are driving at. If there was a way to register named phases with the numbers that would be better. OTOH, wouldn't it be better just to allow the list of phases to be specified in settings.xml? Ralph You can always make your own lifecycle, which is not that hard if you really need it. We will only expand the lifecycle as the need requires. It will never become a mess of spaghetti like Maven 1.x. To allow free form to accommodate the ever shrinking number of cases we can't handle is just not worth it. The standard lifecycle then disappears and Maven becomes a very hard to explain. It one of the fundamental differences between Maven and everything else and though we run up against some limitations it is one of Maven's most powerful attributes. Jason. Richard van der Hoff wrote: Brett Porter wrote: Actually, before we jump into this, let's consider the use case at hand. While easily solved by pre-package at this point, we may find other needs. To take these suggestions even further, perhaps the idea of a fixed set of phases is too limiting. An alternative would be to number phases, from (say) 0 to 1000, with the current named phases as aliases for 100, 200, etc. Then it's easy for plugins which need it to slip in an extra phase. I've lost count of the number of times I've told people on #maven that there is no way to ensure that a particular execution runs between phases X and Y. Admittedly, there's a bug which means that execution order isn't preserved within a phase, and fixing that would ameliorate this. Anyway, I'm fully expected to be shouted down, and told that this will only lead to confusion; however, I think it's worth considering. Cheers, Richard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Manipulating the WAR directory before the WAR file gets built
Mark Struberg wrote: --- Brett Porter [EMAIL PROTECTED] schrieb: Isn't that what war:war does? In theory (documentation) i would say yes: This goal simply package the directory created by war:webapp goal. But unfortunately (for what i see in the code) the buildExplodedWebapp is not seperated, but called from within the WarMojo, and it seems to me that the changes done manually may be overwritten. I haven't tested this though, so it's only a guess and you should give this a try. Yep, exactly. I opened the issue http://jira.codehaus.org/browse/MWAR-86, attached a patch, and commented a typical use case (a plugin that patches some files in the war, before warring it :) ). With the patch there is a snippet of how successfully managed to obtain create war structure - work on it - package the war file. Simone - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Manipulating the WAR directory before the WAR file gets built
Mark Hobson wrote: This sounds similar to my requirement of splitting the package phase into pre-package and package. Pre-package would assemble the exploded archive, whereas package would perform the archiving itself. This would allow other mojos to contribute to the archive assembly phase as you require. See http://www.mail-archive.com/dev@maven.apache.org/msg62286.html Absolutely. A pre-package would be the right hook to place the war exploded goal so that it explodes the war structure, overlays and so on, while on the package phase it will only package it. Then other plugins could simply hook to the pre-package phase if they need to work on the stuff that will end up in the war/jar/whatever else. So, a big non-binding +1 for your proposal :) Simone - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
Richard van der Hoff [EMAIL PROTECTED] schrieb am 04.12.2006 14:08:37: Actually, before we jump into this, let's consider the use case at hand. While easily solved by pre-package at this point, we may find other needs. To take these suggestions even further, perhaps the idea of a fixed set of phases is too limiting. An alternative would be to number phases, from (say) 0 to 1000, with the current named phases as aliases for 100, 200, etc. Then it's easy for plugins which need it to slip in an extra phase. As I said before, I've had very good results with a build system in which you can specify arbitrary phases and say this phase depends on that one. So I could say package depends on prepackage-tomcat-war and maven sorts everything out. This of course means maven has to load all plugins (or at least the configs) at startup. Regards, -- Aaron Digulla - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
On 4 Dec 2006, at 16:51, Jason van Zyl wrote: On 4 Dec 06, at 9:59 AM 4 Dec 06, Ralph Goers wrote: Richard, I love this idea and hate it at the same time. The idea of using numbers, as I'm sure has been pointed out before, just seems awful. But I understand what you are driving at. If there was a way to register named phases with the numbers that would be better. OTOH, wouldn't it be better just to allow the list of phases to be specified in settings.xml? Ralph You can always make your own lifecycle, which is not that hard if you really need it. Am I correct in assuming that you are refering to what, e.g., the release plugin does? We will only expand the lifecycle as the need requires. It will never become a mess of spaghetti like Maven 1.x. To allow free form to accommodate the ever shrinking number of cases we can't handle is just not worth it. The standard lifecycle then disappears and Maven becomes a very hard to explain. It one of the fundamental differences between Maven and everything else and though we run up against some limitations it is one of Maven's most powerful attributes. Jason. Richard van der Hoff wrote: Brett Porter wrote: Actually, before we jump into this, let's consider the use case at hand. While easily solved by pre-package at this point, we may find other needs. To take these suggestions even further, perhaps the idea of a fixed set of phases is too limiting. An alternative would be to number phases, from (say) 0 to 1000, with the current named phases as aliases for 100, 200, etc. Then it's easy for plugins which need it to slip in an extra phase. I've lost count of the number of times I've told people on #maven that there is no way to ensure that a particular execution runs between phases X and Y. Admittedly, there's a bug which means that execution order isn't preserved within a phase, and fixing that would ameliorate this. Anyway, I'm fully expected to be shouted down, and told that this will only lead to confusion; however, I think it's worth considering. Cheers, Richard - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Manipulating the WAR directory before the WAR file gets built
Stephane Nicoll wrote: Yes, I've seen this thread as well. Sounds good to me even if we need strong use cases to create a new standard phase. Basic use cases I've seen so far, applied to the WAR problem : - Cocoon team developed a plugin that deploys its blocks inside a war. This way, the user only have to specify which blocks their application depend on, and then the plugin will take them, unpack some certain files from a standard block jar structure inside some folders in the war, and do some other stuff on the web.xml and similar files. Right now this plugin has been developed as extending the AbstractWarMojo. Unfortunately this worked fine up to a certain version, but now fails with an NPE cause of what's written here http://www.mail-archive.com/dev@maven.apache.org/msg60770.html and here http://issues.apache.org/jira/browse/COCOON-1961 . - I've developed a plugin that applies XML patches to mostly every target directory structure, but if not subclassing the war mojo (and having the errors), or using other techniques (like running war exploded and then using the assembly plugin etc..), or using my patch (http://jira.codehaus.org/browse/MWAR-86 ) I have no way to see it work on a war directory structure before it gets packed. - For a project I'm doing and that I'll post on apache labs ASAP, I developed a plugin that taken a certain source folder structure creates a working cocoon application, generating sitemaps etc.. Same as above, no way to have it work to build a WAR out of it. - A friend of mine needed to run a legacy ant task on some files before packing the WAR, he wanted to use antrun but again... He ended up using war exploded and then appending to it's ant run a task to build the war. Adding a phase is, IMHHHO, not a lightweight change. Also, adding a pre-package phase sounds a bit like going back to maven1 pregoals, but a way to work between the prepare and the package phase of a packaging mojo is absolutely needed. Simone - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: Re: [m2] New pre-package phase?
Jason van Zyl [EMAIL PROTECTED] schrieb am 04.12.2006 16:51:30: You can always make your own lifecycle, which is not that hard if you really need it.[...]To allow free form to accommodate the ever shrinking number of cases we can't handle is just not worth it. The standard lifecycle then disappears and Maven becomes a very hard to explain. It one of the fundamental differences between Maven and everything else and though we run up against some limitations it is one of Maven's most powerful attributes. I'm not against the standard life cycle. I'm against the executions elements in the POM :-) What I would like to see is to get rid of executions and add depends where you can name arbitrary phases. Some will come from the standard life cycle of maven, others will be created by the POM. That would allow to weave in arbitrary complex phase dependencies as you need them. They would not pollute the core or any other plugins. So basically just add an interface which allows me to inject new phases from my POMs and Mojos. And while we're at it: How about merging phases and goals? What is the big difference between them anyway? Isn't that something which new users always wonder about and which you could easily hide behind the scenes? Regards, -- Aaron Digulla - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
On 4 Dec 06, at 11:14 AM 4 Dec 06, [EMAIL PROTECTED] wrote: Richard van der Hoff [EMAIL PROTECTED] schrieb am 04.12.2006 14:08:37: Actually, before we jump into this, let's consider the use case at hand. While easily solved by pre-package at this point, we may find other needs. To take these suggestions even further, perhaps the idea of a fixed set of phases is too limiting. An alternative would be to number phases, from (say) 0 to 1000, with the current named phases as aliases for 100, 200, etc. Then it's easy for plugins which need it to slip in an extra phase. As I said before, I've had very good results with a build system in which you can specify arbitrary phases and say this phase depends on that one. And how much luck have you had showing that system to other people? And how much luck have other people had looking at what you've made without them having to consult you? In my experience it can take an incredibly long time to pass that knowledge on and if the original author of the system is not around it can verge on disaster. People often forget the real costs because they understand it themselves but neglect the critical factor of having to transfer this knowledge to someone else. Creating a system where you have random interaction can potentially create a system with extremely high infrastructural costs. Shared infrastructure means lower costs and that means a predictable system. These needs for new phases arise and we can deal with them. I don't see any point in creating arbitrary phases because almost all application development has the same requirements. They are far less wildly different then people like to think. Jason. So I could say package depends on prepackage-tomcat-war and maven sorts everything out. This of course means maven has to load all plugins (or at least the configs) at startup. Regards, -- Aaron Digulla - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Generating the POM with the schema definition
Hi guys,
The Maven Embedder schema writer does not generate the pom.xml with the
schema definitions, so I went out for the maven-model and generated the
sources and I haven't found a way to add the schema defiition without
changing the generated sources (something that is truly evil).
The code that needs to be added is the following:
private void writeModel(Model model, String tagName, XmlSerializer
serializer)
throws java.io.IOException
{
if ( model != null )
{
serializer.startTag( NAMESPACE, tagName );
serializer.attribute(NAMESPACE, xmlns,
http://maven.apache.org/POM/4.0.0;);
serializer.attribute(NAMESPACE, xmlns:xsi,
http://www.w3.org/2001/XMLSchema-instance;);
serializer.attribute(NAMESPACE, xsi:schemaLocation,
http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd;);
Is there any easier way to do this?
The true problem is, everytime I add a dependency using the M2Eclipse
plugin it removes my schema definition =(
--
Maurício Linhares de Aragão Junior
Estagiário
Avenida Rui Carneiro, 300, Sala 804
Miramar, João Pessoa-Pb, Brasil
CEP: 58032-100
+55 83 3243-0800 (Fone)
+55 83 3243-1014 (Fax)
www.phoebus.com.br
Esta mensagem pode conter informação confidencial e/ou privilegiada,
sendo seu sigilo protegido por lei. Se você não for o destinatário ou a
pessoa autorizada a receber esta mensagem, não pode usar, copiar ou
divulgar as informações nela contidas ou tomar qualquer ação baseada
nessas informações. Se você recebeu esta mensagem por engano, por favor,
avise imediatamente ao remetente, respondendo o e-mail e em seguida
apague-a. Agradecemos sua cooperação.
This message may contain confidential and/or privileged information and
its confidentiality is protected by law. If you are not the addressed or
authorized person to receive this message, you must not use, copy,
disclose or take any action based on it or any information herein. If
you have received this message by mistake, please advise the sender
immediately by replying the e-mail and then deleting it. Thank you for
your cooperation.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Maven 1.x release
Hi Guys, What's left to do before the M1 release can go out? We need to get the Maven 1.x repository usage off Ibiblio. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.x release
Hi, According to the roadmap [1], there's 25 issues left. Mostly plugin upgrades which could come quite quickly and at least 1755 and 1789. The problem is that we're trying to release RC1 and it makes not much sense if we have still open issues scheduled for 1.1 Cheers, Stéphane [1] http://jira.codehaus.org/browse/MAVEN?report=com.atlassian.jira.plugin.system.project:roadmap-panel On 12/5/06, Jason van Zyl [EMAIL PROTECTED] wrote: Hi Guys, What's left to do before the M1 release can go out? We need to get the Maven 1.x repository usage off Ibiblio. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.x release
what I see is that there's always issues that anyone wants to get fixed and that makes the releases take forever. If things are not critical imho is more important to release often and move issues to 1.1.1 On 12/4/06, Stephane Nicoll [EMAIL PROTECTED] wrote: Hi, According to the roadmap [1], there's 25 issues left. Mostly plugin upgrades which could come quite quickly and at least 1755 and 1789. The problem is that we're trying to release RC1 and it makes not much sense if we have still open issues scheduled for 1.1 Cheers, Stéphane [1] http://jira.codehaus.org/browse/MAVEN?report=com.atlassian.jira.plugin.system.project:roadmap-panel On 12/5/06, Jason van Zyl [EMAIL PROTECTED] wrote: Hi Guys, What's left to do before the M1 release can go out? We need to get the Maven 1.x repository usage off Ibiblio. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.x release
On 12/5/06, Carlos Sanchez [EMAIL PROTECTED] wrote: what I see is that there's always issues that anyone wants to get fixed and that makes the releases take forever. If things are not critical imho is more important to release often and move issues to 1.1.1 Then we should at least fix 1755 and 1789. Arnaud, do you have time to work on 1755? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.x release
Exactly... Trying to quantify the stability of a release before it goes out the door is just impossible/not practical for os. Release early often. ;) On 12/4/06, Carlos Sanchez [EMAIL PROTECTED] wrote: what I see is that there's always issues that anyone wants to get fixed and that makes the releases take forever. If things are not critical imho is more important to release often and move issues to 1.1.1 On 12/4/06, Stephane Nicoll [EMAIL PROTECTED] wrote: Hi, According to the roadmap [1], there's 25 issues left. Mostly plugin upgrades which could come quite quickly and at least 1755 and 1789. The problem is that we're trying to release RC1 and it makes not much sense if we have still open issues scheduled for 1.1 Cheers, Stéphane [1] http://jira.codehaus.org/browse/MAVEN?report=com.atlassian.jira.plugin.system.project:roadmap-panel On 12/5/06, Jason van Zyl [EMAIL PROTECTED] wrote: Hi Guys, What's left to do before the M1 release can go out? We need to get the Maven 1.x repository usage off Ibiblio. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 1.x release
The only real condition for Maven 1.1 is making sure backwards compat is intact, or at least documented where broken intentionally. - Brett On 05/12/2006, at 1:47 PM, Jesse Kuhnert wrote: Exactly... Trying to quantify the stability of a release before it goes out the door is just impossible/not practical for os. Release early often. ;) On 12/4/06, Carlos Sanchez [EMAIL PROTECTED] wrote: what I see is that there's always issues that anyone wants to get fixed and that makes the releases take forever. If things are not critical imho is more important to release often and move issues to 1.1.1 On 12/4/06, Stephane Nicoll [EMAIL PROTECTED] wrote: Hi, According to the roadmap [1], there's 25 issues left. Mostly plugin upgrades which could come quite quickly and at least 1755 and 1789. The problem is that we're trying to release RC1 and it makes not much sense if we have still open issues scheduled for 1.1 Cheers, Stéphane [1] http://jira.codehaus.org/browse/MAVEN? report=com.atlassian.jira.plugin.system.project:roadmap-panel On 12/5/06, Jason van Zyl [EMAIL PROTECTED] wrote: Hi Guys, What's left to do before the M1 release can go out? We need to get the Maven 1.x repository usage off Ibiblio. Jason. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
