Le 26/02/2011 18:29, Phil Steitz a écrit : > On 2/26/11 11:47 AM, Luc Maisonobe wrote: >> Le 26/02/2011 17:11, Phil Steitz a écrit : >>> On 2/25/11 5:15 AM, Luc Maisonobe wrote: >>>> Tag: >>>> <http://svn.apache.org/repos/asf/commons/proper/math/tags/MATH_2_2_RC5/> >>>> >>>> All artifacts in Nexus staging repository: >>>> <https://repository.apache.org/content/repositories/orgapachecommons-051/org/apache/commons/commons-math/2.2/> >>>> >>>> site: >>>> <http://people.apache.org/builds/commons/math/2.2/RC5/> >>>> >>>> Clirr report: >>>> <http://people.apache.org/builds/commons/math/2.2/RC5/clirr-report.html> >>>> >>>> Votes, please. This vote will close in 72 hours, 2011-02-28T11:00:00 UTC >>>> >>>> [ ] +1 Release these artifacts >>>> [ ] +0 OK, but... >>>> [ ] -0 OK, but really should fix... >>>> [ ] -1 I oppose this release because... >>>> >>>> Thanks! >>>> >>>> Luc >>>> >>>> >>> I am struggling a little on this one. The code is good. Builds and >>> tests fine. Sigs are good. Release contents are good. But the user >>> guide packaging is not as good as 2.0-2.1, IMO. The reason that I >>> introduced the siteMods stuff in 2.0 was so that we could bundle >>> just the user guide as a self-contained set of web pages in the >>> binary distro. Just file filtering from a full site build results >>> in broken links in the nav and the appearance of the whole site, >>> with only the user guide content available. On the other hand, to >>> fix this, you need to do what the build script does or something >>> similar (at least I couldn't find a way to get it to work >>> otherwise), which means you can't just have maven build and deploy >>> the whole release without additional scripting or commands. The nav >>> links in the user guide into the user guide itself work and the >>> links from the user guide to the bundled javadoc work, so this is >>> really just an appearance/useability issue. >>> >>> So I guess I am +0 on this RC. The broken links / appearance issues >>> are not enough for -1, or even -0, but I would rather ship the >>> cleaner version. I don't know how nexus works, but I would expect >>> that it should be possible to generate just the binary distro and >>> push it out there somehow if you decide to do another RC. >> OK. Perhaps I could try what Sebb suggested: using the siteMods/pom.xml >> and siteMods/site.xml stuff directly from maven. I could even do the >> site manually with your script and later use mvn deploy. >> >> I will give it a try first without cancelling this RC vote. If I succeed >> in having a fully functional menu with only the required links, then >> I'll cancel the vote and push an RC6. > If you just run the script, it will create the correctly bundled > user guide. The previous RCs had it fine. You could then just push > out the binary zip/tgz. I almost suggested that you just do that > and restart the VOTE, since no changes to the tag are necessary to > fix this. IIUC, Sebb's suggestion just simplifies the script. You > still need to execute "mvn site" separately using the modified > resources to get the user guide built.
Fine. I just check if I could do a mix by manually creating the site using the script as a template and leaving it in the target/site directory, then switch to mvn deploy. It seems to work, at least with a local test-deploy. So I cancel this vote now. I will still do an RC6 tag since I have to change the publish target dates in changes.xml and doap_math.rdf (and hence the RC number in one property of pom.xml also). I am really sorry to be so slow in getting this release out and force everybody to vote again and again. Next time, I'll try to get it right faster. Luc >> What should we do about the duplicate javadoc in binary ? Do we keep >> both the jar and the expanded version in the binary zip or do we >> suppress one of them ? If we suppress one, which one ? > > I am not one of them, but some users seem to like to have both > source and javadoc jars included in the binary distributions. I am > not sure why, but I think it has to do with IDE integration. It > doesn't bother me personally to include these jars. It *would* > bother me not to have apidocs in the distro itself, though. > > Phil > >> Luc >> >>> Phil >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
