I am in favor of removing streams-web from master until: a) It is compatible with streams-monitoring and at least one fully documented streams-runtime b) All licensing concerns are straightened out
We might want to consider setting up a separate repository to package 'ready-to-run' artifacts such as streams-web, allowing us to keep the primary repo free of shaded artifacts while providing new users with comprehensive official jars/wars for deployment without having to write code. If anyone feels differently, and would vote -1 on a release candidate without streams-web, please let us know in the 48 hours. If no one objects, I will prepare and submit rc3 on friday minus streams-web. Steve Blackmon [email protected] On Wed, Jan 21, 2015 at 1:50 PM, Robert Douglas < [email protected]> wrote: > Hi all, > > Just to weigh in, I would be in favor of completely removing the web module > from the current project. > > I agree with Steve that having access to web visualizations of executing > Streams would be nice to have. However, since the web module in its current > state is not compatible with a large amount of the code base, I'm not sure > it makes sense to keep it in the project. It may be better to put some > tickets into the JIRA backlog in regards to getting the web module > functional (and meet the requirements that Ate lined out) instead of > keeping non-functioning code in the source. > > I also agree that at this point it makes sense to take the path of least > resistance when it comes to getting a viable release cut. If that means > removing the web module, then that may make sense. > > Thoughts? > - Robert > > On Wed, Jan 21, 2015 at 5:34 AM, Ate Douma <[email protected]> wrote: > > > On 2015-01-21 01:27, Steve Blackmon wrote: > > > >> Ate, > >> > >> 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. > >> > >> Thank you. Cool. > >> > >> 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. > >> > >> If I understand correctly, you are saying we must inventory and merge > the > >> LICENSE and NOTICE of all dependencies (as rave did) if we compile them > >> into a binary during the standard build? > >> > > > > Correct. > > > > > >> Would this still be an issue if we disabled the war plugin execution in > >> the > >> interest of producing a viable release candidate? > >> > > > > No :) > > > > But also see my comment below. > > > > > >> To offer a few points as rationale, > >> a) no other module in incubator-streams builds an uber-war or uber-jar. > >> Assembly is left to user of the project, typically alongside custom > >> components and streams. The ability to run streams 'out of the box' is > >> not > >> a primary goal at this phase of the project's development. > >> b) downloading a pre-built war from a maven repository is not exactly > >> common practice (in my experience.) User's typically build from source > >> after modifying files in WEB-INF anyway to align with their preferred > >> container. > >> c) although web visualization of executing/executed streams is an > >> interesting and useful concept, it has not been under active development > >> recently and is not compatible with the majority of project code. > >> d) the community has an interest in reaching minimum viable release, and > >> may be willing to alter the build plan as it pertains to streams-web and > >> associated less-active modules to accomplish this. > >> > >> If there is no real need for the web war module, I think dropping or > > changing this module probably is better than merely disabling the war > > plugin to deploy. > > > > What I mean with changing: changing its maven coordinates and inclusion > of > > the module by the parent pom. > > As long as the module stays 'as is', but just not is deployed, other > users > > can/may still build it locally, ending up with a *seemingly* formal > Apache > > project artifact but still missing the appropriate LICENSE/NOTICE > > attributions. > > This is not really a 'bug' or issue but could lead to confusion. > > > > If you prefer not dropping the web module, maybe changing its maven > > coordinates to some "org.foo.example:example-streams-web:war" coordinates > > might help. > > The then module still can be referred to and properly maintained as > > "example" usage/setup through documentation etc. > > An alternative would be to either just/only document the required > > setup/dependencies needed for such web module. > > > > Or maybe even create a dedicated maven archetype for it. > > But I'm not sure how useful that would be or how much usage that would > > have. > > > > Anyway, the above are just suggestions, its totally up to the project > > members to decide if/how to proceed with this web module. > > > > HTH, > > Ate > > > > > > 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-di > >> sclaimer-resource-bundle:1.1. > >> > >> You are probably right, easy fix. > >> > >> Thanks for being a thorough mentor and helping us move forward. > >> > >> > >> Steve Blackmon > >> [email protected] > >> > >> On Tue, Jan 20, 2015 at 4:03 PM, Ate Douma <[email protected]> wrote: > >> > >> 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] > >>>> > >>>> > >>>> > >>> > >> > > >
