streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <>
Subject Re: [DISCUSS] Release Apache Streams vension 0.1-incubating (rc2)
Date Tue, 20 Jan 2015 22:03:53 GMT
Hi Steve,

I've been reviewing the new release candidate and I can confirm the earlier 
blocker issues (binary artifact in the sources zip, missing DISCLAIMER files) 
indeed are fixed with this release candidate.

However I found a few new issues, including at least one blocker :(
As a consequence, regrettably I have to vote -1 on this new candidate as well, 
which I'll do shortly.

To begin with the blocker: this concerns the streams-web-0.1-incubating.war
- It bundles many 3rd party (not streams project based) artifacts under its
   WEB-INF/lib folder, many of which require attribution in the *embedded*
   LICENSE and/or NOTICE file.

   This is a legal BLOCKER for release.

   And this probably is going to an annoying one:

   Typically getting all (and only) the required attributions for all the
   embedded/bundled 3rd party resources complete and correct in (only) the
   embedded LICENSE/NOTICE files is a time-consuming process, definitely the
   first time around.

   This typically is done by providing LICENSE/NOTICE fragment files under a
   src/main/appended-resources/META-INF/ folder.
   As reference maybe take a look at:

- The current (default) configuration of the Maven war plugin results in the
   remote-resources-plugin generated LICENSE/NOTICE/DISCLAIMER/etc. files to
   be put under the WEB-INF/classes/META-INF folder (within the streams-web
   war artifact), instead of under typically/expected the META-INF/ folder.

   Furthermore, because the war module is build as war overlay on top of the
   org.apache.camel:camel-web:war dependency (which also is build using the same
   similar default setup), now the streams-web war file *also* (still) contains
   the camel LICENSE.txt/NOTICE.txt besides the streams LICENSE/NOTICE files.
   Pretty confusing and IMO undesirable.

   We had the same/similar problem at Apache Rave initially when overlaying
   a Shindig war module, and solved *both* problems using a custom
   maven-war-plugin configuration.
   Something like the following might fix this (see also issue RAVE-168):

       <!-- copy legal files added/appended by maven-remote-resources-plugin
            from /WEB-INF/classes/META-INF/ to root /META-INF folder as expected
            for war artifacts
       <!-- exclude legal files added/appended by maven-remote-resources-plugin
            under /WEB-INF/classes/META-INF/ as for war artifacts these should
            (see above) be provided under /META-INF/ instead

- Concerning the maven-remote-resources-plugin configuration in the root pom.xml
   I noticed it configures the following *SNAPSHOT* resourcebundles:

     <!- Will generate META-INF/DISCLAIMER  ->

   This maybe isn't really a blocker, but still undesirable IMO.

   Its unclear to me why the unreleased SNAPSHOT resourcebundles are needed,
   as AFAIK the same or similar result is produced by using the pre-configured
   (in the apache-16 parent pom) org.apache:apache-jar-resource-bundle:1.4,
   appended with the org.apache:apache-incubator-disclaimer-resource-bundle:1.1.

   In Rave, during incubation, we configured this like:

           <!-- add apache-incubator-disclaimer-resource-bundle to be removed
                again when graduating from Incubator -->
           <resourceBundles combine.children="append">

- Finally I noticed a few artifacts which are effectively empty, containing only
   a META-INF/ folder. For example: gnip-edc-facebook-0.1-incubating.jar,
   gnip-edc-flickr-0.1-incubating.jar and gnip-edc-youtube-0.1-incubating.jar.
   Turned out these modules only define test classes, so maybe deploying these
   (non-test) jars might be less useful?
   This is just a suggestion though, certainly not a blocker.

Kind regards,

On 2015-01-15 00:59, Steve Blackmon wrote:
> Submit any discussion items related to the open vote to this thread.  I
> have a few comments to start.
> 1)
> Many jars, including test jars, sources, and javadoc jars were lacking a
> disclaimer in rc1.  Since these are not actually artifacts of the release
> (only the source archive is), and in the interest of completing this
> release so development can move forward, I disabled build of test jars,
> sources, and javadoc jar artifacts in this release candidate.
> 2)
> As far as I can tell, jar artifacts now contain DISCLAIMERS, and no jars
> remain in the source archive.  Thus all issues which precipitated -1 votes
> for rc1 have been addressed.
> 3)
> As Ate mentioned, improvements to the website and project READMEs would
> help others outside the community understand what streams does and how to
> get started.  I will be spending time on the website and preparing a code
> donation that should help new users get started, specifically the
> streams-examples repository.
> 4)
> It would be great to get all of the issues in JIRA updated to the right
> status, so all legitimate resolved issues can be associated to version 0.1
> and closed once we have our release finalized.
> Steve Blackmon

View raw message