Re: Managing Different Java Versions
I believe Stephen answered (1) for me quite elegantly. It would help tremendously if his explanation were documented on the introduction page. I'm not sure if sniffer solves (2) which really was my original intent because I had already solved (1) by other means. Eric, if you file a ticket supplying exactly what text you want added (and specify to what page and where on that page) I will make sure it will get committed. You don't have to provide a patch (as you say you don't know how to do that), but you could just type the text in the ticket itself. The key here is to file a jira ticket. Nothing will happen from a mail thread. /Anders - Eric Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
So, if what I want is to avoid calling any Java 6 methods I would use plugin groupIdorg.codehaus.mojo/groupId artifactIdanimal-sniffer-maven-plugin/artifactId version1.3/version executions execution idcheck-java16/id phasetest/phase goals goalcheck/goal /goals configuration signature groupIdorg.codehaus.mojo.signature/groupId artifactIdjava16/artifactId version1.0/version /signature /configuration /execution /executions /plugin When I run this I gets tons of error messages that gives me the impression something is not configured right - what am I still missing? [INFO] [INFO] --- animal-sniffer-maven-plugin:1.3:check (check-java16) @ intersystem-common --- [INFO] Checking unresolved references to org.codehaus.mojo.signature:java16:1.0 com/kodak/intersystem/common/Application$1 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$1.val$exitResult#Lcom/kodak/intersystem/common/ExitListenerManager$ExitResult; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$1.class java/lang/Object com/kodak/intersystem/common/Application$1 com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.exit(Lcom/kodak/intersystem/common/ExitListenerManager$ExitResult;)I in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$1.class java/lang/Thread java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.getName()Ljava/lang/String; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/StringBuilder java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.setName(Ljava/lang/String;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.setDaemon(Z)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.access$000()Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 java/lang/StringBuilder java/lang/StringBuilder java/lang/StringBuilder org/slf4j/Logger [ERROR] Undefined reference: org/slf4j/Logger.debug(Ljava/lang/String;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/Object com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.logger#Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Properties [ERROR] Undefined reference: com/kodak/intersystem/common/Properties.getLogger(Ljava/lang/Class;)Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Application com/kodak/intersystem/common/Application com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.exitListenerManager#Lcom/kodak/intersystem/common/ExitListenerManager; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/ExitListenerManager [ERROR] Undefined reference: com/kodak/intersystem/common/ExitListenerManager.addExitListener(Lcom/kodak/intersystem/common/ExitListener;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Application com/kodak/intersystem/common/ExitListenerManager [ERROR] Undefined reference: com/kodak/intersystem/common/ExitListenerManager.removeExitListener(Lcom/kodak/intersystem/common/ExitListener;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Application com/kodak/intersystem/common/ExitListenerManager [ERROR] Undefined reference: com/kodak/intersystem/common/ExitListenerManager.isExiting#Z in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Application [ERROR] Undefined reference:
Re: Managing Different Java Versions
Well first off, try upgrading the version of animal-sniffer-maven-plugin to latest... The signatures (and their site) were generated when 1.3 was the latest... 1.7 has a number of important fixes, but without regenerating the signatures it is hard to get the site updated to say the version of animal-sniffer should be 1.7 On 11 October 2011 13:49, Eric Kolotyluk eric.koloty...@gmail.com wrote: So, if what I want is to avoid calling any Java 6 methods I would use plugin groupIdorg.codehaus.mojo/groupId artifactIdanimal-sniffer-maven-plugin/artifactId version1.3/version executions execution idcheck-java16/id phasetest/phase goals goalcheck/goal /goals configuration signature groupIdorg.codehaus.mojo.signature/groupId artifactIdjava16/artifactId version1.0/version /signature /configuration /execution /executions /plugin When I run this I gets tons of error messages that gives me the impression something is not configured right - what am I still missing? [INFO] [INFO] --- animal-sniffer-maven-plugin:1.3:check (check-java16) @ intersystem-common --- [INFO] Checking unresolved references to org.codehaus.mojo.signature:java16:1.0 com/kodak/intersystem/common/Application$1 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$1.val$exitResult#Lcom/kodak/intersystem/common/ExitListenerManager$ExitResult; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$1.class java/lang/Object com/kodak/intersystem/common/Application$1 com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.exit(Lcom/kodak/intersystem/common/ExitListenerManager$ExitResult;)I in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$1.class java/lang/Thread java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.getName()Ljava/lang/String; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/StringBuilder java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.setName(Ljava/lang/String;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.setDaemon(Z)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.access$000()Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 java/lang/StringBuilder java/lang/StringBuilder java/lang/StringBuilder org/slf4j/Logger [ERROR] Undefined reference: org/slf4j/Logger.debug(Ljava/lang/String;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/Object com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.logger#Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Properties [ERROR] Undefined reference: com/kodak/intersystem/common/Properties.getLogger(Ljava/lang/Class;)Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Application com/kodak/intersystem/common/Application com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.exitListenerManager#Lcom/kodak/intersystem/common/ExitListenerManager; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/ExitListenerManager [ERROR] Undefined reference: com/kodak/intersystem/common/ExitListenerManager.addExitListener(Lcom/kodak/intersystem/common/ExitListener;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Application com/kodak/intersystem/common/ExitListenerManager [ERROR] Undefined reference: com/kodak/intersystem/common/ExitListenerManager.removeExitListener(Lcom/kodak/intersystem/common/ExitListener;)V in
Re: Managing Different Java Versions
OK, 1.7 works much better - thanks. Finally now that I have it working I can understand better what it does and how it is useful. Thank you to everyone who helped, and for being patient with me. Cheers, Eric On 2011-10-11 6:25 AM, Stephen Connolly wrote: Well first off, try upgrading the version of animal-sniffer-maven-plugin to latest... The signatures (and their site) were generated when 1.3 was the latest... 1.7 has a number of important fixes, but without regenerating the signatures it is hard to get the site updated to say the version of animal-sniffer should be 1.7 On 11 October 2011 13:49, Eric Kolotylukeric.koloty...@gmail.com wrote: So, if what I want is to avoid calling any Java 6 methods I would use plugin groupIdorg.codehaus.mojo/groupId artifactIdanimal-sniffer-maven-plugin/artifactId version1.3/version executions execution idcheck-java16/id phasetest/phase goals goalcheck/goal /goals configuration signature groupIdorg.codehaus.mojo.signature/groupId artifactIdjava16/artifactId version1.0/version /signature /configuration /execution /executions /plugin When I run this I gets tons of error messages that gives me the impression something is not configured right - what am I still missing? [INFO] [INFO] --- animal-sniffer-maven-plugin:1.3:check (check-java16) @ intersystem-common --- [INFO] Checking unresolved references to org.codehaus.mojo.signature:java16:1.0 com/kodak/intersystem/common/Application$1 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$1.val$exitResult#Lcom/kodak/intersystem/common/ExitListenerManager$ExitResult; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$1.class java/lang/Object com/kodak/intersystem/common/Application$1 com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.exit(Lcom/kodak/intersystem/common/ExitListenerManager$ExitResult;)I in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$1.class java/lang/Thread java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.getName()Ljava/lang/String; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/StringBuilder java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.setName(Ljava/lang/String;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.setDaemon(Z)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.access$000()Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 java/lang/StringBuilder java/lang/StringBuilder java/lang/StringBuilder org/slf4j/Logger [ERROR] Undefined reference: org/slf4j/Logger.debug(Ljava/lang/String;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/Object com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.logger#Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Properties [ERROR] Undefined reference: com/kodak/intersystem/common/Properties.getLogger(Ljava/lang/Class;)Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Application com/kodak/intersystem/common/Application com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.exitListenerManager#Lcom/kodak/intersystem/common/ExitListenerManager; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/ExitListenerManager [ERROR] Undefined reference: com/kodak/intersystem/common/ExitListenerManager.addExitListener(Lcom/kodak/intersystem/common/ExitListener;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Application com/kodak/intersystem/common/ExitListenerManager [ERROR] Undefined reference:
Re: Managing Different Java Versions
Done! http://jira.codehaus.org/browse/MANIMALSNIFFER-21 If I think of further documentation improvements should I add them to the same ticket, or create separate ones. Cheers, Eric On 2011-10-11 12:31 AM, Anders Hammar wrote: I believe Stephen answered (1) for me quite elegantly. It would help tremendously if his explanation were documented on the introduction page. I'm not sure if sniffer solves (2) which really was my original intent because I had already solved (1) by other means. Eric, if you file a ticket supplying exactly what text you want added (and specify to what page and where on that page) I will make sure it will get committed. You don't have to provide a patch (as you say you don't know how to do that), but you could just type the text in the ticket itself. The key here is to file a jira ticket. Nothing will happen from a mail thread. /Anders - Eric Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
Wanted to add a plug for the versions-maven-plugin plugin groupIdorg.codehaus.mojo/groupId artifactIdversions-maven-plugin/artifactId version1.2/version /plugin the goal versions:display-plugin-updates will let you know if any plugins that you are referencing have more recent versions versions:display-dependency-updates and versions:display-property-updates are also helpful in keeping pom references current On 10/11/11 9:25 AM, Stephen Connolly wrote: Well first off, try upgrading the version of animal-sniffer-maven-plugin to latest... The signatures (and their site) were generated when 1.3 was the latest... 1.7 has a number of important fixes, but without regenerating the signatures it is hard to get the site updated to say the version of animal-sniffer should be 1.7 On 11 October 2011 13:49, Eric Kolotylukeric.koloty...@gmail.com wrote: So, if what I want is to avoid calling any Java 6 methods I would use plugin groupIdorg.codehaus.mojo/groupId artifactIdanimal-sniffer-maven-plugin/artifactId version1.3/version executions execution idcheck-java16/id phasetest/phase goals goalcheck/goal /goals configuration signature groupIdorg.codehaus.mojo.signature/groupId artifactIdjava16/artifactId version1.0/version /signature /configuration /execution /executions /plugin When I run this I gets tons of error messages that gives me the impression something is not configured right - what am I still missing? [INFO] [INFO] --- animal-sniffer-maven-plugin:1.3:check (check-java16) @ intersystem-common --- [INFO] Checking unresolved references to org.codehaus.mojo.signature:java16:1.0 com/kodak/intersystem/common/Application$1 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$1.val$exitResult#Lcom/kodak/intersystem/common/ExitListenerManager$ExitResult; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$1.class java/lang/Object com/kodak/intersystem/common/Application$1 com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.exit(Lcom/kodak/intersystem/common/ExitListenerManager$ExitResult;)I in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$1.class java/lang/Thread java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.getName()Ljava/lang/String; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/StringBuilder java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.setName(Ljava/lang/String;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class com/kodak/intersystem/common/Application$2 [ERROR] Undefined reference: com/kodak/intersystem/common/Application$2.setDaemon(Z)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.access$000()Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/StringBuilder java/lang/StringBuilder com/kodak/intersystem/common/Application$2 java/lang/StringBuilder java/lang/StringBuilder java/lang/StringBuilder org/slf4j/Logger [ERROR] Undefined reference: org/slf4j/Logger.debug(Ljava/lang/String;)V in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application$2.class java/lang/Object com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.logger#Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Properties [ERROR] Undefined reference: com/kodak/intersystem/common/Properties.getLogger(Ljava/lang/Class;)Lorg/slf4j/Logger; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/Application com/kodak/intersystem/common/Application com/kodak/intersystem/common/Application [ERROR] Undefined reference: com/kodak/intersystem/common/Application.exitListenerManager#Lcom/kodak/intersystem/common/ExitListenerManager; in P:\Intersystem\main\platform.Java\intersystem-common\target\classes\com\kodak\intersystem\common\Application.class com/kodak/intersystem/common/ExitListenerManager [ERROR] Undefined reference: com/kodak/intersystem/common/ExitListenerManager.addExitListener(Lcom/kodak/intersystem/common/ExitListener;)V in
Re: Managing Different Java Versions
If I think of further documentation improvements should I add them to the same ticket, or create separate ones. IMO it depends if the are related or not. Also, working with several smaller tickets is easier than one huge one. When it comes to documentation it's hard to give a good guideline, but for code one should always ensure that the subject of the ticket clearly describes the change and that normally makes it obvious what could be added to it (fix bugs is not a good subject). When it comes to docs I think that a more general level of improve doc is ok. /Anders Cheers, Eric On 2011-10-11 12:31 AM, Anders Hammar wrote: I believe Stephen answered (1) for me quite elegantly. It would help tremendously if his explanation were documented on the introduction page. I'm not sure if sniffer solves (2) which really was my original intent because I had already solved (1) by other means. Eric, if you file a ticket supplying exactly what text you want added (and specify to what page and where on that page) I will make sure it will get committed. You don't have to provide a patch (as you say you don't know how to do that), but you could just type the text in the ticket itself. The key here is to file a jira ticket. Nothing will happen from a mail thread. /Anders - Eric Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
What surprised me the most is people complaining about open source docs, but then very rarely supply any patches for improving them. As they surely do put time into figuring out how to use the software (and to write mail complaining), they would be the very best candidates for fixing the existing docs. Eric, you have an excellent opportunity here to show that you're not one of these people! /Anders On Mon, Oct 10, 2011 at 02:10, Benson Margulies bimargul...@gmail.com wrote: On Sun, Oct 9, 2011 at 7:35 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: in fairness i think i wrote most of the docs. Kohsuke's original docs were less than minimal. most of the docs were written while on public transport on a shitty little netbook. Well, little did I know. Having met KK's work before, I just assumed that this was an unusually verbose example :-) i don't currently have the time to prettify the docs further, and when i have time i want to sort out the versions-maven-plugin integration tests so that i can roll releases with new features safely - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 9 Oct 2011 23:14, Benson Margulies bimargul...@gmail.com wrote: If you have to support 1.5, the easiest thing to do is eschew the use of 1.6 features. Just set the compiler plugin options for source and target of 1.5. After you do that, you might still want the sniffer, since this does not stop you from accidentally coding calls to methods introduced in 1.6. If you really need 1.6 features, you might consider looking at retroweaver, which can convert 1.6 jars into 1.5 jars. *However*, once you start having two versions of a jar floating around (one for 1.5, one for 1.6), Maven is not really terribly helpful. This is not a use-case, apparently, that was anywhere near the front of the collective Maven mind when the dependency model was designed. As for the comprehensibility of the AS docs, well, KK is one of the smartest, nicest, guys pumping out useful stuff for the rest of us. However, the doc he writes is the doc he writes. Or, for another perspective, I could quote Tom Lehrer: The problem with folk music is that it is written by the people. Considering what you are paying for this stuff, you might be argued to be getting a pretty good deal. My usual modus operandi is to go looking at a live example of the use of something if I am unclear as to how to use it. This can be an interesting easter-egg hunt. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
On 2011-10-09 3:14 PM, Benson Margulies wrote: If you have to support 1.5, the easiest thing to do is eschew the use of 1.6 features. Just set the compiler plugin options for source and target of 1.5. Yes, I have already done that part. After you do that, you might still want the sniffer, since this does not stop you from accidentally coding calls to methods introduced in 1.6. The problem is I cannot figure out the intent of how the sniffer is supposed to work - in particular if it will even help with my particular problem. As far as I can tell the Hibernate folks have not set up the necessary signatures for the sniffer to tell me what I need to know. When generating signatures, are we supposed to create a separate Maven project/artifact for the signature? For example com.waycool.myapi com.waycool.myapi.signature If you really need 1.6 features, you might consider looking at retroweaver, which can convert 1.6 jars into 1.5 jars. *However*, once you start having two versions of a jar floating around (one for 1.5, one for 1.6), Maven is not really terribly helpful. This is not a use-case, apparently, that was anywhere near the front of the collective Maven mind when the dependency model was designed. It is not that I need 1.6 features - it is that somewhere I am pulling in a JAR file via Maven that has version 50 class files from Java 6 and the Java 5 run time can only recognize version 49 or earlier. I am trying to pin down which JAR file exactly, and then determine if there is an earlier version of the artifact that has version 49 class files. As for the comprehensibility of the AS docs, well, KK is one of the smartest, nicest, guys pumping out useful stuff for the rest of us. However, the doc he writes is the doc he writes. Or, for another perspective, I could quote Tom Lehrer: The problem with folk music is that it is written by the people. Considering what you are paying for this stuff, you might be argued to be getting a pretty good deal. Fair enough - you are precisely correct about free open source tools. I should have been more kind with my words, but instead let my frustration get the better of me. My usual modus operandi is to go looking at a live example of the use of something if I am unclear as to how to use it. This can be an interesting easter-egg hunt. And I am not even sure where to start the hunt. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
That would be greatly appreciated... Cheers, Eric On 2011-10-09 4:35 PM, Stephen Connolly wrote: in fairness i think i wrote most of the docs. Kohsuke's original docs were less than minimal. most of the docs were written while on public transport on a shitty little netbook. i don't currently have the time to prettify the docs further, and when i have time i want to sort out the versions-maven-plugin integration tests so that i can roll releases with new features safely - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 9 Oct 2011 23:14, Benson Marguliesbimargul...@gmail.com wrote: If you have to support 1.5, the easiest thing to do is eschew the use of 1.6 features. Just set the compiler plugin options for source and target of 1.5. After you do that, you might still want the sniffer, since this does not stop you from accidentally coding calls to methods introduced in 1.6. If you really need 1.6 features, you might consider looking at retroweaver, which can convert 1.6 jars into 1.5 jars. *However*, once you start having two versions of a jar floating around (one for 1.5, one for 1.6), Maven is not really terribly helpful. This is not a use-case, apparently, that was anywhere near the front of the collective Maven mind when the dependency model was designed. As for the comprehensibility of the AS docs, well, KK is one of the smartest, nicest, guys pumping out useful stuff for the rest of us. However, the doc he writes is the doc he writes. Or, for another perspective, I could quote Tom Lehrer: The problem with folk music is that it is written by the people. Considering what you are paying for this stuff, you might be argued to be getting a pretty good deal. My usual modus operandi is to go looking at a live example of the use of something if I am unclear as to how to use it. This can be an interesting easter-egg hunt. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
My usual modus operandi is to go looking at a live example of the use of something if I am unclear as to how to use it. This can be an interesting easter-egg hunt. And I am not even sure where to start the hunt. Go to Github and search for the plugin name... https://github.com/search?type=Everythinglanguage=q=animal-sniffer-maven-pluginrepo=langOverride=x=12y=16start_value=1 Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
At the moment I do not know how to create and submit such patches. If I did I might be so inclined. At the moment, however, I am trying to complete a very time critical project and just need to get things working. I am hope that in 2012, when I am not working 60 hour weeks, I will be able to learn some of the skills to contribute back to the open source community. I have already written a Maven plug-in that I would like to contribute as open source, but I have yet to learn out to document and distribute that properly. Cheers, Eric On 2011-10-09 11:35 PM, Anders Hammar wrote: What surprised me the most is people complaining about open source docs, but then very rarely supply any patches for improving them. As they surely do put time into figuring out how to use the software (and to write mail complaining), they would be the very best candidates for fixing the existing docs. Eric, you have an excellent opportunity here to show that you're not one of these people! /Anders On Mon, Oct 10, 2011 at 02:10, Benson Marguliesbimargul...@gmail.com wrote: On Sun, Oct 9, 2011 at 7:35 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: in fairness i think i wrote most of the docs. Kohsuke's original docs were less than minimal. most of the docs were written while on public transport on a shitty little netbook. Well, little did I know. Having met KK's work before, I just assumed that this was an unusually verbose example :-) i don't currently have the time to prettify the docs further, and when i have time i want to sort out the versions-maven-plugin integration tests so that i can roll releases with new features safely - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 9 Oct 2011 23:14, Benson Marguliesbimargul...@gmail.com wrote: If you have to support 1.5, the easiest thing to do is eschew the use of 1.6 features. Just set the compiler plugin options for source and target of 1.5. After you do that, you might still want the sniffer, since this does not stop you from accidentally coding calls to methods introduced in 1.6. If you really need 1.6 features, you might consider looking at retroweaver, which can convert 1.6 jars into 1.5 jars. *However*, once you start having two versions of a jar floating around (one for 1.5, one for 1.6), Maven is not really terribly helpful. This is not a use-case, apparently, that was anywhere near the front of the collective Maven mind when the dependency model was designed. As for the comprehensibility of the AS docs, well, KK is one of the smartest, nicest, guys pumping out useful stuff for the rest of us. However, the doc he writes is the doc he writes. Or, for another perspective, I could quote Tom Lehrer: The problem with folk music is that it is written by the people. Considering what you are paying for this stuff, you might be argued to be getting a pretty good deal. My usual modus operandi is to go looking at a live example of the use of something if I am unclear as to how to use it. This can be an interesting easter-egg hunt. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
The problem is I cannot figure out the intent of how the sniffer is supposed to work - in particular if it will even help with my particular problem. As far as I can tell the Hibernate folks have not set up the necessary signatures for the sniffer to tell me what I need to know. You should not need to set up signatures. The community has already done that for you. Just use an artifact under the groupId org.codehaus.mojo.signature and specify the Java version you are looking to target (most likely java15-sun in your case). When generating signatures, are we supposed to create a separate Maven project/artifact for the signature? For example I don't believe this is something you need to worry about. Just use the existing signatures. Why would you be generating signatures anyway? It is not that I need 1.6 features - it is that somewhere I am pulling in a JAR file via Maven that has version 50 class files from Java 6 and the Java 5 run time can only recognize version 49 or earlier. I am trying to pin down which JAR file exactly, and then determine if there is an earlier version of the artifact that has version 49 class files. If you set up the plugin properly, it should check all of YOUR code to ensure it only uses JDK5 APIs. It will not help with code in your dependencies (that I am aware of at least). If you want to check the Hibernate artifacts (jars), you should probably just use the Animal Sniffer ant tasks and write a little Ant to compare each Hibernate jar against the jdk15 signature: http://mojo.codehaus.org/animal-sniffer/animal-sniffer-ant-tasks/examples/checking-signatures.html Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
OK, I still clearly do not understand how sniffer is supposed to work, and it does not look like am going to any time soon, even after all these explanations. As it is, I am making better progress now just by specifying the Java 5 compiler in my maven-compiler-plugin. It complains right away when the artifact has Java 6 class files in it and prints an error message identifying the troublesome jar file. I am not really sure why no-one recommended this to me in the first place as it effective and simple to understand. Again, I am at a complete loss to fathom any utility in the sniffer. Maybe I am just too stupid to get it. Cheers, Eric On 2011-10-10 9:49 AM, Wayne Fay wrote: The problem is I cannot figure out the intent of how the sniffer is supposed to work - in particular if it will even help with my particular problem. As far as I can tell the Hibernate folks have not set up the necessary signatures for the sniffer to tell me what I need to know. You should not need to set up signatures. The community has already done that for you. Just use an artifact under the groupId org.codehaus.mojo.signature and specify the Java version you are looking to target (most likely java15-sun in your case). I do not know what you mean... When generating signatures, are we supposed to create a separate Maven project/artifact for the signature? For example I don't believe this is something you need to worry about. Just use the existing signatures. Why would you be generating signatures anyway? I have no idea because I do not know what the intent of the sniffer is or how it is supposed to work. It is not that I need 1.6 features - it is that somewhere I am pulling in a JAR file via Maven that has version 50 class files from Java 6 and the Java 5 run time can only recognize version 49 or earlier. I am trying to pin down which JAR file exactly, and then determine if there is an earlier version of the artifact that has version 49 class files. If you set up the plugin properly, it should check all of YOUR code to ensure it only uses JDK5 APIs. It will not help with code in your dependencies (that I am aware of at least). If you want to check the Hibernate artifacts (jars), you should probably just use the Animal Sniffer ant tasks and write a little Ant to compare each Hibernate jar against the jdk15 signature: http://mojo.codehaus.org/animal-sniffer/animal-sniffer-ant-tasks/examples/checking-signatures.html Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
On 10 October 2011 21:15, Eric Kolotyluk eric.koloty...@gmail.com wrote: OK, I still clearly do not understand how sniffer is supposed to work, and it does not look like am going to any time soon, even after all these explanations. As it is, I am making better progress now just by specifying the Java 5 compiler in my maven-compiler-plugin. It complains right away when the artifact has Java 6 class files in it and prints an error message identifying the troublesome jar file. I am not really sure why no-one recommended this to me in the first place as it effective and simple to understand. Again, I am at a complete loss to fathom any utility in the sniffer. Maybe I am just too stupid to get it. Cheers, Eric On 2011-10-10 9:49 AM, Wayne Fay wrote: The problem is I cannot figure out the intent of how the sniffer is supposed to work - in particular if it will even help with my particular problem. As far as I can tell the Hibernate folks have not set up the necessary signatures for the sniffer to tell me what I need to know. You should not need to set up signatures. The community has already done that for you. Just use an artifact under the groupId org.codehaus.mojo.signature and specify the Java version you are looking to target (most likely java15-sun in your case). I do not know what you mean... When generating signatures, are we supposed to create a separate Maven project/artifact for the signature? For example I don't believe this is something you need to worry about. Just use the existing signatures. Why would you be generating signatures anyway? I have no idea because I do not know what the intent of the sniffer is or how it is supposed to work. The intent of animal sniffer is to allow you to use source1.5/source with a 1.6 JDK and not accidentally link to methods like java.lang.String#isEmpty() Setting the source to 1.5 will only flush out the class format... the signatures of methods used can only be enforced by the sniffer. You run it on all your classes with the signatures you want to enforce on your code... if you use a method outside those signatures it will fail the build for you. HTH -Stephen It is not that I need 1.6 features - it is that somewhere I am pulling in a JAR file via Maven that has version 50 class files from Java 6 and the Java 5 run time can only recognize version 49 or earlier. I am trying to pin down which JAR file exactly, and then determine if there is an earlier version of the artifact that has version 49 class files. If you set up the plugin properly, it should check all of YOUR code to ensure it only uses JDK5 APIs. It will not help with code in your dependencies (that I am aware of at least). If you want to check the Hibernate artifacts (jars), you should probably just use the Animal Sniffer ant tasks and write a little Ant to compare each Hibernate jar against the jdk15 signature: http://mojo.codehaus.org/animal-sniffer/animal-sniffer-ant-tasks/examples/checking-signatures.html Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
Am 10.10.2011 22:15, schrieb Eric Kolotyluk: I am not really sure why no-one recommended this to me in the first place as it effective and simple to understand. Maybe you led the crowd into the wrong direction by claiming: I am almost complete reworking things to run on a Java 5 run-time, and while everything compiles [...] I'd conclude from this, that you're already compiling against version 1.5 and everything actually *does* compile. HTH Ansgar - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
OK, I still clearly do not understand how sniffer is supposed to work, and it does not look like am going to any time soon, even after all these explanations. A signature is like: char java.lang.String.charAt(int) Animal sniffer compares the Java code you are writing against the published signatures of popular Java APIs like Sun JDK 1.5, 1.6, IBM, JRockit, etc. That's it! If this is helpful to you, use it. If you need other functionality, animal sniffer may not be able to help you. identifying the troublesome jar file. I am not really sure why no-one recommended this to me in the first place as it effective and simple to Uhhh Benson *did* suggest this... did you miss it?? On Sun, Oct 9, 2011 at 5:14 PM, Benson Margulies bimargul...@gmail.com wrote: If you have to support 1.5, the easiest thing to do is eschew the use of 1.6 features. Just set the compiler plugin options for source and target of 1.5. Again, I am at a complete loss to fathom any utility in the sniffer. Maybe I It is quite possible that your needs simply do not match the functionality provided by Animal sniffer. There are a large number of people who find it useful. Their needs may be different from your own. Perhaps you can summarize in 1 sentence what problem you are trying to solve, then various alternative solutions can be discussed. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
On 2011-10-10 1:28 PM, Stephen Connolly wrote: On 10 October 2011 21:15, Eric Kolotylukeric.koloty...@gmail.com wrote: OK, I still clearly do not understand how sniffer is supposed to work, and it does not look like am going to any time soon, even after all these explanations. As it is, I am making better progress now just by specifying the Java 5 compiler in my maven-compiler-plugin. It complains right away when the artifact has Java 6 class files in it and prints an error message identifying the troublesome jar file. I am not really sure why no-one recommended this to me in the first place as it effective and simple to understand. Again, I am at a complete loss to fathom any utility in the sniffer. Maybe I am just too stupid to get it. Cheers, Eric On 2011-10-10 9:49 AM, Wayne Fay wrote: The problem is I cannot figure out the intent of how the sniffer is supposed to work - in particular if it will even help with my particular problem. As far as I can tell the Hibernate folks have not set up the necessary signatures for the sniffer to tell me what I need to know. You should not need to set up signatures. The community has already done that for you. Just use an artifact under the groupId org.codehaus.mojo.signature and specify the Java version you are looking to target (most likely java15-sun in your case). I do not know what you mean... When generating signatures, are we supposed to create a separate Maven project/artifact for the signature? For example I don't believe this is something you need to worry about. Just use the existing signatures. Why would you be generating signatures anyway? I have no idea because I do not know what the intent of the sniffer is or how it is supposed to work. The intent of animal sniffer is to allow you to use source1.5/source with a 1.6 JDK and not accidentally link to methods like java.lang.String#isEmpty() OK, that is useful because I had exactly that same case. In the end I had to figure it out by actually using a 1.5 JDK. That particular sentence would be extremely valuable on the introduction page http://mojo.codehaus.org/animal-sniffer-maven-plugin/ Setting the source to 1.5 will only flush out the class format... the signatures of methods used can only be enforced by the sniffer. Excellent point! This would also be extremely valuable to document on the introduction page You run it on all your classes with the signatures you want to enforce on your code... if you use a method outside those signatures it will fail the build for you. Sounds good - unfortunately based on all the examples I have seen - how to actually configure a POM to do this is a huge mystery still. I can say without a doubt, the animal-sniffer-maven-plugin is by far the most abstruse plugin I have yet encountered. - Eric HTH -Stephen It is not that I need 1.6 features - it is that somewhere I am pulling in a JAR file via Maven that has version 50 class files from Java 6 and the Java 5 run time can only recognize version 49 or earlier. I am trying to pin down which JAR file exactly, and then determine if there is an earlier version of the artifact that has version 49 class files. If you set up the plugin properly, it should check all of YOUR code to ensure it only uses JDK5 APIs. It will not help with code in your dependencies (that I am aware of at least). If you want to check the Hibernate artifacts (jars), you should probably just use the Animal Sniffer ant tasks and write a little Ant to compare each Hibernate jar against the jdk15 signature: http://mojo.codehaus.org/animal-sniffer/animal-sniffer-ant-tasks/examples/checking-signatures.html Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
Fair enough. At the time I actually thought I was compiling against 1.5, but in fact I still had not finished setting up Maven properly to do that, and it was still compiling with 1.6. - Eric On 2011-10-10 1:30 PM, Ansgar Konermann wrote: Am 10.10.2011 22:15, schrieb Eric Kolotyluk: I am not really sure why no-one recommended this to me in the first place as it effective and simple to understand. Maybe you led the crowd into the wrong direction by claiming: I am almost complete reworking things to run on a Java 5 run-time, and while everything compiles [...] I'd conclude from this, that you're already compiling against version 1.5 and everything actually *does* compile. HTH Ansgar - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
When you are on a Mac you cannot compile with a 1.5 JDK... Have a look at http://mojo.codehaus.org/signatures/java15/ On 10 October 2011 21:49, Eric Kolotyluk eric.koloty...@gmail.com wrote: Fair enough. At the time I actually thought I was compiling against 1.5, but in fact I still had not finished setting up Maven properly to do that, and it was still compiling with 1.6. - Eric On 2011-10-10 1:30 PM, Ansgar Konermann wrote: Am 10.10.2011 22:15, schrieb Eric Kolotyluk: I am not really sure why no-one recommended this to me in the first place as it effective and simple to understand. Maybe you led the crowd into the wrong direction by claiming: I am almost complete reworking things to run on a Java 5 run-time, and while everything compiles [...] I'd conclude from this, that you're already compiling against version 1.5 and everything actually *does* compile. HTH Ansgar - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Managing Different Java Versions
Ok, just two real world examples: http://svn.codehaus.org/mojo/tags/exec-maven-plugin-1.2.1/pom.xml http://svn.codehaus.org/mojo/tags/sql-maven-plugin-1.5/pom.xml These both verify against the jdk1.4 signatues, but the idea should be clear enough. You'll see that the examples kind of match. Here's the list of available signatures: http://mojo.codehaus.org/signatures/ -Robert Date: Mon, 10 Oct 2011 13:49:53 -0700 From: eric.koloty...@gmail.com To: users@maven.apache.org Subject: Re: Managing Different Java Versions Fair enough. At the time I actually thought I was compiling against 1.5, but in fact I still had not finished setting up Maven properly to do that, and it was still compiling with 1.6. - Eric On 2011-10-10 1:30 PM, Ansgar Konermann wrote: Am 10.10.2011 22:15, schrieb Eric Kolotyluk: I am not really sure why no-one recommended this to me in the first place as it effective and simple to understand. Maybe you led the crowd into the wrong direction by claiming: I am almost complete reworking things to run on a Java 5 run-time, and while everything compiles [...] I'd conclude from this, that you're already compiling against version 1.5 and everything actually *does* compile. HTH Ansgar - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
On 2011-10-10 1:41 PM, Wayne Fay wrote: OK, I still clearly do not understand how sniffer is supposed to work, and it does not look like am going to any time soon, even after all these explanations. A signature is like: char java.lang.String.charAt(int) Animal sniffer compares the Java code you are writing against the published signatures of popular Java APIs like Sun JDK 1.5, 1.6, IBM, JRockit, etc. That's it! If this is helpful to you, use it. If you need other functionality, animal sniffer may not be able to help you. identifying the troublesome jar file. I am not really sure why no-one recommended this to me in the first place as it effective and simple to Uhhh Benson *did* suggest this... did you miss it?? Yes, I did miss it - I guess I got too curious about sniffer - and then frustrated - and then too distracted to go back and read Benson's remarks properly. My bad. On Sun, Oct 9, 2011 at 5:14 PM, Benson Marguliesbimargul...@gmail.com wrote: If you have to support 1.5, the easiest thing to do is eschew the use of 1.6 features. Just set the compiler plugin options for source and target of 1.5. Again, I am at a complete loss to fathom any utility in the sniffer. Maybe I It is quite possible that your needs simply do not match the functionality provided by Animal sniffer. There are a large number of people who find it useful. Their needs may be different from your own. I was unable to determine if sniffer met my needs because I could not understand what it was supposed to do. Perhaps you can summarize in 1 sentence what problem you are trying to solve, then various alternative solutions can be discussed. To check that (1) my sources were compatible with a Java 5 run-time and (2) that any dependencies I was using were also compatible with a Java 5 run-time (in particular that they did not contain version 50 class files). I believe Stephen answered (1) for me quite elegantly. It would help tremendously if his explanation were documented on the introduction page. I'm not sure if sniffer solves (2) which really was my original intent because I had already solved (1) by other means. - Eric Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
On 10 October 2011 22:02, Eric Kolotyluk eric.koloty...@gmail.com wrote: On 2011-10-10 1:41 PM, Wayne Fay wrote: OK, I still clearly do not understand how sniffer is supposed to work, and it does not look like am going to any time soon, even after all these explanations. A signature is like: char java.lang.String.charAt(int) Animal sniffer compares the Java code you are writing against the published signatures of popular Java APIs like Sun JDK 1.5, 1.6, IBM, JRockit, etc. That's it! If this is helpful to you, use it. If you need other functionality, animal sniffer may not be able to help you. identifying the troublesome jar file. I am not really sure why no-one recommended this to me in the first place as it effective and simple to Uhhh Benson *did* suggest this... did you miss it?? Yes, I did miss it - I guess I got too curious about sniffer - and then frustrated - and then too distracted to go back and read Benson's remarks properly. My bad. On Sun, Oct 9, 2011 at 5:14 PM, Benson Marguliesbimargul...@gmail.com wrote: If you have to support 1.5, the easiest thing to do is eschew the use of 1.6 features. Just set the compiler plugin options for source and target of 1.5. Again, I am at a complete loss to fathom any utility in the sniffer. Maybe I It is quite possible that your needs simply do not match the functionality provided by Animal sniffer. There are a large number of people who find it useful. Their needs may be different from your own. I was unable to determine if sniffer met my needs because I could not understand what it was supposed to do. Perhaps you can summarize in 1 sentence what problem you are trying to solve, then various alternative solutions can be discussed. To check that (1) my sources were compatible with a Java 5 run-time and (2) that any dependencies I was using were also compatible with a Java 5 run-time (in particular that they did not contain version 50 class files). I believe Stephen answered (1) for me quite elegantly. It would help tremendously if his explanation were documented on the introduction page. I'm not sure if sniffer solves (2) which really was my original intent because I had already solved (1) by other means. http://mojo.codehaus.org/animal-sniffer/animal-sniffer/usage.html - Eric Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
OK, that page is really clear and helps a lot. Thanks. Unfortunately I do not see any easy way to navigate there from the sniffer site. That would be a very valuable link to add under the examples section. Cheers, Eric On 2011-10-10 1:54 PM, Stephen Connolly wrote: When you are on a Mac you cannot compile with a 1.5 JDK... Have a look at http://mojo.codehaus.org/signatures/java15/ On 10 October 2011 21:49, Eric Kolotylukeric.koloty...@gmail.com wrote: Fair enough. At the time I actually thought I was compiling against 1.5, but in fact I still had not finished setting up Maven properly to do that, and it was still compiling with 1.6. - Eric On 2011-10-10 1:30 PM, Ansgar Konermann wrote: Am 10.10.2011 22:15, schrieb Eric Kolotyluk: I am not really sure why no-one recommended this to me in the first place as it effective and simple to understand. Maybe you led the crowd into the wrong direction by claiming: I am almost complete reworking things to run on a Java 5 run-time, and while everything compiles [...] I'd conclude from this, that you're already compiling against version 1.5 and everything actually *does* compile. HTH Ansgar - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
Thanks for the info Brett. The rest of my response is not directed at you, I just need to vent after trying to understand animal-sniffer. The documentation for the animal-sniffer-maven-plugin is terrible - in particular the examples are abysmal. How are people supposed to learn how to use it - especially for the first time. Just my impression, but whoever(s) designed and documented this plug-in did not seem to have enough pride in their work to motivate others to want to make use of it. In general, why do too many maven documentation authors find it necessary to taunt the reader with examples that sort of explain things, instead of actually explaining things, then forcing the reader to do all kinds of extra research to figure out what the author expects us to just know by ESP or something. Why does too little plugin documentation offer any principles of operation, forcing people to rely on the tribal knowledge in the mail-lists? The wiki was a slight help, and asks some important questions about the poor quality of the documentation, but the wiki is also incomplete with information. To be specific in project modelVersion4.0.0/modelVersion groupId/groupId artifactId/artifactId version/version packagingpom/packaging build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdanimal-sniffer-maven-plugin/artifactId version1.7/version executions execution id___id of execution___/id phasepackage/phase goals goalbuild/goal /goals /execution /executions /plugin /plugins /build /project Would it be too hard to just give specific examples of the execution-id someone might use, such as a best naming practice? Or in project ... build ... plugins ... plugin groupIdorg.codehaus.mojo/groupId artifactIdanimal-sniffer-maven-plugin/artifactId version1.7/version ... configuration ... signature groupId___group id of signature___/groupId artifactId___artifact id of signature___/artifactId version___version of signature___/version /signature ... /configuration ... /plugin ... /plugins ... /build ... /project Would it be too hard to just give some specific examples (as the wiki does)? In particular, the wiki does explain how to find the group-id of signatures. Finally, how am I supposed to figure out if there are any signatures for the hibernate APIs? - Eric On 2011-10-08 10:52 PM, Brett Porter wrote: On 09/10/2011, at 11:25 AM, Eric Kolotyluk wrote: I've been using Maven for about 6 months now so I am still a big green. Recently I discovered that my project needs to be compatible with client code that requires Java 5, because it needs to run on OS 10.5 32-bit Intel. Unfortunately I have been doing all my development with Java 6. I am almost complete reworking things to run on a Java 5 run-time, and while everything compiles, things are dying in hibernate somewhere because there are Java 6 class files in some of the artifacts. Unfortunately from the diaganosics I cannot tell which artifact I am importing that has the Java 6 class files. It should give you the name of the class itself, which you can search for in your repository manager or on one of the public instances of repository search to find out which JAR it is coming from. You might also try the animal sniffer plugin: http://mojo.codehaus.org/animal-sniffer-maven-plugin/examples/generating-other-api-signatures.html Is there some common wisdom or best practices on how to determine which Java versions were used to build an artifact. I know you can specify a java version in the classifier, but is there a way to search for specific coordinates based on the classifier, or some way to tell Maven to only use artifacts with a specific version of Java class files? Maven can't do dependency resolution based on this, because there is no global flag for a JAR that's applicable (each class in it can be different). - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
On 9 October 2011 17:08, Eric Kolotyluk eric.koloty...@gmail.com wrote: Thanks for the info Brett. The rest of my response is not directed at you, I just need to vent after trying to understand animal-sniffer. The documentation for the animal-sniffer-maven-plugin is terrible - in particular the examples are abysmal. How are people supposed to learn how to use it - especially for the first time. Just my impression, but whoever(s) designed and documented this plug-in did not seem to have enough pride in their work to motivate others to want to make use of it. In general, why do too many maven documentation authors find it necessary to taunt the reader with examples that sort of explain things, instead of actually explaining things, then forcing the reader to do all kinds of extra research to figure out what the author expects us to just know by ESP or something. Why does too little plugin documentation offer any principles of operation, forcing people to rely on the tribal knowledge in the mail-lists? The wiki was a slight help, and asks some important questions about the poor quality of the documentation, but the wiki is also incomplete with information. To be specific in project modelVersion4.0.0/**modelVersion groupId/groupId artifactId/artifactId version/version packagingpom/packaging build plugins plugin groupIdorg.codehaus.mojo/**groupId artifactIdanimal-sniffer-**maven-plugin/artifactId version1.7/version executions execution id___id of execution___/id phasepackage/phase goals goalbuild/goal /goals /execution /executions /plugin /plugins /build /project Would it be too hard to just give specific examples of the execution-id someone might use, such as a best naming practice? Or in execution id is part of the standard Maven model. See http://maven.apache.org/pom.html#Plugins for an explanation of what the id is for and how to name it... FYI ___id of execution___ is a perfectly valid value for the execution id ;-) project ... build ... plugins ... plugin groupIdorg.codehaus.mojo/**groupId artifactIdanimal-sniffer-**maven-plugin/artifactId version1.7/version ... configuration ... signature groupId___group id of signature___/groupId artifactId___artifact id of signature___/artifactId version___version of signature___/version /signature ... /configuration ... /plugin ... /plugins ... /build ... /project Would it be too hard to just give some specific examples (as the wiki does)? In particular, the wiki does explain how to find the group-id of signatures. If you want to provide a patch with pointers to the signatures page from the animal sniffer page, please submit the patch, mojo developers are born from submitting patches, and it's the best way to start. There should ideally be links to all the signature sources, including the java.net ones (if you can find where they are hiding now) Finally, how am I supposed to figure out if there are any signatures for the hibernate APIs? I suggest searching in maven repo... but AFAIK there is none - Eric On 2011-10-08 10:52 PM, Brett Porter wrote: On 09/10/2011, at 11:25 AM, Eric Kolotyluk wrote: I've been using Maven for about 6 months now so I am still a big green. Recently I discovered that my project needs to be compatible with client code that requires Java 5, because it needs to run on OS 10.5 32-bit Intel. Unfortunately I have been doing all my development with Java 6. I am almost complete reworking things to run on a Java 5 run-time, and while everything compiles, things are dying in hibernate somewhere because there are Java 6 class files in some of the artifacts. Unfortunately from the diaganosics I cannot tell which artifact I am importing that has the Java 6 class files. It should give you the name of the class itself, which you can search for in your repository manager or on one of the public instances of repository search to find out which JAR it is coming from. You might also try the animal sniffer plugin: http://mojo.codehaus.org/** animal-sniffer-maven-plugin/**examples/generating-other-api-** signatures.htmlhttp://mojo.codehaus.org/animal-sniffer-maven-plugin/examples/generating-other-api-signatures.html Is there some common wisdom or best practices on how to determine which Java versions were used to build an artifact. I know you can specify a java version in the classifier, but is there a way to search for specific coordinates based on the classifier, or some way to tell Maven to only use artifacts with a specific version of Java class files? Maven can't do dependency resolution based on this, because there is no global
Re: Managing Different Java Versions
If you have to support 1.5, the easiest thing to do is eschew the use of 1.6 features. Just set the compiler plugin options for source and target of 1.5. After you do that, you might still want the sniffer, since this does not stop you from accidentally coding calls to methods introduced in 1.6. If you really need 1.6 features, you might consider looking at retroweaver, which can convert 1.6 jars into 1.5 jars. *However*, once you start having two versions of a jar floating around (one for 1.5, one for 1.6), Maven is not really terribly helpful. This is not a use-case, apparently, that was anywhere near the front of the collective Maven mind when the dependency model was designed. As for the comprehensibility of the AS docs, well, KK is one of the smartest, nicest, guys pumping out useful stuff for the rest of us. However, the doc he writes is the doc he writes. Or, for another perspective, I could quote Tom Lehrer: The problem with folk music is that it is written by the people. Considering what you are paying for this stuff, you might be argued to be getting a pretty good deal. My usual modus operandi is to go looking at a live example of the use of something if I am unclear as to how to use it. This can be an interesting easter-egg hunt. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
in fairness i think i wrote most of the docs. Kohsuke's original docs were less than minimal. most of the docs were written while on public transport on a shitty little netbook. i don't currently have the time to prettify the docs further, and when i have time i want to sort out the versions-maven-plugin integration tests so that i can roll releases with new features safely - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 9 Oct 2011 23:14, Benson Margulies bimargul...@gmail.com wrote: If you have to support 1.5, the easiest thing to do is eschew the use of 1.6 features. Just set the compiler plugin options for source and target of 1.5. After you do that, you might still want the sniffer, since this does not stop you from accidentally coding calls to methods introduced in 1.6. If you really need 1.6 features, you might consider looking at retroweaver, which can convert 1.6 jars into 1.5 jars. *However*, once you start having two versions of a jar floating around (one for 1.5, one for 1.6), Maven is not really terribly helpful. This is not a use-case, apparently, that was anywhere near the front of the collective Maven mind when the dependency model was designed. As for the comprehensibility of the AS docs, well, KK is one of the smartest, nicest, guys pumping out useful stuff for the rest of us. However, the doc he writes is the doc he writes. Or, for another perspective, I could quote Tom Lehrer: The problem with folk music is that it is written by the people. Considering what you are paying for this stuff, you might be argued to be getting a pretty good deal. My usual modus operandi is to go looking at a live example of the use of something if I am unclear as to how to use it. This can be an interesting easter-egg hunt. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
On Sun, Oct 9, 2011 at 7:35 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: in fairness i think i wrote most of the docs. Kohsuke's original docs were less than minimal. most of the docs were written while on public transport on a shitty little netbook. Well, little did I know. Having met KK's work before, I just assumed that this was an unusually verbose example :-) i don't currently have the time to prettify the docs further, and when i have time i want to sort out the versions-maven-plugin integration tests so that i can roll releases with new features safely - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 9 Oct 2011 23:14, Benson Margulies bimargul...@gmail.com wrote: If you have to support 1.5, the easiest thing to do is eschew the use of 1.6 features. Just set the compiler plugin options for source and target of 1.5. After you do that, you might still want the sniffer, since this does not stop you from accidentally coding calls to methods introduced in 1.6. If you really need 1.6 features, you might consider looking at retroweaver, which can convert 1.6 jars into 1.5 jars. *However*, once you start having two versions of a jar floating around (one for 1.5, one for 1.6), Maven is not really terribly helpful. This is not a use-case, apparently, that was anywhere near the front of the collective Maven mind when the dependency model was designed. As for the comprehensibility of the AS docs, well, KK is one of the smartest, nicest, guys pumping out useful stuff for the rest of us. However, the doc he writes is the doc he writes. Or, for another perspective, I could quote Tom Lehrer: The problem with folk music is that it is written by the people. Considering what you are paying for this stuff, you might be argued to be getting a pretty good deal. My usual modus operandi is to go looking at a live example of the use of something if I am unclear as to how to use it. This can be an interesting easter-egg hunt. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Managing Different Java Versions
On 09/10/2011, at 11:25 AM, Eric Kolotyluk wrote: I've been using Maven for about 6 months now so I am still a big green. Recently I discovered that my project needs to be compatible with client code that requires Java 5, because it needs to run on OS 10.5 32-bit Intel. Unfortunately I have been doing all my development with Java 6. I am almost complete reworking things to run on a Java 5 run-time, and while everything compiles, things are dying in hibernate somewhere because there are Java 6 class files in some of the artifacts. Unfortunately from the diaganosics I cannot tell which artifact I am importing that has the Java 6 class files. It should give you the name of the class itself, which you can search for in your repository manager or on one of the public instances of repository search to find out which JAR it is coming from. You might also try the animal sniffer plugin: http://mojo.codehaus.org/animal-sniffer-maven-plugin/examples/generating-other-api-signatures.html Is there some common wisdom or best practices on how to determine which Java versions were used to build an artifact. I know you can specify a java version in the classifier, but is there a way to search for specific coordinates based on the classifier, or some way to tell Maven to only use artifacts with a specific version of Java class files? Maven can't do dependency resolution based on this, because there is no global flag for a JAR that's applicable (each class in it can be different). - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
