sebb wrote:
On 09/03/2008, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Niall Pemberton wrote:
> On Sun, Mar 9, 2008 at 10:50 AM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
>> Niall Pemberton wrote:
>> > On Sat, Mar 8, 2008 at 4:19 PM, Dennis Lundberg <[EMAIL PROTECTED]>
wrote:
>> >> Niall Pemberton wrote:
>> >> > On Thu, Mar 6, 2008 at 10:00 PM, Dennis Lundberg <[EMAIL PROTECTED]>
wrote:
>> >> >> Niall Pemberton wrote:
>> >> >> > On Thu, Mar 6, 2008 at 7:38 PM, Dennis Lundberg <[EMAIL
PROTECTED]> 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.
Yes we agree.
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.
At this point in time it seems that automating this comes with a few
hazards, that needs to be fixed. Until that is done I propose that we
advertise this manually in one of the site files.
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
