Turns out the shell scripts *are* in the src zip, they are just moved to /src/shell. Andi did that to avoid a top-level folder called "bin" because that conflicts with IDE default output folders.
I can leave it, and document the change in the README and CHANGES files, or exclude that directory when building, and include it mapped to /bin, like the xmlbeans-bin zip file. Thoughts? I lean toward moving it to /bin in the src zip, to match the bin zip. I'll work on that unless someone has a reason not to. On Thu, Mar 21, 2019 at 10:51 AM Greg Woolsey <greg.wool...@gmail.com> wrote: > I hard from Andi, who is text-only on a vacation. He redid the build to > align names better with POI naming conventions and remove unnecessary > things like the separate public jar. > > I think the following changes would be helpful, but beyond that I think it > looks fine: > > 1. include the bin/* scripts in the src zip > 2. bump the version to 3.1.0 and mention the packaging changes in the > changelog > 3. fix the README version # > > Then I would do a 3.1.0 XMLBeans build and deploy to staging. > > How does that sound to folks? > > > On Thu, Mar 21, 2019 at 10:28 AM Greg Woolsey <greg.wool...@gmail.com> > wrote: > >> I'm OK with changing the number and re-doing a build. Reminds me I need >> to go install JDK 1.6, I don't have it yet on the new laptop. It looks to >> me like the changes were intentional to get rid of old stuff no longer >> needed by anyone, but I don't know who still uses it, and is using the >> newer builds we produce. >> >> Looks like Javadoc is now in a jar, which is probably fine, as most >> people access it via IDE, which look for it in jars. Easy enough to unzip >> if you want the HTML directly. >> >> As for the scripts, I suspect they should still go in the src file, as I >> would expect that file to have everything needed to build and use the >> package. >> >> On Thu, Mar 21, 2019 at 10:02 AM Dominik Stadler <dominik.stad...@gmx.at> >> wrote: >> >>> Hi, >>> >>> Maybe Andi can comment on some of these if changes were on-purpose or >>> unintentional. I also don't have any experience whats-o-ever with >>> XMLBeans, >>> so am not sure myself. >>> >>> Missing jars may be fine to get rid of some old cruft, renaming of >>> tgz/zip >>> should not cause much issues as nowadays most people drag in dependencies >>> via maven/gradle. >>> >>> Missing javadoc and bin/scripts I would investigate because it may mean >>> that important pieces are missing. >>> >>> Finally should we use a different version number, e.g. 3.1.0 to indicate >>> that some more changes in functionality did occur, 3.0.3 would suggest >>> "drop in replacement", which will not guarantee here? >>> >>> Thanks... Dominik. >>> >>> On Thu, Mar 21, 2019 at 5:21 PM Greg Woolsey <greg.wool...@gmail.com> >>> wrote: >>> >>> > xmlpublic.jar and the other different/missing pieces are all due to the >>> > revamping of build.xml. Many targets have been removed in the current >>> > version. >>> > >>> > The XMLBeans web site says xmlpublic.jar was just the "public" API, a >>> > slimmed-down dependency if projects were not going to need the whole >>> > thing. Not sure that matters for our purposes, as we are releasing >>> updates >>> > targeted primarily for POI, and the JAR size differences aren't enough >>> to >>> > matter in my mind. >>> > >>> > I can't find any reference to xmlbean_xpath.jar in the old build.xml, >>> web >>> > site, or any other file in the source tree, so I don't know where that >>> > comes from or why it was included. >>> > >>> > On Thu, Mar 21, 2019 at 8:25 AM Greg Woolsey <greg.wool...@gmail.com> >>> > wrote: >>> > >>> > > Removed 3.0.2 artifacts from the dist/dev tree. >>> > > >>> > > I pulled the zips from the Jenkins build artifacts, and then >>> repackaged >>> > > them to *.tgz as well. The build.xml has been heavily modified since >>> > > 3.0.2, so perhaps some things got lost along the way, as well as >>> renamed. >>> > > This is the first new release since the reworking of the XMLBeans >>> build. >>> > > >>> > > If the package artifacts should be named differently, that should go >>> in >>> > > build.xml, not manual steps after. >>> > > >>> > > I don't know XMLBeans at all, so I have no frame of reference other >>> than >>> > > previous builds to know what was intentional and what was accidental >>> in >>> > the >>> > > modifications since October. >>> > > >>> > > I can update the README if we want, but I'd be doing so without a >>> good >>> > > sense of where the project stands, as I've never used it outside of >>> a POI >>> > > dependency. >>> > > >>> > > On Thu, Mar 21, 2019 at 12:14 AM Dominik Stadler < >>> dominik.stad...@gmx.at >>> > > >>> > > wrote: >>> > > >>> > >> Can you remove the 3.0.2 files from >>> > >> https://dist.apache.org/repos/dist/dev/poi/xmlbeans/, they are >>> > available >>> > >> as >>> > >> official release anyway. >>> > >> >>> > >> File names are slightly different now, not sure if this is intended >>> or >>> > >> will >>> > >> cause issues: xmlbeans-3.0.2-src.tgz >>> > >> < >>> > >> >>> > >>> https://dist.apache.org/repos/dist/dev/poi/xmlbeans/src/xmlbeans-3.0.2-src.tgz >>> > >> > >>> > >> vs. xmlbeans-src-3.0.3.tgz >>> > >> < >>> > >> >>> > >>> https://dist.apache.org/repos/dist/dev/poi/xmlbeans/src/xmlbeans-src-3.0.3.tgz >>> > >> >, >>> > >> similar for bin: xmlbeans-3.0.2.tgz >>> > >> < >>> > >> >>> > >>> https://dist.apache.org/repos/dist/dev/poi/xmlbeans/bin/xmlbeans-3.0.2.tgz >>> > >> > >>> > >> vs. xmlbeans-bin-3.0.3.tgz >>> > >> < >>> > >> >>> > >>> https://dist.apache.org/repos/dist/dev/poi/xmlbeans/bin/xmlbeans-bin-3.0.3.tgz >>> > >> > >>> > >> >>> > >> Inside the files I found the following differences compared to >>> 3.0.2: >>> > >> >>> > >> * In the bin-files, the folder docs/reference is missing, this >>> included >>> > >> javadoc in 3.0.2 >>> > >> * jar-files in the bin-tgz are now called xmlbeans-3.0.3.jar >>> compared to >>> > >> just xmlbeans.jar before. files for javadoc and src jars are new in >>> the >>> > >> bin-tgz >>> > >> * in the bin-tgz, lib/xmlbean_xpath.jar and xmlpublic.jar are >>> missing. >>> > Not >>> > >> sure what they were used for, though >>> > >> * in the bin-tgz, the README is not updated, it actually still >>> states >>> > >> 2.5.0, so it was not updated in a long time >>> > >> * The content of the src-tgz/zip is fairly different, libs are moved >>> > >> around, the folder "bin" with scripts is missing, ... most of it >>> will >>> > be >>> > >> on-purpose, but we should check, I don't know XMLBeans well enough >>> to be >>> > >> sure >>> > >> * We should exclude file "build.javacheck.xml" in the packaging, it >>> is >>> > >> used >>> > >> by CI jobs, but not useful to include >>> > >> >>> > >> >>> > >> Dominik. >>> > >> >>> > >> On Thu, Mar 21, 2019 at 12:00 AM Greg Woolsey < >>> greg.wool...@gmail.com> >>> > >> wrote: >>> > >> >>> > >> > I have pushed xmlbeans 3.0.3 release candidate to: >>> > >> > >>> > >> > >>> > >> > >>> > >> >>> > >>> https://repository.apache.org/content/repositories/staging/org/apache/xmlbeans/xmlbeans/3.0.3/ >>> > >> > >>> > >> > https://dist.apache.org/repos/dist/dev/poi/xmlbeans/bin >>> > >> > https://dist.apache.org/repos/dist/dev/poi/xmlbeans/src >>> > >> > >>> > >> > If those look good to folks, what do I do to "release" from >>> staging in >>> > >> the >>> > >> > repository? Do I just click the "Release" button in the web >>> > interface, >>> > >> > perhaps selecting "Public Repositories" if there is a prompt? >>> > >> > >>> > >> > I assume I then modify site docs like site.xml, modifying 3.0.2 to >>> > >> 3.0.3, >>> > >> > then running forrest and committing. It's my understanding we >>> don't >>> > >> need >>> > >> > to do anything special to release the site changes? >>> > >> > >>> > >> > Any other steps? I'm thinking I should also commit what I've >>> done in >>> > a >>> > >> > build instructions file so this thread and the previous one >>> aren't the >>> > >> > source for future releases. >>> > >> > >>> > >> > Maybe also mentioning the AdblockPlus Chrome and Firefox >>> extensions >>> > >> break >>> > >> > nexus uploads unless you exclude the repository domain. That >>> cost me >>> > a >>> > >> bit >>> > >> > of time. >>> > >> > >>> > >> >>> > > >>> > >>> >>
