Re: dependencies
Hi Manuel, maven has the notion of a or many repositories which house 3rd party library jars and additionally jars for your project. Whenever you have a new version of a component you would deploy the new version of the jar into the repository and make it available to projects which depend on them. This process can be automated with a continuous integration tool such as cruisecontrol. There are pointers in the mailing list how to do that, if you are interested. Another way of dealing with inner-project dependencies is to define your project as a multiproject and let the multiproject goals resolve a dependency graph and build/install your projects/components in the appropriate order. Since a project can get easily very complex I would suggest the use of repositories to keep all versions of your jars. Hope that helps. Dominik On Tue, 2004-05-18 at 21:07, Manuel Darveau wrote: Hi! I probably have missed something somewhere but dont dependencies should be by project-version instead of only by project? I mean, is the project ABC-1.0 could have a dependency on XXX-1.0 and ABC-2.0 a dependency on XXX-1.5 and YYY-2.0. How does the build system handle this? Suppose that I tag my version on CVS with VERSION_M_m. I can have an old version tagged VERSION_1_0 and newer one tagged VERSION_2_0. If I ask to build a project with the CVS tag VERSION_1_0, does maven checkout the project.xml tagged as VERSION_1_0 and resolve dependencies with that version (1.0) of the project.xml? Since version 1.0 and 2.0 does not have the same depdendencies, it make a big difference on the build. I may be completely off the track (I am reading maven doc for 2 days) but please bring me back in the good direction ;-) Thank you Manuel Darveau __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dominik Dahlem [EMAIL PROTECTED] --- Trinity College Dublin Department of Computer Science, Dublin 2, Ireland fax: (+353) 1-677 2204 www: http://www.cs.tcd.ie/Dominik.Dahlem/ --- signature.asc Description: This is a digitally signed message part
Re: javadoc on generated source directories
On Tue, 2004-05-18 at 07:33, Denis McLaughlin wrote: I had sent the email below asking for some information about modifying the maven javadoc plugin to properly support the maven.compile.src.set. I've generated a patch that seems to do the right thing: it's attached below. Comments quite welcome. Raise a JIRA issue, I wanna vote for it :-) Lets hope that it will be included in RC3, cu -- Martin Skopp Riege Software International GmbH Support: mailto:[EMAIL PROTECTED], Information: http://www.riege.com This email is intended to be viewed with a nonproportional font. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: resolve a jelly property explicitly
It appears to me that only the property ${basedir} can be resolved at
runtime. I don't know, whether that is a limitation to the ant
checkstyle ant target.
Because some of my projects have a different depth in the project layout
I can't rely on a one-for-all setting of the maven.checkstyle.properties
in the ~/build.properties file. I got away with my problem when I
specified this property in each project. There is a bit of duplication
here, but i don't have the error anymore.
Cheers,
Dominik
On Mon, 2004-05-17 at 11:06, Dominik Dahlem wrote:
Hi all,
is there a way to resolve a property in jelly explicitly? The checkstyle
plugin internally sets the checkstyleProperties property which in my
case is based on maven.checkstyle.properties. I set
maven.checkstyle.properties to
${projectA.home}/master/src/config/checkstyle.xml in ~/build.properties.
projectA.home in turn is specified in a specific project.properties
file.
Before the ant target of checkstyle is executed it prints out the
checkstyleProperties property correctly with the path resolved whereas
the target itself bellies up, because it can not find the configuration
file file:${projectA.home}/master/src/config/checkstyle.xml. I assume
the checkstyleProperties property is not resolved correctly inside the
checkstyle ant target.
Did anyone come across a similar problem?
Thanks for any help.
Dominik
--
Dominik Dahlem [EMAIL PROTECTED]
---
Trinity College Dublin
Department of Computer Science,
Dublin 2, Ireland
fax: (+353) 1-677 2204
www: http://www.cs.tcd.ie/Dominik.Dahlem/
---
signature.asc
Description: This is a digitally signed message part
Multiproject as a sub-project?
I'm setting up my first Maven project, and trying to plan for the future. The main project will be a collection of web applications (separate ones), so I want to configure the project so that the main project will build all the web apps (sub-projects), which in turn build all of their EJBs, WARs, EARs, JARs, etc. To do that, I figured the main project would use a multiproject, and each sub-project top level would as well. However, when I tried to set that up, the sub-project only generated overview information for the site documentation, it doesn't compile its code, or generate the reports based on the compiled code. If I run Maven in the sub-project, it does compile its code. I guess I'm surprised that the multiproject goal can't be recursive, because I see no reason as to why it couldn't/shouldn't be. Maybe I'm reading the docs wrong? Has anyone managed to set up this kind of project? Or do I just have to resign myself to building each sub-project separately, or making a custom goal or something like that? Thanks! Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Xdoclet Eclipse
Hi All, I'm using Maven + eclipse + xdoclet. When I run maven eclipse, I want to add in the eclipse project source folder list the location of xdoclet generated files (/target/xdoclet/ejbdoclet). How I can do that ? Kind regards, Christophe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Xdoclet Eclipse
--- LOMBART Christophe [EMAIL PROTECTED] wrote: Hi All, I'm using Maven + eclipse + xdoclet. When I run maven eclipse, I want to add in the eclipse project source folder list the location of xdoclet generated files (/target/xdoclet/ejbdoclet). How I can do that ? define pre goal? use some property? ( do not know anything about eclipse plugin, but there is plugin.jelly and it contains elmost every bit of ionformation necessary... ) regards, = [ Konstantin Pribluda ( ko5tik ) ] Zu Verstärkung meines Teams suche ich ab Sofort einen Softwareentwickler[In] für die Festanstellung. Arbeitsort: Mainz Skills: Programieren, Kentnisse in OpenSource-Bereich [ http://www.pribluda.de ] __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Xdoclet Eclipse
slightly OT My view is that it's a bad practice (anti-pattern) for a plugin to use preGoal/postGoal. Plugins should provide their own goals, possibly wrapping existing goals. /slightly OT -Vincent -Original Message- From: Kristopher Brown [mailto:[EMAIL PROTECTED] Sent: 19 May 2004 12:06 To: Maven Users List Subject: RE: Xdoclet Eclipse You can't easily. It's a general problem with plugins that affect the compile set, i.e. generation plugins such as antlr, castor etc, and plugins that should utilise the compile set, e.g. java:compile, javadoc, and ide plugins. Personally I think it should all be addressed in the same way across all the plugins of this nature - there are a few variations and different people have done it different ways. At the moment, most generation plugins include a preGoal for java:compile in plugin.jelly to ensure they are called before the compile occurs. java:compile is just one goal that requires the generation goals to have occurred (or at least the part that adds the generation path to the src set), and people have solved their plugin for this case as its typically the most used. javadoc, eclipse et al. need this modification to src.set to have occurred for them too. One easy way to ensure that this has occurred is to perform java:compile as a preGoal to the goal you are using eclipse/javadoc. This does more work then is needed, but it would ensure that any generation modification have occured. Another way would be for the affecting plugins to be aware of all projects that utilise the src.set and add a preGoal to them, but this would get bloated very quickly. There seems to be something missing in all of this though, a way in which a plugin can say that is a src.set affecting plugin and a way in which a plugin can say it's a src.set utilising plugin. Then all the utilising projects would have to do is iterate down the list of affecting plugins and call their src.set modifying goal, then do what they need. I think this is similar to the way in which the reports work for site generation, i.e. they register themselves, and site calls them back as and when needed. This would be a fairly huge undertaking for someone to sort out though. So for the eclipse plugin to work in the short term: 1. it needs to utilise the maven.compile.src.set rather than pom.build.sourceDirectory - this is a similar issue to what people have been discussing re the javadoc plugin. 2. the plugins need to interact somewhat to ensure that the src set has been populated with the generated src.set. This can be done by adding a custom preGoal in you maven.xml file for eclipse to call java:compile, or you could isolate the src.set affecting goal in xdoclet and call that goal instead. Kris. -Original Message- From: LOMBART Christophe [mailto:[EMAIL PROTECTED] Sent: 19 May 2004 10:34 To: [EMAIL PROTECTED] Subject: Xdoclet Eclipse Hi All, I'm using Maven + eclipse + xdoclet. When I run maven eclipse, I want to add in the eclipse project source folder list the location of xdoclet generated files (/target/xdoclet/ejbdoclet). How I can do that ? Kind regards, Christophe - 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: Xdoclet Eclipse
Without some kind of defined (and widely used!) mechanism for source-modifying plugins to do their thing, it's not clear how they have any real choice in the matter. Does there exist a better way that works right now? -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: 19 May 2004 11:15 To: 'Maven Users List' Subject: RE: Xdoclet Eclipse slightly OT My view is that it's a bad practice (anti-pattern) for a plugin to use preGoal/postGoal. Plugins should provide their own goals, possibly wrapping existing goals. /slightly OT -Vincent -Original Message- From: Kristopher Brown [mailto:[EMAIL PROTECTED] Sent: 19 May 2004 12:06 To: Maven Users List Subject: RE: Xdoclet Eclipse You can't easily. It's a general problem with plugins that affect the compile set, i.e. generation plugins such as antlr, castor etc, and plugins that should utilise the compile set, e.g. java:compile, javadoc, and ide plugins. Personally I think it should all be addressed in the same way across all the plugins of this nature - there are a few variations and different people have done it different ways. At the moment, most generation plugins include a preGoal for java:compile in plugin.jelly to ensure they are called before the compile occurs. java:compile is just one goal that requires the generation goals to have occurred (or at least the part that adds the generation path to the src set), and people have solved their plugin for this case as its typically the most used. javadoc, eclipse et al. need this modification to src.set to have occurred for them too. One easy way to ensure that this has occurred is to perform java:compile as a preGoal to the goal you are using eclipse/javadoc. This does more work then is needed, but it would ensure that any generation modification have occured. Another way would be for the affecting plugins to be aware of all projects that utilise the src.set and add a preGoal to them, but this would get bloated very quickly. There seems to be something missing in all of this though, a way in which a plugin can say that is a src.set affecting plugin and a way in which a plugin can say it's a src.set utilising plugin. Then all the utilising projects would have to do is iterate down the list of affecting plugins and call their src.set modifying goal, then do what they need. I think this is similar to the way in which the reports work for site generation, i.e. they register themselves, and site calls them back as and when needed. This would be a fairly huge undertaking for someone to sort out though. So for the eclipse plugin to work in the short term: 1. it needs to utilise the maven.compile.src.set rather than pom.build.sourceDirectory - this is a similar issue to what people have been discussing re the javadoc plugin. 2. the plugins need to interact somewhat to ensure that the src set has been populated with the generated src.set. This can be done by adding a custom preGoal in you maven.xml file for eclipse to call java:compile, or you could isolate the src.set affecting goal in xdoclet and call that goal instead. Kris. -Original Message- From: LOMBART Christophe [mailto:[EMAIL PROTECTED] Sent: 19 May 2004 10:34 To: [EMAIL PROTECTED] Subject: Xdoclet Eclipse Hi All, I'm using Maven + eclipse + xdoclet. When I run maven eclipse, I want to add in the eclipse project source folder list the location of xdoclet generated files (/target/xdoclet/ejbdoclet). How I can do that ? Kind regards, Christophe - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: javadoc on generated source directories
I'm working on a release 1.5.1 for the javadoc which will be supplied in RC3. If you have a patch, post it on Jira and it will be applied. Arnaud -Message d'origine- De : Martin Skopp [mailto:[EMAIL PROTECTED] Envoyé : mercredi 19 mai 2004 09:18 À : Maven Users List Objet : Re: javadoc on generated source directories On Tue, 2004-05-18 at 07:33, Denis McLaughlin wrote: I had sent the email below asking for some information about modifying the maven javadoc plugin to properly support the maven.compile.src.set. I've generated a patch that seems to do the right thing: it's attached below. Comments quite welcome. Raise a JIRA issue, I wanna vote for it :-) Lets hope that it will be included in RC3, cu -- Martin Skopp Riege Software International GmbH Support: mailto:[EMAIL PROTECTED], Information: http://www.riege.com This email is intended to be viewed with a nonproportional font. - 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: Xdoclet Eclipse
I'd tend to agree - looks like this needs sorting throughout the plugin code base then :) there are quite a few occurances of it. Its usually the easiest way to get something working though, and is in keeping with the way that this has been achieved to date (not that this justifies it). I'd rather see the registering approach similar to that employed in the xdoc plugin (which would not have this antipattern). -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: 19 May 2004 11:15 To: 'Maven Users List' Subject: RE: Xdoclet Eclipse slightly OT My view is that it's a bad practice (anti-pattern) for a plugin to use preGoal/postGoal. Plugins should provide their own goals, possibly wrapping existing goals. /slightly OT -Vincent -Original Message- From: Kristopher Brown [mailto:[EMAIL PROTECTED] Sent: 19 May 2004 12:06 To: Maven Users List Subject: RE: Xdoclet Eclipse You can't easily. It's a general problem with plugins that affect the compile set, i.e. generation plugins such as antlr, castor etc, and plugins that should utilise the compile set, e.g. java:compile, javadoc, and ide plugins. Personally I think it should all be addressed in the same way across all the plugins of this nature - there are a few variations and different people have done it different ways. At the moment, most generation plugins include a preGoal for java:compile in plugin.jelly to ensure they are called before the compile occurs. java:compile is just one goal that requires the generation goals to have occurred (or at least the part that adds the generation path to the src set), and people have solved their plugin for this case as its typically the most used. javadoc, eclipse et al. need this modification to src.set to have occurred for them too. One easy way to ensure that this has occurred is to perform java:compile as a preGoal to the goal you are using eclipse/javadoc. This does more work then is needed, but it would ensure that any generation modification have occured. Another way would be for the affecting plugins to be aware of all projects that utilise the src.set and add a preGoal to them, but this would get bloated very quickly. There seems to be something missing in all of this though, a way in which a plugin can say that is a src.set affecting plugin and a way in which a plugin can say it's a src.set utilising plugin. Then all the utilising projects would have to do is iterate down the list of affecting plugins and call their src.set modifying goal, then do what they need. I think this is similar to the way in which the reports work for site generation, i.e. they register themselves, and site calls them back as and when needed. This would be a fairly huge undertaking for someone to sort out though. So for the eclipse plugin to work in the short term: 1. it needs to utilise the maven.compile.src.set rather than pom.build.sourceDirectory - this is a similar issue to what people have been discussing re the javadoc plugin. 2. the plugins need to interact somewhat to ensure that the src set has been populated with the generated src.set. This can be done by adding a custom preGoal in you maven.xml file for eclipse to call java:compile, or you could isolate the src.set affecting goal in xdoclet and call that goal instead. Kris. -Original Message- From: LOMBART Christophe [mailto:[EMAIL PROTECTED] Sent: 19 May 2004 10:34 To: [EMAIL PROTECTED] Subject: Xdoclet Eclipse Hi All, I'm using Maven + eclipse + xdoclet. When I run maven eclipse, I want to add in the eclipse project source folder list the location of xdoclet generated files (/target/xdoclet/ejbdoclet). How I can do that ? Kind regards, Christophe - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Xdoclet Eclipse
The last paragraph of my email suggested just that (a pragmatic solution): So for the eclipse plugin to work in the short term: 1. it needs to utilise the maven.compile.src.set rather than pom.build.sourceDirectory - this is a similar issue to what people have been discussing re the javadoc plugin. 2. the plugins need to interact somewhat to ensure that the src set has been populated with the generated src.set. This can be done by adding a custom preGoal in your maven.xml file for eclipse to call java:compile, or you could isolate the src.set affecting goal in xdoclet and call that goal instead. There are numerous entries in JIRA proposing fixes to the eclipse plugin that have not been committed due to the patch becoming out of date. It needs someone to step up and just get it all in and working. Kris. -Original Message- From: Peter Bright [mailto:[EMAIL PROTECTED] Sent: 19 May 2004 11:14 To: 'Maven Users List' Subject: RE: Xdoclet Eclipse Without some kind of defined (and widely used!) mechanism for source-modifying plugins to do their thing, it's not clear how they have any real choice in the matter. Does there exist a better way that works right now? -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: 19 May 2004 11:15 To: 'Maven Users List' Subject: RE: Xdoclet Eclipse slightly OT My view is that it's a bad practice (anti-pattern) for a plugin to use preGoal/postGoal. Plugins should provide their own goals, possibly wrapping existing goals. /slightly OT -Vincent -Original Message- From: Kristopher Brown [mailto:[EMAIL PROTECTED] Sent: 19 May 2004 12:06 To: Maven Users List Subject: RE: Xdoclet Eclipse You can't easily. It's a general problem with plugins that affect the compile set, i.e. generation plugins such as antlr, castor etc, and plugins that should utilise the compile set, e.g. java:compile, javadoc, and ide plugins. Personally I think it should all be addressed in the same way across all the plugins of this nature - there are a few variations and different people have done it different ways. At the moment, most generation plugins include a preGoal for java:compile in plugin.jelly to ensure they are called before the compile occurs. java:compile is just one goal that requires the generation goals to have occurred (or at least the part that adds the generation path to the src set), and people have solved their plugin for this case as its typically the most used. javadoc, eclipse et al. need this modification to src.set to have occurred for them too. One easy way to ensure that this has occurred is to perform java:compile as a preGoal to the goal you are using eclipse/javadoc. This does more work then is needed, but it would ensure that any generation modification have occured. Another way would be for the affecting plugins to be aware of all projects that utilise the src.set and add a preGoal to them, but this would get bloated very quickly. There seems to be something missing in all of this though, a way in which a plugin can say that is a src.set affecting plugin and a way in which a plugin can say it's a src.set utilising plugin. Then all the utilising projects would have to do is iterate down the list of affecting plugins and call their src.set modifying goal, then do what they need. I think this is similar to the way in which the reports work for site generation, i.e. they register themselves, and site calls them back as and when needed. This would be a fairly huge undertaking for someone to sort out though. So for the eclipse plugin to work in the short term: 1. it needs to utilise the maven.compile.src.set rather than pom.build.sourceDirectory - this is a similar issue to what people have been discussing re the javadoc plugin. 2. the plugins need to interact somewhat to ensure that the src set has been populated with the generated src.set. This can be done by adding a custom preGoal in you maven.xml file for eclipse to call java:compile, or you could isolate the src.set affecting goal in xdoclet and call that goal instead. Kris. -Original Message- From: LOMBART Christophe [mailto:[EMAIL PROTECTED] Sent: 19 May 2004 10:34 To: [EMAIL PROTECTED] Subject: Xdoclet Eclipse Hi All, I'm using Maven + eclipse + xdoclet. When I run maven eclipse, I want to add in the eclipse project source folder list the location of xdoclet generated files (/target/xdoclet/ejbdoclet). How I can do that ? Kind regards, Christophe - To unsubscribe, e-mail: [EMAIL PROTECTED] For
RE: Xdoclet Eclipse
-Original Message- From: Peter Bright [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 19, 2004 12:14 PM To: 'Maven Users List' Subject: RE: Xdoclet Eclipse Without some kind of defined (and widely used!) mechanism for source-modifying plugins to do their thing, it's not clear how they have any real choice in the matter. Does there exist a better way that works right now? I agree with Vicent that pre/post Goals should be not used by plugins. At the moment common pratice is to have a maven.xml file with something like: project preGoal name=java:compile attainGoal name=javacc/ /preGoal /project in it and unfortunatly plugins like eclipse, javadocs etc. are not seeing yet that there are seeing that some java sources were generated We have dissussed this issue sometime ago and if I remember we were close to agreeing that we should add to POM a tag generatedSourceDirectory which can be used by all plugins. Later on we can even think about adding other tags like webSourceDirectory or codeGenerator (e.g codeGeneratorjavacc/codeGenerator or codeGeneratorxdoclet/codeGenerator) etc once we will be able disovered some common patters and generalize them. In an case no change in POM structure is planned for 1.0 release. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Xdoclet Eclipse
I don't really see how it is a solution. Perhaps I'm misunderstanding, but if I have to edit _my_ maven.xml to call the src.set-affecting goal then it seems to me that I'm doing the Eclipse plugin's work for it. If the Eclipse plugin depends on the src.set containing any generated source then surely it's the Eclipse plugin's responsibility (not mine) to do that generation. My responsibility should begin and end with simply saying I want to use these source-generating plugins. I should not have to care about calling the actual source-generating goals. I understand the downside to this--it requires reasonably extensive changes (I imagine it needs a registration mechanism akin to that used already for reports and such)--but in the absence of it, it's not clear how your proagmatic solution represents any clear benefits over source-generating plugins having their own preGoals. -Original Message- From: Kristopher Brown [mailto:[EMAIL PROTECTED] Sent: 19 May 2004 11:38 To: Maven Users List Subject: RE: Xdoclet Eclipse The last paragraph of my email suggested just that (a pragmatic solution): So for the eclipse plugin to work in the short term: 1. it needs to utilise the maven.compile.src.set rather than pom.build.sourceDirectory - this is a similar issue to what people have been discussing re the javadoc plugin. 2. the plugins need to interact somewhat to ensure that the src set has been populated with the generated src.set. This can be done by adding a custom preGoal in your maven.xml file for eclipse to call java:compile, or you could isolate the src.set affecting goal in xdoclet and call that goal instead. There are numerous entries in JIRA proposing fixes to the eclipse plugin that have not been committed due to the patch becoming out of date. It needs someone to step up and just get it all in and working. Kris. -Original Message- From: Peter Bright [mailto:[EMAIL PROTECTED] Sent: 19 May 2004 11:14 To: 'Maven Users List' Subject: RE: Xdoclet Eclipse Without some kind of defined (and widely used!) mechanism for source-modifying plugins to do their thing, it's not clear how they have any real choice in the matter. Does there exist a better way that works right now? -Original Message- From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: 19 May 2004 11:15 To: 'Maven Users List' Subject: RE: Xdoclet Eclipse slightly OT My view is that it's a bad practice (anti-pattern) for a plugin to use preGoal/postGoal. Plugins should provide their own goals, possibly wrapping existing goals. /slightly OT -Vincent -Original Message- From: Kristopher Brown [mailto:[EMAIL PROTECTED] Sent: 19 May 2004 12:06 To: Maven Users List Subject: RE: Xdoclet Eclipse You can't easily. It's a general problem with plugins that affect the compile set, i.e. generation plugins such as antlr, castor etc, and plugins that should utilise the compile set, e.g. java:compile, javadoc, and ide plugins. Personally I think it should all be addressed in the same way across all the plugins of this nature - there are a few variations and different people have done it different ways. At the moment, most generation plugins include a preGoal for java:compile in plugin.jelly to ensure they are called before the compile occurs. java:compile is just one goal that requires the generation goals to have occurred (or at least the part that adds the generation path to the src set), and people have solved their plugin for this case as its typically the most used. javadoc, eclipse et al. need this modification to src.set to have occurred for them too. One easy way to ensure that this has occurred is to perform java:compile as a preGoal to the goal you are using eclipse/javadoc. This does more work then is needed, but it would ensure that any generation modification have occured. Another way would be for the affecting plugins to be aware of all projects that utilise the src.set and add a preGoal to them, but this would get bloated very quickly. There seems to be something missing in all of this though, a way in which a plugin can say that is a src.set affecting plugin and a way in which a plugin can say it's a src.set utilising plugin. Then all the utilising projects would have to do is iterate down the list of affecting plugins and call their src.set modifying goal, then do what they need. I think this is similar to the way in which the reports work for site generation, i.e. they register themselves, and site calls them back as and when needed. This would be a fairly huge undertaking for someone to sort out though. So for
RE: dependencies
I am not sure if I understad you you will have (for version 1.0) project groupIdABC/groupId artifactIdABC/artifactId version1.0/version dependencies dependency groupIdXXX/groupId artifactIdXXX/artifactId version1.0/version /dependency /dependencies /project and (for version 2.0) project groupIdABC/groupId artifactIdABC/artifactId version2.0/version dependencies dependency groupIdXXX/groupId artifactIdXXX/artifactId version1.5/version /dependency dependency groupIdYYY/groupId artifactIdYYY/artifactId version2.0/version /dependency /dependencies /project Michal -Original Message- From: Manuel Darveau [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 18, 2004 10:07 PM To: [EMAIL PROTECTED] Subject: dependencies Hi! I probably have missed something somewhere but dont dependencies should be by project-version instead of only by project? I mean, is the project ABC-1.0 could have a dependency on XXX-1.0 and ABC-2.0 a dependency on XXX-1.5 and YYY-2.0. How does the build system handle this? Suppose that I tag my version on CVS with VERSION_M_m. I can have an old version tagged VERSION_1_0 and newer one tagged VERSION_2_0. If I ask to build a project with the CVS tag VERSION_1_0, does maven checkout the project.xml tagged as VERSION_1_0 and resolve dependencies with that version (1.0) of the project.xml? Since version 1.0 and 2.0 does not have the same depdendencies, it make a big difference on the build. I may be completely off the track (I am reading maven doc for 2 days) but please bring me back in the good direction ;-) Thank you Manuel Darveau __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ - 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]
Maven with CruiseControl
I'm getting some very odd behaviour running Maven from CC.
It seems that every other build, my ${user.home}/build.properties file
is not being
read, so my build fails, thus 50% of them seem to fail all the time.
Is there any reason this file would not get read?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
extend javadoc's sourceset
Hi all, I'm generating some .java files form a .wsdl definition. These .java files are not kept in the src folder but rather in target/wsdl/src/. As a result, the javadoc report complains about some files not being present. I had a look at the plugin.jelly file from the maven-javadoc-plugin and it uses javadoc:check-needed to set the sourceset. Is there a possibility to add another src directory to this sourceset? Thanks, Dominik -- Dominik Dahlem [EMAIL PROTECTED] --- Trinity College Dublin Department of Computer Science, Dublin 2, Ireland fax: (+353) 1-677 2204 www: http://www.cs.tcd.ie/Dominik.Dahlem/ --- signature.asc Description: This is a digitally signed message part
Re: extend javadoc's sourceset
Sorry for spamming. I've just seen that this issue has been posted already. I should research better before posting. Dominik On Wed, 2004-05-19 at 12:37, Dominik Dahlem wrote: Hi all, I'm generating some .java files form a .wsdl definition. These .java files are not kept in the src folder but rather in target/wsdl/src/. As a result, the javadoc report complains about some files not being present. I had a look at the plugin.jelly file from the maven-javadoc-plugin and it uses javadoc:check-needed to set the sourceset. Is there a possibility to add another src directory to this sourceset? Thanks, Dominik -- Dominik Dahlem [EMAIL PROTECTED] --- Trinity College Dublin Department of Computer Science, Dublin 2, Ireland fax: (+353) 1-677 2204 www: http://www.cs.tcd.ie/Dominik.Dahlem/ --- signature.asc Description: This is a digitally signed message part
RE: 1 Project, Multiple Atrifacts
Everything what can be done with ant can be done with maven. In this case you have to by pass the maven plugin which generates jar and write your own script in maven.xml file. But this is something we discourage. Subprojects option is much simpler and cleaner and recommended. -Original Message- From: David R Robison [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 19, 2004 1:42 PM To: Maven Users List; [EMAIL PROTECTED] Subject: 1 Project, Multiple Atrifacts Is there a way to set up a project that produces 2 jars without having to setup sub projects? Thanks, David Robison - 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]
1 Project, Multiple Atrifacts
Is there a way to set up a project that produces 2 jars without having to setup sub projects? Thanks, David Robison - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Xdoclet Eclipse
Hi Martin, In the project.properties, I set maven.eclipse.classpath.include=target/xdoclet/ejbdoclet I'm using the rc2, I check the jelly script and it seems this variable is used. Maybe it is something wrong in my maven config because it doesn't work. I had some strange warnings. Do you have an idea why (I'm a newbie :-)) Here is the result from maven eclipse Tag library requested that is not present: 'cactus' in plugin: 'maven-eclipse-plugin-1.6' cactus:dependency-handle/cactus:dependency-handlebuild:start: eclipse:generate-project: [echo] Creating C:\JavaProjects\badgebud-2005/.project ... eclipse:generate-classpath: [echo] Creating C:\JavaProjects\badgebud-2005/.classpath ... Plugin 'cactus-maven' in project 'Badgebud' is not available [echo] Setting default output directory to target\classes eclipse: [echo] Now refresh your project in Eclipse (right click on the project and select Refresh) BUILD SUCCESSFUL Total time: 2 seconds Finished at: Wed May 19 14:13:41 CEST 2004 -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Wed 5/19/2004 12:59 PM To: Maven Users List Cc: Subject:Re: Xdoclet Eclipse Just add maven.eclipse.classpath.include=path to source, so in your case target/xdoclet/ejbdoclet To have it mapped within eclipse (you need to use rc2 for this btw) Mvgr, Martin On Wed, 2004-05-19 at 11:34, LOMBART Christophe wrote: Hi All, I'm using Maven + eclipse + xdoclet. When I run maven eclipse, I want to add in the eclipse project source folder list the location of xdoclet generated files (/target/xdoclet/ejbdoclet). How I can do that ? Kind regards, Christophe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mvgr, Martin - 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: Xdoclet Eclipse
Ignore the warning, it is just a leftover from cactus integration in the eclipse plugin (if you want the cactus plugin you need to download it through the cactus project, but if you don't use cactus, you don't have to do that). Btw I assumed the target directory you described are actually java source files and not class files. The directory should turn up in Eclipse in project properties/build path/source Mvgr, Martin On Wed, 2004-05-19 at 14:25, LOMBART Christophe wrote: Hi Martin, In the project.properties, I set maven.eclipse.classpath.include=target/xdoclet/ejbdoclet I'm using the rc2, I check the jelly script and it seems this variable is used. Maybe it is something wrong in my maven config because it doesn't work. I had some strange warnings. Do you have an idea why (I'm a newbie :-)) Here is the result from maven eclipse Tag library requested that is not present: 'cactus' in plugin: 'maven-eclipse-plugin-1.6' cactus:dependency-handle/cactus:dependency-handlebuild:start: eclipse:generate-project: [echo] Creating C:\JavaProjects\badgebud-2005/.project ... eclipse:generate-classpath: [echo] Creating C:\JavaProjects\badgebud-2005/.classpath ... Plugin 'cactus-maven' in project 'Badgebud' is not available [echo] Setting default output directory to target\classes eclipse: [echo] Now refresh your project in Eclipse (right click on the project and select Refresh) BUILD SUCCESSFUL Total time: 2 seconds Finished at: Wed May 19 14:13:41 CEST 2004 -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Wed 5/19/2004 12:59 PM To: Maven Users List Cc: Subject: Re: Xdoclet Eclipse Just add maven.eclipse.classpath.include=path to source, so in your case target/xdoclet/ejbdoclet To have it mapped within eclipse (you need to use rc2 for this btw) Mvgr, Martin On Wed, 2004-05-19 at 11:34, LOMBART Christophe wrote: Hi All, I'm using Maven + eclipse + xdoclet. When I run maven eclipse, I want to add in the eclipse project source folder list the location of xdoclet generated files (/target/xdoclet/ejbdoclet). How I can do that ? Kind regards, Christophe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mvgr, Martin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Xdoclet Eclipse
Also, the maven.eclipse.classpath.include is only used if there is a test directory. -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: 19 May 2004 13:40 To: Maven Users List Subject: RE: Xdoclet Eclipse Ignore the warning, it is just a leftover from cactus integration in the eclipse plugin (if you want the cactus plugin you need to download it through the cactus project, but if you don't use cactus, you don't have to do that). Btw I assumed the target directory you described are actually java source files and not class files. The directory should turn up in Eclipse in project properties/build path/source Mvgr, Martin On Wed, 2004-05-19 at 14:25, LOMBART Christophe wrote: Hi Martin, In the project.properties, I set maven.eclipse.classpath.include=target/xdoclet/ejbdoclet I'm using the rc2, I check the jelly script and it seems this variable is used. Maybe it is something wrong in my maven config because it doesn't work. I had some strange warnings. Do you have an idea why (I'm a newbie :-)) Here is the result from maven eclipse Tag library requested that is not present: 'cactus' in plugin: 'maven-eclipse-plugin-1.6' cactus:dependency-handle/cactus:dependency-handlebuild:start: eclipse:generate-project: [echo] Creating C:\JavaProjects\badgebud-2005/.project ... eclipse:generate-classpath: [echo] Creating C:\JavaProjects\badgebud-2005/.classpath ... Plugin 'cactus-maven' in project 'Badgebud' is not available [echo] Setting default output directory to target\classes eclipse: [echo] Now refresh your project in Eclipse (right click on the project and select Refresh) BUILD SUCCESSFUL Total time: 2 seconds Finished at: Wed May 19 14:13:41 CEST 2004 -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Wed 5/19/2004 12:59 PM To: Maven Users List Cc: Subject:Re: Xdoclet Eclipse Just add maven.eclipse.classpath.include=path to source, so in your case target/xdoclet/ejbdoclet To have it mapped within eclipse (you need to use rc2 for this btw) Mvgr, Martin On Wed, 2004-05-19 at 11:34, LOMBART Christophe wrote: Hi All, I'm using Maven + eclipse + xdoclet. When I run maven eclipse, I want to add in the eclipse project source folder list the location of xdoclet generated files (/target/xdoclet/ejbdoclet). How I can do that ? Kind regards, Christophe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mvgr, Martin - 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: Xdoclet Eclipse
Ok That works ! Thanks to all - Great experience in this maven user list. Christophe -Original Message- From: Kristopher Brown [mailto:[EMAIL PROTECTED] Sent: Wed 5/19/2004 2:44 PM To: Maven Users List Cc: Subject:RE: Xdoclet Eclipse Also, the maven.eclipse.classpath.include is only used if there is a test directory. -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: 19 May 2004 13:40 To: Maven Users List Subject: RE: Xdoclet Eclipse Ignore the warning, it is just a leftover from cactus integration in the eclipse plugin (if you want the cactus plugin you need to download it through the cactus project, but if you don't use cactus, you don't have to do that). Btw I assumed the target directory you described are actually java source files and not class files. The directory should turn up in Eclipse in project properties/build path/source Mvgr, Martin On Wed, 2004-05-19 at 14:25, LOMBART Christophe wrote: Hi Martin, In the project.properties, I set maven.eclipse.classpath.include=target/xdoclet/ejbdoclet I'm using the rc2, I check the jelly script and it seems this variable is used. Maybe it is something wrong in my maven config because it doesn't work. I had some strange warnings. Do you have an idea why (I'm a newbie :-)) Here is the result from maven eclipse Tag library requested that is not present: 'cactus' in plugin: 'maven-eclipse-plugin-1.6' cactus:dependency-handle/cactus:dependency-handlebuild:start: eclipse:generate-project: [echo] Creating C:\JavaProjects\badgebud-2005/.project ... eclipse:generate-classpath: [echo] Creating C:\JavaProjects\badgebud-2005/.classpath ... Plugin 'cactus-maven' in project 'Badgebud' is not available [echo] Setting default output directory to target\classes eclipse: [echo] Now refresh your project in Eclipse (right click on the project and select Refresh) BUILD SUCCESSFUL Total time: 2 seconds Finished at: Wed May 19 14:13:41 CEST 2004 -Original Message- From: Martin van den Bemt [mailto:[EMAIL PROTECTED] Sent: Wed 5/19/2004 12:59 PM To: Maven Users List Cc: Subject:Re: Xdoclet Eclipse Just add maven.eclipse.classpath.include=path to source, so in your case target/xdoclet/ejbdoclet To have it mapped within eclipse (you need to use rc2 for this btw) Mvgr, Martin On Wed, 2004-05-19 at 11:34, LOMBART Christophe wrote: Hi All, I'm using Maven + eclipse + xdoclet. When I run maven eclipse, I want to add in the eclipse project source folder list the location of xdoclet generated files (/target/xdoclet/ejbdoclet). How I can do that ? Kind regards, Christophe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Mvgr, Martin - 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: dependencies
Yes, that's it, but I dont want to maintain 2 project.xml files. The version 1.0 would be tagged in CVS as VERSION_1_0 and the second one as VERSION_2_0. Now, if I have the 2.0 version locally and I want to build the version 1.0. I think I can use the scm:perform-release goal to perform this automatically. Can you confirm that maven will: 1- Checkout me project with tag VERSION_1_0 2- Read the 1.0 project.xml (just checked out) 3- Compile using 1.0 dependencies (XXX-1.0 only) Thank you Manuel P.S.: I know I could try all this and find answer, but I'm still trying to get something out of the scm:perform-release goal (see other post). --- Maczka Michal [EMAIL PROTECTED] wrote: I am not sure if I understad you you will have (for version 1.0) project groupIdABC/groupId artifactIdABC/artifactId version1.0/version dependencies dependency groupIdXXX/groupId artifactIdXXX/artifactId version1.0/version /dependency /dependencies /project and (for version 2.0) project groupIdABC/groupId artifactIdABC/artifactId version2.0/version dependencies dependency groupIdXXX/groupId artifactIdXXX/artifactId version1.5/version /dependency dependency groupIdYYY/groupId artifactIdYYY/artifactId version2.0/version /dependency /dependencies /project Michal -Original Message- From: Manuel Darveau [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 18, 2004 10:07 PM To: [EMAIL PROTECTED] Subject: dependencies Hi! I probably have missed something somewhere but dont dependencies should be by project-version instead of only by project? I mean, is the project ABC-1.0 could have a dependency on XXX-1.0 and ABC-2.0 a dependency on XXX-1.5 and YYY-2.0. How does the build system handle this? Suppose that I tag my version on CVS with VERSION_M_m. I can have an old version tagged VERSION_1_0 and newer one tagged VERSION_2_0. If I ask to build a project with the CVS tag VERSION_1_0, does maven checkout the project.xml tagged as VERSION_1_0 and resolve dependencies with that version (1.0) of the project.xml? Since version 1.0 and 2.0 does not have the same depdendencies, it make a big difference on the build. I may be completely off the track (I am reading maven doc for 2 days) but please bring me back in the good direction ;-) Thank you Manuel Darveau __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ - 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] __ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven and Integration Test
Hello, I've a problem with my integration tests. In my system we have both unit and integration test, the first type is perfectly handled by maven that execute them, and generates a report and a clover coverage too. Now I also have integration that are test to cover not the single class but a package and functional tests that must be run on the deployed system that are junit tests aswell. All that comes to my mind is to write and additional goal that must override the test source directory that must be lauched when functional tests wants to be executed, while for integration i think using them as unit test is the best approach even if they are not accounted in the clover report Anyone else ever had a problem like that? What's the solution you implemented? Max - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Integration Test
-Original Message- From: Amato Massimiliano (TLAB) [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 19, 2004 4:17 PM To: Maven Users List Subject: Maven and Integration Test Hello, I've a problem with my integration tests. In my system we have both unit and integration test, the first type is perfectly handled by maven that execute them, and generates a report and a clover coverage too. Now I also have integration that are test to cover not the single class but a package and functional tests that must be run on the deployed system that are junit tests aswell. All that comes to my mind is to write and additional goal that must override the test source directory that must be lauched when functional tests wants to be executed, while for integration i think using them as unit test is the best approach even if they are not accounted in the clover report Anyone else ever had a problem like that? What's the solution you implemented? Just put them to another project. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven and Integration Test
Hi, +) I have a couple of projects to build and run the JUNIT tests and in my EAR project I automatically deploy to BEA WebLogic to run my webtest. +) I currently reintegrate CLOVER to get the test coverage for the web regression tests Cheers, Siegfried Goeschl -Original Message- From: Amato Massimiliano (TLAB) [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 19. Mai 2004 16:17 To: Maven Users List Subject: Maven and Integration Test Hello, I've a problem with my integration tests. In my system we have both unit and integration test, the first type is perfectly handled by maven that execute them, and generates a report and a clover coverage too. Now I also have integration that are test to cover not the single class but a package and functional tests that must be run on the deployed system that are junit tests aswell. All that comes to my mind is to write and additional goal that must override the test source directory that must be lauched when functional tests wants to be executed, while for integration i think using them as unit test is the best approach even if they are not accounted in the clover report Anyone else ever had a problem like that? What's the solution you implemented? Max - 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: Maven and Integration Test
-Original Message- From: Ryan Sonnek [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 19, 2004 4:46 PM To: Maven Users List Subject: RE: Maven and Integration Test I was REALLY hoping to hear another solution to this problem. I'm running into the same thing, and would like to contain my project code (tests and all). I remember the cactus plugin introducing the concept of src/test-cactus for it's integration test code. Two options would be to reuse the current test plugin and change the source directory dynamically, or create another test plugin for integration tests that looks to something like src/test-integration. I think that creating a new test plugin might make the most sence in order to plug easier into project reports. How plausible is this? I think it's the bad idea. You can have quite a few types of integration tests. /src/test /test-cactus /test-stresstests /test-db and so on. It makes it difficult to maintain, difficult to select which type of tests you want to execute and difficult to integrate with plugins like idea, eclipse and so on. the layout: mainproject /src /test java (unit tests) mainproject-iu-catus /src /test java mainproject-iu-stresstests mainproject-iu-test-db is scalable and it will work out of the box with existing test plugin and is supported by idea/eclipse plugins. Michal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Source for new Plugin release
Hi Arnaud In the MAVEN-1_0-BRANCH... is there some code that was merged from the main trunk? Explanations. We're running here a maven 1.1 snapshot that was taken out of CVS about a month ago. Do you think there may be issues with the plugins if we take the latests running with this snapshot? Eric. Arnaud Heritier wrote: You must checkout the MAVEN-1_0-BRANCH for maven and the HEAD for maven-plugins. Arnaud. -Message d'origine- De : Eric Giguere [mailto:[EMAIL PROTECTED] Envoyé : mardi 18 mai 2004 15:28 À : Maven Users List Objet : Re: Source for new Plugin release Thx guys I had some problem with HEAD but on the maven project.. Didn't even check if there were branches in the plugins. Eric. Arnaud Heritier wrote: There's no branch in maven-plugins. You must get the HEAD one. Arnaud -Message d'origine- De : Eric Giguere [mailto:[EMAIL PROTECTED] Envoyé : lundi 17 mai 2004 16:04 À : Maven User List Objet : Source for new Plugin release Hi In which branch can we get the sources of all the newly released plugins from the apache CVS? thx Eric. - 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]
Missing resource in jcoverage plugin?
Sorry I think I saw this thread before but do not have a copy of the message. I am running jcoverage plugin 1.0.5. It has a dependency on xpp3 1.1.2a. When I run I get the exception: jcoverage 1.0.5 copyright (c)2003 jcoverage ltd. http://jcoverage.com/ jcoverage is licensed under the GNU General Public License jcoverage comes with ABSOLUTELY NO WARRANTY Generate report for /home/jm56692/maventest/target/jcoverage/coverage.xml file. OutputDir = /home/jm56692/maventest/target/docs/jcoverage org.xmlpull.v1.XmlPullParserException: caused by: org.xmlpull.v1.XmlPullParserEx ception: Ressource not found: /META-INF/services/org.xmlpull.v1.XmlPullParserFac tory at org.xmlpull.v1.XmlPullParserFactory.newInstance(XmlPullParserFactory. java:233) at org.xmlpull.v1.XmlPullParserFactory.newInstance(XmlPullParserFactory. java:200) at org.apache.maven.jcoveragereport.CoverageUnmarshaller.parse(CoverageU nmarshaller.java:35) at org.apache.maven.jcoveragereport.CoverageReportGenerator.execute(Cove rageReportGenerator.java:64) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces Seems that the xpp jar is in the CLASSPATH as it is executing methods from there, it just can't locate the resource. But if I jar -tvf the jar file I see the resource is in the jar. Only oddity I see is that it doesn't have the preceeding slash. i.e. exception says looking for /META-INF/... but jar shows META-INF/... Any ideas how to resolve this? Thanks, Jason - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Multiproject as a sub-project?
I'm seeing a lot of that PDF, seems to be a popular presentation. Slide 21 seems to indicate that a custom goal in the project's maven.xml file can use the reactor plugin to build all the sub-projects. However, I've read that the reactor plugin is old, and multiproject is new (hence preferred); did I misunderstand? The other question is, how do I get the sub-projects, if they are built in this way, to share a generated site? I have only one project site, for the main project, but I'd like all the sub-projects to be listed in the main one, and have links to them as well. Thanks, Mark Subject: Multiproject as a sub-project? From: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wed, 19 May 2004 11:32:22 +0200 Content-Type: text/plain; charset=iso-8859-1 take a look at this architecture which could solve your problems : http://www.pivolis.com/pdf/J2EE_projects_Maven_V1.1.pdf Nicolas, Mark Slater [EMAIL PROTECTED] 19/05/2004 11:23 Veuillez répondre à Maven Users List Pour : [EMAIL PROTECTED] cc : Objet : Multiproject as a sub-project? I'm setting up my first Maven project, and trying to plan for the future. The main project will be a collection of web applications (separate ones), so I want to configure the project so that the main project will build all the web apps (sub-projects), which in turn build all of their EJBs, WARs, EARs, JARs, etc. To do that, I figured the main project would use a multiproject, and each sub-project top level would as well. However, when I tried to set that up, the sub-project only generated overview information for the site documentation, it doesn't compile its code, or generate the reports based on the compiled code. If I run Maven in the sub-project, it does compile its code. I guess I'm surprised that the multiproject goal can't be recursive, because I see no reason as to why it couldn't/shouldn't be. Maybe I'm reading the docs wrong? Has anyone managed to set up this kind of project? Or do I just have to resign myself to building each sub-project separately, or making a custom goal or something like that? Thanks! Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiproject as a sub-project?
The other question is, how do I get the sub-projects, if they
are built in this way, to share a generated site? I have only
one project site, for the main project, but I'd like all the
sub-projects to be listed in the main one, and have links to
them as well.
I use beta 10, since it seems to be stable enough for me. It had a
semi-working version of multiproject. I also wanted to do the single site
thing, so I wrote a goal to build subprojects (as part of a custom plugin,
actually).
One thing needs explaining: in our setup, we put all subprojects into a
modules directory at the project root. Thus, to detect if a project has
subprojects, we just check for the existence of this directory (the
ant:available tag below). You'll need to customize that to you own layout
(or just eliminate the check altogether). The idea of the goal was to be
able to run a single goal that would work for projects both with and without
subprojects.
Also, due to some weirdness with reactor (at least in beta 10), the root
project must exclude itself from the reactor processing (i.e.
maven.multiproject.excludes=project.xml). This may be fixed by now.
Run this on the root project:
goal name=tag:site description=Site generation that detects
multiproject builds
ant:property name=maven.docs.dest value=${maven.build.dir}/docs/
ant:mkdir dir=${maven.docs.dest}/
ant:available file=modules type=dir property=hasModules/
j:if test=${hasModules}
!-- Do something .close. to what multiproject:site does, but
without
overwriting the index files. And without cleaning. --
maven:reactor
basedir=.
includes=**/project.xml
excludes=${maven.multiproject.excludes}
postProcessing=true
goals=site:generate
ignoreFailures=false
/
/j:if
--
attainGoal name=site:generate/
j:if test=${hasModules}
!-- copy each project over into ${maven.docs.dest} --
j:forEach var=reactorProject items=${reactorProjects}
j:set var=directory
value=${maven.docs.dest}/${reactorProject.artifactId}/
mkdir dir=${directory}/
j:set var=fromDir
value=${reactorProject.getPluginContext('maven-xdoc-plugin').getVariable('m
aven.docs.dest')}/
ant:move toDir=${directory}
fileset dir=${fromDir}/
/ant:move
/j:forEach
/j:if
/goal
The end result is that the subproject documentation is moved as
subdirectories within the root projects target/docs directory.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiproject as a sub-project?
Hi Mark, These slides are more than 1 year old. At that time, the multiproject was still very new and I was not using it. If I had to do it today, I would replace the reactor call by the multiproject call. However it does not change anything. Simply replace: reactor[...] by j:set var=goal value=whatever_goal/ attainGoal name=multiproject:goal/ For the second question, use the multiproject:site goal. Thanks -Vincent -Original Message- From: Mark Slater [mailto:[EMAIL PROTECTED] Sent: 19 May 2004 21:15 To: [EMAIL PROTECTED] Subject: Multiproject as a sub-project? I'm seeing a lot of that PDF, seems to be a popular presentation. Slide 21 seems to indicate that a custom goal in the project's maven.xml file can use the reactor plugin to build all the sub-projects. However, I've read that the reactor plugin is old, and multiproject is new (hence preferred); did I misunderstand? The other question is, how do I get the sub-projects, if they are built in this way, to share a generated site? I have only one project site, for the main project, but I'd like all the sub-projects to be listed in the main one, and have links to them as well. Thanks, Mark Subject: Multiproject as a sub-project? From: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wed, 19 May 2004 11:32:22 +0200 Content-Type: text/plain; charset=iso-8859-1 take a look at this architecture which could solve your problems : http://www.pivolis.com/pdf/J2EE_projects_Maven_V1.1.pdf Nicolas, Mark Slater [EMAIL PROTECTED] 19/05/2004 11:23 Veuillez répondre à Maven Users List Pour : [EMAIL PROTECTED] cc : Objet : Multiproject as a sub-project? I'm setting up my first Maven project, and trying to plan for the future. The main project will be a collection of web applications (separate ones), so I want to configure the project so that the main project will build all the web apps (sub-projects), which in turn build all of their EJBs, WARs, EARs, JARs, etc. To do that, I figured the main project would use a multiproject, and each sub-project top level would as well. However, when I tried to set that up, the sub-project only generated overview information for the site documentation, it doesn't compile its code, or generate the reports based on the compiled code. If I run Maven in the sub-project, it does compile its code. I guess I'm surprised that the multiproject goal can't be recursive, because I see no reason as to why it couldn't/shouldn't be. Maybe I'm reading the docs wrong? Has anyone managed to set up this kind of project? Or do I just have to resign myself to building each sub-project separately, or making a custom goal or something like that? Thanks! Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Multiproject as a sub-project?
Hi Mark, I've set up a project called doc which holds the site wide documentation and use multiproject:site to include the documentation of every project. I added these properties: maven.multiproject.basedir=.. maven.multiproject.includes=*/*/project.xml This is my directory layout: /doc/ /common/all/ /common/model/ /common/webapp/ /party/model/ /party/webapp/ and so on... Then I call multiproject:site in /doc/ and everything is generated If you want you can add navigation links to /doc/xdoc/navigation.xml menu name=Subprojects item name=Overview href=projects-overview.html/ item name=ONess Common href=multiproject/oness-common/index.html/ item name=ONess Common Model href=multiproject/oness-common-model/index.html/ and so on ... /menu Carlos Sanchez A Coruña, Spain Oness Project http://oness.sourceforge.net -Mensaje original- De: Vincent Massol [mailto:[EMAIL PROTECTED] Enviado el: miércoles, 19 de mayo de 2004 21:35 Para: 'Maven Users List' Asunto: RE: Multiproject as a sub-project? Hi Mark, These slides are more than 1 year old. At that time, the multiproject was still very new and I was not using it. If I had to do it today, I would replace the reactor call by the multiproject call. However it does not change anything. Simply replace: reactor[...] by j:set var=goal value=whatever_goal/ attainGoal name=multiproject:goal/ For the second question, use the multiproject:site goal. Thanks -Vincent -Original Message- From: Mark Slater [mailto:[EMAIL PROTECTED] Sent: 19 May 2004 21:15 To: [EMAIL PROTECTED] Subject: Multiproject as a sub-project? I'm seeing a lot of that PDF, seems to be a popular presentation. Slide 21 seems to indicate that a custom goal in the project's maven.xml file can use the reactor plugin to build all the sub-projects. However, I've read that the reactor plugin is old, and multiproject is new (hence preferred); did I misunderstand? The other question is, how do I get the sub-projects, if they are built in this way, to share a generated site? I have only one project site, for the main project, but I'd like all the sub-projects to be listed in the main one, and have links to them as well. Thanks, Mark Subject: Multiproject as a sub-project? From: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wed, 19 May 2004 11:32:22 +0200 Content-Type: text/plain; charset=iso-8859-1 take a look at this architecture which could solve your problems : http://www.pivolis.com/pdf/J2EE_projects_Maven_V1.1.pdf Nicolas, Mark Slater [EMAIL PROTECTED] 19/05/2004 11:23 Veuillez répondre à Maven Users List Pour : [EMAIL PROTECTED] cc : Objet : Multiproject as a sub-project? I'm setting up my first Maven project, and trying to plan for the future. The main project will be a collection of web applications (separate ones), so I want to configure the project so that the main project will build all the web apps (sub-projects), which in turn build all of their EJBs, WARs, EARs, JARs, etc. To do that, I figured the main project would use a multiproject, and each sub-project top level would as well. However, when I tried to set that up, the sub-project only generated overview information for the site documentation, it doesn't compile its code, or generate the reports based on the compiled code. If I run Maven in the sub-project, it does compile its code. I guess I'm surprised that the multiproject goal can't be recursive, because I see no reason as to why it couldn't/shouldn't be. Maybe I'm reading the docs wrong? Has anyone managed to set up this kind of project? Or do I just have to resign myself to building each sub-project separately, or making a custom goal or something like that? Thanks! Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Missing resource in jcoverage plugin?
I can't reproduce this error. Which version of maven and plugin do you have? Do you have particular dependencies in your project.xml? Emmanuel - Original Message - From: Morris, Jason [IT] [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 19, 2004 6:40 PM Subject: Missing resource in jcoverage plugin? Sorry I think I saw this thread before but do not have a copy of the message. I am running jcoverage plugin 1.0.5. It has a dependency on xpp3 1.1.2a. When I run I get the exception: jcoverage 1.0.5 copyright (c)2003 jcoverage ltd. http://jcoverage.com/ jcoverage is licensed under the GNU General Public License jcoverage comes with ABSOLUTELY NO WARRANTY Generate report for /home/jm56692/maventest/target/jcoverage/coverage.xml file. OutputDir = /home/jm56692/maventest/target/docs/jcoverage org.xmlpull.v1.XmlPullParserException: caused by: org.xmlpull.v1.XmlPullParserEx ception: Ressource not found: /META-INF/services/org.xmlpull.v1.XmlPullParserFac tory at org.xmlpull.v1.XmlPullParserFactory.newInstance(XmlPullParserFactory. java:233) at org.xmlpull.v1.XmlPullParserFactory.newInstance(XmlPullParserFactory. java:200) at org.apache.maven.jcoveragereport.CoverageUnmarshaller.parse(CoverageU nmarshaller.java:35) at org.apache.maven.jcoveragereport.CoverageReportGenerator.execute(Cove rageReportGenerator.java:64) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces Seems that the xpp jar is in the CLASSPATH as it is executing methods from there, it just can't locate the resource. But if I jar -tvf the jar file I see the resource is in the jar. Only oddity I see is that it doesn't have the preceeding slash. i.e. exception says looking for /META-INF/... but jar shows META-INF/... Any ideas how to resolve this? Thanks, Jason - 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: Maven with CruiseControl
Works for me... Might be environmental?
Is this on windows or unix?
IS CC running as the user you expect?
- Brett
-Original Message-
From: Nigel Magnay [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 19 May 2004 9:15 PM
To: [EMAIL PROTECTED]
Subject: Maven with CruiseControl
I'm getting some very odd behaviour running Maven from CC.
It seems that every other build, my
${user.home}/build.properties file is not being read, so my
build fails, thus 50% of them seem to fail all the time.
Is there any reason this file would not get read?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: javadoc on generated source directories
Alrighty, I found an existing issue on Jira regarding the use of maven.compile.src.set with Javadoc: http://jira.codehaus.org/browse/MPJAVADOC-5 So I've attached my 1.3 patch to that issue, and added a comment. For what it's worth, I'd be happy to generate a patch against 1.4 or 1.5 (the relevant sections being the same in both, I believe), but I have some questions about the newer plugins. If someone can answer these, I'll poop out a patch against 1.5. I think moving the fileset generation from the maven-javadoc-plugin:report tag to the check-needed tag is so that the contents of the fileset can be checked: if there's nothing in there, needed is set to false and javadoc will never even be called. Also, the fileset is passed out of the check-needed tag via the sourceSet refid. To support multiple source directories, I can change the check-needed tag so that it iterates across maven.compile.src.set, setting needed to be true if there are files in any of the filesets, and false otherwise. However, I don't think there's any way to preserve the functionality of passing the fileset out via sourceSet: can filesets be added to one another, so that the set of all files in all directories of maven.compile.src.set can be put into one fileset? If not, it means iterating across the directories of maven.compile.src.set twice: once to set the needed value, and again when the filesets are needed in the javadoc tag. Not pretty, but it should work. Can someone let me know if this sounds vaguely correct? If I have a basic understanding of this, I'll generate a patch against the 1.5 javadoc and put it up on jira. Denis On Wed, 2004-05-19 at 05:58, Arnaud Heritier wrote: I'm working on a release 1.5.1 for the javadoc which will be supplied in RC3. If you have a patch, post it on Jira and it will be applied. Arnaud -Message d'origine- De : Martin Skopp [mailto:[EMAIL PROTECTED] Envoyé : mercredi 19 mai 2004 09:18 À : Maven Users List Objet : Re: javadoc on generated source directories On Tue, 2004-05-18 at 07:33, Denis McLaughlin wrote: I had sent the email below asking for some information about modifying the maven javadoc plugin to properly support the maven.compile.src.set. I've generated a patch that seems to do the right thing: it's attached below. Comments quite welcome. Raise a JIRA issue, I wanna vote for it :-) Lets hope that it will be included in RC3, cu -- Martin Skopp Riege Software International GmbH Support: mailto:[EMAIL PROTECTED], Information: http://www.riege.com This email is intended to be viewed with a nonproportional font. - 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: External Library dependencies within a project
Thanks for the responses guys... I wouldn't say that I want to hide the dependencies, I just want an easy way of figuring out what a library depends on. It would be nice if the project.xml for a dependency was published along side the jar file (I notice there are poms directories on ibiblio but they don't seem to contain anything). I noticed that when you download a plug-in it heads off and downloads jar files it depends on... I was wondering if there could be something similar for the jar files... Cheers, Dan -Original Message- From: Amato Massimiliano (TLAB) [mailto:[EMAIL PROTECTED] Sent: Tuesday, 18 May 2004 4:58 PM To: Maven Users List Subject: RE: External Library dependencies within a project Hi Dan We decided not to solve your question since we believed that in the open source world that approach (not to hide dependencies) is widely accepted. Anyway if you really want to do it one solution would be to update the jar plugin so it accepts a jar.bunlde property that basically includes the hidden dependencies in the the common.jar file, if you are interested i can send you the piece of code that do it all. I am also thinking that this would be a great addition to the plugin that would come almost for free. I am stil using RC1 and i am waiting for 1.0 before migrating so it could be already included in the latest jar plugin release Hope this helps Max -Original Message- From: Washusen, Dan [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 18, 2004 3:48 AM To: [EMAIL PROTECTED] Subject: External Library dependencies within a project Morning all, I have a question regarding dependencies. If for example my project depends on a library called common and common depends on several other libraries (for example castor). Is there a nice/easy way of determining what libraries I should include in my project based on the dependencies of the common? Example: MyProject depends on CommonProject CommonProject depends on Blah.jar, Foo.jar and Bar.jar Can I easily include Blah.jar, Foo.jar and Bar.jar in MyProject (without having to declare them in MyProjects project.xml)? Hope that makes sense... -- Dan Washusen Developer Structured Search Sensis Pty Ltd www.sensis.com.au A leading Australian advertising, information and directories business. www.yellowpages.com.au www.whitepages.com.au www.citysearch.com.au www.whereis.com.au www.telstra.com.au This email and any attachments are intended only for the use of the recipient and may be confidential and/or legally privileged. Sensis Pty Ltd disclaims liability for any errors, omissions, viruses, loss and/or damage arising from using, opening or transmitting this email. If you are not the intended recipient you must not use, interfere with, disclose, copy or retain this email and you should notify the sender immediately by return email or by contacting Sensis Pty Ltd by telephone on [+61 3 9201 4888] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] www.sensis.com.au A leading Australian advertising, information and directories business. www.yellowpages.com.au www.whitepages.com.au www.citysearch.com.au www.whereis.com.au www.telstra.com.au This email and any attachments are intended only for the use of the recipient and may be confidential and/or legally privileged. Sensis Pty Ltd disclaims liability for any errors, omissions, viruses, loss and/or damage arising from using, opening or transmitting this email. If you are not the intended recipient you must not use, interfere with, disclose, copy or retain this email and you should notify the sender immediately by return email or by contacting Sensis Pty Ltd by telephone on [+61 3 9201 4888]
RE: External Library dependencies within a project
Dan, What you are talking about is transitive dependencies and its been on the TODO list for quite a while. I think it will start to materialise reasonably soon. I believe you can inspect the JAR manfiest Class-Path for a list of dependant JARs? - Brett -- Brett Porter Team Leader, Core Systems f2 network ~ everything essential -Original Message- From: Washusen, Dan [mailto:[EMAIL PROTECTED] Sent: Thursday, 20 May 2004 2:16 PM To: Maven Users List Subject: RE: External Library dependencies within a project Thanks for the responses guys... I wouldn't say that I want to hide the dependencies, I just want an easy way of figuring out what a library depends on. It would be nice if the project.xml for a dependency was published along side the jar file (I notice there are poms directories on ibiblio but they don't seem to contain anything). I noticed that when you download a plug-in it heads off and downloads jar files it depends on... I was wondering if there could be something similar for the jar files... Cheers, Dan
RE: External Library dependencies within a project
Excellent to hear that it will be materialising soon. It can make the initial setup of a project a little tedious without it... At any rate, Maven is an awesome step forward. Cheers, Dan Ps. Apologies, that sensis footer is bloody annoying! -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Thursday, 20 May 2004 2:25 PM To: 'Maven Users List' Subject: RE: External Library dependencies within a project Dan, What you are talking about is transitive dependencies and its been on the TODO list for quite a while. I think it will start to materialise reasonably soon. I believe you can inspect the JAR manfiest Class-Path for a list of dependant JARs? - Brett -- Brett Porter Team Leader, Core Systems f2 network ~ everything essential -Original Message- From: Washusen, Dan [mailto:[EMAIL PROTECTED] Sent: Thursday, 20 May 2004 2:16 PM To: Maven Users List Subject: RE: External Library dependencies within a project Thanks for the responses guys... I wouldn't say that I want to hide the dependencies, I just want an easy way of figuring out what a library depends on. It would be nice if the project.xml for a dependency was published along side the jar file (I notice there are poms directories on ibiblio but they don't seem to contain anything). I noticed that when you download a plug-in it heads off and downloads jar files it depends on... I was wondering if there could be something similar for the jar files... Cheers, Dan www.sensis.com.au A leading Australian advertising, information and directories business. www.yellowpages.com.au www.whitepages.com.au www.citysearch.com.au www.whereis.com.au www.telstra.com.au This email and any attachments are intended only for the use of the recipient and may be confidential and/or legally privileged. Sensis Pty Ltd disclaims liability for any errors, omissions, viruses, loss and/or damage arising from using, opening or transmitting this email. If you are not the intended recipient you must not use, interfere with, disclose, copy or retain this email and you should notify the sender immediately by return email or by contacting Sensis Pty Ltd by telephone on [+61 3 9201 4888]
