You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@streams.apache.org by Steve Blackmon <sb...@apache.org> on 2015/01/15 00:59:38 UTC
[DISCUSS] Release Apache Streams vension 0.1-incubating (rc2)
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
Re: [DISCUSS] Release Apache Streams vension 0.1-incubating (rc2)
Posted by Steve Blackmon <sb...@apache.org>.
+1
Steve Blackmon
sblackmon@apache.org
On Sat, Jan 17, 2015 at 8:31 AM, Matt Franklin <m....@gmail.com>
wrote:
> You are right. I was thinking of it like a source archive.
>
> On Fri Jan 16 2015 at 12:42:35 PM Steve Blackmon <sb...@apache.org>
> wrote:
>
> > That jar looks correct to me. What should be different to comply with
> > Apache release rules?
> >
> >
> >
> > Steve Blackmon
> > sblackmon@apache.org
> >
> > On Fri, Jan 16, 2015 at 7:27 AM, Matt Franklin <m.ben.franklin@gmail.com
> >
> > wrote:
> >
> >> It looks like at least some binary jars don't have the DISCLAIMER file
> >>
> >>
> >>
> https://repository.apache.org/content/repositories/orgapachestreams-1002/org/apache/streams/streams-provider-moreover/0.1-incubating/streams-provider-moreover-0.1-incubating.jar
> >>
> >>
> >> On Thu Jan 15 2015 at 3:16:19 PM Steve Blackmon <sb...@apache.org>
> >> wrote:
> >>
> >> > My bad, the repo was still 'open', now it is 'closed' and is
> browse-able
> >> > publically.
> >> >
> >> > Steve Blackmon
> >> > sblackmon@apache.org
> >> >
> >> > On Thu, Jan 15, 2015 at 7:37 AM, Matt Franklin <
> >> m.ben.franklin@gmail.com>
> >> > wrote:
> >> >
> >> > > I am getting the following from the staging repo:
> >> > >
> >> > > 404 - Repository "orgapachestreams-1002 (staging: open)"
> >> > > [id=orgapachestreams-1002] exists but is not exposed.
> >> > >
> >> > > Is it closed?
> >> > >
> >> > > On Wed Jan 14 2015 at 7:00:10 PM Steve Blackmon <
> sblackmon@apache.org
> >> >
> >> > > 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
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: [DISCUSS] Release Apache Streams vension 0.1-incubating (rc2)
Posted by Matt Franklin <m....@gmail.com>.
You are right. I was thinking of it like a source archive.
On Fri Jan 16 2015 at 12:42:35 PM Steve Blackmon <sb...@apache.org>
wrote:
> That jar looks correct to me. What should be different to comply with
> Apache release rules?
>
>
>
> Steve Blackmon
> sblackmon@apache.org
>
> On Fri, Jan 16, 2015 at 7:27 AM, Matt Franklin <m....@gmail.com>
> wrote:
>
>> It looks like at least some binary jars don't have the DISCLAIMER file
>>
>>
>> https://repository.apache.org/content/repositories/orgapachestreams-1002/org/apache/streams/streams-provider-moreover/0.1-incubating/streams-provider-moreover-0.1-incubating.jar
>>
>>
>> On Thu Jan 15 2015 at 3:16:19 PM Steve Blackmon <sb...@apache.org>
>> wrote:
>>
>> > My bad, the repo was still 'open', now it is 'closed' and is browse-able
>> > publically.
>> >
>> > Steve Blackmon
>> > sblackmon@apache.org
>> >
>> > On Thu, Jan 15, 2015 at 7:37 AM, Matt Franklin <
>> m.ben.franklin@gmail.com>
>> > wrote:
>> >
>> > > I am getting the following from the staging repo:
>> > >
>> > > 404 - Repository "orgapachestreams-1002 (staging: open)"
>> > > [id=orgapachestreams-1002] exists but is not exposed.
>> > >
>> > > Is it closed?
>> > >
>> > > On Wed Jan 14 2015 at 7:00:10 PM Steve Blackmon <sblackmon@apache.org
>> >
>> > > 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
>> > > >
>> > >
>> >
>>
>
>
Re: [DISCUSS] Release Apache Streams vension 0.1-incubating (rc2)
Posted by Steve Blackmon <sb...@apache.org>.
That jar looks correct to me. What should be different to comply with
Apache release rules?
Steve Blackmon
sblackmon@apache.org
On Fri, Jan 16, 2015 at 7:27 AM, Matt Franklin <m....@gmail.com>
wrote:
> It looks like at least some binary jars don't have the DISCLAIMER file
>
>
> https://repository.apache.org/content/repositories/orgapachestreams-1002/org/apache/streams/streams-provider-moreover/0.1-incubating/streams-provider-moreover-0.1-incubating.jar
>
>
> On Thu Jan 15 2015 at 3:16:19 PM Steve Blackmon <sb...@apache.org>
> wrote:
>
> > My bad, the repo was still 'open', now it is 'closed' and is browse-able
> > publically.
> >
> > Steve Blackmon
> > sblackmon@apache.org
> >
> > On Thu, Jan 15, 2015 at 7:37 AM, Matt Franklin <m.ben.franklin@gmail.com
> >
> > wrote:
> >
> > > I am getting the following from the staging repo:
> > >
> > > 404 - Repository "orgapachestreams-1002 (staging: open)"
> > > [id=orgapachestreams-1002] exists but is not exposed.
> > >
> > > Is it closed?
> > >
> > > On Wed Jan 14 2015 at 7:00:10 PM Steve Blackmon <sb...@apache.org>
> > > 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
> > > >
> > >
> >
>
Re: [DISCUSS] Release Apache Streams vension 0.1-incubating (rc2)
Posted by Matt Franklin <m....@gmail.com>.
It looks like at least some binary jars don't have the DISCLAIMER file
https://repository.apache.org/content/repositories/orgapachestreams-1002/org/apache/streams/streams-provider-moreover/0.1-incubating/streams-provider-moreover-0.1-incubating.jar
On Thu Jan 15 2015 at 3:16:19 PM Steve Blackmon <sb...@apache.org>
wrote:
> My bad, the repo was still 'open', now it is 'closed' and is browse-able
> publically.
>
> Steve Blackmon
> sblackmon@apache.org
>
> On Thu, Jan 15, 2015 at 7:37 AM, Matt Franklin <m....@gmail.com>
> wrote:
>
> > I am getting the following from the staging repo:
> >
> > 404 - Repository "orgapachestreams-1002 (staging: open)"
> > [id=orgapachestreams-1002] exists but is not exposed.
> >
> > Is it closed?
> >
> > On Wed Jan 14 2015 at 7:00:10 PM Steve Blackmon <sb...@apache.org>
> > 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
> > >
> >
>
Re: [DISCUSS] Release Apache Streams vension 0.1-incubating (rc2)
Posted by Steve Blackmon <sb...@apache.org>.
My bad, the repo was still 'open', now it is 'closed' and is browse-able
publically.
Steve Blackmon
sblackmon@apache.org
On Thu, Jan 15, 2015 at 7:37 AM, Matt Franklin <m....@gmail.com>
wrote:
> I am getting the following from the staging repo:
>
> 404 - Repository "orgapachestreams-1002 (staging: open)"
> [id=orgapachestreams-1002] exists but is not exposed.
>
> Is it closed?
>
> On Wed Jan 14 2015 at 7:00:10 PM Steve Blackmon <sb...@apache.org>
> 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
> >
>
Re: [DISCUSS] Release Apache Streams vension 0.1-incubating (rc2)
Posted by Matt Franklin <m....@gmail.com>.
I am getting the following from the staging repo:
404 - Repository "orgapachestreams-1002 (staging: open)"
[id=orgapachestreams-1002] exists but is not exposed.
Is it closed?
On Wed Jan 14 2015 at 7:00:10 PM Steve Blackmon <sb...@apache.org>
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
>
Re: [DISCUSS] Release Apache Streams vension 0.1-incubating (rc2)
Posted by Steve Blackmon <sb...@apache.org>.
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 <at...@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 <at...@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
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
Re: [DISCUSS] Release Apache Streams vension 0.1-incubating (rc2)
Posted by Robert Douglas <ro...@gmail.com>.
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 <at...@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 <at...@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
>>>>
>>>>
>>>>
>>>
>>
>
Re: [DISCUSS] Release Apache Streams vension 0.1-incubating (rc2)
Posted by Ate Douma <at...@douma.nu>.
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 <at...@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
>>>
>>>
>>
>
Re: [DISCUSS] Release Apache Streams vension 0.1-incubating (rc2)
Posted by Steve Blackmon <sb...@apache.org>.
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?
Would this still be an issue if we disabled the war plugin execution in the
interest of producing a viable release candidate?
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.
>> 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 <at...@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
>>
>>
>
Re: [DISCUSS] Release Apache Streams vension 0.1-incubating (rc2)
Posted by Ate Douma <at...@douma.nu>.
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
>