Re: [m2] New pre-package phase?
Quoting Brett Porter [EMAIL PROTECTED]: I don't think either of these are cases for 'package resources', but general lifecycle improvements (Which are in the 2.1 design wiki). I'm still arguing for a generic lifecycle management (where a mojo can add any number of additional phases and maven just supplies a default starting set). Do you want me to add my ideas and use cases to http://docs.codehaus.org/display/MAVEN/Lifecycle+and+Plugin+Handling? Regards, -- Aaron Optimizer Digulla a.k.a. Philmann Dark It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits. http://www.philmann-dark.de/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
I don't think either of these are cases for 'package resources', but general lifecycle improvements (Which are in the 2.1 design wiki). Is that right? - Brett On 06/01/2007, at 7:47 AM, Aaron Digulla wrote: Brett Porter wrote: Can anyone think of a use case other than the war plugin, or should we just go with the pre-package phase? I have these use cases: - Filter or generate files for the site plugin (for example, extract information out of the sources for apt files) - Multi-Step source/unit test generation (XML - XML - Java and DB - XML - Java including filtering) Regards, -- Aaron Optimizer Digulla a.k.a. Philmann Dark It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits. http://www.philmann-dark.de/ - 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?
Brett Porter wrote: Can anyone think of a use case other than the war plugin, or should we just go with the pre-package phase? I have these use cases: - Filter or generate files for the site plugin (for example, extract information out of the sources for apt files) - Multi-Step source/unit test generation (XML - XML - Java and DB - XML - Java including filtering) Regards, -- Aaron Optimizer Digulla a.k.a. Philmann Dark It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits. http://www.philmann-dark.de/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
Can anyone think of a use case other than the war plugin, or should we just go with the pre-package phase? On 18/12/2006, at 8:49 PM, Brett Porter wrote: On 18/12/2006, at 7:02 PM, Kenney Westerhof wrote: If you put it that way, then it sounds fine. Except it's not generally appliccable, only for (currently) war projects (possibly ear projects too). (Also for non-java projects, resources usually aren't classpath resources - real resources like windows .res files are linked in with the dll/exe, although that is kind of a 'classpath' resource too then). Yeah, I know what you mean. It's really a relic of being ill- defined in the past so we have to stick with the current behaviour (where things like properties files wind up in the right place to be picked up as bundles, etc). What about we just change the lifecycle for the war plugin and add phases there? I think redefining the lifecycle for a packaging would be uglier (and I don't think we actually support that in the current implementation - would need to check). Aside from that, there is use for the concept for other packagings (eg, the assembly plugin). I guess, the question is whether we generalise a concept that may or may not have uses outside the war plugin (ie, pushing webResources up to POM level and adding the extra phases for them), or whether we address the use case with a pre-package phase. I'd be happy with either. I think if we have any use cases beyond the war plugin we should do the first, otherwise the second (as it is far simpler). Cheers, Brett - 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?
Brett Porter wrote: I read through all these threads, and they kind of ran off into entirely different tracks on alternate build systems and CM. On Kenney's points in particular: On 06/12/2006, at 12:41 AM, Kenney Westerhof wrote: I'm basically -0 on adding generate-package-resources/process-package-resources since it doesn't add anything new - things done there can be done in generate-resources/process-resources. There's no need to duplicate those pases later on in the lifecycle (right?). Well, it depends on how 'resources' are defined. The definition, as defined by current behaviour, is a classpath resource (or equivalent for your given language that isn't Java). The WAR plugin already has a custom configuration webResources/, which are 'packaging resources', a different thing. We can't repurpose resources/ or change the war plugin in the ways you've suggested (disallowing classes) without a significant break in backwards compatibility (far worse than changing the lifecycle) My opinion is still that adding 'packaging resources' (or something with a better name), and the corresponding lifecycle stages (for consistency with other types of 'resources') is the best solution to the presented use cases (rather than a pre-package phase, though that'd do the trick too). WDYT? If you put it that way, then it sounds fine. Except it's not generally appliccable, only for (currently) war projects (possibly ear projects too). (Also for non-java projects, resources usually aren't classpath resources - real resources like windows .res files are linked in with the dll/exe, although that is kind of a 'classpath' resource too then). What about we just change the lifecycle for the war plugin and add phases there? -- Kenney - Brett - 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 18/12/2006, at 7:02 PM, Kenney Westerhof wrote: If you put it that way, then it sounds fine. Except it's not generally appliccable, only for (currently) war projects (possibly ear projects too). (Also for non-java projects, resources usually aren't classpath resources - real resources like windows .res files are linked in with the dll/exe, although that is kind of a 'classpath' resource too then). Yeah, I know what you mean. It's really a relic of being ill-defined in the past so we have to stick with the current behaviour (where things like properties files wind up in the right place to be picked up as bundles, etc). What about we just change the lifecycle for the war plugin and add phases there? I think redefining the lifecycle for a packaging would be uglier (and I don't think we actually support that in the current implementation - would need to check). Aside from that, there is use for the concept for other packagings (eg, the assembly plugin). I guess, the question is whether we generalise a concept that may or may not have uses outside the war plugin (ie, pushing webResources up to POM level and adding the extra phases for them), or whether we address the use case with a pre-package phase. I'd be happy with either. I think if we have any use cases beyond the war plugin we should do the first, otherwise the second (as it is far simpler). Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
Hello, What about we just change the lifecycle for the war plugin and add phases there? Because the same problem crops up time and time again which means the current solution is part of the problem. Imagine. I'm generating a database for my tests from XML descriptions. The intended control flow should be: - Copy resources (fill in DB connection details from some existing file) - Copy resources (convert model specific XML into XML to SQL tool specific XML) - Copy resources (turn the XML into SQL) - Copy resources (load DB with SQL) - Copy resources (classpath resources for tests) - Run the tests How can I make sure in my mojo that the many copy resources are executed in the right order? The idea of lifecycle is good but only as a big framework in which you can plug other things and you need a way to specify dependencies between the other things, too. Regards, -- Aaron Digulla - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
I read through all these threads, and they kind of ran off into entirely different tracks on alternate build systems and CM. On Kenney's points in particular: On 06/12/2006, at 12:41 AM, Kenney Westerhof wrote: I'm basically -0 on adding generate-package-resources/process- package-resources since it doesn't add anything new - things done there can be done in generate-resources/process-resources. There's no need to duplicate those pases later on in the lifecycle (right?). Well, it depends on how 'resources' are defined. The definition, as defined by current behaviour, is a classpath resource (or equivalent for your given language that isn't Java). The WAR plugin already has a custom configuration webResources/, which are 'packaging resources', a different thing. We can't repurpose resources/ or change the war plugin in the ways you've suggested (disallowing classes) without a significant break in backwards compatibility (far worse than changing the lifecycle) My opinion is still that adding 'packaging resources' (or something with a better name), and the corresponding lifecycle stages (for consistency with other types of 'resources') is the best solution to the presented use cases (rather than a pre-package phase, though that'd do the trick too). WDYT? - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
Kenney Westerhof [EMAIL PROTECTED] schrieb am 07.12.2006 15:54:46: Hi, What I'm reading below looks exactly like Maven, except for the scope of the dependencies. Just for fun, I'll try to make the differences in your system and maven more concrete. Correct me if I get anything wrong. In Maven we have 2 types of 'dependencies': artifact dependencies, which control build order (amongst other things), and 'mojo dependencies', which hook into the lifecycle and make sure that certain things are executed. Your system only has 1 type of (build order) dependency, which depends on phases/goals in all projects in your system. If you were to depend on the 'install' phase of other projects only, you'd have the Maven dependency thing. In maven, if you specify a dependency, you implicitly specify a dependency on the install/deploy phase (depending on wheter the artifact's project is in the reactor). In your system you can specify a dependency on 'generate-resources', but you can't specify for what project that is. So basically your entire project tree can be built using just 1 lifecycle, where for each lifecycle phase, that phase is executed for all projects - and all hooks to that phase from all projects areexecuted. I bet your system only works for a monolithic project tree, since you require access to files in artifacts that have not been completely built. I don't know if you have a 'deploy' kind of phase, but is it possible for you to just build a sub-tree of your project tree, and if that sub tree requires some icon, can that icon be pulled from a remote repo? If you run MetaMake in a sub-project, it will build only those things which the sub-project really needs. If you build at the root, MetaMake sees everything. If you need something like downloading from a remote repo, this is not implemented (we're C guys, we like monolithic project trees :-). But it would be simple to run a tool during a certain phase which tries to download the file and directs MetaMake to build it if the download fails. The key to make this simple was inversion of dependency. In my project (module) I don't say my new phase depends on generate but generate depends on my new phase. When the build tool decides to look at generate, it first considers all the phases which pre-depend on it. Like so: ## generate:: generate-includes This can be done in Maven: in the project that has a 'generate- includes' requirement just adds a mojo for that to the 'generate-sources' phase. Imagine you have two mojos which both are run during generate-sources. How do you make sure one of them is run before or after the other? As I see it, that's the major difference between the maven approach and MetaMake. In MetaMake, you can reorder dependencies. Example: Mojo A runs in generate-sources Mojo B runs in generate-sources Usually, the order of them is undefined (A and B don't depend on each other). Mojo C wants to run after A but before C. In MetaMake, I can say in C: ## C: A ## B: C Now, the build order will be defined: A - C - B. Regards, -- Aaron Digulla - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
Hi, What I'm reading below looks exactly like Maven, except for the scope of the dependencies. Just for fun, I'll try to make the differences in your system and maven more concrete. Correct me if I get anything wrong. In Maven we have 2 types of 'dependencies': artifact dependencies, which control build order (amongst other things), and 'mojo dependencies', which hook into the lifecycle and make sure that certain things are executed. Your system only has 1 type of (build order) dependency, which depends on phases/goals in all projects in your system. If you were to depend on the 'install' phase of other projects only, you'd have the Maven dependency thing. In maven, if you specify a dependency, you implicitly specify a dependency on the install/deploy phase (depending on wheter the artifact's project is in the reactor). In your system you can specify a dependency on 'generate-resources', but you can't specify for what project that is. So basically your entire project tree can be built using just 1 lifecycle, where for each lifecycle phase, that phase is executed for all projects - and all hooks to that phase from all projects are executed. I bet your system only works for a monolithic project tree, since you require access to files in artifacts that have not been completely built. I don't know if you have a 'deploy' kind of phase, but is it possible for you to just build a sub-tree of your project tree, and if that sub tree requires some icon, can that icon be pulled from a remote repo? Snippet: The key to make this simple was inversion of dependency. In my project (module) I don't say my new phase depends on generate but generate depends on my new phase. When the build tool decides to look at generate, it first considers all the phases which pre-depend on it. Like so: ## generate:: generate-includes This can be done in Maven: in the project that has a 'generate-includes' requirement just adds a mojo for that to the 'generate-sources' phase. Other projects don't need to know about that Depending projects just know that if they were to depend on a project that has 'generate-sources' executed, then that project has taken care of generating everything needed for that project. You don't even have to know it generates includes or icons or whatever. Now, MetaMake will look for projects which define generate-includes (or new dependencies for it) and runs those phases/goals/targets first. Basically the same as in maven, though it doesn't search for 'generate-includes', it just executes 'generate-sources'. If you were to run 'mvn generate-resources' in a maven project tree you'd get the same results as with MetaMake. The difference here is more of a philosophical nature: in Maven, if you depend on some icon resource, you'd specify a dependency on the project that creates it. But your system looks like it was meant for C development, and linking there also includes processing .res files for GUI elements that embed icons (something like that?). In maven this would be a bit more complicated, but there are several solutions for this (which I'm not going to enumerate). Btw, I've run across a problem that's kind of related to this: i just made a plugin that creates a bill of materials from an assembly: it scans the directory created by assembly:directory, creates a listing for all files and lists the details for all jars by looking at the embedded pom.xml in the artifacts. But that file needs to be inside the assembly itself. So it only works if you run assembly:directory first. The problem is that you could also run it on some assembly archive, and then somehow add the file to the assembly afterwards. I can't just run it in 'generate-resources' or something since the directory structure generated from the assembly needs to be in the file too. Also, updating a tar.gz is not ideal (gunzip, tar uvf, gzip). So in this case, I would actually require writing a plugin for the assembly plugin itself, that scans the directory just after it's created and just before it's converted to an archive. But this is only possible if there's a complete unzipped directory, which isn't the case if dependencies are added to the archive directly from the local repository. So, 2 solutions I can think of: 1) let the assembly plugin support plugins for itself; this is not generic enough.. 2) split the assembly plugin up, binding it to 2 executions, and let the bill of materials plugin execute between the 2 executions. Btw, in your MetaMake system, how would you solve this? -- Kenney [EMAIL PROTECTED] wrote: Jason van Zyl [EMAIL PROTECTED] schrieb am 04.12.2006 17:43:29: 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
Re: [m2] New pre-package phase?
Jason van Zyl [EMAIL PROTECTED] schrieb am 04.12.2006 17:43:29: 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? It's about as hard to explain and understand as the Maven dependency system. It's just an odd idea at first glance. You see, just like Maven, we have several big phases (generate, compile, link, site). Eventually, we added generate-includes, generate-source, generate-scripts, generate-makefiles, ... The key to make this simple was inversion of dependency. In my project (module) I don't say my new phase depends on generate but generate depends on my new phase. When the build tool decides to look at generate, it first considers all the phases which pre-depend on it. Like so: ## generate:: generate-includes Now, MetaMake will look for projects which define generate-includes (or new dependencies for it) and runs those phases/goals/targets first. This way, each developer can create their own little world, making sure all their phases are called in the correct order. You need a second generate include phase? No problem. Hooking them into the big world is also simple because of the predefined phases which are always there. The implementation was dead simple (4h in plain C) and worked reliable at the first attempt. We only had to add caching because searching 20'000 Makefiles for targets was bit slow :-) My project (AROS) is using this build system for several years, now. Currently, we have roughly 5'000 phases which, oddly enough, makes the build more *simple*. Let me explain. You have a big maven project with hundreds of modules (we have about 200). How do you make sure that module X is built and ready before module Y? Or, say, I need a generated file from a module now but not all of it? In current Maven, you have to move things around in the parent POMs. The dependencies leak. In our world, I say: Project X: ## install:: workbench-icon ## workbench-icon:: icon-generator-install ... create the workbench icon ... Project Y: ## site: workbench-icon ... use the icon ... Let's imagine I have a clean checkout and want to see the website. Even though workbench hasn't been completely yet, the single icon file can be generated after the icon generator has been installed. When I say mmake site, it will compile and install the icon generator, generate the workbench icon and then the HTML files. In maven, this level of detail is probably not possible. Maven projects are more encapsulated than ours and I don't think it's even necessary to go to such lengths in Maven. Operating systems usually have many small components with heavy dependencies between them, that's why we choose the approach described above. What I would like to see is a simple way to 'install' depends on my new phase/target/goal in a Mojo and in the execute-elements in the POM. That way, I could do extra work before something is installed, without influencing the standard lifecycle, other projects or plugins. 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. Random? Since when is the maven dependency resolution random? I haven't seen the code but from what I see, it probebly works exactly like the MetaMake target resolution. Regards, -- Aaron Digulla - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
Steve Loughran [EMAIL PROTECTED] schrieb am 05.12.2006 14:51:52: The weakness is that someone, somewhere, has to lay down what those states are. And what works for simple ready-to-compile-compiled-packaged-tested-published lifecycle gets complex if you have to do silly things like throw the SOAP stack at the compiled app source to generate the WSDL for the test run, or create a test JAR that is itself signed and tested (meta testing, yes!). With MetaMake, something like that is possible but we (usually) don't do it. As you said, the key argument is: Even if it's stupid to run though a mine field, sometimes, you *have* to (because someone is shooting at you). A build tool should make the obvious things simple but it should not prevent to solve corner cases. The current maven build system just cannot cope with running mvn deploy for a part of the project so you can run your tests in another. The question is not if it's a stupid thing to do, the question is: If I *have* to, what do I do? Currently, my solution is to revert to ant and control maven from there. Rgards, -- Aaron Digulla - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
[EMAIL PROTECTED] wrote: Steve Loughran [EMAIL PROTECTED] schrieb am 05.12.2006 14:51:52: The weakness is that someone, somewhere, has to lay down what those states are. And what works for simple ready-to-compile-compiled-packaged-tested-published lifecycle gets complex if you have to do silly things like throw the SOAP stack at the compiled app source to generate the WSDL for the test run, or create a test JAR that is itself signed and tested (meta testing, yes!). With MetaMake, something like that is possible but we (usually) don't do it. As you said, the key argument is: Even if it's stupid to run though a mine field, sometimes, you *have* to (because someone is shooting at you). A build tool should make the obvious things simple but it should not prevent to solve corner cases. The current maven build system just cannot cope with running mvn deploy for a part of the project so you can run your tests in another. The question is not if it's a stupid thing to do, the question is: If I *have* to, what do I do? Currently, my solution is to revert to ant and control maven from there I use Ant+Ivy. I have my own complex state model. I just have to struggle to keep everything locked down across 30 projects in 4 different repositories. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
A build tool should make the obvious things simple but it should not prevent to solve corner cases. The current maven build system just cannot cope with running mvn deploy for a part of the project so you can run your tests in another. The question is not if it's a stupid thing to do, the question is: If I *have* to, what do I do? Currently, my solution is to revert to ant and control maven from there. You can't run mvn deploy (as this only builds the artifact, it does not make it available to other projects), but you can run mvn install on one part of your project and then run the tests in another. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
Hi, Some ramblings, trying to analyze a use-case and finding a solution without modifying the lifecycle: 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? Now this is the one idea I like. I'm basically -0 on adding generate-package-resources/process-package-resources since it doesn't add anything new - things done there can be done in generate-resources/process-resources. There's no need to duplicate those pases later on in the lifecycle (right?). The real problem is that people want an unpacked artifact, probably since packaging a war artifact is too slow (lots of dependencies copied, and zipping up zips is slow). If we require everyhing to be present in target/ prior to the package phase, then the package phase would just zip it up, as it was intended to with 'jar' packagings. For jar packaging, would require the pom.properties and pom.xml to be generated during generate-sources, which is needed anyway because when you use those files at runtime and you're running from your IDE those aren't present yet. For ear/ejb packaging, make sure metadata descriptors like application.xml are created during the generate resources phase. So basically: don't modify the content's of the artifact during packaging, except maybe to include dependencies. Now, war's are a bit strange compared to 'normal' jars. The src/main/java and src/main/resources don't end up in the archive root, but in /WEB-INF/classes, which is part of the artifact's classpath. The src/main/webapp, the real 'war' resources (not on the classpath, but used by the webapp), end up in the archive root. A solution for this case would be to not allow any code in war projects; everything that goes in /WEB-INF/classes should just be in a dependency placed in /WEB-INF/lib. Then, the war packaging would be simplified to not filter-copy src/main/resources to the archive root; this is then handled during the normal resources phases. No more src/main/webapp. What it does right now is correct, though: src/main/resources should end up in the classpath. I'm proposing a change to deal with 'war' project resources differently. Also, overlaying could be handled in generate-resources. This would simplify the war goal, as Michael suggests. As it is, war packaging is comparable to an 'uberjar' packaging or an assembly. There's currently no way to replace the main artifact with an assembly, which is a problem in this case. We've got one problem left: maven currently can handle testing projects and running webapps without having to copy all the dependencies since it can resolve them from the local repo/reactor. They are typically included in the artifact during the package phase. For jetty:run, it is not needed to copy them since it also resolves them using maven. So we need a phase to hook jetty into that's before package and after testing. This would simply be solved by adding @execute phase='test'. Then, if we allow the package phase to include other dependencies, like how it's done in the ear plugin, the war problem is solved. If you want an unpacked war, you can call the non-lifecycle mojo unpacked-war (or whatever it's called), that also @execute phase='test'. Btw, the '@execute phase=..' is basically the same as a 'depends' clause, in that it enables you to run something after another phase has run, but before the next phase. WDYT? I'd like to gather all use cases that would benefit from a 'prepare-package' phase, and see if there are solutions that don't require lifecycle phases. As Jason said, it will be something that we can never take back. Also, most packaging mojo's would require re-wiring to that phase and leave the 'zipping up' to a simple mojo bound to 'package'. -- Kenney 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?
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. 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. The strength of standardised 'states', as that is what this really is, is that you can be sure that even third party products can be moved into the same state. This becomes important when your build tree includes symlinks to four different repositories and something above to co-ordinate the lot. The weakness is that someone, somewhere, has to lay down what those states are. And what works for simple ready-to-compile-compiled-packaged-tested-published lifecycle gets complex if you have to do silly things like throw the SOAP stack at the compiled app source to generate the WSDL for the test run, or create a test JAR that is itself signed and tested (meta testing, yes!). Adding more stages is certainly one solution. The other is to say 'our build should be refactored into more tractable components, each with a simpler lifecycle and inter-dependencies'. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
Kenney Westerhof wrote: The real problem is that people want an unpacked artifact, probably since packaging a war artifact is too slow (lots of dependencies copied, and zipping up zips is slow). More or less, in the parallel thread Manipulating the WAR directory before the WAR file gets built the problem is not to optimize build time, but actually to be able to write plugins that can operate on the WAR file before it is generated. Obviously this could be solved by generating the war, reopening it, manipulating it, reassemboling it, but if this is the only solution then maybe even my stupid patch (http://jira.codehaus.org/browse/MWAR-86 ) can prove useful. If we require everyhing to be present in target/ prior to the package phase, then the package phase would just zip it up, as it was intended to with 'jar' packagings. Yep, IMO this is it. A solution for this case would be to not allow any code in war projects; everything that goes in /WEB-INF/classes should just be in a dependency placed in /WEB-INF/lib. Then, the war packaging would be simplified to not filter-copy src/main/resources to the archive root; this is then handled during the normal resources phases. No more src/main/webapp. What it does right now is correct, though: src/main/resources should end up in the classpath. I'm proposing a change to deal with 'war' project resources differently. Also, overlaying could be handled in generate-resources. generate-resources is intended to generate something in the target folder? or in the src folders? cause, if it's intended to generate in the target then there is no problem at all, is the perfect phase to do everything (overlay the war, pack all the stuff in the target folder, manipulate it with third party plugins) and the package can simply zip it. I'm asking this because in http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html it's not specified, and its companion phase generate-sources seems to mean generate spacial sources like ejb distribution code or rmi stubs in src/main/java so that the default compile system will compile them. Then, if we allow the package phase to include other dependencies, like how it's done in the ear plugin, the war problem is solved. If you want an unpacked war, you can call the non-lifecycle mojo unpacked-war (or whatever it's called), that also @execute phase='test'. In the case of third party plugin that needs to work on a war before it's packed, the work of this third party plugin could be (as it is for the cocoon deployer plugin) part of the normal build/package/install cycle of the application, so placing this in a non-lifecycle step is not a (good) solution. I'd like to gather all use cases that would benefit from a 'prepare-package' phase, and see if there are solutions that don't require lifecycle phases. As Jason said, it will be something that we can never take back. Also, most packaging mojo's would require re-wiring to that phase and leave the 'zipping up' to a simple mojo bound to 'package'. See my email Re: Manipulating the WAR directory before the WAR file gets built of 2006-12-04 @17:24 for some usecases I have encountered. Simone - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
Simone Gianni wrote: Kenney Westerhof wrote: The real problem is that people want an unpacked artifact, probably since packaging a war artifact is too slow (lots of dependencies copied, and zipping up zips is slow). More or less, in the parallel thread Manipulating the WAR directory before the WAR file gets built the problem is not to optimize build time, but actually to be able to write plugins that can operate on the WAR file before it is generated. Obviously this could be solved by generating the war, reopening it, manipulating it, reassemboling it, but if this is the only solution then maybe even my stupid patch (http://jira.codehaus.org/browse/MWAR-86 ) can prove useful. Hm, that sounds complicated, but probably necessary given what the war mojo currently does. If we require everyhing to be present in target/ prior to the package phase, then the package phase would just zip it up, as it was intended to with 'jar' packagings. Yep, IMO this is it. A solution for this case would be to not allow any code in war projects; everything that goes in /WEB-INF/classes should just be in a dependency placed in /WEB-INF/lib. Then, the war packaging would be simplified to not filter-copy src/main/resources to the archive root; this is then handled during the normal resources phases. No more src/main/webapp. What it does right now is correct, though: src/main/resources should end up in the classpath. I'm proposing a change to deal with 'war' project resources differently. Also, overlaying could be handled in generate-resources. generate-resources is intended to generate something in the target folder? or in the src folders? cause, if it's intended to generate in the target then there is no problem at all, is the perfect phase to do everything (overlay the war, pack all the stuff in the target folder, manipulate it with third party plugins) and the package can simply zip it. Everything that's generated or modified should put their results in the target/ directory. Everything under src/ is human-created and most of the times, under version control. Having plugins modify or add files in src/ is very bad. I'm asking this because in http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html it's not specified, and its companion phase generate-sources seems to mean generate spacial sources like ejb distribution code or rmi stubs in src/main/java so that the default compile system will compile them. No, it means generate sources and register their path as a new compile source root. Maybe that page needs to be fine-tuned a bit more, but sources are NEVER added to src/. All generated sources and resources should be placed in target/, and mojo's can register them. Take for example the maven-antrun-plugin; it has 2 configuration options to specify locations that should be added to the compile-list (for main sources and test sources). Then, if we allow the package phase to include other dependencies, like how it's done in the ear plugin, the war problem is solved. If you want an unpacked war, you can call the non-lifecycle mojo unpacked-war (or whatever it's called), that also @execute phase='test'. In the case of third party plugin that needs to work on a war before it's packed, the work of this third party plugin could be (as it is for the cocoon deployer plugin) part of the normal build/package/install cycle of the application, so placing this in a non-lifecycle step is not a (good) solution. The statement above was purely meant for creating a monolithic directory that could be used by say tomcat to deploy the war; deploying a war is not part of the lifecycle, at least not up to the package phase. It could be used by integration tests, but those are after the package phase and have access to the war file. For all other purposes, it is not needed that all data be placed in 1 directory in the correct 'war' structure, as maven knows where all the parts are that contribute to the war file. Inthe case of 3rd party plugins, they can and should be linked to the generate/process resource/source phases, as that's what they do. Unless some of the 3rd party plugins you're referring to are doing 'more evil' things? ;) ere are other plugins out there that do other things? I'd like to gather all use cases that would benefit from a 'prepare-package' phase, and see if there are solutions that don't require lifecycle phases. As Jason said, it will be something that we can never take back. Also, most packaging mojo's would require re-wiring to that phase and leave the 'zipping up' to a simple mojo bound to 'package'. See my email Re: Manipulating the WAR directory before the WAR file gets built of 2006-12-04 @17:24 for some usecases I have encountered. Okay, I'll read up on that thread. Thanks, Kenney Simone - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL
Re: [m2] New pre-package phase?
On 12/5/06, Kenney Westerhof [EMAIL PROTECTED] wrote: A solution for this case would be to not allow any code in war projects; everything that goes in /WEB-INF/classes should just be in a dependency placed in /WEB-INF/lib. This would be a pain for things like web framework example apps. (It would double the number of modules we have to keep up with.) While any non-trivial webapp is going to have multiple modules, I wouldn't like to see it be impossible to have an entire webapp in a single module with war packaging. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
Hi... On Tue, 2006-12-05 at 14:14 -0700, Wendy Smoak wrote: On 12/5/06, Kenney Westerhof [EMAIL PROTECTED] wrote: A solution for this case would be to not allow any code in war projects; everything that goes in /WEB-INF/classes should just be in a dependency placed in /WEB-INF/lib. This would be a pain for things like web framework example apps. (It would double the number of modules we have to keep up with.) While any non-trivial webapp is going to have multiple modules, I wouldn't like to see it be impossible to have an entire webapp in a single module with war packaging. A co-worker of mine whose first introduction to Maven was with an EJB project expressed surprise when he encountered difficulty with classpaths and overlays in a WAR project. He said he had expected the WAR plugin to offer the option of creating something analagous to the ejb-client jar produced by the EJB plugin. So as long as the plugin made the creation of the web-classes.jar transparent (and possibly optional) for the user, it could be used in a single module project. And then other clients could declare a dependency of type 'web-classes' or something. Would that work? Jim - 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: [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]
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]
[m2] New pre-package phase?
Hi there, Has anyone got any objections to adding a new 'pre-package' phase to the default lifecycle? This is required by goals such as tomcat:run-war which require package pre-processing (overlaying wars, etc.) but not necessarily the fully built archive. I'll raise an issue if no-one objects. Cheers, Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
Mark Hobson wrote: Hi there, Has anyone got any objections to adding a new 'pre-package' phase to the default lifecycle? This is required by goals such as tomcat:run-war which require package pre-processing (overlaying wars, etc.) but not necessarily the fully built archive. I would definitely +1 such a phase, it's something the appassembler most definitely need too. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
+1 -- Regards, Garvin LeClaire [EMAIL PROTECTED] On 12/3/06, Trygve Laugstøl [EMAIL PROTECTED] wrote: Mark Hobson wrote: Hi there, Has anyone got any objections to adding a new 'pre-package' phase to the default lifecycle? This is required by goals such as tomcat:run-war which require package pre-processing (overlaying wars, etc.) but not necessarily the fully built archive. I would definitely +1 such a phase, it's something the appassembler most definitely need too. -- Trygve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
Pretty sure the issue already exists... should just be done IMO. On 04/12/2006, at 8:28 AM, Mark Hobson wrote: Hi there, Has anyone got any objections to adding a new 'pre-package' phase to the default lifecycle? This is required by goals such as tomcat:run-war which require package pre-processing (overlaying wars, etc.) but not necessarily the fully built archive. I'll raise an issue if no-one objects. Cheers, 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 03/12/06, Brett Porter [EMAIL PROTECTED] wrote: Pretty sure the issue already exists... should just be done IMO. I did search JIRA for 'lifecycle' and couldn't anything. Let me know if you can find the issue. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m2] New pre-package phase?
On 3 Dec 06, at 4:28 PM 3 Dec 06, Mark Hobson wrote: Hi there, Has anyone got any objections to adding a new 'pre-package' phase to the default lifecycle? This is required by goals such as tomcat:run-war which require package pre-processing (overlaying wars, etc.) but not necessarily the fully built archive. I'll raise an issue if no-one objects. 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. Jason. Cheers, 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]
