Re: We need some explanation ...
Hi Vincent, The architecture is quite clear now, but there remains some questions: - I understand that when calling clover:instrument in any phase, this triggers a custom lifecycle (clover LC) that runs instrumentInternal and then runs the tests so that clover DB gets populated. This lifecycle is forked so that original sources are prevented from ending up in artifact. - the original question was about the use of process-sources: It seemed to me that coverage intsrumentation should be done after all sources are generated. Why is this not the case for clover ? Thx -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: We need some explanation ...
-Original Message- From: Arnaud Bailly [mailto:[EMAIL PROTECTED] Sent: mardi 7 novembre 2006 09:04 To: Maven Users List Subject: Re: We need some explanation ... Hi Vincent, The architecture is quite clear now, but there remains some questions: - I understand that when calling clover:instrument in any phase, this triggers a custom lifecycle (clover LC) that runs instrumentInternal and then runs the tests so that clover DB gets populated. This lifecycle is forked so that original sources are prevented from ending up in artifact. Yes, exactly. - the original question was about the use of process-sources: It seemed to me that coverage intsrumentation should be done after all sources are generated. Why is this not the case for clover ? The clover:instrumentInternal goal is bound to the generate-sources phase (the first phase for sources). The main reason is that any source generated is usually already tested (the generators are usually tested) and there's usually no need to write tests for it. Instrumenting the generated sources would skew the coverage result. Now I agree that it's possible that there are cases where you'd want the instrumentation to include generated sources. This is not supported as of now. Actually nobody has asked for this use case yet... Thanks -Vincent ___ Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire. http://fr.mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: We need some explanation ...
Thanks for the (quick :-)) answer. I agree that generated sources are usually tested and do not need specific tests, so instrumenting them may not be very useful as far as branch/line coverage is concerned. I can think however of a use case where you would need coverage of generated code. Imagine that your generator provides glue code between components/classes folloving some pattern of communication and that you want to cover with your tests the interaction between two classes. You would need instrumentation information for generated sources to link standard java method invocation in your classes with something in your glue code. This all depends on what you are trying to cover with your tests. All tools I am aware of gives you so-called branch or line coverage, but there exists different coverage information that would be often more useful to have. Best regards, -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: We need some explanation ...
-Original Message- From: Arnaud Bailly [mailto:[EMAIL PROTECTED] Sent: mardi 7 novembre 2006 11:03 To: Maven Users List Subject: Re: We need some explanation ... Thanks for the (quick :-)) answer. I agree that generated sources are usually tested and do not need specific tests, so instrumenting them may not be very useful as far as branch/line coverage is concerned. I can think however of a use case where you would need coverage of generated code. Imagine that your generator provides glue code between components/classes folloving some pattern of communication and that you want to cover with your tests the interaction between two classes. You would need instrumentation information for generated sources to link standard java method invocation in your classes with something in your glue code. This all depends on what you are trying to cover with your tests. All tools I am aware of gives you so-called branch or line coverage, but there exists different coverage information that would be often more useful to have. As I said I agree that there are valid use cases. Do you need this feature for your build? If so, please create a jira issue on the Clover plugin. You could also provide a patch if you need it. It should be quite easy I think: we'll need to create 2 new goals: One new clover:instrumentWithGeneratedSources and one clover:instrumentInternalWithGeneratesSources. It's kind of ugly but I don't currently see any other way. Thanks -Vincent ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: We need some explanation ...
Vincent Massol [EMAIL PROTECTED] writes: As I said I agree that there are valid use cases. Do you need this feature for your build? If so, please create a jira issue on the Clover plugin. You could also provide a patch if you need it. It should be quite easy I think: we'll need to create 2 new goals: One new clover:instrumentWithGeneratedSources and one clover:instrumentInternalWithGeneratesSources. It's kind of ugly but I don't currently see any other way. Not really needed right now, and don't have much time for implementing it anyway, but I keep the idea around. best regards, -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: We need some explanation ...
Good day to you, Arnaud, Ah, yes :-) Thank you for that example :-) the maven-clover-plugin's (see [1]) instrumentInternal goal is bound to the process-sources phase. Not sure though how it works :-) [1] http://maven.apache.org/plugins/maven-clover-plugin/ Arnaud Bailly-3 wrote: franz see [EMAIL PROTECTED] writes: Good day to you, David, The generate-sources, phase is used for auto code generation. An example for this would be the maven-modello-plugin (see [1]) which allows the creation of Xpp3 Readers, Writers and the corresponding models. Running an XDoclet maven goal would most probably be bound here if that goal produces source codes. For the process-sources, its the phase used when what you're processing (prior to compilation) is the sources themselves. hhmm..can't think of a good example though... Maybe instrumentation for profiling or coverage ? I have however checked with the clover plugin and it uses the generate-sources phase. My 50cents -- Oqube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/We-need-some-explanation-...-tf2579501s177.html#a7194707 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: We need some explanation ...
franz see [EMAIL PROTECTED] writes: Good day to you, Arnaud, Ah, yes :-) Thank you for that example :-) the maven-clover-plugin's (see [1]) instrumentInternal goal is bound to the process-sources phase. Not sure though how it works :-) Good day to you too, Unfortunately, the example is nice but flawed :-( The maven-clover-plugin is not bound anywhere to the process-sources phase but to the generate-sources phase. That raises the issue of knowing what happens if the plugin is run before another plugin that generates sources. But any plugin that need to do some blakc magic on the sources (AOP, annotations processing, refactoring, obfuscation,...) may be bound to this phase as this entails managing both manual and generated sources. regards, -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: We need some explanation ...
Good day to you, Arnaud, Thanks for the correction :-) my eyes must be playing tricks on me :-P hehehe :-D Anyway, I'm not sure though if another goal would be bound to the same phase as instrumentInternal. Though I haven't really disected the code to its very core, the architecture provided in [1] seems to indicate that it is forked to its own lifecycle (clover lifecycle). But I haven't trace that part yet where forking happens so I'm not sure if that architectural design is still updated. Thanks, Franz [1] http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-clover-plugin/src/site/resources/images/ Arnaud Bailly-3 wrote: franz see [EMAIL PROTECTED] writes: Good day to you, Arnaud, Ah, yes :-) Thank you for that example :-) the maven-clover-plugin's (see [1]) instrumentInternal goal is bound to the process-sources phase. Not sure though how it works :-) Good day to you too, Unfortunately, the example is nice but flawed :-( The maven-clover-plugin is not bound anywhere to the process-sources phase but to the generate-sources phase. That raises the issue of knowing what happens if the plugin is run before another plugin that generates sources. But any plugin that need to do some blakc magic on the sources (AOP, annotations processing, refactoring, obfuscation,...) may be bound to this phase as this entails managing both manual and generated sources. regards, -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/We-need-some-explanation-...-tf2579501s177.html#a7195147 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: We need some explanation ...
franz see [EMAIL PROTECTED] writes: Anyway, I'm not sure though if another goal would be bound to the same phase as instrumentInternal. Though I haven't really disected the code to its very core, the architecture provided in [1] seems to indicate that it is forked to its own lifecycle (clover lifecycle). But I haven't trace that part yet where forking happens so I'm not sure if that architectural design is still updated. Yes, there is a custom lifecycle, see [1]. But I do not know what really happens with this lifecycle fork: I must confess I am still confused by this forking stuff. According to the descriptor, the clover plugin runs: generate-sources, test and integration-test phases, with goal instrumentInternal bound to generate-sources. This implies that no other goals from other plugins are run in this phase, so generated sources (eg. from modello plugin) are not covered by clover's instrumentation . If someone with more knowledge than me is lurking around, help appreciated. regards,, [1] http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-clover-plugin/src/main/resources/META-INF/maven/lifecycle.xml -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: We need some explanation ...
Hi Arnaud, The clover plugin is presumably one of the most complex m2 plugin. I had some architecture diagrams to explain how it worked but I've hidden them as the code has changed a bit and I hadn't had the time to update the diagrams. I'll try to find some time today to update them and republish them. Thanks -Vincent -Original Message- From: Arnaud Bailly [mailto:[EMAIL PROTECTED] Sent: lundi 6 novembre 2006 10:36 To: Maven Users List Subject: Re: We need some explanation ... franz see [EMAIL PROTECTED] writes: Anyway, I'm not sure though if another goal would be bound to the same phase as instrumentInternal. Though I haven't really disected the code to its very core, the architecture provided in [1] seems to indicate that it is forked to its own lifecycle (clover lifecycle). But I haven't trace that part yet where forking happens so I'm not sure if that architectural design is still updated. Yes, there is a custom lifecycle, see [1]. But I do not know what really happens with this lifecycle fork: I must confess I am still confused by this forking stuff. According to the descriptor, the clover plugin runs: generate-sources, test and integration-test phases, with goal instrumentInternal bound to generate-sources. This implies that no other goals from other plugins are run in this phase, so generated sources (eg. from modello plugin) are not covered by clover's instrumentation . If someone with more knowledge than me is lurking around, help appreciated. regards,, [1] http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-clover- plugin/src/main/resources/META-INF/maven/lifecycle.xml -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: We need some explanation ...
Franz: Yes, recipes or prescriptions for doing various types of projects. David On 11/5/06, franz see [EMAIL PROTECTED] wrote: Good day to you, David, Hhmmm...I'm not sure I understand your message. What do you mean by neutral to maven or any specific plugin ? Regading the more specific builds, im guessing you want to create a cookbook. If so, then you can may want to contribute your recipes in the wiki (see [1]) or in the maven site (see [2]). To contribute to the maven site, checkout the source from [3] using SVN. Then modify the source of the docu that you want to change. Afterwhich, create a jira issue in [4] and submit your patch. Btw, the format of the documentation is in APT (see [5]) Cheers, Franz [1] http://docs.codehaus.org/display/MAVENUSER/Home [2] http://maven.apache.org/run-maven/cookbook/index.html [3] http://svn.apache.org/repos/asf/maven/site/trunk/ [4] http://jira.codehaus.org/browse/mng [5] http://maven.apache.org/guides/mini/guide-apt-format.html David Whitehurst wrote: Franz: This is excellent discussion. This was what I was looking for. I had seen the intro to the lifecycle link before but that seems out there somewhat for most folks. I'm looking to put together more documentation that is neutral to maven or any specific plugin and try to focus on e.g. J2EE packaging. If I wanted to put together a project for a web service and package that service for JBoss, the information for using Maven or the corresponding plugin is scarce. I want to define my project and package it and I don't want to spend all my time trying to figure out how to use Maven2 even though I might have used Maven1 a little years past. Does that make sense? There is a lot of information, but it has very little organization. Most of it's complicated and seems to run me away instead of convincing me to give it a try. I know better so I want to figure things out more and document it for others. Thanks, David Whitehurst On 11/5/06, franz see [EMAIL PROTECTED] wrote: Good day to you, David, The generate-sources, phase is used for auto code generation. An example for this would be the maven-modello-plugin (see [1]) which allows the creation of Xpp3 Readers, Writers and the corresponding models. Running an XDoclet maven goal would most probably be bound here if that goal produces source codes. For the process-sources, its the phase used when what you're processing (prior to compilation) is the sources themselves. hhmm..can't think of a good example though... The generate-resources phase on the other hand, is like the generate-sources phase, except that this auto generates resources (i.e. xmls, property files) instead of codes. An example which uses that is the maven-eclipse-plugin. the eclipse:eclipse goal which generates the .classpath and .project resources is bound to that phase (see [2] for the released documentation and for [3] for the staged unreleased documentation). And if you have an XDoclet goal which produces resources such as schemas, that goal would most likely be bound to this goal. And as for the process-resources phase, this phase handles the resources-related processes prior to compilation. An example of this is the maven-resources-plugin, which filters and copies resources (see [4] for the released documentation and for [5] for the staged unreleased documentation). And example of a resource would be a property file. For more information about the lifecycle, kindly see [6]. And if you want to suggest somethings or have some feebdacks or something, you might want to create a jira issue in [7] under the Documentation: Introduction component. In relation to the eclipse plugin, only one goal (that i know of that works) is bound to a lifecycle phase, and that's the eclipse:eclipse goal which is bound to the generate-resources phase. And with regards to the goals, the current plugin documentations now have their goals documented. However, not all of these new plugin documentations have been released yet (plugin documentations released after Oct 16, 2006 are probably the latest ones..since it was the last time [8] was updated). But nonetheless, if you have any comments about the plugin documentation, you can create a jira issue under that plugin ([9] for maven-eclipse-plugin, [10] for maven-resources-pluign, etc). And lastly, goals are plugin-specific (a plugin consists of 1 or more goals). Phases are were a goal can bind to so that you can use a lifecycle (sequence of phases) to execute your goals in a specific manner. At least, these are my notes. :-) Did I answer your question? Cheers, Franz [1] http://modello.codehaus.org/ [2] http://maven.apache.org/plugins/maven-eclipse-plugin/ [3] http://people.apache.org/~epunzalan/maven-eclipse-plugin/ [4] http://maven.apache.org/plugins/maven-resources-plugin/ [5] http://people.apache.org/~aramirez/maven-resources-plugin/ [6]
RE: We need some explanation ...
Hi Arnaud, I've added the architecture diagrams. See http://maven.apache.org/plugins/maven-clover-plugin/architecture/architectur e.html I don't know why but some images are not displayed correctly. Here are 2 diagrams explaining 2 use cases: - clover:check - http://maven.apache.org/plugins/maven-clover-plugin/images/clover-check-achi tecture.jpg - clover:report - http://maven.apache.org/plugins/maven-clover-plugin/images/clover-report-arc hitecture.jpg Let me know if something is not clear. Thanks -Vincent -Original Message- From: Arnaud Bailly [mailto:[EMAIL PROTECTED] Sent: lundi 6 novembre 2006 10:36 To: Maven Users List Subject: Re: We need some explanation ... franz see [EMAIL PROTECTED] writes: Anyway, I'm not sure though if another goal would be bound to the same phase as instrumentInternal. Though I haven't really disected the code to its very core, the architecture provided in [1] seems to indicate that it is forked to its own lifecycle (clover lifecycle). But I haven't trace that part yet where forking happens so I'm not sure if that architectural design is still updated. Yes, there is a custom lifecycle, see [1]. But I do not know what really happens with this lifecycle fork: I must confess I am still confused by this forking stuff. According to the descriptor, the clover plugin runs: generate-sources, test and integration-test phases, with goal instrumentInternal bound to generate-sources. This implies that no other goals from other plugins are run in this phase, so generated sources (eg. from modello plugin) are not covered by clover's instrumentation . If someone with more knowledge than me is lurking around, help appreciated. regards,, [1] http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-clover- plugin/src/main/resources/META-INF/maven/lifecycle.xml -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: We need some explanation ...
Vincent Massol [EMAIL PROTECTED] writes: Hi Arnaud, Hi Vincent, Thanks a lot for this information. I will devote some time to understand it :-) I have in my work queue a new coverage tool implementation and this my give some insight into issues for these matters. Regards, -- OQube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: We need some explanation ...
Good day to you, David, The generate-sources, phase is used for auto code generation. An example for this would be the maven-modello-plugin (see [1]) which allows the creation of Xpp3 Readers, Writers and the corresponding models. Running an XDoclet maven goal would most probably be bound here if that goal produces source codes. For the process-sources, its the phase used when what you're processing (prior to compilation) is the sources themselves. hhmm..can't think of a good example though... The generate-resources phase on the other hand, is like the generate-sources phase, except that this auto generates resources (i.e. xmls, property files) instead of codes. An example which uses that is the maven-eclipse-plugin. the eclipse:eclipse goal which generates the .classpath and .project resources is bound to that phase (see [2] for the released documentation and for [3] for the staged unreleased documentation). And if you have an XDoclet goal which produces resources such as schemas, that goal would most likely be bound to this goal. And as for the process-resources phase, this phase handles the resources-related processes prior to compilation. An example of this is the maven-resources-plugin, which filters and copies resources (see [4] for the released documentation and for [5] for the staged unreleased documentation). And example of a resource would be a property file. For more information about the lifecycle, kindly see [6]. And if you want to suggest somethings or have some feebdacks or something, you might want to create a jira issue in [7] under the Documentation: Introduction component. In relation to the eclipse plugin, only one goal (that i know of that works) is bound to a lifecycle phase, and that's the eclipse:eclipse goal which is bound to the generate-resources phase. And with regards to the goals, the current plugin documentations now have their goals documented. However, not all of these new plugin documentations have been released yet (plugin documentations released after Oct 16, 2006 are probably the latest ones..since it was the last time [8] was updated). But nonetheless, if you have any comments about the plugin documentation, you can create a jira issue under that plugin ([9] for maven-eclipse-plugin, [10] for maven-resources-pluign, etc). And lastly, goals are plugin-specific (a plugin consists of 1 or more goals). Phases are were a goal can bind to so that you can use a lifecycle (sequence of phases) to execute your goals in a specific manner. At least, these are my notes. :-) Did I answer your question? Cheers, Franz [1] http://modello.codehaus.org/ [2] http://maven.apache.org/plugins/maven-eclipse-plugin/ [3] http://people.apache.org/~epunzalan/maven-eclipse-plugin/ [4] http://maven.apache.org/plugins/maven-resources-plugin/ [5] http://people.apache.org/~aramirez/maven-resources-plugin/ [6] http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html [7] http://jira.codehaus.org/browse/mng [8] http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation [9] http://jira.codehaus.org/browse/MECLIPSE [10] http://jira.codehaus.org/browse/MRESOURCES David Whitehurst wrote: After the message about the documentation, I kind of felt the same way. I like ANT because I can look at my build.xml file and see what each target will do exactly. Maven2 is much different but it's more standard. That's good because we all can begin to learn each goal and then know as we issue the keystroke what's going to happen and what to expect. I started moving around some of the texts on the Maven User WIKI at http://docs.codehaus.org/display/MAVENUSER/Home As long as my interest holds, I plan to keep working on the basic documentation for using Maven. I'm interested in Appfuse now and they've moved to Maven2 and away from my old friend ANT. This message is a request to get some answers on some goals that I'm not exactly familiar with yet. I'm using the Maven plugin for Eclipse and I figured that I would start with explanation of the lifecycle phases. Let's document through mvn compile. - Initialize -Generate sources -Process sources -Generate resources -Process resources -compile I understand initialize and compile. Can someone relate the ones in between for me in relation to doing things e.g. running xdoclet, moving properties files, building schema, etc.? The official documentation discusses validate, compile, and test. I understand these, but the eclipse plugin has more. We should document goals that are used the most for various types of projects. If this was ANT, I'd know what these goals did exactly. Can someone tell me what the above goals will do when I run them in eclipse? Also, I imagine some of them may or may not be there. That would be worth documenting for folks on the WIKI. Thanks, David Whitehurst -- View this message in context:
Re: We need some explanation ...
Franz: This is excellent discussion. This was what I was looking for. I had seen the intro to the lifecycle link before but that seems out there somewhat for most folks. I'm looking to put together more documentation that is neutral to maven or any specific plugin and try to focus on e.g. J2EE packaging. If I wanted to put together a project for a web service and package that service for JBoss, the information for using Maven or the corresponding plugin is scarce. I want to define my project and package it and I don't want to spend all my time trying to figure out how to use Maven2 even though I might have used Maven1 a little years past. Does that make sense? There is a lot of information, but it has very little organization. Most of it's complicated and seems to run me away instead of convincing me to give it a try. I know better so I want to figure things out more and document it for others. Thanks, David Whitehurst On 11/5/06, franz see [EMAIL PROTECTED] wrote: Good day to you, David, The generate-sources, phase is used for auto code generation. An example for this would be the maven-modello-plugin (see [1]) which allows the creation of Xpp3 Readers, Writers and the corresponding models. Running an XDoclet maven goal would most probably be bound here if that goal produces source codes. For the process-sources, its the phase used when what you're processing (prior to compilation) is the sources themselves. hhmm..can't think of a good example though... The generate-resources phase on the other hand, is like the generate-sources phase, except that this auto generates resources (i.e. xmls, property files) instead of codes. An example which uses that is the maven-eclipse-plugin. the eclipse:eclipse goal which generates the .classpath and .project resources is bound to that phase (see [2] for the released documentation and for [3] for the staged unreleased documentation). And if you have an XDoclet goal which produces resources such as schemas, that goal would most likely be bound to this goal. And as for the process-resources phase, this phase handles the resources-related processes prior to compilation. An example of this is the maven-resources-plugin, which filters and copies resources (see [4] for the released documentation and for [5] for the staged unreleased documentation). And example of a resource would be a property file. For more information about the lifecycle, kindly see [6]. And if you want to suggest somethings or have some feebdacks or something, you might want to create a jira issue in [7] under the Documentation: Introduction component. In relation to the eclipse plugin, only one goal (that i know of that works) is bound to a lifecycle phase, and that's the eclipse:eclipse goal which is bound to the generate-resources phase. And with regards to the goals, the current plugin documentations now have their goals documented. However, not all of these new plugin documentations have been released yet (plugin documentations released after Oct 16, 2006 are probably the latest ones..since it was the last time [8] was updated). But nonetheless, if you have any comments about the plugin documentation, you can create a jira issue under that plugin ([9] for maven-eclipse-plugin, [10] for maven-resources-pluign, etc). And lastly, goals are plugin-specific (a plugin consists of 1 or more goals). Phases are were a goal can bind to so that you can use a lifecycle (sequence of phases) to execute your goals in a specific manner. At least, these are my notes. :-) Did I answer your question? Cheers, Franz [1] http://modello.codehaus.org/ [2] http://maven.apache.org/plugins/maven-eclipse-plugin/ [3] http://people.apache.org/~epunzalan/maven-eclipse-plugin/ [4] http://maven.apache.org/plugins/maven-resources-plugin/ [5] http://people.apache.org/~aramirez/maven-resources-plugin/ [6] http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html [7] http://jira.codehaus.org/browse/mng [8] http://docs.codehaus.org/display/MAVEN/Maven+Plugin+Documentation [9] http://jira.codehaus.org/browse/MECLIPSE [10] http://jira.codehaus.org/browse/MRESOURCES David Whitehurst wrote: After the message about the documentation, I kind of felt the same way. I like ANT because I can look at my build.xml file and see what each target will do exactly. Maven2 is much different but it's more standard. That's good because we all can begin to learn each goal and then know as we issue the keystroke what's going to happen and what to expect. I started moving around some of the texts on the Maven User WIKI at http://docs.codehaus.org/display/MAVENUSER/Home As long as my interest holds, I plan to keep working on the basic documentation for using Maven. I'm interested in Appfuse now and they've moved to Maven2 and away from my old friend ANT. This message is a request to get some answers on some goals that I'm not exactly familiar with yet. I'm using the Maven plugin for
Re: We need some explanation ...
Good day to you, David, Hhmmm...I'm not sure I understand your message. What do you mean by neutral to maven or any specific plugin ? Regading the more specific builds, im guessing you want to create a cookbook. If so, then you can may want to contribute your recipes in the wiki (see [1]) or in the maven site (see [2]). To contribute to the maven site, checkout the source from [3] using SVN. Then modify the source of the docu that you want to change. Afterwhich, create a jira issue in [4] and submit your patch. Btw, the format of the documentation is in APT (see [5]) Cheers, Franz [1] http://docs.codehaus.org/display/MAVENUSER/Home [2] http://maven.apache.org/run-maven/cookbook/index.html [3] http://svn.apache.org/repos/asf/maven/site/trunk/ [4] http://jira.codehaus.org/browse/mng [5] http://maven.apache.org/guides/mini/guide-apt-format.html David Whitehurst wrote: Franz: This is excellent discussion. This was what I was looking for. I had seen the intro to the lifecycle link before but that seems out there somewhat for most folks. I'm looking to put together more documentation that is neutral to maven or any specific plugin and try to focus on e.g. J2EE packaging. If I wanted to put together a project for a web service and package that service for JBoss, the information for using Maven or the corresponding plugin is scarce. I want to define my project and package it and I don't want to spend all my time trying to figure out how to use Maven2 even though I might have used Maven1 a little years past. Does that make sense? There is a lot of information, but it has very little organization. Most of it's complicated and seems to run me away instead of convincing me to give it a try. I know better so I want to figure things out more and document it for others. Thanks, David Whitehurst On 11/5/06, franz see [EMAIL PROTECTED] wrote: Good day to you, David, The generate-sources, phase is used for auto code generation. An example for this would be the maven-modello-plugin (see [1]) which allows the creation of Xpp3 Readers, Writers and the corresponding models. Running an XDoclet maven goal would most probably be bound here if that goal produces source codes. For the process-sources, its the phase used when what you're processing (prior to compilation) is the sources themselves. hhmm..can't think of a good example though... The generate-resources phase on the other hand, is like the generate-sources phase, except that this auto generates resources (i.e. xmls, property files) instead of codes. An example which uses that is the maven-eclipse-plugin. the eclipse:eclipse goal which generates the .classpath and .project resources is bound to that phase (see [2] for the released documentation and for [3] for the staged unreleased documentation). And if you have an XDoclet goal which produces resources such as schemas, that goal would most likely be bound to this goal. And as for the process-resources phase, this phase handles the resources-related processes prior to compilation. An example of this is the maven-resources-plugin, which filters and copies resources (see [4] for the released documentation and for [5] for the staged unreleased documentation). And example of a resource would be a property file. For more information about the lifecycle, kindly see [6]. And if you want to suggest somethings or have some feebdacks or something, you might want to create a jira issue in [7] under the Documentation: Introduction component. In relation to the eclipse plugin, only one goal (that i know of that works) is bound to a lifecycle phase, and that's the eclipse:eclipse goal which is bound to the generate-resources phase. And with regards to the goals, the current plugin documentations now have their goals documented. However, not all of these new plugin documentations have been released yet (plugin documentations released after Oct 16, 2006 are probably the latest ones..since it was the last time [8] was updated). But nonetheless, if you have any comments about the plugin documentation, you can create a jira issue under that plugin ([9] for maven-eclipse-plugin, [10] for maven-resources-pluign, etc). And lastly, goals are plugin-specific (a plugin consists of 1 or more goals). Phases are were a goal can bind to so that you can use a lifecycle (sequence of phases) to execute your goals in a specific manner. At least, these are my notes. :-) Did I answer your question? Cheers, Franz [1] http://modello.codehaus.org/ [2] http://maven.apache.org/plugins/maven-eclipse-plugin/ [3] http://people.apache.org/~epunzalan/maven-eclipse-plugin/ [4] http://maven.apache.org/plugins/maven-resources-plugin/ [5] http://people.apache.org/~aramirez/maven-resources-plugin/ [6] http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html [7] http://jira.codehaus.org/browse/mng [8]
Re: We need some explanation ...
franz see [EMAIL PROTECTED] writes: Good day to you, David, The generate-sources, phase is used for auto code generation. An example for this would be the maven-modello-plugin (see [1]) which allows the creation of Xpp3 Readers, Writers and the corresponding models. Running an XDoclet maven goal would most probably be bound here if that goal produces source codes. For the process-sources, its the phase used when what you're processing (prior to compilation) is the sources themselves. hhmm..can't think of a good example though... Maybe instrumentation for profiling or coverage ? I have however checked with the clover plugin and it uses the generate-sources phase. My 50cents -- Oqube software engineering \ génie logiciel Arnaud Bailly, Dr. \web http://www.oqube.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
