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
artifact:
- 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:
https://github.com/apache/rave/tree/master/rave-portal/src/main/appended-resources/META-INF
- 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):
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<!-- 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
-->
<webResources>
<resource>
<directory>${project.build.directory}/classes/META-INF</directory>
<includes>
<include>LICENSE</include>
<include>NOTICE</include>
<include>DEPENDENCIES</include>
<include>DISCLAIMER</include>
</includes>
<targetPath>META-INF</targetPath>
<filtering>false</filtering>
</resource>
</webResources>
<!-- 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
-->
<packagingExcludes>
WEB-INF/classes/META-INF/LICENSE,
WEB-INF/classes/META-INF/LICENSE.txt,
WEB-INF/classes/META-INF/NOTICE,
WEB-INF/classes/META-INF/NOTICE.txt,
WEB-INF/classes/META-INF/DISCLAIMER,
WEB-INF/classes/META-INF/DEPENDENCIES
</packagingExcludes>
</configuration>
</plugin>
- Concerning the maven-remote-resources-plugin configuration in the root pom.xml
I noticed it configures the following *SNAPSHOT* resourcebundles:
<resourceBundles>
<!- Will generate META-INF/DEPENDENCIES META-INF/LICENSE META-INF/NOTICE ->
<resourceBundle>org.apache.apache.resources:apache-jar-resource-bundle:1.5-SNAPSHOT</resourceBundle>
<!- Will generate META-INF/DISCLAIMER ->
<resourceBundle>org.apache.apache.resources:apache-incubator-disclaimer-resource-bundle:1.2-SNAPSHOT</resourceBundle>
</resourceBundles>
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:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-remote-resources-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>process</goal>
</goals>
<configuration>
<!-- add apache-incubator-disclaimer-resource-bundle to be removed
again when graduating from Incubator -->
<resourceBundles combine.children="append">
<resourceBundle>org.apache:apache-incubator-disclaimer-resource-bundle:1.1</resourceBundle>
</resourceBundles>
</configuration>
</execution>
</executions>
</plugin>
- 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,
Ate
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
[email protected]
