partial deployments
Hi, Sorry if this topic has been discussed before, but I couldn't find anything appropriate in the archives. I'm working with a fairly large project with about 60 generated artifacts. We're currently using CruiseControl to build hourly, and are now looking to expand this by having CC call a goal which will build, test using Cactus, and then deploy the artifacts to our internal repository for ourselves and other related groups. However, it seems to me that because the multiproject:deploy goal deploys the artifacts as it builds them, that it is susceptible to a partial deployment. If the deploy goal encounters a problem halfway through the deployment, then the repository will contain some new and some old artifacts, and this may lead to inconsistent results for other groups using those artifacts from the repository. One possible solution would be to have the deploy goal deploy to a temporary name, and then as the final step in the deployment, move all the artifacts with the temporary name to the final name. So, for example, if I want to deploy all my artifacts as 1.0-SNAPSHOT, I would instead deploy to 1.0-TEMP, and then, once the deploy has finished and all the artifacts deployed, rename all the 1.0-TEMP artifacts in the repository to 1.0-SNAPSHOT. Am I correct in thinking that this type of partial deployment can be a problem? Are there other methods to avoid this, or is there something I'm missing? Feedback quite welcome... Denis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem with modifying bundled plugins in rc3
Alrighty, thanks for the response. :) Denis On Sat, 2004-06-05 at 19:47, Brett Porter wrote: Thanks Denis. This is already open in JIRA - differing versions of installed plugins will not be available until after Maven 1.0 Denis McLaughlin wrote: Hi, I've begun to use Maven RC3, and have noticed a problem when trying to use a modified version of one of the plugins bundled with RC3. I've been discussing fixes to the javadoc plugin on the list. The patched javadoc plugin wasn't in RC3, but that's cool, I'm sure it'll be in the next release. However, because I need the new functionality, I had to patch the javadoc plugin that came with RC3. So I took a copy of the maven-javadoc-plugin-1.5.jar from MAVEN_HOME/plugins, unjarred it, modified the plugin.jelly file to get it to use maven.compile.src.set, rejarred it as maven-javadoc-plugin-1.5-dm1.jar and put it on my repository (maven.repo.remote). Then I went into my project and changed the project.xml to refer to my modified javadoc plugin. When I then ran a clean or a build, maven would install both the vanilla 1.5 plugin and my modified plugin in ~/.maven/plugins. However, when I actually executed the javadoc:generate goal, it used the goal as described by the vanilla 1.5 plugin, rather than using my modified plugin. This was in spite of my having made no mention in any project.xml files to the vanilla plugin, I was only specifying a dependency on my modified plugin. After playing with it, I found the following: - for any goal that was in the vanilla 1.5 plugin, but not in my modified plugin, the goal from the vanilla plugin would be used - for any goal that was in my modified plugin, but not in the vanilla 1.5 plugin, the goal from my modified plugin would be used - for any goal that was in both the vanilla 1.5 plugin and in my modified plugin, the goal from the vanilla plugin would be used To work around this problem, I deleted the vanilla 1.5 plugin from MAVEN_HOME/plugins: then only my modified plugin would be installed into ~/.maven, and the correct goal would be run. Anything I'm doing wrong? If this sounds like an unreported bug, I'll open a jira against it. Denis - 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
Oopsie, I spoke too soon. I found a small bug in the patched javadoc plugin. The needed check at line 101 (in version 1.42) should be testing for != true, rather than == null. I've opened MPJAVADOC-26 describing this problem and giving the (trivial) fix. http://jira.codehaus.org/browse/MPJAVADOC-26 Denis On Wed, 2004-05-26 at 01:54, Denis McLaughlin wrote: Hi Arnaud, Per my off-list email, your latest version of the patch looks fine. Thanks! Denis On Sat, 2004-05-22 at 13:59, Arnaud Heritier wrote: Hello Denis, I studied your patch and I modified the Javadoc plugin to allow the use of maven.compile.src.set if you want to test. Arnaud -Message d'origine- De : Arnaud Heritier [mailto:[EMAIL PROTECTED] Envoyé : jeudi 20 mai 2004 15:41 À : 'Maven Users List'; [EMAIL PROTECTED] Objet : RE: javadoc on generated source directories -Message d'origine- De : Denis McLaughlin [mailto:[EMAIL PROTECTED] Envoyé : jeudi 20 mai 2004 06:02 À : Maven Users List Objet : 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 yes So I've attached my 1.3 patch to that issue, and added a comment. thanks 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 will try to answer ;-) 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. All right. 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. Seems to be good. The problem is to not duplicate entries between pom.build.sourceDirectory and maven.compile.src.set 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. You can't have in ant a fileset with several directories. We can begin to test if it works. We will optimize it after. 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. This sounds correct. I'll test your patch as soon as possible. Arnaud 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
problem with modifying bundled plugins in rc3
Hi, I've begun to use Maven RC3, and have noticed a problem when trying to use a modified version of one of the plugins bundled with RC3. I've been discussing fixes to the javadoc plugin on the list. The patched javadoc plugin wasn't in RC3, but that's cool, I'm sure it'll be in the next release. However, because I need the new functionality, I had to patch the javadoc plugin that came with RC3. So I took a copy of the maven-javadoc-plugin-1.5.jar from MAVEN_HOME/plugins, unjarred it, modified the plugin.jelly file to get it to use maven.compile.src.set, rejarred it as maven-javadoc-plugin-1.5-dm1.jar and put it on my repository (maven.repo.remote). Then I went into my project and changed the project.xml to refer to my modified javadoc plugin. When I then ran a clean or a build, maven would install both the vanilla 1.5 plugin and my modified plugin in ~/.maven/plugins. However, when I actually executed the javadoc:generate goal, it used the goal as described by the vanilla 1.5 plugin, rather than using my modified plugin. This was in spite of my having made no mention in any project.xml files to the vanilla plugin, I was only specifying a dependency on my modified plugin. After playing with it, I found the following: - for any goal that was in the vanilla 1.5 plugin, but not in my modified plugin, the goal from the vanilla plugin would be used - for any goal that was in my modified plugin, but not in the vanilla 1.5 plugin, the goal from my modified plugin would be used - for any goal that was in both the vanilla 1.5 plugin and in my modified plugin, the goal from the vanilla plugin would be used To work around this problem, I deleted the vanilla 1.5 plugin from MAVEN_HOME/plugins: then only my modified plugin would be installed into ~/.maven, and the correct goal would be run. Anything I'm doing wrong? If this sounds like an unreported bug, I'll open a jira against it. Denis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: javadoc on generated source directories
Hi Arnaud, Thanks for doing this. I had a look at the patch (version 1.40 from CVS), and I have a couple questions. To my reading, your patch uses a maven.compile.src.set property to track which directories should be traversed when generating javadocs. However, I believe maven.compile.src.set is used in other plugins as a path refid, and the property and path refid name spaces seem to be distinct: I can change the value of the maven.compile.src.set path without changing the value of the maven.compile.src.set property. I think it would be a good idea to have the maven.compile.src.set self-adjusting: any time a goal is run that generates code someplace other than src/java, then that goal should add that directory to maven.compile.src.set. That way any subsequent goal that needs to operate on all code (generated or otherwise) can just iterate across the directories in maven.compile.src.set. I believe this technique is already being used in the antlr and castor plugins: both of these plugins add directories to the maven.compile.src.set path refid. In my original patch, I had created a maven.javadoc.src.set property based on the maven.compile.src.set path refid, and used that to generate the javadoc filesets: this way it would pick up any additional directories that other goals had added. I believe your patch does things a bit differently. In your patch, the user is expected to set a maven.compile.src.set property with all the directories that the javadoc plugin should traverse to generate the docs. (Sorry if my shallow maven knowledge has led me to misunderstand this.) I don't think using a maven.compile.src.set property value (as it is in your patch) provides the same benefits as the maven.compile.src.set path refid. Users are bound to miss something if we make them add all the appropriate paths to the project.properties file: it may not be obvious to the user which directory is holding the generated code, and the directory may change from release to release of the plugin. It would be possible to work around this problem by expecting plugins to append paths to the maven.compile.src.set property, but this would just duplicate existing functionality (as mentioned, antlr and castor are already appending paths to the path refid), and holding multiple paths is really what path refids were intended for, I think, since they take care of figuring out the path separator and so on. Is there some value to using the maven.compile.src.set property rather than the path refid? Denis On Mon, 2004-05-24 at 01:18, Arnaud Heritier wrote: It's done. I wrote a test case for maven.compile.src.set. It works only if maven.compile.src.set is manually setted in the project.properties. In CVS I commented tests for this. Arnaud. -Message d'origine- De : Dion Gillard [mailto:[EMAIL PROTECTED] Envoyé : dimanche 23 mai 2004 23:23 À : Maven Users List Objet : Re: javadoc on generated source directories How about coding a failing (at the moment) plugin test case that can be run on demand? On Sat, 22 May 2004 19:59:07 +0200, Arnaud Heritier [EMAIL PROTECTED] wrote: Hello Denis, I studied your patch and I modified the Javadoc plugin to allow the use of maven.compile.src.set if you want to test. Arnaud - 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
Hi Arnaud, Per my off-list email, your latest version of the patch looks fine. Thanks! Denis On Sat, 2004-05-22 at 13:59, Arnaud Heritier wrote: Hello Denis, I studied your patch and I modified the Javadoc plugin to allow the use of maven.compile.src.set if you want to test. Arnaud -Message d'origine- De : Arnaud Heritier [mailto:[EMAIL PROTECTED] Envoyé : jeudi 20 mai 2004 15:41 À : 'Maven Users List'; [EMAIL PROTECTED] Objet : RE: javadoc on generated source directories -Message d'origine- De : Denis McLaughlin [mailto:[EMAIL PROTECTED] Envoyé : jeudi 20 mai 2004 06:02 À : Maven Users List Objet : 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 yes So I've attached my 1.3 patch to that issue, and added a comment. thanks 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 will try to answer ;-) 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. All right. 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. Seems to be good. The problem is to not duplicate entries between pom.build.sourceDirectory and maven.compile.src.set 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. You can't have in ant a fileset with several directories. We can begin to test if it works. We will optimize it after. 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. This sounds correct. I'll test your patch as soon as possible. Arnaud 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] - 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
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: javadoc on generated source directories
Hi, 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. I looked at making a patch against 1.5, but the fileset generation was pushed into the check-needed tag between versions 1.3 and 1.4, and I'm unclear on how to preserve the function of the filescanner across multiple filesets. (refids based on the dir name maybe?) Plus it's nearly 1:30am and I wanna go to bed. :) Hope this is useful. Denis On Thu, 2004-05-13 at 20:42, [EMAIL PROTECTED] wrote: Denis McLaughlin [EMAIL PROTECTED] wrote on 14/05/2004 09:45:58 AM: Hi, We're generating some source into target/generate, and we'd like to run javadoc on it. Currently (RC1) javadoc is only run on the source in pom.build.sourceDirectory. Reading through the mailing list, I see that after this thread: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]m sgId=807588 the javadoc plugin was changed to use the maven.compile.src.set variable instead, and users could append additional directories to it to generate javadoc for those directories. However, this was changed between versions 1.15 and 1.16 of the javadoc plugin.jelly: http://cvs.apache.org/viewcvs.cgi/maven-plugins/javadoc/plugin.jelly?r1=text tr1=1.15r2=texttr2=1.16diff_format=u Yep, it looks like my addition of sourceModifications removed the src.set usage. I think the right thing would be to have the javadoc plugin iterate across the directories in maven.compile.src.set, generating a fileset tag for each directory with appropriate exclusions. Does this sound right? Yes. Unfortunately, my attempts to do this the j:forEach tag brought nothing but heartbreak and psoriasis. So, my questions: - should the javadoc plugin be using maven.compile.src.set rather than pom.build.sourceDirectory? Yes. - if not, how should non-src/java directories have their javadoc created? - if so, can someone point me at some (any!) documentation for the forEach tag? http://jakarta.apache.org/commons/jelly/tags.html I'm happy to help with this if you get stuck or just want another pair of eyes on it, as once it's done for javadoc, we can apply it across the other plugins too. -- 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]
javadoc on generated source directories
Hi, We're generating some source into target/generate, and we'd like to run javadoc on it. Currently (RC1) javadoc is only run on the source in pom.build.sourceDirectory. Reading through the mailing list, I see that after this thread: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]m sgId=807588 the javadoc plugin was changed to use the maven.compile.src.set variable instead, and users could append additional directories to it to generate javadoc for those directories. However, this was changed between versions 1.15 and 1.16 of the javadoc plugin.jelly: http://cvs.apache.org/viewcvs.cgi/maven-plugins/javadoc/plugin.jelly?r1=text tr1=1.15r2=texttr2=1.16diff_format=u I think the right thing would be to have the javadoc plugin iterate across the directories in maven.compile.src.set, generating a fileset tag for each directory with appropriate exclusions. Does this sound right? Unfortunately, my attempts to do this the j:forEach tag brought nothing but heartbreak and psoriasis. So, my questions: - should the javadoc plugin be using maven.compile.src.set rather than pom.build.sourceDirectory? - if not, how should non-src/java directories have their javadoc created? - if so, can someone point me at some (any!) documentation for the forEach tag? Many thanks... :) Denis
