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 ...
> -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 ...
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 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 ...
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 ...
"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 ...
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 ...
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: >> http://www.nabble.com/We-need-some-explanation-...-tf2579501s177.html#a7192212 >> Sent from the Maven - Users mailing list archive at Nabble.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#a7193651 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 ...
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 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 ...
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: > 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, 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, 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]
Re: We need some explanation ...
e 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: >> http://www.nabble.com/We-need-some-explanation-...-tf2579501s177.html#a7192212 >> Sent from the Maven - Users mailing list archive at Nabble.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#a7193651 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 ...
age 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: http://www.nabble.com/We-need-some-explanation-...-tf2579501s177.html#a7192212 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 ...
se? 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: http://www.nabble.com/We-need-some-explanation-...-tf2579501s177.html#a7192212 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
We need some explanation ...
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
