I've not lost track. Just busy. FWIW, I have a product at works that
depends on the bin zip file being in Maven repos through Ivy:

    <dependency org="commons-daemon" name="commons-daemon"
conf="ais.dist.acd" rev="1.0.15">
      <artifact name="commons-daemon" maven:classifier="bin-windows"
type="zip" />
    </dependency>


Gary

On Fri, Nov 10, 2017 at 5:40 AM, Mark Thomas <ma...@apache.org> wrote:

> On 09/11/17 20:15, Mark Thomas wrote:
>
> <snip/>
>
> > The proposed release is:
> >
> > The proposed 1.1.0 release based on RC2 is:
> > [ ] Broken   - do not release because...
> > [ ] Approved - go ahead and release as 1.1.0
>
> I'm undecided.
>
> From a functional, policy and packaging point of view I don't have any
> concerns. However, test JARs seem fairly pointless to have in Maven
> Central and there is benefit in providing the various binaries via Maven
> Central.
>
> While I don't want to delay the release unnecessarily, I'm leaning
> towards an RC3 with a set of uploads to the Nexus staging repo that
> aligns with the 1.0.15 release. While I could probably figure out how to
> do that manually, just re-rolling the release is probably going to be
> quicker.
>
> Thoughts? Comments? Feedback on the review below - particularly the
> website also welcome.
>
> Detailed review follows.
>
> Mark
>
>
> Java version
> ------------
>
> The minimum Java version is 6 but Daemon can't be built with Java 6 (the
> Maven toolchain requires Java 7). That should be OK but merits
> additional checks.
>
> Checking one of the class files in commons-daemon-1.1.0.jar it is
> version 50 as expected.
>
>
> Unit tests
> ----------
>
> The test code isn't a unit test, it is a sample.
>
>
> Maven Central
> -------------
>
> It doesn't do any harm uploading the test JARs to Maven Central but I'm
> leaning towards excluding them in future.
>
> The binary and native src distributions for 1.1.0 were not uploaded to
> Maven Central (strictly they were but were then removed before the repo
> was closed). The 1.0.11 to 1.0.15 releases did include those
> distributions. There are benefits to having them on Maven Central so I'm
> leaning towards including them in future.
>
>
> Integration testing
> -------------------
>
> Windows with Tomcat 7.0.82
> Tested by replacing the Windows binaries with those from Commons Daemon
> 1.1.0.
> - Digital signatures are valid (Symantec code signing)
> - Passed simple smoke test running on Java 6
> - Configuring Java 9 specific options didn't prevent running on Java 6
>   (as expected)
> - Java 9 options used when running on Java 9 (needed to remove
>    endorsedDirs setting - as expected)
>
> Linux with Tomcat trunk
> - Warnings compiling jsvc (no change from 1.0.15)
> - Runs under Java 8
> - Runs under Java 9
>
>
> Packaging
> ---------
>
> I compared the contents of various artefacts in the 1.1.0 release with
> the equivalent from 1.0.15:
>
> - commons-daemon-n.n.n-bin-windows.zip
>   - No ia64 dir (as expected)
>   - Otherwise file/dir names the same
>   - Differences in files all expected
> - commons-daemon-n.n.n-bin.tar.gz
>   - no apidocs/src-html directory (looks OK)
>   - differences in generated Javadoc files  (expected)
>   - Otherwise file/dir names the same
>   - Differences in files all expected
> - commons-daemon-n.n.n-native-src.tar.gz
>   - CHANGES.txt removed as expected
>   - Otherwise file/dir names the same
>   - Differences in files all expected
> - commons-daemon-n.n.n-src.zip
>   - CHANGES.txt -> changes.xml (expected)
>   - Maven source layout changed slightly (expected)
>   - Otherwise file/dir names the same
>   - Differences in files all expected
>
> Overall I'm pleasantly surprised. With the time between releases,
> changes in the release process and my unfamiliarity with both Maven and
> the release process I was expected some packaging issues but all looks
> to be OK.
>
>
> Web site
> --------
>
> Not part of the release but since I'm here...
>
> The link for "Javadoc (SVN latest)" just points to the latest release.
> Should this point to a CI build, be removed or something else?
>
> What is the purpose of the Jira report? Do we need to add some more fix
> versions, remove the report or something else?
>
> RAT report suggests we should add an ASF header to HOWTO-RELEASE.txt but
> that is a minor issue I'll fix shortly.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Reply via email to