commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Lundberg <denn...@apache.org>
Subject Re: [all] Showing the Java Version on component sites
Date Sat, 08 Mar 2008 16:19:40 GMT
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.

But in the case of the currently deployed site of commons-logging, the 
JDK used to build the released jar is not the same as the JDK that was 
used to build the site.

By this I mean that it is impossible (or at least very hard) to know 
what JDK was used to build the jar file. Simply because they might be 
built by different people on different platforms at different points in 
time. The only way to know for sure would be to inspect the jar file 
itself, as suggested by sebb. But, as is the case here, that jar file 
might have already been deployed.

The JDK used to build the jar file is what is interesting to our users. 
They couldn't care less which version was used to build the site. Right?

> 
> Niall
> 
>>  > Niall
>>  >
>>  >>  This is related to publishing versioned sites that I touched upon in
>>  >>  another mail.
>>  >>
>>  >>
>>  >>  >
>>  >>  > BeanUtils is an example of the same source/target versions:
>>  >>  >    http://commons.apache.org/beanutils/dependencies.html
>>  >>  >    http://commons.apache.org/beanutils/project-summary.html
>>  >>  >
>>  >>  > My preference is to have it on the dependencies page, because I think
>>  >>  > people are more likely to look there - but perhaps both places would
>>  >>  > be good. I haven't had any feedback since I submitted the second
>>  >>  > pacth, so If you think its a good idea for commons then it would
be
>>  >>  > good to vote for that JIRA bug:
>>  >>  >
>>  >>  > http://jira.codehaus.org/browse/MPIR-80
>>  >>  >
>>  >>  > Niall
> 
> ---------------------------------------------------------------------
> 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


Mime
View raw message