On 05/03/2008, Niall Pemberton <[EMAIL PROTECTED]> wrote: > On Wed, Mar 5, 2008 at 5:25 PM, sebb <[EMAIL PROTECTED]> wrote: > > On 05/03/2008, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > > On Wed, Mar 5, 2008 at 3:58 PM, sebb <[EMAIL PROTECTED]> wrote: > > > > On 05/03/2008, Niall Pemberton <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
