Re: Managing Different Java Versions

[Brett Porter]

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

Re: Managing Different Java Versions

[Eric Kolotyluk]

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


  4.0.0
  
  
  
  pom
  

  
org.codehaus.mojo
animal-sniffer-maven-plugin
1.7

  
___id of execution___
package

  build

  

  

  


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



  ...
  
...

  ...
  
org.codehaus.mojo
animal-sniffer-maven-plugin
1.7
...

  ...
  
___group id of signature___
___artifact id of signature___
___version of signature___
  
  ...

...
  
  ...

...
  
  ...


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

[Stephen Connolly]

On 9 October 2011 17:08, Eric Kolotyluk  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
>
> 
>  4.0.0
>  
>  
>  
>  pom
>  
>
>  
>org.codehaus.mojo
>animal-sniffer-**maven-plugin
>1.7
>
>  
>___id of execution___
>package
>
>  build
>
>  
>
>  
>
>  
> 
>
> 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 ;-)



> 
>  ...
>  
>...
>
>  ...
>  
>org.codehaus.mojo
>animal-sniffer-**maven-plugin
>1.7
>...
>
>  ...
>  
>___group id of signature___
>___artifact id of signature___
>___version of signature___
>  
>  ...
>
>...
>  
>  ...
>
>...
>  
>  ...
> 
>
> 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.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-unsubscribe@maven.**

Re: Managing Different Java Versions

[Benson Margulies]

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

[Stephen Connolly]

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"  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

[Benson Margulies]

On Sun, Oct 9, 2011 at 7: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.

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"  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

[Anders Hammar]

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  wrote:
> On Sun, Oct 9, 2011 at 7: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.
>
> 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"  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

[Eric Kolotyluk]

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

[Eric Kolotyluk]

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 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.

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

[Wayne Fay]

>> 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=Everything&language=&q=animal-sniffer-maven-plugin&repo=&langOverride=&x=12&y=16&start_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

[Eric Kolotyluk]

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 Margulies  wrote:

On Sun, Oct 9, 2011 at 7: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.

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"  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

[Wayne Fay]

> 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

[Eric Kolotyluk]

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

[Stephen Connolly]

On 10 October 2011 21:15, Eric Kolotyluk  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
1.5 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

[Ansgar Konermann]

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

[Wayne Fay]

> 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  
> 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

[Eric Kolotyluk]

On 2011-10-10 1:28 PM, Stephen Connolly wrote:

On 10 October 2011 21:15, Eric Kolotyluk  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
1.5  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

[Eric Kolotyluk]

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

[Stephen Connolly]

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  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

[Robert Scholte]

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

[Eric Kolotyluk]

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 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.

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

[Stephen Connolly]

On 10 October 2011 22:02, Eric Kolotyluk  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 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.
>>>
>>> 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

[Eric Kolotyluk]

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 Kolotyluk  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

[Benson Margulies]

The following is probably too late to be useful.

In my foggy memory, my sense is that the exception error message for
the class format error identifies a class name. Under normal
conditions, it's not terribly hard to map a class name to a jar.
Personally, I use grep, because ZIP files (JAR files being ZIP files
in drag) have their contents in plain old greppable format. If all
else fails,

   find ~/.m2/repository -name "*.jar" -exec grep com.whatever.Whoever
{} \; -print

will do the job.

So the sniffer is not in the business of helping with this case. As
now elaborated on this thread, the sniffer was invented to solve a
very particular problem that compiling with the source and target
options to javac, while it prevents format errors, isn't enough to
avoid new JRE dependencies.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Managing Different Java Versions

[Anders Hammar]

> 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

[Eric Kolotyluk]

So, if what I want is to avoid calling any Java 6 methods I would use


org.codehaus.mojo
animal-sniffer-maven-plugin
1.3


check-java16
test

check



org.codehaus.mojo.signature
java16
1.0






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: 
com/kodak/intersystem/common/Application.stopping#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: 
com/kodak/intersy

Re: Managing Different Java Versions

[Stephen Connolly]

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  wrote:
> So, if what I want is to avoid calling any Java 6 methods I would use
>
> 
> org.codehaus.mojo
> animal-sniffer-maven-plugin
> 1.3
> 
> 
> check-java16
> test
> 
> check
> 
> 
> 
> org.codehaus.mojo.signature
> java16
> 1.0
> 
> 
> 
> 
> 
>
> 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] U

Re: Managing Different Java Versions

[Eric Kolotyluk]

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 Kolotyluk  wrote:

So, if what I want is to avoid calling any Java 6 methods I would use


org.codehaus.mojo
animal-sniffer-maven-plugin
1.3


check-java16
test

check



org.codehaus.mojo.signature
java16
1.0






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

Re: Managing Different Java Versions

[Eric Kolotyluk]

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

[Andy Glick]

Wanted to add a "plug" for the versions-maven-plugin


org.codehaus.mojo
versions-maven-plugin
1.2


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 Kolotyluk  wrote:

So, if what I want is to avoid calling any Java 6 methods I would use


org.codehaus.mojo
animal-sniffer-maven-plugin
1.3


check-java16
test

check



org.codehaus.mojo.signature
java16
1.0






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

Re: Managing Different Java Versions

[Anders Hammar]

> 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