About sourceModifications
Does exclude classes or sources? Here for classes I mean .class. In my experience, this element excludes the sources completely. Therefore these won't never get compiled and included in the jar. If so, the example in the descriptor documentation page could change. Marco
Re: bcel dependency problem
Webb, that was me. Thank you. Marco - Original Message - From: "Webb Morris" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, March 18, 2004 10:34 PM Subject: bcel dependency problem > A few days ago there was a discussion concerning the ejb jar plugin and I mentioned I had written > my own but had a problem loading the bcel dependency. I've since deleted the thread, but I solved > the problem: > > I specified the bcel dependency with the root property. > > Hope this helps whoever it was, > > WM > > __ > Do you Yahoo!? > Yahoo! Mail - More reliable, more storage, less spam > http://mail.yahoo.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: How to run maven using JDK 1.4 and compile the java files usi ng IBM compiler available in a particular location
Try surrounding with " " because of the space. I though maven -X would show you the compiler? - Brett > -Original Message- > From: Veerasamy, Thirumalai (Cognizant) > [mailto:[EMAIL PROTECTED] > Sent: Friday, 19 March 2004 5:27 PM > To: Maven Users List > Subject: RE: How to run maven using JDK 1.4 and compile the > java files using IBM compiler available in a particular location > > > I am not sure, it comes with IBM Websphere Studio. I set the > value as mentioned below but still I don't think it uses it. > How do I find out whether it uses the executable, in debug it > doesn't show the javac executeable > > maven.compile.executable=D:/Program Files/IBM/WebSphere > Studio501/runtimes/aes_v4/java/bin/javac.exe > > Is it correct? > > Regards > > Thiru > > > -Original Message- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Friday, March 19, 2004 11:16 AM > To: 'Maven Users List' > Subject: RE: How to run maven using JDK 1.4 and compile the > java files using IBM compiler available in a particular location > > Is that with "jikes"? > http://maven.apache.org/reference/plugins/java/properties.html Set maven.compile.executable - Brett > -Original Message- > From: Veerasamy, Thirumalai (Cognizant) > [mailto:[EMAIL PROTECTED] > Sent: Friday, 19 March 2004 4:36 PM > To: Maven Users List > Subject: How to run maven using JDK 1.4 and compile the java > files using IBM compiler available in a particular location > > > Hi, > > I need to run the maven using JDK 1.4 but the compile the > java files using IBM Java compiler which is available in a location. > > Regards, > Thiru > >
RE: How to run maven using JDK 1.4 and compile the java files using IBM compiler available in a particular location
I am not sure, it comes with IBM Websphere Studio. I set the value as mentioned below but still I don't think it uses it. How do I find out whether it uses the executable, in debug it doesn't show the javac executeable maven.compile.executable=D:/Program Files/IBM/WebSphere Studio501/runtimes/aes_v4/java/bin/javac.exe Is it correct? Regards Thiru -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Friday, March 19, 2004 11:16 AM To: 'Maven Users List' Subject: RE: How to run maven using JDK 1.4 and compile the java files using IBM compiler available in a particular location Is that with "jikes"? http://maven.apache.org/reference/plugins/java/properties.html Set maven.compile.executable - Brett > -Original Message- > From: Veerasamy, Thirumalai (Cognizant) > [mailto:[EMAIL PROTECTED] > Sent: Friday, 19 March 2004 4:36 PM > To: Maven Users List > Subject: How to run maven using JDK 1.4 and compile the java > files using IBM compiler available in a particular location > > > Hi, > > I need to run the maven using JDK 1.4 but the compile the > java files using IBM Java compiler which is available in a location. > > Regards, > Thiru > > This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: SCM in Maven
http://maven.apache.org/faq.html#changelog-no-local-copy > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Friday, 19 March 2004 4:42 PM > To: [EMAIL PROTECTED] > Subject: SCM in Maven > > > > Hello, > > I am trying to use maven. But there is a problem about SCM > plugin. I setup a CVS server with CVSNT, and create a > repository: "d:/cvs_folder" My source code exist in > "d:/cvs_folder/maventest/src/..." > > In project.xml, set repository: > > > scm|cvs|pserver|liuyk:[EMAIL PROTECTED]|d:/cv > s_folder|maventest > > http://cvs.apache.org/viewcvs/maven/src/plugins-build/exa > mples/ > > > But after I checkout source code, I execute: "maven site", > the error info appears as following: > > /** > .. > .. > [echo] Generating the Change Log... > maven-changelog-plugin:report: > [echo] Generating the changelog report > SCM Working Directory: D:\maventest > SCM Command Line[0]: cvs > SCM Command Line[1]: -d > SCM Command Line[2]: > :pserver:liuyk:[EMAIL PROTECTED]:d:/cvs_folder > SCM Command Line[3]: log > SCM Command Line[4]: -d 2004-02-18<2004-03-20 > cvs log: in directory .: > cvs [log aborted]: there is no version here; run 'cvs > checkout' first ChangeLog found: 0 entries .. .. > /** > > Do I need to set other properties? > > Regards, > Yongkang > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
RE: How to run maven using JDK 1.4 and compile the java files usi ng IBM compiler available in a particular location
Is that with "jikes"? http://maven.apache.org/reference/plugins/java/properties.html Set maven.compile.executable - Brett > -Original Message- > From: Veerasamy, Thirumalai (Cognizant) > [mailto:[EMAIL PROTECTED] > Sent: Friday, 19 March 2004 4:36 PM > To: Maven Users List > Subject: How to run maven using JDK 1.4 and compile the java > files using IBM compiler available in a particular location > > > Hi, > > I need to run the maven using JDK 1.4 but the compile the > java files using IBM Java compiler which is available in a location. > > Regards, > Thiru > >
SCM in Maven
Hello, I am trying to use maven. But there is a problem about SCM plugin. I setup a CVS server with CVSNT, and create a repository: "d:/cvs_folder" My source code exist in "d:/cvs_folder/maventest/src/..." In project.xml, set repository: scm|cvs|pserver|liuyk:[EMAIL PROTECTED]|d:/cvs_folder|maventest http://cvs.apache.org/viewcvs/maven/src/plugins-build/examples/ But after I checkout source code, I execute: "maven site", the error info appears as following: /** .. .. [echo] Generating the Change Log... maven-changelog-plugin:report: [echo] Generating the changelog report SCM Working Directory: D:\maventest SCM Command Line[0]: cvs SCM Command Line[1]: -d SCM Command Line[2]: :pserver:liuyk:[EMAIL PROTECTED]:d:/cvs_folder SCM Command Line[3]: log SCM Command Line[4]: -d 2004-02-18<2004-03-20 cvs log: in directory .: cvs [log aborted]: there is no version here; run 'cvs checkout' first ChangeLog found: 0 entries .. .. /** Do I need to set other properties? Regards, Yongkang - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How can I generate Deploy and RMIC Code for IBM Websphere, I couldn't find any plugins
Hi, How can I generate Deploy and RMIC Code for IBM Websphere, I couldn't find any plugins in maven. Regards, Thiru This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to run maven using JDK 1.4 and compile the java files using IBM compiler available in a particular location
Hi, I need to run the maven using JDK 1.4 but the compile the java files using IBM Java compiler which is available in a location. Regards, Thiru This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Any unauthorised review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly prohibited and may be unlawful. Visit us at http://www.cognizant.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [reactor] Invoking reactor without a project.xml
On Thu, 2004-03-18 at 22:45, Alex Karasulu wrote: > > -Original Message- > > From: David Jencks [mailto:[EMAIL PROTECTED] > > > > you might want to take a look also at the geronimo build structure. > > I'm not sure what the maven experts think of it but I like it and find > > it very convenient. It assumes a 2 level subproject structure > > > > base > > type1 > > module1 > > module2 > >type2 > > module3 > > module4 > > > > > > you can select what you want to build by such expressions as > > > > maven -Dmodules=module1,module3 rebuild > > > > or > > > > maven -Dtypes=type1 > > Really nice I'll have a look. And that's certainly something we can cook into maven to make this sort of use dead simple. The geronimo build has some magic in there to do this. But as multi project builds are a common thing it's another thing we can provide a default structure for to make it easier. > Thanks, > Alex > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [reactor] Invoking reactor without a project.xml
> -Original Message- > From: David Jencks [mailto:[EMAIL PROTECTED] > > you might want to take a look also at the geronimo build structure. > I'm not sure what the maven experts think of it but I like it and find > it very convenient. It assumes a 2 level subproject structure > > base > type1 > module1 > module2 >type2 > module3 > module4 > > > you can select what you want to build by such expressions as > > maven -Dmodules=module1,module3 rebuild > > or > > maven -Dtypes=type1 Really nice I'll have a look. Thanks, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [reactor] Invoking reactor without a project.xml
you might want to take a look also at the geronimo build structure. I'm not sure what the maven experts think of it but I like it and find it very convenient. It assumes a 2 level subproject structure base type1 module1 module2 type2 module3 module4 you can select what you want to build by such expressions as maven -Dmodules=module1,module3 rebuild or maven -Dtypes=type1 david jencks On Thursday, March 18, 2004, at 12:29 PM, Alex Karasulu wrote: Hope it helps... Oh yes it helps thank you very much. I'll experiment with it and get back to you if I have issues. Thanks much, Alex - 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: More visual project descriptor documentation
[EMAIL PROTECTED] writes: > Jim Crossley <[EMAIL PROTECTED]> wrote on 18/03/2004 10:57:54 PM: [...] >> Some visual way of distinguishing the required elements from the [...] > How about bold for required and strikethrough or italic for > deprecated? I like it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: More visual project descriptor documentation
Ok. I replied too quickly :-) > -Message d'origine- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Envoyé : jeudi 18 mars 2004 23:09 > À : Maven Users List > Objet : RE: More visual project descriptor documentation > > Found the unsub duplicate. Thanks. > -- > dIon Gillard, Multitask Consulting > > > > "Arnaud Heritier" <[EMAIL PROTECTED]> wrote on 19/03/2004 08:39:31 AM: > > > There's also the tag duplicated 2 times. > > > > Same thing for mailingLists/mailingList/unsubscribe. > > > > dependencies/dependency/properties can be simplified > > > > Arnaud. > > > > > -Message d'origine- > > > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > Envoyé : jeudi 18 mars 2004 22:09 > > > À : Maven Users List > > > Objet : RE: More visual project descriptor documentation > > > > > > Fixing that now. > > > -- > > > dIon Gillard, Multitask Consulting > > > > > > > > > > > > "Heritier Arnaud" <[EMAIL PROTECTED]> wrote on 18/03/2004 07:26:05 > PM: > > > > > > > +1 for me. > > > > > > > > there's just a little error with the organization end tag: > > > > > > > > > > > > Arnaud. > > > > > > > > -Message d'origine- > > > > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > > Envoyé : jeudi 18 mars 2004 02:20 > > > > À : Maven Users List > > > > Objet : RE: More visual project descriptor documentation > > > > > > > > > > > > "Heritier Arnaud" <[EMAIL PROTECTED]> wrote on 17/03/2004 09:45:30 > PM: > > > > > > > > > I like it. > > > > > Can't you reduce the space between lines ?? > > > > > Maybe you can use a source tag to enclose your description ?? > > > > > > > > I fixed my copy of the xdoc plugin, and regenerated the URL using a > > > source > > > > tag and some more indentation. > > > > > > > > http://maven.apache.org/~dion/maven.apache.org/reference/project- > > > > descriptor.html > > > > > > > > Better? > > > > -- > > > > dIon Gillard, Multitask Consulting > > > > > > > > > - > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: More visual project descriptor documentation
> -Message d'origine- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Envoyé : jeudi 18 mars 2004 23:09 > À : Maven Users List > Objet : RE: More visual project descriptor documentation > > "Arnaud Heritier" <[EMAIL PROTECTED]> wrote on 19/03/2004 08:39:31 AM: > > > There's also the tag duplicated 2 times. > > Fixed that. > > > Same thing for mailingLists/mailingList/unsubscribe. > > ? I can't see a duplication for mailingLists etc.. > > > dependencies/dependency/properties can be simplified > > That one was intentional. I was trying to show that there can be nested > elements for properties rather than text. Ok. Arnaud. > -- > dIon Gillard, Multitask Consulting
RE: More visual project descriptor documentation
Found the unsub duplicate. Thanks. -- dIon Gillard, Multitask Consulting "Arnaud Heritier" <[EMAIL PROTECTED]> wrote on 19/03/2004 08:39:31 AM: > There's also the tag duplicated 2 times. > > Same thing for mailingLists/mailingList/unsubscribe. > > dependencies/dependency/properties can be simplified > > Arnaud. > > > -Message d'origine- > > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Envoyé : jeudi 18 mars 2004 22:09 > > À : Maven Users List > > Objet : RE: More visual project descriptor documentation > > > > Fixing that now. > > -- > > dIon Gillard, Multitask Consulting > > > > > > > > "Heritier Arnaud" <[EMAIL PROTECTED]> wrote on 18/03/2004 07:26:05 PM: > > > > > +1 for me. > > > > > > there's just a little error with the organization end tag: > > > > > > > > > Arnaud. > > > > > > -Message d'origine- > > > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > > Envoyé : jeudi 18 mars 2004 02:20 > > > À : Maven Users List > > > Objet : RE: More visual project descriptor documentation > > > > > > > > > "Heritier Arnaud" <[EMAIL PROTECTED]> wrote on 17/03/2004 09:45:30 PM: > > > > > > > I like it. > > > > Can't you reduce the space between lines ?? > > > > Maybe you can use a source tag to enclose your description ?? > > > > > > I fixed my copy of the xdoc plugin, and regenerated the URL using a > > source > > > tag and some more indentation. > > > > > > http://maven.apache.org/~dion/maven.apache.org/reference/project- > > > descriptor.html > > > > > > Better? > > > -- > > > dIon Gillard, Multitask Consulting > > > > > > - > > > 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: More visual project descriptor documentation
"Arnaud Heritier" <[EMAIL PROTECTED]> wrote on 19/03/2004 08:39:31 AM: > There's also the tag duplicated 2 times. Fixed that. > Same thing for mailingLists/mailingList/unsubscribe. ? I can't see a duplication for mailingLists etc.. > dependencies/dependency/properties can be simplified That one was intentional. I was trying to show that there can be nested elements for properties rather than text. -- dIon Gillard, Multitask Consulting
bcel dependency problem
A few days ago there was a discussion concerning the ejb jar plugin and I mentioned I had written my own but had a problem loading the bcel dependency. I've since deleted the thread, but I solved the problem: I specified the bcel dependency with the root property. Hope this helps whoever it was, WM __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: More visual project descriptor documentation
There's also the tag duplicated 2 times. Same thing for mailingLists/mailingList/unsubscribe. dependencies/dependency/properties can be simplified Arnaud. > -Message d'origine- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Envoyé : jeudi 18 mars 2004 22:09 > À : Maven Users List > Objet : RE: More visual project descriptor documentation > > Fixing that now. > -- > dIon Gillard, Multitask Consulting > > > > "Heritier Arnaud" <[EMAIL PROTECTED]> wrote on 18/03/2004 07:26:05 PM: > > > +1 for me. > > > > there's just a little error with the organization end tag: > > > > > > Arnaud. > > > > -Message d'origine- > > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Envoyé : jeudi 18 mars 2004 02:20 > > À : Maven Users List > > Objet : RE: More visual project descriptor documentation > > > > > > "Heritier Arnaud" <[EMAIL PROTECTED]> wrote on 17/03/2004 09:45:30 PM: > > > > > I like it. > > > Can't you reduce the space between lines ?? > > > Maybe you can use a source tag to enclose your description ?? > > > > I fixed my copy of the xdoc plugin, and regenerated the URL using a > source > > tag and some more indentation. > > > > http://maven.apache.org/~dion/maven.apache.org/reference/project- > > descriptor.html > > > > Better? > > -- > > dIon Gillard, Multitask Consulting > > > > - > > 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: More visual project descriptor documentation
Fixing that now. -- dIon Gillard, Multitask Consulting "Heritier Arnaud" <[EMAIL PROTECTED]> wrote on 18/03/2004 07:26:05 PM: > +1 for me. > > there's just a little error with the organization end tag: > > > Arnaud. > > -Message d'origine- > De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Envoyé : jeudi 18 mars 2004 02:20 > À : Maven Users List > Objet : RE: More visual project descriptor documentation > > > "Heritier Arnaud" <[EMAIL PROTECTED]> wrote on 17/03/2004 09:45:30 PM: > > > I like it. > > Can't you reduce the space between lines ?? > > Maybe you can use a source tag to enclose your description ?? > > I fixed my copy of the xdoc plugin, and regenerated the URL using a source > tag and some more indentation. > > http://maven.apache.org/~dion/maven.apache.org/reference/project- > descriptor.html > > Better? > -- > dIon Gillard, Multitask Consulting > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
Re: More visual project descriptor documentation
Jim Crossley <[EMAIL PROTECTED]> wrote on 18/03/2004 10:57:54 PM: > [EMAIL PROTECTED] writes: > > > I'd like to suggest a more visual way of documenting the project > > descriptor. > > Looks great. > > > Comments?? > > Some visual way of distinguishing the required elements from the > optional ones might be nice. My first thought was color, but since > the tags are links, that might be a little confusing. Maybe just > asterisks beside the required ones? How about bold for required and strikethrough or italic for deprecated? -- dIon Gillard, Multitask Consulting
RE: [reactor] Invoking reactor without a project.xml
> Hope it helps... Oh yes it helps thank you very much. I'll experiment with it and get back to you if I have issues. Thanks much, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [reactor] Invoking reactor without a project.xml
I guess I'd go back to my original comment, and provide a bare-bones project.xml at the base dir, just as a placeholder...then, that will free you up to write a base-level maven.xml/project.properties to manage the various builds via multiproject and/or straight reactor. Or am I missing something? If anyone has a better method, please pipe up. I have something like this in some cases, and am currently using the following: - multiproject:install goal - base-level project.properties with the following properties: - maven.multiproject.includes=projects/*/project.xml (note ONE star) - project-level project.properties with something akin to the following: - maven.multiproject.type=ejb (only specified at all when EJB project) Then, within the maven.xml of the EJB projects, I kick off the build for the ejb-client sub-project (arranged underneath the EJB project dir structure). This way, even when I run a build straight from an EJB sub-project, it will still build the ejb-client. I don't know if this helps or not, but there you go. Oh, and BTW, since I'm using multiple EJB's in some projects, I reference a maven.xml-in-disguise which lives in the base-directory, named something like 'maven-ejb-goals.xml' via something akin to in the top of the EJB-project maven.xml file. Hope it helps... -john On Thu, 2004-03-18 at 15:16, Alex Karasulu wrote: > > -Original Message- > > From: John Casey [mailto:[EMAIL PROTECTED] > > Sent: Thursday, March 18, 2004 3:08 PM > > To: Maven Users List > > Subject: RE: [reactor] Invoking reactor without a project.xml > > > > yeah...didn't read that closely enough. I'm still confused on what you > > mean by 'convenience builds'...is this something akin to an ejb-client > > as a secondary build, or what? > > Not exactly John - let me clarify by describing the whole situation. > Basically I have a directory structure like so: > > top server dir/ > frontend/ > subsystem/ > comp1/ > comp2/ > ... > backend/ > Same situation as the frontend > > I want to be able to build the entire server up at the top. If I want > I would like to build the front end or the backend only because of the > amount of time it takes for the build. Likewise we can extend the same > case to the subsystem level or to the component level. > > What is the best way for me to handle these 'convenience' builds at the > various levels using Maven? > > If the reactor facility did not rebuild every time but only when one > was necessary due to changes to the project or to one of its dependencies > this would not be an issue or is this possible some how and I don't know > it. > > Alex > > > On Thu, 2004-03-18 at 15:01, Alex Karasulu wrote: > > > John, > > > > > > > > > > -Original Message- > > > > From: John Casey [mailto:[EMAIL PROTECTED] > > > > Sent: Thursday, March 18, 2004 2:52 PM > > > > > > > > If you have a project.xml at the base level but never extend from it, > > it > > > > should not restrict this use case... > > > > > > > > -john > > > > > > > > On Thu, 2004-03-18 at 14:45, Alex Karasulu wrote: > > > > > Hello, > > > > > > > > > > Is there a way to invoke the reactor without having a project.xml > > for > > > > the > > > > > top level directory. Basically can I just have a maven.xml to > > invoke > > > > the > > > > > reactor. The reason I ask this is because I have multiple levels > > that I > > > > > would like to start off a reactor build on. The problem is the > > > > restriction > > > > > on the levels of inheritance. Only one level is allowed so I don't > > want > > > > to > > > > > have the extra POM on those levels where I want builds to occur for > > > > > convenience. > > > > > > And how do recommend I prevent the reactor from picking up POMs at > > > these intermediate levels in the directory structure when the > > > reactor is invoked up at the topmost level? Do I just use the > > > exclude attribute to do that, or is there a better way? Will maven > > > ignore POMs if they duplicate builds of a proper subset of the component > > > projects scheduled for the reactor? > > > > > > Alex > > > > > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > -- > > John Casey > > [EMAIL PROTECTED] > > CommonJava Open Components Project > > http://www.commonjava.org > > > > > > - > > 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] -- John Casey [EMAIL PROTECTED] CommonJava Open Components Project http://www.
RE: [reactor] Invoking reactor without a project.xml
> -Original Message- > From: John Casey [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 18, 2004 3:08 PM > To: Maven Users List > Subject: RE: [reactor] Invoking reactor without a project.xml > > yeah...didn't read that closely enough. I'm still confused on what you > mean by 'convenience builds'...is this something akin to an ejb-client > as a secondary build, or what? Not exactly John - let me clarify by describing the whole situation. Basically I have a directory structure like so: top server dir/ frontend/ subsystem/ comp1/ comp2/ ... backend/ Same situation as the frontend I want to be able to build the entire server up at the top. If I want I would like to build the front end or the backend only because of the amount of time it takes for the build. Likewise we can extend the same case to the subsystem level or to the component level. What is the best way for me to handle these 'convenience' builds at the various levels using Maven? If the reactor facility did not rebuild every time but only when one was necessary due to changes to the project or to one of its dependencies this would not be an issue or is this possible some how and I don't know it. Alex > On Thu, 2004-03-18 at 15:01, Alex Karasulu wrote: > > John, > > > > > > > -Original Message- > > > From: John Casey [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, March 18, 2004 2:52 PM > > > > > > If you have a project.xml at the base level but never extend from it, > it > > > should not restrict this use case... > > > > > > -john > > > > > > On Thu, 2004-03-18 at 14:45, Alex Karasulu wrote: > > > > Hello, > > > > > > > > Is there a way to invoke the reactor without having a project.xml > for > > > the > > > > top level directory. Basically can I just have a maven.xml to > invoke > > > the > > > > reactor. The reason I ask this is because I have multiple levels > that I > > > > would like to start off a reactor build on. The problem is the > > > restriction > > > > on the levels of inheritance. Only one level is allowed so I don't > want > > > to > > > > have the extra POM on those levels where I want builds to occur for > > > > convenience. > > > > And how do recommend I prevent the reactor from picking up POMs at > > these intermediate levels in the directory structure when the > > reactor is invoked up at the topmost level? Do I just use the > > exclude attribute to do that, or is there a better way? Will maven > > ignore POMs if they duplicate builds of a proper subset of the component > > projects scheduled for the reactor? > > > > Alex > > > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > -- > John Casey > [EMAIL PROTECTED] > CommonJava Open Components Project > http://www.commonjava.org > > > - > 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: [reactor] Invoking reactor without a project.xml
yeah...didn't read that closely enough. I'm still confused on what you mean by 'convenience builds'...is this something akin to an ejb-client as a secondary build, or what? -j On Thu, 2004-03-18 at 15:01, Alex Karasulu wrote: > John, > > > > -Original Message- > > From: John Casey [mailto:[EMAIL PROTECTED] > > Sent: Thursday, March 18, 2004 2:52 PM > > > > If you have a project.xml at the base level but never extend from it, it > > should not restrict this use case... > > > > -john > > > > On Thu, 2004-03-18 at 14:45, Alex Karasulu wrote: > > > Hello, > > > > > > Is there a way to invoke the reactor without having a project.xml for > > the > > > top level directory. Basically can I just have a maven.xml to invoke > > the > > > reactor. The reason I ask this is because I have multiple levels that I > > > would like to start off a reactor build on. The problem is the > > restriction > > > on the levels of inheritance. Only one level is allowed so I don't want > > to > > > have the extra POM on those levels where I want builds to occur for > > > convenience. > > And how do recommend I prevent the reactor from picking up POMs at > these intermediate levels in the directory structure when the > reactor is invoked up at the topmost level? Do I just use the > exclude attribute to do that, or is there a better way? Will maven > ignore POMs if they duplicate builds of a proper subset of the component > projects scheduled for the reactor? > > Alex > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey [EMAIL PROTECTED] CommonJava Open Components Project http://www.commonjava.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [reactor] Invoking reactor without a project.xml
John, > -Original Message- > From: John Casey [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 18, 2004 2:52 PM > > If you have a project.xml at the base level but never extend from it, it > should not restrict this use case... > > -john > > On Thu, 2004-03-18 at 14:45, Alex Karasulu wrote: > > Hello, > > > > Is there a way to invoke the reactor without having a project.xml for > the > > top level directory. Basically can I just have a maven.xml to invoke > the > > reactor. The reason I ask this is because I have multiple levels that I > > would like to start off a reactor build on. The problem is the > restriction > > on the levels of inheritance. Only one level is allowed so I don't want > to > > have the extra POM on those levels where I want builds to occur for > > convenience. And how do recommend I prevent the reactor from picking up POMs at these intermediate levels in the directory structure when the reactor is invoked up at the topmost level? Do I just use the exclude attribute to do that, or is there a better way? Will maven ignore POMs if they duplicate builds of a proper subset of the component projects scheduled for the reactor? Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [reactor] Invoking reactor without a project.xml
If you have a project.xml at the base level but never extend from it, it should not restrict this use case... -john On Thu, 2004-03-18 at 14:45, Alex Karasulu wrote: > Hello, > > Is there a way to invoke the reactor without having a project.xml for the > top level directory. Basically can I just have a maven.xml to invoke the > reactor. The reason I ask this is because I have multiple levels that I > would like to start off a reactor build on. The problem is the restriction > on the levels of inheritance. Only one level is allowed so I don't want to > have the extra POM on those levels where I want builds to occur for > convenience. > > Thanks, > Alex > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- John Casey [EMAIL PROTECTED] CommonJava Open Components Project http://www.commonjava.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[reactor] Invoking reactor without a project.xml
Hello, Is there a way to invoke the reactor without having a project.xml for the top level directory. Basically can I just have a maven.xml to invoke the reactor. The reason I ask this is because I have multiple levels that I would like to start off a reactor build on. The problem is the restriction on the levels of inheritance. Only one level is allowed so I don't want to have the extra POM on those levels where I want builds to occur for convenience. Thanks, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: More visual project descriptor documentation
On Thu, 2004-03-18 at 10:33, Sonnek, Ryan wrote: > What about adding a column to the documentation area for "required" tags? > This would allow the layout to be verbose and users can click on the tag > name to see if it is required. the documentation already has "Optional" > next to many of the tags, but it is not visually distinct since it is in the > description column. If a new column was added for the sole purpose of > displaying the required status, it'd be a bit easier to read. Ultimately the page describing the model will be generated from this: http://cvs.apache.org/viewcvs.cgi/maven-components/maven-model/maven.mdo?rev=1.22&view=auto I am already generating the model sources, the XSD, the xpp3 unmarshaller and marshaller and the xdoc: http://maven.apache.org/maven.html Certainly not finished by any stretch of the imagination, but the maven.mdo will be augmented to provide any information that is useful. Optional fields will definitely be added as they are required for the correct generation of the XSD: http://maven.apache.org/~jvanzyl/maven.xsd As you can see there's nothing there to allow optional fields yet, but it's coming. Ultimately, I want any artifact that is useful and stems from the model to be generated so that it remains up-to-date with changes in the model. This has been the biggest problem with Maven which I hope remedy soon. So even that sample full document at the top of Dion's can be generated and I will incorporate that if desired. This week and next week are plugin weeks the following week will be work on the new xdoc plugin: http://cvs.apache.org/viewcvs.cgi/maven-components/maven-xdoc/ Which will produce nice sites like: http://groovy.codehaus.org/ And do it pretty much instaneously. I can currently generate the xhtml for the Maven site in under a second. > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More visual project descriptor documentation
On Thu, 2004-03-18 at 00:39, matthew.hawthorne wrote: > >>http://maven.apache.org/~dion/maven.apache.org/reference/project-descriptor.html > > This is very cool. This version is much better IMO. > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl [EMAIL PROTECTED] http://maven.apache.org happiness is like a butterfly: the more you chase it, the more it will elude you, but if you turn your attention to other things, it will come and sit softly on your shoulder ... -- Thoreau - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: More visual project descriptor documentation
What about adding a column to the documentation area for "required" tags? This would allow the layout to be verbose and users can click on the tag name to see if it is required. the documentation already has "Optional" next to many of the tags, but it is not visually distinct since it is in the description column. If a new column was added for the sole purpose of displaying the required status, it'd be a bit easier to read. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: More visual project descriptor documentation
Looks great! > -Original Message- > From: matthew.hawthorne [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 17, 2004 11:40 PM > To: Maven Users List > Subject: Re: More visual project descriptor documentation > > >>http://maven.apache.org/~dion/maven.apache.org/reference/project- > descriptor.html > > This is very cool. > > - > 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: Purging old snapshots in repository
> Snapshots are deployed to ibiblio and they are not removed. > Nothing is supposed to be removed from ibiblio and if someone went in > and did so they shouldn't have. Interesting. While that problably works for ibiblio, where new additions are manually deployed, it wouldn't work in a corporate situation where continuous integration builds (via CruiseControl) are constantly pushing snapshots to an intermediary repository. I was more curious than anything else, since this really isn't too hard a problem to solve (shell script via cron job, a maven plugin, etc.). Kyle _ Kyle Adams | Java Developer | Gordon Food Service | 616-717-6162 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Including dependencies from external file
Jörn Gebhardt wrote on Thursday, March 18, 2004 3:16 PM: > Thanks Jörg for this great documentation!!! Hope you liked it. Just fixed some syntax errors ... seems there is always something left Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Form feed character in license file kills xml transformation
On Thu, 2004-03-18 at 04:26, BjÃrn Ola Smievoll wrote: > Seems not to be the license-plugin as the XML in license.xml is > correct, representing the form feed character as . The only thing > on line 59 of license.xml is . Don't know where the &#c that's > in the error comes from. 12 decimal is 0C hexadecimal. I'm guessing that something tried translating the entity for the form feed character to hex notation (either in the XML translation or the error reporting) and got it wrong. "&#c" is not a valid XML entity, but " " is, I believe. -- Craig S. Cottingham [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Including dependencies from external file
Thanks Jörg for this great documentation!!! Jörn > -Ursprüngliche Nachricht- > Von: Jörg Schaible [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 18. März 2004 15:08 > An: Maven Users List > Betreff: RE: Including dependencies from external file > > > Gilles Dodinet wrote on Wednesday, March 17, 2004 8:14 PM: > > > Jörg Schaible wrote: > > > >>> we use something like that to include external xml fragments : > >>> > >>> >>> "file:../mevenide-ui-eclipse/pom-fragments/inherited-dependenc > >>> ies.xml"> > >>> > >>> it works under xp and linux. > >> > >> But only if all included POMs (by reactor or extend tag) share the > >> same directory level to the multiproject's basedir. > > > > indeed. actually this entity is defined in > > mevenide-ui-eclipse pom. the > > mevenide-ui-eclipse segment is added to allow the entity to > > be resolved > > whether pom is read from parent directory or directly from within > > basedir (i.e. using rector or not). and you're right : > another trick > > should be applied if using nested projects structure. perhaps > > something like your locator indirection. it would be cool if a later > > maven version > > supported file inclusion in a smoother way. > > I just add a wiki about entity usage in Maven: > http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities > > Hope it helps ... :) > > Regards, > Jörg > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
RE: Including dependencies from external file
Gilles Dodinet wrote on Wednesday, March 17, 2004 8:14 PM: > Jörg Schaible wrote: > >>> we use something like that to include external xml fragments : >>> >>> >> "file:../mevenide-ui-eclipse/pom-fragments/inherited-dependenc >>> ies.xml"> >>> >>> it works under xp and linux. >> >> But only if all included POMs (by reactor or extend tag) share the >> same directory level to the multiproject's basedir. > > indeed. actually this entity is defined in > mevenide-ui-eclipse pom. the > mevenide-ui-eclipse segment is added to allow the entity to > be resolved > whether pom is read from parent directory or directly from within > basedir (i.e. using rector or not). and you're right : another trick > should be applied if using nested projects structure. perhaps > something like your locator indirection. it would be cool if a later > maven version > supported file inclusion in a smoother way. I just add a wiki about entity usage in Maven: http://wiki.codehaus.org/maven/EnsureProjectConsistencyWithEntities Hope it helps ... :) Regards, Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: logging output
Hi Eric Almost. I want to log the screen output from my most important goals to a file, and also have the output on screen. Shell redirection is not enough. Thanks a lot. Heiko Eric Giguere wrote: Hi there I'm not sure if I miss the point but from what I understand, yes, you can now log at a goal level. I guess you may check this : http://jakarta.apache.org/commons/jelly/libs/log/index.html There is a nice log taglib for jelly that acts as the well known log4j api. This tag lib uses in fact the commons-logging. You just have to insert this : xmlns:log="jelly:log" in the project tag of you maven.xml file. Then, you can use the jelly log taglib tags like this : bla bla or bla bla All log tags also allow to specify which logger instance you want to use or logger name using the tags build-in properties. And these log tags are not reserved to plugins only... maven.xml can contain jelly scripting to. With proper configuration (still have to do that), you will be able like in java app to set the log level and since you can specifiy the logger instance, you could even filter logging as you want, like we do with commons-logging (or log4j). Hope it helps Eric. Eric Hauser wrote: If you are interested in Ant logging, I submitted a patch http://jira.codehaus.org/secure/ViewIssue.jspa?key=MAVEN-126 called MAVEN126.patch that gives you the ability to get Ant logging when using Ant tasks. It is a quick hack to add this functionality, but at least should serve as a good example for how to add it yourself. As far as configuring logging for Maven itself, I do not believe what you are trying to do is possible. If you are working on your own tasks, you can use a property for a logging level and handle it accordingly in your Jelly. Currently, Maven does not have a very flexible logging system in the core, but I believe this is planned for the future. Heiko Kundlacz wrote: Hi, in Ant there is a output flag on the task level. Is there any according functionality for maven? Can I log output on a goal level? Thanks for your help Heiko - 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] -- -- Heiko Kundlacz | MailTo: [EMAIL PROTECTED] Qnamic AG| Tel: +41 62 209 7056 Fabrikstr. 10| Natel:+41 78 861 4006 4614 Haegendorf | Fax: +41 62 209 7044 Switzerland | Homepage: http://www.qnamic.com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [REPOST] Properties and subprojects
[EMAIL PROTECTED] writes: > Jim Crossley <[EMAIL PROTECTED]> wrote on 18/03/2004 01:57:22 PM: > > > How do I arrange my ?ar.bundle dependency properties in the pom so > > that when I build the war subproject, the external jars are > > packaged with the war, and when I build the ear subproject, they > > are not? > > Have a postGoal on war that uses a property set in the parent to > remove the unwanted jars after the war creation? That works, thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More visual project descriptor documentation
[EMAIL PROTECTED] writes: > I'd like to suggest a more visual way of documenting the project > descriptor. Looks great. > Comments?? Some visual way of distinguishing the required elements from the optional ones might be nice. My first thought was color, but since the tags are links, that might be a little confusing. Maybe just asterisks beside the required ones? Jim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: More visual project descriptor documentation
+1 for me. there's just a little error with the organization end tag: Arnaud. -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Envoyé : jeudi 18 mars 2004 02:20 À : Maven Users List Objet : RE: More visual project descriptor documentation "Heritier Arnaud" <[EMAIL PROTECTED]> wrote on 17/03/2004 09:45:30 PM: > I like it. > Can't you reduce the space between lines ?? > Maybe you can use a source tag to enclose your description ?? I fixed my copy of the xdoc plugin, and regenerated the URL using a source tag and some more indentation. http://maven.apache.org/~dion/maven.apache.org/reference/project-descriptor.html Better? -- dIon Gillard, Multitask Consulting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Form feed character in license file kills xml transformation
I have a LICENSE.txt that includes form feed characters. When running maven site this file causes the build to fail. Tried tracing the problem to it's true root so I could report it in Jira, but I didn't really understand who the culprit was (maven core, jelly:xml or xdoc-plugin). Seems not to be the license-plugin as the XML in license.xml is correct, representing the form feed character as . The only thing on line 59 of license.xml is . Don't know where the &#c that's in the error comes from. If I remove the form feeds from LICENSE.txt there's no problem. Get this with both maven rc1 and the latest MAVEN_1-0_BRANCH from cvs. BUILD FAILED File.. file:/home/bos/.maven/plugins/maven-xdoc-plugin-1.4/ Element... x:parse Line.. 328 Column 43 Error on line 59 of document file:/home/bos/tmp/moria-ng/modules/moria-ctrl/target/generated-xdocs/license.xml : Character reference "&#c" is an invalid XML character. Nested exception: Character reference "&#c" is an invalid XML character. Total time: 16 seconds (bo) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: RE : More visual project descriptor documentation
I'm agree with you Sébastien. There's always a lack of documentations in maven. Everybody is invited to help to write or enhance the doc. This problem is not a Maven problem but more generally an opensource problem. For example it was the same problem with Tomcat or Struts. At the beginning, there was a lot of good ideas but the documentation was poor. After several years, this projects are well documented. It's a question of time. A good developer is not necessarily a good author. So all help is appreciated !!! Arnaud. -Message d'origine- De : Sébastien BRUNOT [mailto:[EMAIL PROTECTED] Envoyé : mercredi 17 mars 2004 17:55 À : 'Maven Users List' Objet : RE : More visual project descriptor documentation . Anyway, i have a pray for maven authors : please DOCUMENT WHAT YOU DO ! Some clients of mine rejected maven because of the lack of real documentation (example : What is the list of variable used by maven and its different plugins ? What is The grammaticaly correct syntax for a jelly expression ?). Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Latex plugin
Hi, I'd like to try to fix a bug in the latex plugin (MPLATEX-2 bug : the plugin doesn't work in win32 environment... Because the anttex (ant task used by the plugin) needs a unix path separator whereas the plugin give it a path that use the platform path separator). Could somebody tell me where the anttex 1.0 library sources are stored ? I've found the 0.2 version with google (a .zip that contains the sources), but where the hell are the 1.0 sources ??? Sebastien Brunot --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.614 / Virus Database: 393 - Release Date: 05/03/2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE : RE : More visual project descriptor documentation
In fact, it is not documented at all. Sebastien -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Envoyé : jeudi 18 mars 2004 01:06 À : Maven Users List Objet : RE : More visual project descriptor documentation There currently is a complete project.xml as part of the documentation. See http://maven.apache.org/start/integrate.html It's not terribly well documented though. -- dIon Gillard, Multitask Consulting Sébastien BRUNOT <[EMAIL PROTECTED]> wrote on 18/03/2004 03:54:51 AM: > Hi, > > Another idea could be the release of a sample COMPLETE project.xml > documented. The documentation need to be completed first (for example > : what is the connection string for a subversion repository ?). Here > is my personal file for that (named project.xml.template) : > > < BEGINING OF THE FILE > == > == > ===> > > > > > 3 > > > SampleJ2EE > > > A Sample J2EE project to compare ant versus maven build > process > > > 1.0-SNAPSHOT > > > > > Octo Technology > > http://www.octo.com/ > > http://images/octo-logo.jpg > > > > 2003 > > > com.octo.j2ee.sample > > > /images/project-logo.jpg > > > > > > > This project is a sample J2EE project that is build with maven. > The following maven sub projects are used : TO BE CONTINUED > > > > > How to use maven for building a j2ee project. > > > > http://localhost/samplej2ee > > > > > > localhost > > > C:/Documents and Settings/sbrunot/Mes > documents/www/samplej2ee > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Sebastien Brunot > > sbrunot > > [EMAIL PROTECTED] > > Octo Technology > > > developer > > > > > 1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [EMAIL PROTECTED] > > src/java > > > > > > > > > > > > > > > > > src/test > > > > > > > > **/*Test.java > > > > > **/NaughtyTest.java > > > > > > > > src/conf > > > > > > *.properties > > > > > > > > > > > > > > > > > > > > > > < END OF THE FILE > > > > > Anyway, i have a pray for maven authors : please DOCUMENT WHAT YOU DO ! > Some clients of mine rejected maven because of > the lack of real documentation (example : What is the list of variable > used by maven and its different plugins ? What is > The grammaticaly correct syntax for a jelly expression ?). > > Sebastien > > -Message d'origine- > De : Jean-Marc Lavoie [mailto:[EMAIL PROTECTED] > Envoyé : mercredi 17 mars 2004 16:47 > À : Maven Users List > Objet : RE: More visual project descriptor documentation > > > The representation is great, it will be perfect with the proposed > enhancements. > > > My in first experience with maven projects, I had to create all the > folder structure, with some errors. Then I discoved the genapp plugin. > The plugin provides a sample POMS that provides a really great start. I > think the plugin should be introduced in the "getting started" section > to allow user not to start from scratch. This would remove lot of > questions like resouces in jars, jars creation, JUnits, what to include > in the file, and malformed project files as you start with a working > pom. Then the section you're working one would become an advance topic, > as people getting there would already have something working for most of > the cases, instead of getting there to create new pom sections. > > > > > > -Original Message- > > From: Erik Husby [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, March 17, 2004 10:31 AM > > To: Maven Users List > > Subject: Re: More visual project descriptor documentation > > > > > > Definitely a step in the right direction. I too think that more > > indentation is required. > > > > Al
Re: More visual project descriptor documentation
"Marco Tedone" <[EMAIL PROTECTED]> wrote on 18/03/2004 06:54:33 PM: > As far as I'm concerned, the description of each descriptor element is > pretty pour (Maven is still young!) and waiting for an official book on > Maven (coming soon), e newcomer has got only the descriptor documentation > (and the mailing list!) to get started. I believe that adding documentation > to each element, with the view of a newcomer that has to migrate to > Maven...let's say from Ant, would save hours of work and frustration. > Nothing avoids you from adding the same type of docs also under the > integration page. Sure. The more the merrier. Have a look at the example for sourceModifications that's up there now. If I add one for resources in a similar place would that be helpful? -- dIon Gillard, Multitask Consulting
