streams-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Blackmon <sblack...@apache.org>
Subject Re: [DISCUSS] Release Apache Streams vension 0.1-incubating (rc2)
Date Wed, 21 Jan 2015 21:04:59 GMT
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
sblackmon@apache.org

On Wed, Jan 21, 2015 at 1:50 PM, Robert Douglas <
robert.baker.douglas@gmail.com> 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 <ate@douma.nu> 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
> >> sblackmon@apache.org
> >>
> >> On Tue, Jan 20, 2015 at 4:03 PM, Ate Douma <ate@douma.nu> 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
> >>>> sblackmon@apache.org
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message