RE: dist tooling
Well, I'm late Hervé answered before me. Of course you can improve the plugin which we should maybe rename to avoid confusion with end user maven plugin. A todo.md file is available to add RFE that needs a couple of days (my definition :p) . Idea was to not overwhelm Hervé (or any other maven dev). Thanks you for the IT settings. Regards, Eric - skygo PS: FYI the JDK version choice (on a feature point ) try with resource feature + new javadoc style. As a lecturer in HCI field, when you ask student to get java (oracle version) they found jdk 7, jdk 6 is shown as end of life (with security warning everywhere). Side effect is that, you play with the new features. (student later learn backward compatibility) -Message d'origine- De : Hervé BOUTEMY [mailto:herve.bout...@free.fr] Envoyé : jeudi 20 juin 2013 07:19 À : Maven Developers List Objet : Re: dist tooling this is not a plugin for end users, only for internal Maven team: and once it is scheduled daily on our Jenkins server, i don't expect us to run it on our personal machines so I don't think JDK7 nor Maven version requirements are a problem. ITs would be nice, yes, to be sure things are detected even when we fix errors actually reported Regards, Hervé Le mercredi 19 juin 2013 23:22:13 Robert Scholte a écrit : Hi, I noticed there are no IT's. It shouldn't be too hard to write that. I can make a setup for that in order to be able to execute some ITs Although most of us want to use the latest and greatest, I have my doubts about using JDK7 and M3.0.4 for compilation. Since our advice is to compile with lowest required versions, I think we should aim for JDK5 and M3.0, unless there's a very, very good reason not to. I see some other improvements, put I'll pick these up myself. Should be easy to verify once I've got the ITs running. Robert Op Wed, 19 Jun 2013 21:42:33 +0200 schreef Robert Scholte rfscho...@apache.org: I'd like to have a look at it too. Give me a couple of days. Robert Op Wed, 19 Jun 2013 00:11:55 +0200 schreef Hervé BOUTEMY herve.bout...@free.fr: Thanks to Eric, we now have a tool to check dist content And I just added it to our Jenkins instance, to build once a day: you can look at the result [1] I just had to remove the preview of site, since Firefox isn't available on the CI server (or not able to start in headless mode) Any feedback? Regards, Hervé [1] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/ ws/tar get/site/index.html --- -- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.1.0-beta-1
Hi Jason, Jason van Zyl wrote: Doesn't see to be a whole lot of activity around the 3.1.0-alpha-1 so I plan to cut the 3.1.0-beta-1 this weekend if there are no objections. Since all versions of M30x fail in their core competence to make reliable builds because it uses stale snapshots, it would be fine to have at least a properly working M31x. What I am talking about? See MNG-5207! Reported months ago, a proper IT test bit rots in JIRA and if you search through the archives of this list for the issue, then you'll notice that it has been reported more than once, with promises to look into it. And yes, I have verified that M31a still fails. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JavadocFixTool integration with Javadoc plugin?
See https://github.com/olamy/JavadocUpdaterTool I added a maven build and a mojo. IANAL so I don't know if we can integrate the source of JavadocFixTool.java in javadoc plugin ( https://github.com/olamy/JavadocUpdaterTool/blob/master/LICENSE ) 2013/6/20 sebb seb...@gmail.com: On 19 June 2013 22:40, Baptiste MATHUS bmat...@batmat.net wrote: Hi, I think the best way to track this is to file a JIRA ticket on http://jira.codehaus.org/browse/MJAVADOC Well OK, I can raise an enhancement request there too. Btw, we might be interested by https://github.com/AdoptOpenJDK/JavadocUpdaterTool/blob/master/src/main/java/JavadocFixTool.java That looks exactly like the file that was released by Oracle; anyone can pick up the tool packaged as a jar from the Oracle web-site. On it's own, it does not help. Cheers 2013/6/19 sebb seb...@gmail.com I expect you have all see the news about the Javadoc javascript bug. It's going to take a long time for everyone to update their Java installations to Java 1.7 u25. Likewise for builds that need to use other Java versions, tweaking poms so Java 7 is used for Javadocs whilst still maintaining compatibility is a non-trivial task. Is there any interest in releasing a quick-fix version of the javadoc plugin that automatically runs the tool after Javadoc completes? The fix code is in Java, and can easily be directly called from the plugin (no need to start a new process). The license looks friendly so long as the code is only used for Javadoc fixups, and changes are allowed, which is just as well - There are a couple of bugs in the tool as currently released. It does not close all the resources; and failure to close the input file means it cannot delete the original input file on Windows; that needs to be fixed as it would not make sense to keep the old faulty file (even if it is now called index.html.orig). I can provide details of the fixes, but a decent IDE will probably warn about them anyway. It would be a great service to the Java community if this could be fast-tracked. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JavadocFixTool integration with Javadoc plugin?
On 20 June 2013 12:15, Olivier Lamy ol...@apache.org wrote: See https://github.com/olamy/JavadocUpdaterTool I added a maven build and a mojo. IANAL so I don't know if we can integrate the source of JavadocFixTool.java in javadoc plugin ( https://github.com/olamy/JavadocUpdaterTool/blob/master/LICENSE ) As far as I can tell, so long as the code is only used for the intended purpose then it's OK. However, I don't think your plugin fixes all instances of bad javadoc; certainly the instructions only solve the problem for site builds. What about javadoc jars? The Maven javadoc jar has lots of goals that occur in different phases; the only way to be sure to fix all the issues is to always run the tool after running Javadoc. 2013/6/20 sebb seb...@gmail.com: On 19 June 2013 22:40, Baptiste MATHUS bmat...@batmat.net wrote: Hi, I think the best way to track this is to file a JIRA ticket on http://jira.codehaus.org/browse/MJAVADOC Well OK, I can raise an enhancement request there too. Btw, we might be interested by https://github.com/AdoptOpenJDK/JavadocUpdaterTool/blob/master/src/main/java/JavadocFixTool.java That looks exactly like the file that was released by Oracle; anyone can pick up the tool packaged as a jar from the Oracle web-site. On it's own, it does not help. Cheers 2013/6/19 sebb seb...@gmail.com I expect you have all see the news about the Javadoc javascript bug. It's going to take a long time for everyone to update their Java installations to Java 1.7 u25. Likewise for builds that need to use other Java versions, tweaking poms so Java 7 is used for Javadocs whilst still maintaining compatibility is a non-trivial task. Is there any interest in releasing a quick-fix version of the javadoc plugin that automatically runs the tool after Javadoc completes? The fix code is in Java, and can easily be directly called from the plugin (no need to start a new process). The license looks friendly so long as the code is only used for Javadoc fixups, and changes are allowed, which is just as well - There are a couple of bugs in the tool as currently released. It does not close all the resources; and failure to close the input file means it cannot delete the original input file on Windows; that needs to be fixed as it would not make sense to keep the old faulty file (even if it is now called index.html.orig). I can provide details of the fixes, but a decent IDE will probably warn about them anyway. It would be a great service to the Java community if this could be fast-tracked. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JavadocFixTool integration with Javadoc plugin?
FYI, I just sent an email on the jug-leaders ML to ask for clarification about the license aspect by Oracle. Let's hope this won't be dead letter. Cheers 2013/6/20 sebb seb...@gmail.com On 20 June 2013 12:15, Olivier Lamy ol...@apache.org wrote: See https://github.com/olamy/JavadocUpdaterTool I added a maven build and a mojo. IANAL so I don't know if we can integrate the source of JavadocFixTool.java in javadoc plugin ( https://github.com/olamy/JavadocUpdaterTool/blob/master/LICENSE ) As far as I can tell, so long as the code is only used for the intended purpose then it's OK. However, I don't think your plugin fixes all instances of bad javadoc; certainly the instructions only solve the problem for site builds. What about javadoc jars? The Maven javadoc jar has lots of goals that occur in different phases; the only way to be sure to fix all the issues is to always run the tool after running Javadoc. 2013/6/20 sebb seb...@gmail.com: On 19 June 2013 22:40, Baptiste MATHUS bmat...@batmat.net wrote: Hi, I think the best way to track this is to file a JIRA ticket on http://jira.codehaus.org/browse/MJAVADOC Well OK, I can raise an enhancement request there too. Btw, we might be interested by https://github.com/AdoptOpenJDK/JavadocUpdaterTool/blob/master/src/main/java/JavadocFixTool.java That looks exactly like the file that was released by Oracle; anyone can pick up the tool packaged as a jar from the Oracle web-site. On it's own, it does not help. Cheers 2013/6/19 sebb seb...@gmail.com I expect you have all see the news about the Javadoc javascript bug. It's going to take a long time for everyone to update their Java installations to Java 1.7 u25. Likewise for builds that need to use other Java versions, tweaking poms so Java 7 is used for Javadocs whilst still maintaining compatibility is a non-trivial task. Is there any interest in releasing a quick-fix version of the javadoc plugin that automatically runs the tool after Javadoc completes? The fix code is in Java, and can easily be directly called from the plugin (no need to start a new process). The license looks friendly so long as the code is only used for Javadoc fixups, and changes are allowed, which is just as well - There are a couple of bugs in the tool as currently released. It does not close all the resources; and failure to close the input file means it cannot delete the original input file on Windows; that needs to be fixed as it would not make sense to keep the old faulty file (even if it is now called index.html.orig). I can provide details of the fixes, but a decent IDE will probably warn about them anyway. It would be a great service to the Java community if this could be fast-tracked. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: JavadocFixTool integration with Javadoc plugin?
On 20 June 2013 13:08, sebb seb...@gmail.com wrote: On 20 June 2013 12:15, Olivier Lamy ol...@apache.org wrote: See https://github.com/olamy/JavadocUpdaterTool I added a maven build and a mojo. IANAL so I don't know if we can integrate the source of JavadocFixTool.java in javadoc plugin ( https://github.com/olamy/JavadocUpdaterTool/blob/master/LICENSE ) As far as I can tell, so long as the code is only used for the intended purpose then it's OK. However, if you do change it, it would make sense to update the comments and the version string. There are a couple of resources that are not closed properly; one such means the original file is not deleted on Windows. However, I don't think your plugin fixes all instances of bad javadoc; certainly the instructions only solve the problem for site builds. What about javadoc jars? The Maven javadoc jar has lots of goals that occur in different phases; the only way to be sure to fix all the issues is to always run the tool after running Javadoc. 2013/6/20 sebb seb...@gmail.com: On 19 June 2013 22:40, Baptiste MATHUS bmat...@batmat.net wrote: Hi, I think the best way to track this is to file a JIRA ticket on http://jira.codehaus.org/browse/MJAVADOC Well OK, I can raise an enhancement request there too. Btw, we might be interested by https://github.com/AdoptOpenJDK/JavadocUpdaterTool/blob/master/src/main/java/JavadocFixTool.java That looks exactly like the file that was released by Oracle; anyone can pick up the tool packaged as a jar from the Oracle web-site. On it's own, it does not help. Cheers 2013/6/19 sebb seb...@gmail.com I expect you have all see the news about the Javadoc javascript bug. It's going to take a long time for everyone to update their Java installations to Java 1.7 u25. Likewise for builds that need to use other Java versions, tweaking poms so Java 7 is used for Javadocs whilst still maintaining compatibility is a non-trivial task. Is there any interest in releasing a quick-fix version of the javadoc plugin that automatically runs the tool after Javadoc completes? The fix code is in Java, and can easily be directly called from the plugin (no need to start a new process). The license looks friendly so long as the code is only used for Javadoc fixups, and changes are allowed, which is just as well - There are a couple of bugs in the tool as currently released. It does not close all the resources; and failure to close the input file means it cannot delete the original input file on Windows; that needs to be fixed as it would not make sense to keep the old faulty file (even if it is now called index.html.orig). I can provide details of the fixes, but a decent IDE will probably warn about them anyway. It would be a great service to the Java community if this could be fast-tracked. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JavadocFixTool integration with Javadoc plugin?
2013/6/20 sebb seb...@gmail.com: On 20 June 2013 12:15, Olivier Lamy ol...@apache.org wrote: See https://github.com/olamy/JavadocUpdaterTool I added a maven build and a mojo. IANAL so I don't know if we can integrate the source of JavadocFixTool.java in javadoc plugin ( https://github.com/olamy/JavadocUpdaterTool/blob/master/LICENSE ) As far as I can tell, so long as the code is only used for the intended purpose then it's OK. However, I don't think your plugin fixes all instances of bad javadoc; certainly the instructions only solve the problem for site builds. What about javadoc jars? it simply depends the phase you bind the plugin (per default it's not bind to any phase) The Maven javadoc jar has lots of goals that occur in different phases; the only way to be sure to fix all the issues is to always run the tool after running Javadoc. 2013/6/20 sebb seb...@gmail.com: On 19 June 2013 22:40, Baptiste MATHUS bmat...@batmat.net wrote: Hi, I think the best way to track this is to file a JIRA ticket on http://jira.codehaus.org/browse/MJAVADOC Well OK, I can raise an enhancement request there too. Btw, we might be interested by https://github.com/AdoptOpenJDK/JavadocUpdaterTool/blob/master/src/main/java/JavadocFixTool.java That looks exactly like the file that was released by Oracle; anyone can pick up the tool packaged as a jar from the Oracle web-site. On it's own, it does not help. Cheers 2013/6/19 sebb seb...@gmail.com I expect you have all see the news about the Javadoc javascript bug. It's going to take a long time for everyone to update their Java installations to Java 1.7 u25. Likewise for builds that need to use other Java versions, tweaking poms so Java 7 is used for Javadocs whilst still maintaining compatibility is a non-trivial task. Is there any interest in releasing a quick-fix version of the javadoc plugin that automatically runs the tool after Javadoc completes? The fix code is in Java, and can easily be directly called from the plugin (no need to start a new process). The license looks friendly so long as the code is only used for Javadoc fixups, and changes are allowed, which is just as well - There are a couple of bugs in the tool as currently released. It does not close all the resources; and failure to close the input file means it cannot delete the original input file on Windows; that needs to be fixed as it would not make sense to keep the old faulty file (even if it is now called index.html.orig). I can provide details of the fixes, but a decent IDE will probably warn about them anyway. It would be a great service to the Java community if this could be fast-tracked. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JavadocFixTool integration with Javadoc plugin?
On 20 June 2013 13:21, Olivier Lamy ol...@apache.org wrote: 2013/6/20 sebb seb...@gmail.com: On 20 June 2013 12:15, Olivier Lamy ol...@apache.org wrote: See https://github.com/olamy/JavadocUpdaterTool I added a maven build and a mojo. IANAL so I don't know if we can integrate the source of JavadocFixTool.java in javadoc plugin ( https://github.com/olamy/JavadocUpdaterTool/blob/master/LICENSE ) As far as I can tell, so long as the code is only used for the intended purpose then it's OK. However, I don't think your plugin fixes all instances of bad javadoc; certainly the instructions only solve the problem for site builds. What about javadoc jars? it simply depends the phase you bind the plugin (per default it's not bind to any phase) But the point is that a separate plugin will have to be separately configured, probably several times. That's not a trivial job, and it's easy to overlook phases and locations of Javadoc. Whereas if the Javadoc plugin fixes any issues before it completes, the end user merely has to ensure they are using the new Javadoc plugin. That's much easier to do. The Maven javadoc jar has lots of goals that occur in different phases; the only way to be sure to fix all the issues is to always run the tool after running Javadoc. 2013/6/20 sebb seb...@gmail.com: On 19 June 2013 22:40, Baptiste MATHUS bmat...@batmat.net wrote: Hi, I think the best way to track this is to file a JIRA ticket on http://jira.codehaus.org/browse/MJAVADOC Well OK, I can raise an enhancement request there too. Btw, we might be interested by https://github.com/AdoptOpenJDK/JavadocUpdaterTool/blob/master/src/main/java/JavadocFixTool.java That looks exactly like the file that was released by Oracle; anyone can pick up the tool packaged as a jar from the Oracle web-site. On it's own, it does not help. Cheers 2013/6/19 sebb seb...@gmail.com I expect you have all see the news about the Javadoc javascript bug. It's going to take a long time for everyone to update their Java installations to Java 1.7 u25. Likewise for builds that need to use other Java versions, tweaking poms so Java 7 is used for Javadocs whilst still maintaining compatibility is a non-trivial task. Is there any interest in releasing a quick-fix version of the javadoc plugin that automatically runs the tool after Javadoc completes? The fix code is in Java, and can easily be directly called from the plugin (no need to start a new process). The license looks friendly so long as the code is only used for Javadoc fixups, and changes are allowed, which is just as well - There are a couple of bugs in the tool as currently released. It does not close all the resources; and failure to close the input file means it cannot delete the original input file on Windows; that needs to be fixed as it would not make sense to keep the old faulty file (even if it is now called index.html.orig). I can provide details of the fixes, but a decent IDE will probably warn about them anyway. It would be a great service to the Java community if this could be fast-tracked. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JavadocFixTool integration with Javadoc plugin?
I'm +1 with you on the fact that this code should be included after each javadoc goal. I guess they agree too, but I *think* this is just something Olivier and the Maven PMC cannot afford integrating this code into the maven-javadoc-plugin without being 200% sure this isn't going to be a license infringement. This is their responsability not to drag the Apache foundation into such issues. Cheers 2013/6/20 sebb seb...@gmail.com On 20 June 2013 13:21, Olivier Lamy ol...@apache.org wrote: 2013/6/20 sebb seb...@gmail.com: On 20 June 2013 12:15, Olivier Lamy ol...@apache.org wrote: See https://github.com/olamy/JavadocUpdaterTool I added a maven build and a mojo. IANAL so I don't know if we can integrate the source of JavadocFixTool.java in javadoc plugin ( https://github.com/olamy/JavadocUpdaterTool/blob/master/LICENSE ) As far as I can tell, so long as the code is only used for the intended purpose then it's OK. However, I don't think your plugin fixes all instances of bad javadoc; certainly the instructions only solve the problem for site builds. What about javadoc jars? it simply depends the phase you bind the plugin (per default it's not bind to any phase) But the point is that a separate plugin will have to be separately configured, probably several times. That's not a trivial job, and it's easy to overlook phases and locations of Javadoc. Whereas if the Javadoc plugin fixes any issues before it completes, the end user merely has to ensure they are using the new Javadoc plugin. That's much easier to do. The Maven javadoc jar has lots of goals that occur in different phases; the only way to be sure to fix all the issues is to always run the tool after running Javadoc. 2013/6/20 sebb seb...@gmail.com: On 19 June 2013 22:40, Baptiste MATHUS bmat...@batmat.net wrote: Hi, I think the best way to track this is to file a JIRA ticket on http://jira.codehaus.org/browse/MJAVADOC Well OK, I can raise an enhancement request there too. Btw, we might be interested by https://github.com/AdoptOpenJDK/JavadocUpdaterTool/blob/master/src/main/java/JavadocFixTool.java That looks exactly like the file that was released by Oracle; anyone can pick up the tool packaged as a jar from the Oracle web-site. On it's own, it does not help. Cheers 2013/6/19 sebb seb...@gmail.com I expect you have all see the news about the Javadoc javascript bug. It's going to take a long time for everyone to update their Java installations to Java 1.7 u25. Likewise for builds that need to use other Java versions, tweaking poms so Java 7 is used for Javadocs whilst still maintaining compatibility is a non-trivial task. Is there any interest in releasing a quick-fix version of the javadoc plugin that automatically runs the tool after Javadoc completes? The fix code is in Java, and can easily be directly called from the plugin (no need to start a new process). The license looks friendly so long as the code is only used for Javadoc fixups, and changes are allowed, which is just as well - There are a couple of bugs in the tool as currently released. It does not close all the resources; and failure to close the input file means it cannot delete the original input file on Windows; that needs to be fixed as it would not make sense to keep the old faulty file (even if it is now called index.html.orig). I can provide details of the fixes, but a decent IDE will probably warn about them anyway. It would be a great service to the Java community if this could be fast-tracked. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JavadocFixTool integration with Javadoc plugin?
On 20 June 2013 14:20, Baptiste MATHUS bmat...@batmat.net wrote: I'm +1 with you on the fact that this code should be included after each javadoc goal. I guess they agree too, but I *think* this is just something Olivier and the Maven PMC cannot afford integrating this code into the maven-javadoc-plugin without being 200% sure this isn't going to be a license infringement. This is their 100% is enough. responsability not to drag the Apache foundation into such issues. Ok, but from all the comments I have seen the license is OK. We are wasting time and effort here. Cheers 2013/6/20 sebb seb...@gmail.com On 20 June 2013 13:21, Olivier Lamy ol...@apache.org wrote: 2013/6/20 sebb seb...@gmail.com: On 20 June 2013 12:15, Olivier Lamy ol...@apache.org wrote: See https://github.com/olamy/JavadocUpdaterTool I added a maven build and a mojo. IANAL so I don't know if we can integrate the source of JavadocFixTool.java in javadoc plugin ( https://github.com/olamy/JavadocUpdaterTool/blob/master/LICENSE ) As far as I can tell, so long as the code is only used for the intended purpose then it's OK. However, I don't think your plugin fixes all instances of bad javadoc; certainly the instructions only solve the problem for site builds. What about javadoc jars? it simply depends the phase you bind the plugin (per default it's not bind to any phase) But the point is that a separate plugin will have to be separately configured, probably several times. That's not a trivial job, and it's easy to overlook phases and locations of Javadoc. Whereas if the Javadoc plugin fixes any issues before it completes, the end user merely has to ensure they are using the new Javadoc plugin. That's much easier to do. The Maven javadoc jar has lots of goals that occur in different phases; the only way to be sure to fix all the issues is to always run the tool after running Javadoc. 2013/6/20 sebb seb...@gmail.com: On 19 June 2013 22:40, Baptiste MATHUS bmat...@batmat.net wrote: Hi, I think the best way to track this is to file a JIRA ticket on http://jira.codehaus.org/browse/MJAVADOC Well OK, I can raise an enhancement request there too. Btw, we might be interested by https://github.com/AdoptOpenJDK/JavadocUpdaterTool/blob/master/src/main/java/JavadocFixTool.java That looks exactly like the file that was released by Oracle; anyone can pick up the tool packaged as a jar from the Oracle web-site. On it's own, it does not help. Cheers 2013/6/19 sebb seb...@gmail.com I expect you have all see the news about the Javadoc javascript bug. It's going to take a long time for everyone to update their Java installations to Java 1.7 u25. Likewise for builds that need to use other Java versions, tweaking poms so Java 7 is used for Javadocs whilst still maintaining compatibility is a non-trivial task. Is there any interest in releasing a quick-fix version of the javadoc plugin that automatically runs the tool after Javadoc completes? The fix code is in Java, and can easily be directly called from the plugin (no need to start a new process). The license looks friendly so long as the code is only used for Javadoc fixups, and changes are allowed, which is just as well - There are a couple of bugs in the tool as currently released. It does not close all the resources; and failure to close the input file means it cannot delete the original input file on Windows; that needs to be fixed as it would not make sense to keep the old faulty file (even if it is now called index.html.orig). I can provide details of the fixes, but a decent IDE will probably warn about them anyway. It would be a great service to the Java community if this could be fast-tracked. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: JavadocFixTool integration with Javadoc plugin?
On 20 Jun 2013, at 15:19, sebb wrote: On 20 June 2013 14:20, Baptiste MATHUS bmat...@batmat.net wrote: I'm +1 with you on the fact that this code should be included after each javadoc goal. I guess they agree too, but I *think* this is just something Olivier and the Maven PMC cannot afford integrating this code into the maven-javadoc-plugin without being 200% sure this isn't going to be a license infringement. This is their 100% is enough. responsability not to drag the Apache foundation into such issues. Ok, but from all the comments I have seen the license is OK. IANAL, but there appears to be an export/field-of-use clause in that license: You agree to comply fully with export laws and regulations of the United States and any other applicable export laws (Export Laws) to assure that neither the Program nor any direct products thereof are: (1) exported, directly or indirectly, in violation of this Agreement or Export Laws; or (2) used for any purposes prohibited by the Export Laws, including, without limitation, nuclear, chemical, or biological weapons proliferation, or development of missile technology. so I think it would be best to run this past legal before committing We are wasting time and effort here. Cheers 2013/6/20 sebb seb...@gmail.com On 20 June 2013 13:21, Olivier Lamy ol...@apache.org wrote: 2013/6/20 sebb seb...@gmail.com: On 20 June 2013 12:15, Olivier Lamy ol...@apache.org wrote: See https://github.com/olamy/JavadocUpdaterTool I added a maven build and a mojo. IANAL so I don't know if we can integrate the source of JavadocFixTool.java in javadoc plugin ( https://github.com/olamy/JavadocUpdaterTool/blob/master/LICENSE ) As far as I can tell, so long as the code is only used for the intended purpose then it's OK. However, I don't think your plugin fixes all instances of bad javadoc; certainly the instructions only solve the problem for site builds. What about javadoc jars? it simply depends the phase you bind the plugin (per default it's not bind to any phase) But the point is that a separate plugin will have to be separately configured, probably several times. That's not a trivial job, and it's easy to overlook phases and locations of Javadoc. Whereas if the Javadoc plugin fixes any issues before it completes, the end user merely has to ensure they are using the new Javadoc plugin. That's much easier to do. The Maven javadoc jar has lots of goals that occur in different phases; the only way to be sure to fix all the issues is to always run the tool after running Javadoc. 2013/6/20 sebb seb...@gmail.com: On 19 June 2013 22:40, Baptiste MATHUS bmat...@batmat.net wrote: Hi, I think the best way to track this is to file a JIRA ticket on http://jira.codehaus.org/browse/MJAVADOC Well OK, I can raise an enhancement request there too. Btw, we might be interested by https://github.com/AdoptOpenJDK/JavadocUpdaterTool/blob/master/src/main/java/JavadocFixTool.java That looks exactly like the file that was released by Oracle; anyone can pick up the tool packaged as a jar from the Oracle web-site. On it's own, it does not help. Cheers 2013/6/19 sebb seb...@gmail.com I expect you have all see the news about the Javadoc javascript bug. It's going to take a long time for everyone to update their Java installations to Java 1.7 u25. Likewise for builds that need to use other Java versions, tweaking poms so Java 7 is used for Javadocs whilst still maintaining compatibility is a non-trivial task. Is there any interest in releasing a quick-fix version of the javadoc plugin that automatically runs the tool after Javadoc completes? The fix code is in Java, and can easily be directly called from the plugin (no need to start a new process). The license looks friendly so long as the code is only used for Javadoc fixups, and changes are allowed, which is just as well - There are a couple of bugs in the tool as currently released. It does not close all the resources; and failure to close the input file means it cannot delete the original input file on Windows; that needs to be fixed as it would not make sense to keep the old faulty file (even if it is now called index.html.orig). I can provide details of the fixes, but a decent IDE will probably warn about them anyway. It would be a great service to the Java community if this could be fast-tracked. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail:
Re: JavadocFixTool integration with Javadoc plugin?
https://issues.apache.org/jira/browse/LEGAL-171 On 20 June 2013 15:35, Stuart McCulloch mccu...@gmail.com wrote: On 20 Jun 2013, at 15:19, sebb wrote: On 20 June 2013 14:20, Baptiste MATHUS bmat...@batmat.net wrote: I'm +1 with you on the fact that this code should be included after each javadoc goal. I guess they agree too, but I *think* this is just something Olivier and the Maven PMC cannot afford integrating this code into the maven-javadoc-plugin without being 200% sure this isn't going to be a license infringement. This is their 100% is enough. responsability not to drag the Apache foundation into such issues. Ok, but from all the comments I have seen the license is OK. IANAL, but there appears to be an export/field-of-use clause in that license: You agree to comply fully with export laws and regulations of the United States and any other applicable export laws (Export Laws) to assure that neither the Program nor any direct products thereof are: (1) exported, directly or indirectly, in violation of this Agreement or Export Laws; or (2) used for any purposes prohibited by the Export Laws, including, without limitation, nuclear, chemical, or biological weapons proliferation, or development of missile technology. so I think it would be best to run this past legal before committing We are wasting time and effort here. Cheers 2013/6/20 sebb seb...@gmail.com On 20 June 2013 13:21, Olivier Lamy ol...@apache.org wrote: 2013/6/20 sebb seb...@gmail.com: On 20 June 2013 12:15, Olivier Lamy ol...@apache.org wrote: See https://github.com/olamy/JavadocUpdaterTool I added a maven build and a mojo. IANAL so I don't know if we can integrate the source of JavadocFixTool.java in javadoc plugin ( https://github.com/olamy/JavadocUpdaterTool/blob/master/LICENSE ) As far as I can tell, so long as the code is only used for the intended purpose then it's OK. However, I don't think your plugin fixes all instances of bad javadoc; certainly the instructions only solve the problem for site builds. What about javadoc jars? it simply depends the phase you bind the plugin (per default it's not bind to any phase) But the point is that a separate plugin will have to be separately configured, probably several times. That's not a trivial job, and it's easy to overlook phases and locations of Javadoc. Whereas if the Javadoc plugin fixes any issues before it completes, the end user merely has to ensure they are using the new Javadoc plugin. That's much easier to do. The Maven javadoc jar has lots of goals that occur in different phases; the only way to be sure to fix all the issues is to always run the tool after running Javadoc. 2013/6/20 sebb seb...@gmail.com: On 19 June 2013 22:40, Baptiste MATHUS bmat...@batmat.net wrote: Hi, I think the best way to track this is to file a JIRA ticket on http://jira.codehaus.org/browse/MJAVADOC Well OK, I can raise an enhancement request there too. Btw, we might be interested by https://github.com/AdoptOpenJDK/JavadocUpdaterTool/blob/master/src/main/java/JavadocFixTool.java That looks exactly like the file that was released by Oracle; anyone can pick up the tool packaged as a jar from the Oracle web-site. On it's own, it does not help. Cheers 2013/6/19 sebb seb...@gmail.com I expect you have all see the news about the Javadoc javascript bug. It's going to take a long time for everyone to update their Java installations to Java 1.7 u25. Likewise for builds that need to use other Java versions, tweaking poms so Java 7 is used for Javadocs whilst still maintaining compatibility is a non-trivial task. Is there any interest in releasing a quick-fix version of the javadoc plugin that automatically runs the tool after Javadoc completes? The fix code is in Java, and can easily be directly called from the plugin (no need to start a new process). The license looks friendly so long as the code is only used for Javadoc fixups, and changes are allowed, which is just as well - There are a couple of bugs in the tool as currently released. It does not close all the resources; and failure to close the input file means it cannot delete the original input file on Windows; that needs to be fixed as it would not make sense to keep the old faulty file (even if it is now called index.html.orig). I can provide details of the fixes, but a decent IDE will probably warn about them anyway. It would be a great service to the Java community if this could be fast-tracked. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! - To unsubscribe,
Re: Maven 3.1.0-beta-1
I unpacked your example and ran your preparation script and it fails in 2.2.1 as well: https://gist.github.com/jvanzyl/5824206 What's the overall usecase? You have a build with snapshots and you find you need to go back to a release so you lock down to a previous release and want to use that? If you want to iteratively work on it together put it in a github repo. On Jun 20, 2013, at 2:45 AM, Jörg Schaible joerg.schai...@scalaris.com wrote: Hi Jason, Jason van Zyl wrote: Doesn't see to be a whole lot of activity around the 3.1.0-alpha-1 so I plan to cut the 3.1.0-beta-1 this weekend if there are no objections. Since all versions of M30x fail in their core competence to make reliable builds because it uses stale snapshots, it would be fine to have at least a properly working M31x. What I am talking about? See MNG-5207! Reported months ago, a proper IT test bit rots in JIRA and if you search through the archives of this list for the issue, then you'll notice that it has been reported more than once, with promises to look into it. And yes, I have verified that M31a still fails. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl - Three people can keep a secret provided two of them are dead. -- Benjamin Franklin
Re: dist tooling
If the intention for this plugin is to let run standalone on a CI-Server, then that's good enough for me. The plugin doesn't use org.apache.maven.plugins as groupId, so it'll be a bit harder to be found by the general user, which is good. I can image that this tool could be interesting for any large project with staging. So some parts need to be more generic. With less hardcoded values it is also easier to make proper tests. Robert Op Thu, 20 Jun 2013 10:54:46 +0200 schreef Eric Barboni sk...@apache.org: Well, I'm late Hervé answered before me. Of course you can improve the plugin which we should maybe rename to avoid confusion with end user maven plugin. A todo.md file is available to add RFE that needs a couple of days (my definition :p) . Idea was to not overwhelm Hervé (or any other maven dev). Thanks you for the IT settings. Regards, Eric - skygo PS: FYI the JDK version choice (on a feature point ) try with resource feature + new javadoc style. As a lecturer in HCI field, when you ask student to get java (oracle version) they found jdk 7, jdk 6 is shown as end of life (with security warning everywhere). Side effect is that, you play with the new features. (student later learn backward compatibility) -Message d'origine- De : Hervé BOUTEMY [mailto:herve.bout...@free.fr] Envoyé : jeudi 20 juin 2013 07:19 À : Maven Developers List Objet : Re: dist tooling this is not a plugin for end users, only for internal Maven team: and once it is scheduled daily on our Jenkins server, i don't expect us to run it on our personal machines so I don't think JDK7 nor Maven version requirements are a problem. ITs would be nice, yes, to be sure things are detected even when we fix errors actually reported Regards, Hervé Le mercredi 19 juin 2013 23:22:13 Robert Scholte a écrit : Hi, I noticed there are no IT's. It shouldn't be too hard to write that. I can make a setup for that in order to be able to execute some ITs Although most of us want to use the latest and greatest, I have my doubts about using JDK7 and M3.0.4 for compilation. Since our advice is to compile with lowest required versions, I think we should aim for JDK5 and M3.0, unless there's a very, very good reason not to. I see some other improvements, put I'll pick these up myself. Should be easy to verify once I've got the ITs running. Robert Op Wed, 19 Jun 2013 21:42:33 +0200 schreef Robert Scholte rfscho...@apache.org: I'd like to have a look at it too. Give me a couple of days. Robert Op Wed, 19 Jun 2013 00:11:55 +0200 schreef Hervé BOUTEMY herve.bout...@free.fr: Thanks to Eric, we now have a tool to check dist content And I just added it to our Jenkins instance, to build once a day: you can look at the result [1] I just had to remove the preview of site, since Firefox isn't available on the CI server (or not able to start in headless mode) Any feedback? Regards, Hervé [1] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/ ws/tar get/site/index.html --- -- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Maven assembly plugin throwing error
Hi,
I am simply trying to create a .zip from some folders in an svn project. When
I try to run this a maven build I get the following error:
ERROR] BUILD ERROR
[INFO]
[INFO] Compiler errors:
error no sources specified
abort AspectJ Compiler 1.6.11
Usage: options source file | @argfile..
AspectJ-specific options:
-inpath list use classes in dirs and jars/zips in list as
source
(list uses platform-specific path delimiter)
-injars jarList use classes in jarList zip files as source
(jarList uses classpath delimiter)
...
Here is my descriptor xml file contents...
assembly
xmlns=http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://maven.apache.org/plugins/maven-assembly-plugin
/assembly /1.1.0 http://maven.apache.org/xsd/assembly-1.1.0.xsd;
idbatch/id
formats
formatzip/format
/formats
fileSets
fileSet
directory${project.basedir}/src/main/scripts/directory
outputDirectory/scripts//outputDirectory
includes
include*/include
/includes
/fileSet
fileSet
directory${project.basedir}/src/main/resources/lib/directory
outputDirectory/lib//outputDirectory
includes
include*/include
/includes
/fileSet
/fileSets
/assembly
... and here is the build section of my POM ...
build
plugins
plugin
artifactIdmaven-assembly-plugin/artifactId
configuration
descriptors
descriptorsrc/main/assembly
/nge-batch.xml/descriptor
/descriptors
/configuration
executions
execution
idmake-assembly/id
phasepackage/phase
goals
goalsingle/goal
/goals
/execution
/executions
/plugin
/plugins
/build
I don't have any dependencies definded in my POM. Using maven 2.2.1 and here
is my command:
-B clean deploy (inside a GUI buildtool)
Do you have any ideas on why I am getting the no sources found aspectJ error
message and what to do about it?
Thank you.
- Spuds23
