> One thing that I found is that Ant-target "assemble" fails now because we > call the target "maven-pom", but the directory "maven" and the pom.xml > files are not included in the source-package.. "ant clean assemble" works for me on a full svn checkout. Are you referring to assemble failing when compiling from source?
I'm fine with leaving build.xml unfrozen. The release tag defines the release, not the state of trunk on release day. Feel free to commit your changes so that this is fixed in either the next beta 1 RC or beta 2. On Sun, Nov 13, 2016 at 2:07 PM, Dominik Stadler <dominik.stad...@gmx.at> wrote: > +1 > > verified the contents of the various packages and did a full build from the > sources via target "jenkins". > > One thing that I found is that Ant-target "assemble" fails now because we > call the target "maven-pom", but the directory "maven" and the pom.xml > files are not included in the source-package.. > > But I think this was also the case in 3.15, seems to have been introduced > via http://svn.apache.org/viewvc?view=revision&revision=1733863 as far as I > see, so I would not hold a beta1 because of that, but rather fix it > afterwards for beta2. > > I will check why our "source rebuild" target in the CI does not stumble > across that because it should! > > BTW, API-comparisons to 3.15 are at https://builds.apache.org/ > view/POI/job/POI-API-Check/ > > Dominik. > > On Sun, Nov 13, 2016 at 2:29 PM, Andreas Beeker <kiwiwi...@apache.org> > wrote: > >> +1 >> >> I've copy&paste-checked the signatures, checked the archives for clutter >> and ran a very small XSLF test project. >> >> In the release note the "... password ..." line should be replaced by: >> - Add support for mixed-length cipher/hashes in password protected files >> typically used by Office for Mac >> (... I probably should adapt the changelog to ... but we can do this after >> the release ...) >> >> As we discussed yesterday in IRC, I think it's difficult to distinguish >> between un-/intentional API breaks - >> if it's possible with the api diff tool, I would simply provide a >> api-break-report. >> It would be cool (, if it's not too large/confusing), to diff against >> older versions too, as most users will probably update >> from an earlier version. >> >> Andi. >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org >> For additional commands, e-mail: dev-h...@poi.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
