You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Niall Pemberton <ni...@gmail.com> on 2008/03/05 16:37:52 UTC
[all] Showing the Java Version on component sites
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
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
Re: [all] Showing the Java Version on component sites
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Mar 5, 2008 at 3:51 PM, Gary Gregory
<GG...@seagullsoftware.com> wrote:
> Feel free to use this compatibility information: http://garygregory.com/os/builds/index.html
> I run it from time to time or on demand.
Could you run it for the current trunk of lang as I think Henri's
gearing up for a release.
Niall
> Gary
>
>
> > -----Original Message-----
> > From: Niall Pemberton [mailto:niall.pemberton@gmail.com]
> > Sent: Wednesday, March 05, 2008 7:38 AM
> > To: Commons Developers List
> > Subject: [all] Showing the Java Version on component sites
> >
> > 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
> >
> > 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
>
>
> ---------------------------------------------------------------------
> 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
Re: [all] Showing the Java Version on component sites
Posted by Emmanuel Bourg <eb...@apache.org>.
Gary Gregory a écrit :
>> Really nice ! If you have some time to add Commons Configuration that
>> would be great.
>
> Et hop: http://garygregory.com/os/builds/index.html#commons-configuration-1.5
Thank you! The failure on Java 1.3 is not surprising (missing JDBC
classes that can't be fetched automatically). Harmony has an issue with
the UnicodeBig encoding, that breaks one of the tests.
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [all] Showing the Java Version on component sites
Posted by Gary Gregory <GG...@seagullsoftware.com>.
> -----Original Message-----
> From: Emmanuel Bourg [mailto:ebourg@apache.org]
> Sent: Wednesday, March 05, 2008 12:12 PM
> To: Jakarta Commons Developers List
> Subject: Re: [all] Showing the Java Version on component sites
>
> Gary Gregory a écrit :
> > Feel free to use this compatibility information:
> http://garygregory.com/os/builds/index.html
> > I run it from time to time or on demand.
> >
> > Gary
>
> Really nice ! If you have some time to add Commons Configuration that
> would be great.
Et hop: http://garygregory.com/os/builds/index.html#commons-configuration-1.5
Gary
>
> I'd love to have this kind of report for the nightly builds, on several
> platforms, with all the VMs available (including Java 7 and GNU
> Classpath)... Just dreaming :)
>
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> 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
Re: [all] Showing the Java Version on component sites
Posted by Emmanuel Bourg <eb...@apache.org>.
Gary Gregory a écrit :
> Feel free to use this compatibility information: http://garygregory.com/os/builds/index.html
> I run it from time to time or on demand.
>
> Gary
Really nice ! If you have some time to add Commons Configuration that
would be great.
I'd love to have this kind of report for the nightly builds, on several
platforms, with all the VMs available (including Java 7 and GNU
Classpath)... Just dreaming :)
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [all] Showing the Java Version on component sites
Posted by Gary Gregory <GG...@seagullsoftware.com>.
Feel free to use this compatibility information: http://garygregory.com/os/builds/index.html
I run it from time to time or on demand.
Gary
> -----Original Message-----
> From: Niall Pemberton [mailto:niall.pemberton@gmail.com]
> Sent: Wednesday, March 05, 2008 7:38 AM
> To: Commons Developers List
> Subject: [all] Showing the Java Version on component sites
>
> 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
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Showing the Java Version on component sites
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> On Wed, Mar 5, 2008 at 3:58 PM, sebb <se...@gmail.com> wrote:
>> On 05/03/2008, Niall Pemberton <ni...@gmail.com> 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 version on the latter page shows 1.1.2-SNAPSHOT.
>> Surely it should be 1.1.1 - which is the current version?
>
> This is built from the current trunk - so its correct for whats in the
> trunk - as is the whole web site.
>
>> > 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
>> >
>>
>> Likewise, the version is not the current version.
>>
>> I think the dependencies page needs to list the POM version used to
>> provide the details (this is already on the summary page); I've
>> updated the JIRA issue accordingly.
>
> Commons Skin specifies this and with version 2.0-beta-6 of the
> maven-site-plugin (which commons-parent 8 specifies) it works (see the
> beanutils pages) - however logging overrides commons-parent specifying
> 2.0-beta-5 of the maven-site-plugin and the version doesn't appear -
> so need to remove that from logging's pom.
That's because the latest logging release predates the site plugin
version 2.0-beta-6.
>> > 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.
>>
>> Both is better.
>>
>> ==
>>
>> Where a project lists multiple releases, it seems to me it would be
>> useful to have the dependency and project information available for
>> all the displayed releases, not just the current one.
>
> The patch I put forward for the mave plugin just picks up the
> configuration options used by the maven-compiler-plugin at the time.
> Working out the java versions for all releases would be many times
> more difficult. Probably the best way to do that would be simply to
> record that information in a hand-written page for each component. Not
> something I'm interested in doing but if you feel its important then
> go for it.
>
>> In any case, the information should relate to at lease one of the
>> releases - not whatever happens to be current in SVN which is what
>> seems to be happening at present.
>
> Same answer as above.
>
> Niall
>
>> > 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
>>
>> Updated and voted on.
>>
>>
>>
>> > 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
Re: [all] Showing the Java Version on component sites
Posted by sebb <se...@gmail.com>.
On 05/03/2008, Niall Pemberton <ni...@gmail.com> wrote:
> On Wed, Mar 5, 2008 at 5:25 PM, sebb <se...@gmail.com> wrote:
> > On 05/03/2008, Niall Pemberton <ni...@gmail.com> wrote:
> > > On Wed, Mar 5, 2008 at 3:58 PM, sebb <se...@gmail.com> wrote:
> > > > On 05/03/2008, Niall Pemberton <ni...@gmail.com> 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 version on the latter page shows 1.1.2-SNAPSHOT.
> > > > Surely it should be 1.1.1 - which is the current version?
> > >
> > >
> > > This is built from the current trunk - so its correct for whats in the
> > > trunk - as is the whole web site.
> > >
> >
> > In which case I think the information should probably be removed, as
> > it is misleading.
> >
> >
> > > > > 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
> > > > >
> > > >
> > > > Likewise, the version is not the current version.
> > > >
> > > > I think the dependencies page needs to list the POM version used to
> > > > provide the details (this is already on the summary page); I've
> > > > updated the JIRA issue accordingly.
> > >
> > >
> > > Commons Skin specifies this and with version 2.0-beta-6 of the
> > > maven-site-plugin (which commons-parent 8 specifies) it works (see the
> > > beanutils pages) -
> >
> > It only appears in the page header; I meant that it should be stated
> > in the page body, e.g.
> >
> > instead of:
> >
> > This project requires a minimum of Java 1.3.
> >
> > it would read something like:
> >
> > Version xxx of this project requires a minimum of Java 1.3.
>
>
> You can request that on the JIRA issue for the maven ticket, probably
> more likely to get accepted if you submit a patch with it.
>
OK, I'll look into that.
>
> > > however logging overrides commons-parent specifying
> > > 2.0-beta-5 of the maven-site-plugin and the version doesn't appear -
> > > so need to remove that from logging's pom.
> > >
> >
> > Would not be necessary if the above change was implemented.
>
>
> And the other way round - doing that makes adding the version unnecessary.
True, but I think it's clearer to have it all together, as on the summary page.
>
> > > > > 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.
> > > >
> > > > Both is better.
> > > >
> > > > ==
> > > >
> > > > Where a project lists multiple releases, it seems to me it would be
> > > > useful to have the dependency and project information available for
> > > > all the displayed releases, not just the current one.
> > >
> > >
> > > The patch I put forward for the mave plugin just picks up the
> > > configuration options used by the maven-compiler-plugin at the time.
> > >
> > > Working out the java versions for all releases would be many times
> > > more difficult.
> >
> > How difficult would it be to provide the information for just the
> > latest release?
>
>
> I wouldn't really know where to start. I guess you would have to
> analyse the pom the release was made with - resolving properties
> including those inherited from commons-parent - but my patch also
> finds the current Java version being used - how you would find that
> out I don't know.
"Being used" - is that the Java compiler version used to generate the
documentation?
So unless the same version is also used to build and test the product,
the version will not agree?
At present I cannot see the point of having the information if it does
not necessarily agree with anything the user can download.
As to generating documentation for a specific version after the build,
the manifests in the jar(s) may contain the version information; if
they do, it should be accurate.
> Its a completely different ball game from just
> picking up another plugins configuration and the current java version
> while the project is being built. Which is why I said probably easier
> to just hand write.
>
>
> > > Probably the best way to do that would be simply to
> > > record that information in a hand-written page for each component. Not
> > > something I'm interested in doing but if you feel its important then
> > > go for it.
> >
> > I think it's important that users can easily find out which versions
> > of Java (and indeed which other dependencies) are required for a
> > particular version of a product.
>
>
> Thats fine to say, but someone needs to actually do it - otherwise its
> down to whether the devs on individual components can be bothered.
I'm inclined to say it should be a requirement...
>
> Niall
>
>
> > > > In any case, the information should relate to at lease one of the
> > > > releases - not whatever happens to be current in SVN which is what
> > > > seems to be happening at present.
> > >
> > >
> > > Same answer as above.
> > >
> > >
> > > Niall
> > >
> > >
> > > > > 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
> > > >
> > > > Updated and voted on.
> > > >
> > > >
> > > >
> > > > > Niall
> > >
> >
> >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
> ---------------------------------------------------------------------
> 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
Re: [all] Showing the Java Version on component sites
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Mar 5, 2008 at 5:25 PM, sebb <se...@gmail.com> wrote:
> On 05/03/2008, Niall Pemberton <ni...@gmail.com> wrote:
> > On Wed, Mar 5, 2008 at 3:58 PM, sebb <se...@gmail.com> wrote:
> > > On 05/03/2008, Niall Pemberton <ni...@gmail.com> 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 version on the latter page shows 1.1.2-SNAPSHOT.
> > > Surely it should be 1.1.1 - which is the current version?
> >
> >
> > This is built from the current trunk - so its correct for whats in the
> > trunk - as is the whole web site.
> >
>
> In which case I think the information should probably be removed, as
> it is misleading.
>
>
> > > > 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
> > > >
> > >
> > > Likewise, the version is not the current version.
> > >
> > > I think the dependencies page needs to list the POM version used to
> > > provide the details (this is already on the summary page); I've
> > > updated the JIRA issue accordingly.
> >
> >
> > Commons Skin specifies this and with version 2.0-beta-6 of the
> > maven-site-plugin (which commons-parent 8 specifies) it works (see the
> > beanutils pages) -
>
> It only appears in the page header; I meant that it should be stated
> in the page body, e.g.
>
> instead of:
>
> This project requires a minimum of Java 1.3.
>
> it would read something like:
>
> Version xxx of this project requires a minimum of Java 1.3.
You can request that on the JIRA issue for the maven ticket, probably
more likely to get accepted if you submit a patch with it.
> > however logging overrides commons-parent specifying
> > 2.0-beta-5 of the maven-site-plugin and the version doesn't appear -
> > so need to remove that from logging's pom.
> >
>
> Would not be necessary if the above change was implemented.
And the other way round - doing that makes adding the version unnecessary.
> > > > 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.
> > >
> > > Both is better.
> > >
> > > ==
> > >
> > > Where a project lists multiple releases, it seems to me it would be
> > > useful to have the dependency and project information available for
> > > all the displayed releases, not just the current one.
> >
> >
> > The patch I put forward for the mave plugin just picks up the
> > configuration options used by the maven-compiler-plugin at the time.
> >
> > Working out the java versions for all releases would be many times
> > more difficult.
>
> How difficult would it be to provide the information for just the
> latest release?
I wouldn't really know where to start. I guess you would have to
analyse the pom the release was made with - resolving properties
including those inherited from commons-parent - but my patch also
finds the current Java version being used - how you would find that
out I don't know. Its a completely different ball game from just
picking up another plugins configuration and the current java version
while the project is being built. Which is why I said probably easier
to just hand write.
> > Probably the best way to do that would be simply to
> > record that information in a hand-written page for each component. Not
> > something I'm interested in doing but if you feel its important then
> > go for it.
>
> I think it's important that users can easily find out which versions
> of Java (and indeed which other dependencies) are required for a
> particular version of a product.
Thats fine to say, but someone needs to actually do it - otherwise its
down to whether the devs on individual components can be bothered.
Niall
> > > In any case, the information should relate to at lease one of the
> > > releases - not whatever happens to be current in SVN which is what
> > > seems to be happening at present.
> >
> >
> > Same answer as above.
> >
> >
> > Niall
> >
> >
> > > > 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
> > >
> > > Updated and voted on.
> > >
> > >
> > >
> > > > Niall
> >
>
>
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Showing the Java Version on component sites
Posted by sebb <se...@gmail.com>.
On 05/03/2008, Niall Pemberton <ni...@gmail.com> wrote:
> On Wed, Mar 5, 2008 at 3:58 PM, sebb <se...@gmail.com> wrote:
> > On 05/03/2008, Niall Pemberton <ni...@gmail.com> 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 version on the latter page shows 1.1.2-SNAPSHOT.
> > Surely it should be 1.1.1 - which is the current version?
>
>
> This is built from the current trunk - so its correct for whats in the
> trunk - as is the whole web site.
>
In which case I think the information should probably be removed, as
it is misleading.
> > > 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
> > >
> >
> > Likewise, the version is not the current version.
> >
> > I think the dependencies page needs to list the POM version used to
> > provide the details (this is already on the summary page); I've
> > updated the JIRA issue accordingly.
>
>
> Commons Skin specifies this and with version 2.0-beta-6 of the
> maven-site-plugin (which commons-parent 8 specifies) it works (see the
> beanutils pages) -
It only appears in the page header; I meant that it should be stated
in the page body, e.g.
instead of:
This project requires a minimum of Java 1.3.
it would read something like:
Version xxx of this project requires a minimum of Java 1.3.
> however logging overrides commons-parent specifying
> 2.0-beta-5 of the maven-site-plugin and the version doesn't appear -
> so need to remove that from logging's pom.
>
Would not be necessary if the above change was implemented.
>
> > > 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.
> >
> > Both is better.
> >
> > ==
> >
> > Where a project lists multiple releases, it seems to me it would be
> > useful to have the dependency and project information available for
> > all the displayed releases, not just the current one.
>
>
> The patch I put forward for the mave plugin just picks up the
> configuration options used by the maven-compiler-plugin at the time.
>
> Working out the java versions for all releases would be many times
> more difficult.
How difficult would it be to provide the information for just the
latest release?
> Probably the best way to do that would be simply to
> record that information in a hand-written page for each component. Not
> something I'm interested in doing but if you feel its important then
> go for it.
I think it's important that users can easily find out which versions
of Java (and indeed which other dependencies) are required for a
particular version of a product.
>
> > In any case, the information should relate to at lease one of the
> > releases - not whatever happens to be current in SVN which is what
> > seems to be happening at present.
>
>
> Same answer as above.
>
>
> Niall
>
>
> > > 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
> >
> > Updated and voted on.
> >
> >
> >
> > > Niall
>
> ---------------------------------------------------------------------
> 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
Re: [all] Showing the Java Version on component sites
Posted by Niall Pemberton <ni...@gmail.com>.
On Wed, Mar 5, 2008 at 3:58 PM, sebb <se...@gmail.com> wrote:
> On 05/03/2008, Niall Pemberton <ni...@gmail.com> 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 version on the latter page shows 1.1.2-SNAPSHOT.
> Surely it should be 1.1.1 - which is the current version?
This is built from the current trunk - so its correct for whats in the
trunk - as is the whole web site.
> > 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
> >
>
> Likewise, the version is not the current version.
>
> I think the dependencies page needs to list the POM version used to
> provide the details (this is already on the summary page); I've
> updated the JIRA issue accordingly.
Commons Skin specifies this and with version 2.0-beta-6 of the
maven-site-plugin (which commons-parent 8 specifies) it works (see the
beanutils pages) - however logging overrides commons-parent specifying
2.0-beta-5 of the maven-site-plugin and the version doesn't appear -
so need to remove that from logging's pom.
> > 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.
>
> Both is better.
>
> ==
>
> Where a project lists multiple releases, it seems to me it would be
> useful to have the dependency and project information available for
> all the displayed releases, not just the current one.
The patch I put forward for the mave plugin just picks up the
configuration options used by the maven-compiler-plugin at the time.
Working out the java versions for all releases would be many times
more difficult. Probably the best way to do that would be simply to
record that information in a hand-written page for each component. Not
something I'm interested in doing but if you feel its important then
go for it.
> In any case, the information should relate to at lease one of the
> releases - not whatever happens to be current in SVN which is what
> seems to be happening at present.
Same answer as above.
Niall
> > 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
>
> Updated and voted on.
>
>
>
> > Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Showing the Java Version on component sites
Posted by Henri Yandell <fl...@gmail.com>.
On Thu, Mar 6, 2008 at 11:29 AM, Dennis Lundberg <de...@apache.org> wrote:
> sebb wrote:
> > On 05/03/2008, Niall Pemberton <ni...@gmail.com> 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 version on the latter page shows 1.1.2-SNAPSHOT.
> > Surely it should be 1.1.1 - which is the current version?
>
> This is what happens when you re-publish the site for a Maven 2 project,
> post release. We should establish a policy (if there isn't one already)
> regarding when, who and how it is allowed to re-publish a component's site.
Any committer; any time; whatever the process is :)
Problem is the bad content, not the policy on site building. We should
fix the content. Sites are not related to builds, that's confused
maven for ages because it confuses sites with documentation.
Not very practical; but:
* package all the valuable reports for a release in one directory;
that means the ones with content rather than the code quality ones. No
one gives a crap about the quality of 1.0 etc.
* Build a site around those versioned report directories.
* Have a development report directory which is hooked to snapshot.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Showing the Java Version on component sites
Posted by Dennis Lundberg <de...@apache.org>.
sebb wrote:
> On 05/03/2008, Niall Pemberton <ni...@gmail.com> 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 version on the latter page shows 1.1.2-SNAPSHOT.
> Surely it should be 1.1.1 - which is the current version?
This is what happens when you re-publish the site for a Maven 2 project,
post release. We should establish a policy (if there isn't one already)
regarding when, who and how it is allowed to re-publish a component's site.
Over in Maven-land we have just started using a mechanism that publishes
the site for a released version in one place and a snapshot site in
another place. Perhaps this can be used in commons as well?
>> 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
>>
>
> Likewise, the version is not the current version.
>
> I think the dependencies page needs to list the POM version used to
> provide the details (this is already on the summary page); I've
> updated the JIRA issue accordingly.
>
>> 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.
>
> Both is better.
>
> ==
>
> Where a project lists multiple releases, it seems to me it would be
> useful to have the dependency and project information available for
> all the displayed releases, not just the current one.
>
> In any case, the information should relate to at lease one of the
> releases - not whatever happens to be current in SVN which is what
> seems to be happening at present.
>
>> 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
>
> Updated and voted on.
>
>> Niall
>>
>> ---------------------------------------------------------------------
>> 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
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Showing the Java Version on component sites
Posted by sebb <se...@gmail.com>.
On 05/03/2008, Niall Pemberton <ni...@gmail.com> 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 version on the latter page shows 1.1.2-SNAPSHOT.
Surely it should be 1.1.1 - which is the current version?
> 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
>
Likewise, the version is not the current version.
I think the dependencies page needs to list the POM version used to
provide the details (this is already on the summary page); I've
updated the JIRA issue accordingly.
> 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.
Both is better.
==
Where a project lists multiple releases, it seems to me it would be
useful to have the dependency and project information available for
all the displayed releases, not just the current one.
In any case, the information should relate to at lease one of the
releases - not whatever happens to be current in SVN which is what
seems to be happening at present.
> 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
Updated and voted on.
> Niall
>
> ---------------------------------------------------------------------
> 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
Re: [all] Showing the Java Version on component sites
Posted by Niall Pemberton <ni...@gmail.com>.
On Sun, Mar 9, 2008 at 4:21 PM, sebb <se...@gmail.com> wrote:
>
> On 09/03/2008, Dennis Lundberg <de...@apache.org> wrote:
> > Niall Pemberton wrote:
> > > On Sun, Mar 9, 2008 at 10:50 AM, Dennis Lundberg <de...@apache.org> wrote:
> > >> Niall Pemberton wrote:
> > >> > On Sat, Mar 8, 2008 at 4:19 PM, Dennis Lundberg <de...@apache.org> wrote:
> > >> >> Niall Pemberton wrote:
> > >> >> > On Thu, Mar 6, 2008 at 10:00 PM, Dennis Lundberg <de...@apache.org> wrote:
> > >> >> >> Niall Pemberton wrote:
> > >> >> >> > On Thu, Mar 6, 2008 at 7:38 PM, Dennis Lundberg <de...@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.
I would say nice-to-have rather than *important*. Things I would term
*important* would be show-stoppers for a release and this IMO doesn't
fit that category.
Niall
> 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
Re: [all] Showing the Java Version on component sites
Posted by Henri Yandell <fl...@gmail.com>.
Plus link to the javadoc and the release notes please. And maybe the license.
It's going to look like an xdoc page :)
Hen
On Sun, Mar 9, 2008 at 6:04 PM, James Carman <ja...@carmanconsulting.com> wrote:
> Perhaps there could be a maven plugin report for this? It could be
> configured in the pom?
>
> <configuration>
> <releases>
> <release>
> <name>1.0</name>
> <date>01/01/1970</date>
> <minimumJavaVersion>1.2</minimumJavaVersion>
> </release>
> </release>
> </configuration>
>
>
>
>
> On 3/9/08, Henri Yandell <fl...@gmail.com> wrote:
> > On Sun, Mar 9, 2008 at 11:25 AM, Dennis Lundberg <de...@apache.org> wrote:
> > >
> > > 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.
> >
> >
> > I'll go as far as to say automating is impossible. It'll only work if
> > you make the bad assumption of site==documentation.
> >
> > ie) The site should say what the JDK version is for _all_ releases.
> >
> > Add it manually to:
> >
> > http://commons.apache.org/lang/release-history.html
> >
> > etc.
> >
> > Hen
> >
> >
>
>
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Showing the Java Version on component sites
Posted by James Carman <ja...@carmanconsulting.com>.
Perhaps there could be a maven plugin report for this? It could be
configured in the pom?
<configuration>
<releases>
<release>
<name>1.0</name>
<date>01/01/1970</date>
<minimumJavaVersion>1.2</minimumJavaVersion>
</release>
</release>
</configuration>
On 3/9/08, Henri Yandell <fl...@gmail.com> wrote:
> On Sun, Mar 9, 2008 at 11:25 AM, Dennis Lundberg <de...@apache.org> wrote:
> >
> > 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.
>
>
> I'll go as far as to say automating is impossible. It'll only work if
> you make the bad assumption of site==documentation.
>
> ie) The site should say what the JDK version is for _all_ releases.
>
> Add it manually to:
>
> http://commons.apache.org/lang/release-history.html
>
> etc.
>
> Hen
>
>
> ---------------------------------------------------------------------
> 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
Re: [all] Showing the Java Version on component sites
Posted by Henri Yandell <fl...@gmail.com>.
On Sun, Mar 9, 2008 at 11:25 AM, Dennis Lundberg <de...@apache.org> wrote:
>
> 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.
I'll go as far as to say automating is impossible. It'll only work if
you make the bad assumption of site==documentation.
ie) The site should say what the JDK version is for _all_ releases.
Add it manually to:
http://commons.apache.org/lang/release-history.html
etc.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Showing the Java Version on component sites
Posted by Dennis Lundberg <de...@apache.org>.
sebb wrote:
> On 09/03/2008, Dennis Lundberg <de...@apache.org> wrote:
>> Niall Pemberton wrote:
>> > On Sun, Mar 9, 2008 at 10:50 AM, Dennis Lundberg <de...@apache.org> wrote:
>> >> Niall Pemberton wrote:
>> >> > On Sat, Mar 8, 2008 at 4:19 PM, Dennis Lundberg <de...@apache.org> wrote:
>> >> >> Niall Pemberton wrote:
>> >> >> > On Thu, Mar 6, 2008 at 10:00 PM, Dennis Lundberg <de...@apache.org> wrote:
>> >> >> >> Niall Pemberton wrote:
>> >> >> >> > On Thu, Mar 6, 2008 at 7:38 PM, Dennis Lundberg <de...@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.
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: 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
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Showing the Java Version on component sites
Posted by sebb <se...@gmail.com>.
On 09/03/2008, Dennis Lundberg <de...@apache.org> wrote:
> Niall Pemberton wrote:
> > On Sun, Mar 9, 2008 at 10:50 AM, Dennis Lundberg <de...@apache.org> wrote:
> >> Niall Pemberton wrote:
> >> > On Sat, Mar 8, 2008 at 4:19 PM, Dennis Lundberg <de...@apache.org> wrote:
> >> >> Niall Pemberton wrote:
> >> >> > On Thu, Mar 6, 2008 at 10:00 PM, Dennis Lundberg <de...@apache.org> wrote:
> >> >> >> Niall Pemberton wrote:
> >> >> >> > On Thu, Mar 6, 2008 at 7:38 PM, Dennis Lundberg <de...@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
Re: [all] Showing the Java Version on component sites
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> On Sun, Mar 9, 2008 at 7:32 PM, Dennis Lundberg <de...@apache.org> wrote:
>> Niall Pemberton wrote:
>> > On Sun, Mar 9, 2008 at 1:40 PM, Dennis Lundberg <de...@apache.org> wrote:
>> >> Niall Pemberton wrote:
>> >> > On Sun, Mar 9, 2008 at 10:50 AM, Dennis Lundberg <de...@apache.org> wrote:
>> >> >> Niall Pemberton wrote:
>> >> >> > On Sat, Mar 8, 2008 at 4:19 PM, Dennis Lundberg <de...@apache.org> wrote:
>> >> >> >> Niall Pemberton wrote:
>> >> >> >> > On Thu, Mar 6, 2008 at 10:00 PM, Dennis Lundberg <de...@apache.org> wrote:
>> >> >> >> >> Niall Pemberton wrote:
>> >> >> >> >> > On Thu, Mar 6, 2008 at 7:38 PM, Dennis Lundberg <de...@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.
>> >
>> > My patch makes no difference to what you term mis-information. For
>> > example, if someone adds/removes/changes version of a component's
>> > dependency AFTER a release and re-publishes the site then whats
>> > published no longer relates to the last release. The same is true for
>> > the whole site - e.g. adding a new feature and documenting it in a
>> > user guide and re-publishing.
>>
>> Right, sorry for the confusion. The misinformation doesn't come from
>> your patch, but from the fact that it is possible to re-deploy a site,
>> thereby altering the content that was published at release time.
>>
>>
>> > For me though, having the site reflect whats currently in trunk and
>> > not the latest release is OK and I wouldn't term it mis-information -
>> > its the latest information.
>> >
>> > I did that patch originally because Sebb kept asking for the java
>> > version to be on the dependencies page. However given his recent
>> > comments it clearly doesn't meet his requirements. I think its quite
>> > nice and adding it does no harm, but I'm less interested in it now if
>> > you just want to close it as WONT FIX,
>>
>> I'd like to keep the issue open, because I think it is adds value to the
>> reports. I will however postpone it until Maven has better support for
>> versioned sites.
>
> Is that something thats in progress - or just on a wish list for the future?
Currently it is not a piece of software, but rather a configuration best
practice (hopefully). We're currently trying it out over in Maven land.
>
> Niall
>
>> > Niall
>> >
>> >> > 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
Re: [all] Showing the Java Version on component sites
Posted by Niall Pemberton <ni...@gmail.com>.
On Sun, Mar 9, 2008 at 7:32 PM, Dennis Lundberg <de...@apache.org> wrote:
>
> Niall Pemberton wrote:
> > On Sun, Mar 9, 2008 at 1:40 PM, Dennis Lundberg <de...@apache.org> wrote:
> >> Niall Pemberton wrote:
> >> > On Sun, Mar 9, 2008 at 10:50 AM, Dennis Lundberg <de...@apache.org> wrote:
> >> >> Niall Pemberton wrote:
> >> >> > On Sat, Mar 8, 2008 at 4:19 PM, Dennis Lundberg <de...@apache.org> wrote:
> >> >> >> Niall Pemberton wrote:
> >> >> >> > On Thu, Mar 6, 2008 at 10:00 PM, Dennis Lundberg <de...@apache.org> wrote:
> >> >> >> >> Niall Pemberton wrote:
> >> >> >> >> > On Thu, Mar 6, 2008 at 7:38 PM, Dennis Lundberg <de...@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.
> >
> > My patch makes no difference to what you term mis-information. For
> > example, if someone adds/removes/changes version of a component's
> > dependency AFTER a release and re-publishes the site then whats
> > published no longer relates to the last release. The same is true for
> > the whole site - e.g. adding a new feature and documenting it in a
> > user guide and re-publishing.
>
> Right, sorry for the confusion. The misinformation doesn't come from
> your patch, but from the fact that it is possible to re-deploy a site,
> thereby altering the content that was published at release time.
>
>
> > For me though, having the site reflect whats currently in trunk and
> > not the latest release is OK and I wouldn't term it mis-information -
> > its the latest information.
> >
> > I did that patch originally because Sebb kept asking for the java
> > version to be on the dependencies page. However given his recent
> > comments it clearly doesn't meet his requirements. I think its quite
> > nice and adding it does no harm, but I'm less interested in it now if
> > you just want to close it as WONT FIX,
>
> I'd like to keep the issue open, because I think it is adds value to the
> reports. I will however postpone it until Maven has better support for
> versioned sites.
Is that something thats in progress - or just on a wish list for the future?
Niall
> > Niall
> >
> >> > 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
Re: [all] Showing the Java Version on component sites
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> On Sun, Mar 9, 2008 at 1:40 PM, Dennis Lundberg <de...@apache.org> wrote:
>> Niall Pemberton wrote:
>> > On Sun, Mar 9, 2008 at 10:50 AM, Dennis Lundberg <de...@apache.org> wrote:
>> >> Niall Pemberton wrote:
>> >> > On Sat, Mar 8, 2008 at 4:19 PM, Dennis Lundberg <de...@apache.org> wrote:
>> >> >> Niall Pemberton wrote:
>> >> >> > On Thu, Mar 6, 2008 at 10:00 PM, Dennis Lundberg <de...@apache.org> wrote:
>> >> >> >> Niall Pemberton wrote:
>> >> >> >> > On Thu, Mar 6, 2008 at 7:38 PM, Dennis Lundberg <de...@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.
>
> My patch makes no difference to what you term mis-information. For
> example, if someone adds/removes/changes version of a component's
> dependency AFTER a release and re-publishes the site then whats
> published no longer relates to the last release. The same is true for
> the whole site - e.g. adding a new feature and documenting it in a
> user guide and re-publishing.
Right, sorry for the confusion. The misinformation doesn't come from
your patch, but from the fact that it is possible to re-deploy a site,
thereby altering the content that was published at release time.
> For me though, having the site reflect whats currently in trunk and
> not the latest release is OK and I wouldn't term it mis-information -
> its the latest information.
>
> I did that patch originally because Sebb kept asking for the java
> version to be on the dependencies page. However given his recent
> comments it clearly doesn't meet his requirements. I think its quite
> nice and adding it does no harm, but I'm less interested in it now if
> you just want to close it as WONT FIX,
I'd like to keep the issue open, because I think it is adds value to the
reports. I will however postpone it until Maven has better support for
versioned sites.
> Niall
>
>> > 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
Re: [all] Showing the Java Version on component sites
Posted by Niall Pemberton <ni...@gmail.com>.
On Sun, Mar 9, 2008 at 1:40 PM, Dennis Lundberg <de...@apache.org> wrote:
>
> Niall Pemberton wrote:
> > On Sun, Mar 9, 2008 at 10:50 AM, Dennis Lundberg <de...@apache.org> wrote:
> >> Niall Pemberton wrote:
> >> > On Sat, Mar 8, 2008 at 4:19 PM, Dennis Lundberg <de...@apache.org> wrote:
> >> >> Niall Pemberton wrote:
> >> >> > On Thu, Mar 6, 2008 at 10:00 PM, Dennis Lundberg <de...@apache.org> wrote:
> >> >> >> Niall Pemberton wrote:
> >> >> >> > On Thu, Mar 6, 2008 at 7:38 PM, Dennis Lundberg <de...@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.
My patch makes no difference to what you term mis-information. For
example, if someone adds/removes/changes version of a component's
dependency AFTER a release and re-publishes the site then whats
published no longer relates to the last release. The same is true for
the whole site - e.g. adding a new feature and documenting it in a
user guide and re-publishing.
For me though, having the site reflect whats currently in trunk and
not the latest release is OK and I wouldn't term it mis-information -
its the latest information.
I did that patch originally because Sebb kept asking for the java
version to be on the dependencies page. However given his recent
comments it clearly doesn't meet his requirements. I think its quite
nice and adding it does no harm, but I'm less interested in it now if
you just want to close it as WONT FIX,
Niall
> > 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
Re: [all] Showing the Java Version on component sites
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> On Sun, Mar 9, 2008 at 10:50 AM, Dennis Lundberg <de...@apache.org> wrote:
>> Niall Pemberton wrote:
>> > On Sat, Mar 8, 2008 at 4:19 PM, Dennis Lundberg <de...@apache.org> wrote:
>> >> Niall Pemberton wrote:
>> >> > On Thu, Mar 6, 2008 at 10:00 PM, Dennis Lundberg <de...@apache.org> wrote:
>> >> >> Niall Pemberton wrote:
>> >> >> > On Thu, Mar 6, 2008 at 7:38 PM, Dennis Lundberg <de...@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.
> 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
Re: [all] Showing the Java Version on component sites
Posted by Niall Pemberton <ni...@gmail.com>.
On Sun, Mar 9, 2008 at 10:50 AM, Dennis Lundberg <de...@apache.org> wrote:
>
> Niall Pemberton wrote:
> > On Sat, Mar 8, 2008 at 4:19 PM, Dennis Lundberg <de...@apache.org> wrote:
> >> Niall Pemberton wrote:
> >> > On Thu, Mar 6, 2008 at 10:00 PM, Dennis Lundberg <de...@apache.org> wrote:
> >> >> Niall Pemberton wrote:
> >> >> > On Thu, Mar 6, 2008 at 7:38 PM, Dennis Lundberg <de...@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.
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
Re: [all] Showing the Java Version on component sites
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> On Sat, Mar 8, 2008 at 4:19 PM, Dennis Lundberg <de...@apache.org> wrote:
>> Niall Pemberton wrote:
>> > On Thu, Mar 6, 2008 at 10:00 PM, Dennis Lundberg <de...@apache.org> wrote:
>> >> Niall Pemberton wrote:
>> >> > On Thu, Mar 6, 2008 at 7:38 PM, Dennis Lundberg <de...@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?
- 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.
<snip/>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Showing the Java Version on component sites
Posted by Niall Pemberton <ni...@gmail.com>.
On Sat, Mar 8, 2008 at 4:19 PM, Dennis Lundberg <de...@apache.org> wrote:
>
> Niall Pemberton wrote:
> > On Thu, Mar 6, 2008 at 10:00 PM, Dennis Lundberg <de...@apache.org> wrote:
> >> Niall Pemberton wrote:
> >> > On Thu, Mar 6, 2008 at 7:38 PM, Dennis Lundberg <de...@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.
Niall
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Showing the Java Version on component sites
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> On Thu, Mar 6, 2008 at 10:00 PM, Dennis Lundberg <de...@apache.org> wrote:
>> Niall Pemberton wrote:
>> > On Thu, Mar 6, 2008 at 7:38 PM, Dennis Lundberg <de...@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
Re: [all] Showing the Java Version on component sites
Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Mar 6, 2008 at 10:00 PM, Dennis Lundberg <de...@apache.org> wrote:
> Niall Pemberton wrote:
> > On Thu, Mar 6, 2008 at 7:38 PM, Dennis Lundberg <de...@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".
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
Re: [all] Showing the Java Version on component sites
Posted by Dennis Lundberg <de...@apache.org>.
Niall Pemberton wrote:
> On Thu, Mar 6, 2008 at 7:38 PM, Dennis Lundberg <de...@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.
> 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
Re: [all] Showing the Java Version on component sites
Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Mar 6, 2008 at 7:38 PM, Dennis Lundberg <de...@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.
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.
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
Re: [all] Showing the Java Version on component sites
Posted by Dennis Lundberg <de...@apache.org>.
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?
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
Re: [all] Showing the Java Version on component sites
Posted by James Carman <ja...@carmanconsulting.com>.
On 3/5/08, Niall Pemberton <ni...@gmail.com> 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
>
> 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:
>
I agree that it should be on the dependencies page, but it couldn't
hurt to have it on the project summary page also. Very nice, by the
way!
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org