Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of sebbaz@gmail.com designates
 72.14.204.233 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=iUIxdZKoUVSjg6Kwyqx6Pxlq4ge4z/4aGN6c6Ld00uwQUu3iMjFPaA5BiNpeflW7kyEA4HzahCrAcGjdMQBQoCls8AO17J2d2Uvk/YnAC9TXzW+nPZz+0iVEYSLTlnt5QlFtqOYvPJPoXSlYMEt+sqdA084n7CHOa6Wnf1xjYkI=
Message-ID: <25aac9fc0803090921j313f8dbaj6ac406540eeeb99@mail.gmail.com>
Date: Sun, 9 Mar 2008 16:21:11 +0000
From: sebb <sebbaz@gmail.com>
To: "Jakarta Commons Developers List" <dev@commons.apache.org>
Subject: Re: [all] Showing the Java Version on component sites
In-Reply-To: <47D3E8C3.60805@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <55afdc850803050737r4956de15od6d0561c7d66f06f@mail.gmail.com>
	 <47D0482B.3060908@apache.org>
	 <55afdc850803061214i48f1933bu2dc81e0b2fd1c10f@mail.gmail.com>
	 <47D0698A.2070202@apache.org>
	 <55afdc850803061514o2a9d047ck9295b15c7d2e326a@mail.gmail.com>
	 <47D2BC9C.9030209@apache.org>
	 <55afdc850803090316l5c4925d7v8e4155ed0fb7a97@mail.gmail.com>
	 <47D3C111.8040909@apache.org>
	 <55afdc850803090526j2182a680i3c6bb102108a1702@mail.gmail.com>
	 <47D3E8C3.60805@apache.org>

On 09/03/2008, Dennis Lundberg <dennisl@apache.org> wrote:
> Niall Pemberton wrote:
>  > On Sun, Mar 9, 2008 at 10:50 AM, Dennis Lundberg <dennisl@apache.org> wrote:
>  >> Niall Pemberton wrote:
>  >>  > On Sat, Mar 8, 2008 at 4:19 PM, Dennis Lundberg <dennisl@apache.org> wrote:
>  >>  >> Niall Pemberton wrote:
>  >>  >>  > On Thu, Mar 6, 2008 at 10:00 PM, Dennis Lundberg <dennisl@apache.org> wrote:
>  >>  >>  >> Niall Pemberton wrote:
>  >>  >>  >>  > On Thu, Mar 6, 2008 at 7:38 PM, Dennis Lundberg <dennisl@apache.org> wrote:
>  >>  >>  >>  >> Niall Pemberton wrote:
>  >>  >>  >>  >>  > I just re-published all the component sites and notice that (by
>  >>  >>  >>  >>  > mistake) it had used a patched copy of the
>  >>  >>  >>  >>  > maven-project-info-reports-plugin that I have in my local repo
>  >>  >>  >>  >>  > (sorry!). Anyway I submitted a patch to maven to include the Java
>  >>  >>  >>  >>  > version on the dependencies page. The feedback I got was they prefer
>  >>  >>  >>  >>  > it on the project summary page - so I submitted a patch for that as
>  >>  >>  >>  >>  > well.
>  >>  >>  >>  >>  >
>  >>  >>  >>  >>  > Logging is an example of using different source/target versions:
>  >>  >>  >>  >>  >    http://commons.apache.org/logging/dependencies.html
>  >>  >>  >>  >>  >    http://commons.apache.org/logging/project-summary.html
>  >>  >>  >>  >>
>  >>  >>  >>  >>  The part about "It has been built using Java 1.5" in the dependencies
>  >>  >>  >>  >>  report isn't accurate. 1.5 is the version used (by you) to build and
>  >>  >>  >>  >>  publish the site. I used 1.4 when I did the logging release, so having
>  >>  >>  >>  >>  anything else there is misleading. I think that part should be removed.
>  >>  >>  >>  >>  What extra value does it give to users, providing it was correct?
>  >>  >>  >>  >
>  >>  >>  >>  > I could ask the same question of maven and the Build-Jdk it puts in
>  >>  >>  >>  > the manifest which is really mis-leading since the source/target
>  >>  >>  >>  > settings are missing - except here in commons.
>  >>  >>  >>
>  >>  >>  >>  The Build-Jdk in this case is the actual JDK that was used to produce
>  >>  >>  >>  the jar file. So it is correct. Having the source and target in there is
>  >>  >>  >>  much better though, for the reasons you mention below.
>  >>  >>  >>
>  >>  >>  >>
>  >>  >>  >>  > My answer though is its a warning - since setting the target option
>  >>  >>  >>  > doesn't actually guarantee it will run on that version if API's from
>  >>  >>  >>  > later java versions have been used.
>  >>  >>  >>
>  >>  >>  >>  But in this case it's not a warning. It the JDK that was used to build
>  >>  >>  >>  the *site* - not the jar file. That doesn't tell a user anything.
>  >>  >>  >
>  >>  >>  > OK looks like we're mis-communicating here - what exactly did you mean
>  >>  >>  > by "providing it was correct" in your original question? I took it to
>  >>  >>  > mean "providing it was the value used to build the jar for the
>  >>  >>  > release".
>  >>  >>
>  >>  >>  Right, that's what I meant.
>  >>  >
>  >>  > OK well that was the question I was answering - not if it wasn't
>  >>  > correct which I didn't disagree with.
>  >>
>  >>  Great, so do we agree on this summary?
>  >
>  > No not really - the source and target versions don't necessarily
>  > relate to the release either. Take codec - Henri just bumped that up
>  > to 1.4 - but the Codec 1.3 release was (I assume) JDK 1.3 compatible.
>
>
> I was asking, because I wanted to fix and close MPIR-80.
>
>  We really do need properly versioned sites, for your patch to be used
>  without the risk of misinformation.
>

I hope we can all agree that it is important for the user to be able
to quickly discover which version of the JVM is required to run a
particular release of Commons Foo.

Whether this is done automatically from the appropriate source, or
whether this is done by manually editting a list of versions is not
important as far as the end-user is concerned; all they care about is
that Commons Foo 1.3 will run on Java 1.3 and Commons Foo 2.0 requires
Java 7 as a minimum.

>
>  > Niall
>  >
>  >>  - It is good to put the "source" and "target" version parameters for the
>  >>  compiler plugin in the reports.
>  >>
>  >>  - It is bad to put the JDK version in the reports, because it is too
>  >>  difficult to get the correct value for it.
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  > For additional commands, e-mail: dev-help@commons.apache.org
>  >
>  >
>
>
>
> --
>
> Dennis Lundberg
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>  For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org