The second release candidate is available for everyone's review [1]. We plan to call for a vote shortly; please comment if there's any additional feedback.
[1] https://repository.apache.org/content/repositories/orgapachebeam-1001 On Tue, Jun 7, 2016 at 9:33 AM, Kenneth Knowles <k...@google.com.invalid> wrote: > +1 > > Lovely. Very readable. > > The "-parent" artifacts are just leaked implementation details of our build > configuration that no one should ever actually reference, right? > > Kenn > > On Tue, Jun 7, 2016 at 8:54 AM, Dan Halperin <dhalp...@google.com.invalid> > wrote: > > > +2! This seems most concordant with other Apache products and the most > > future-proof. > > > > On Mon, Jun 6, 2016 at 9:35 PM, Jean-Baptiste Onofré <j...@nanthrax.net> > > wrote: > > > > > +1 > > > > > > Regards > > > JB > > > > > > > > > On 06/07/2016 02:49 AM, Davor Bonaci wrote: > > > > > >> After a few rounds of discussions and examining patterns of other > > >> projects, > > >> I think we are converging towards: > > >> > > >> * A flat group structure, where all artifacts belong to the > > >> org.apache.beam > > >> group. > > >> * Prefix all artifact ids with "beam-". > > >> * Name artifacts according to the existing directory/module layout: > > >> beam-sdks-java-core, beam-runners-google-cloud-dataflow-java, etc. > > >> * Suffix all parents with "-parent", e.g., "beam-parent", > > >> "sdks-java-parent", etc. > > >> * Create a "distributions" module, for the purpose of packaging the > > source > > >> code for the ASF release. > > >> > > >> I believe this approach takes into account everybody's feedback so > far, > > >> and > > >> I think opposing positions have been retracted. > > >> > > >> Please comment if that's not the case, or if there are any additional > > >> points that we may have missed. If not, this is implemented in pending > > >> pull > > >> requests #420 and #423. > > >> > > >> Thanks! > > >> > > >> On Fri, Jun 3, 2016 at 9:59 AM, Thomas Weise <thomas.we...@gmail.com> > > >> wrote: > > >> > > >> Another consideration for potential future packaging/distribution > > >>> solutions > > >>> is how the artifacts line up as files in a flat directory. For that > it > > >>> may > > >>> be good to have a common prefix in the artifactId and unique > > artifactId. > > >>> > > >>> The name for the source archive (when relying on ASF parent POM) can > > also > > >>> be controlled without expanding the artifactId: > > >>> > > >>> <build> > > >>> <plugins> > > >>> <plugin> > > >>> <artifactId>maven-assembly-plugin</artifactId> > > >>> <configuration> > > >>> <finalName>apache-beam</finalName> > > >>> </configuration> > > >>> </plugin> > > >>> </plugins> > > >>> </build> > > >>> > > >>> Thanks, > > >>> Thomas > > >>> > > >>> On Fri, Jun 3, 2016 at 9:39 AM, Davor Bonaci > <da...@google.com.invalid > > > > > >>> wrote: > > >>> > > >>> BEAM-315 is definitely important. Normally, I'd always advocate for > > >>>> > > >>> holding > > >>> > > >>>> the release to pick that fix. For the very first release, however, > I'd > > >>>> prefer to proceed to get something out there and test the process. > As > > >>>> you > > >>>> said, we can address this rather quickly once we have the fix merged > > in. > > >>>> > > >>>> In terms of Maven coordinates, there are two basic approaches: > > >>>> * flat structure, where artifacts live under "org.apache.beam" group > > and > > >>>> are differentiated by their artifact id. > > >>>> * hierarchical structure, where we use different groups for > different > > >>>> > > >>> types > > >>> > > >>>> of artifacts (org.apache.beam.sdks; org.apache.beam.runners). > > >>>> > > >>>> There are pros and cons on the both sides of the argument. Different > > >>>> projects made different choices. Flat structure is easier to find > and > > >>>> navigate, but often breaks down with too many artifacts. > Hierarchical > > >>>> structure is just the opposite. > > >>>> > > >>>> On my end, the only important thing is consistency. We used to have > > it, > > >>>> > > >>> and > > >>> > > >>>> it got broken by PR #365. This part should be fixed -- we should > > either > > >>>> finish the vision of the hierarchical structure, or rollback that PR > > to > > >>>> > > >>> get > > >>> > > >>>> back to a fully flat structure. > > >>>> > > >>>> My general biases tend to be: > > >>>> * hierarchical structure, since we have many artifacts already. > > >>>> * short identifiers; no need to repeat a part of the group id in the > > >>>> artifact id. > > >>>> > > >>>> On Fri, Jun 3, 2016 at 4:03 AM, Jean-Baptiste Onofré < > j...@nanthrax.net > > > > > >>>> wrote: > > >>>> > > >>>> Hi Max, > > >>>>> > > >>>>> I discussed with Davor yesterday. Basically, I proposed: > > >>>>> > > >>>>> 1. To rename all parent with a prefix (beam-parent, > > >>>>> > > >>>> flink-runner-parent, > > >>> > > >>>> spark-runner-parent, etc). > > >>>>> 2. For the groupId, I prefer to use different groupId, it's clearer > > to > > >>>>> > > >>>> me, > > >>>> > > >>>>> and it's exactly the usage of the groupId. Some projects use a > single > > >>>>> groupId (spark, hadoop, etc), others use multiple (camel, karaf, > > >>>>> > > >>>> activemq, > > >>>> > > >>>>> etc). I prefer different groupIds but ok to go back to single one. > > >>>>> > > >>>>> Anyway, I'm preparing a PR to introduce a new Maven module: > > >>>>> "distribution". The purpose is to address both BEAM-319 (first) and > > >>>>> BEAM-320 (later). It's where we will be able to define the > different > > >>>>> distributions we plan to publish (source and binaries). > > >>>>> > > >>>>> Regards > > >>>>> JB > > >>>>> > > >>>>> > > >>>>> On 06/03/2016 11:02 AM, Maximilian Michels wrote: > > >>>>> > > >>>>> Thanks for getting us ready for the first release, Davor! We would > > >>>>>> like to fix BEAM-315 next week. Is there already a timeline for > the > > >>>>>> first release? If so, we could also address this in a minor > release. > > >>>>>> Releasing often will give us some experience with our release > > process > > >>>>>> :) > > >>>>>> > > >>>>>> I would like everyone to think about the artifact names and group > > ids > > >>>>>> again. "parent" and "flink" are not very suitable names for the > Beam > > >>>>>> parent or the Flink Runner artifact (same goes for the Spark > > Runner). > > >>>>>> I'd prefer "beam-parent", "flink-runner", and "spark-runner" as > > >>>>>> artifact ids. > > >>>>>> > > >>>>>> One might think of Maven GroupIds as a sort of hierarchy but > they're > > >>>>>> not. They're just an identifier. Renaming the parent pom to > > >>>>>> "apache-beam" or "beam-parent" would give us the old naming scheme > > >>>>>> which used flat group ids (before [1]). > > >>>>>> > > >>>>>> In the end, I guess it doesn't matter too much if we document the > > >>>>>> naming schemes accordingly. What matters is that we use a > consistent > > >>>>>> naming scheme. > > >>>>>> > > >>>>>> Cheers, > > >>>>>> Max > > >>>>>> > > >>>>>> [1] https://issues.apache.org/jira/browse/BEAM-287 > > >>>>>> > > >>>>>> > > >>>>>> On Thu, Jun 2, 2016 at 4:00 PM, Jean-Baptiste Onofré < > > j...@nanthrax.net > > >>>>>> > > >>>>> > > >>>> wrote: > > >>>>>> > > >>>>>> Actually, I think we can fix both issue in one commit. > > >>>>>>> > > >>>>>>> What do you think about renaming the main parent POM with: > > >>>>>>> groupId: org.apache.beam > > >>>>>>> artifactId: apache-beam > > >>>>>>> > > >>>>>>> ? > > >>>>>>> > > >>>>>>> Thanks to that, the source distribution will be named > > >>>>>>> apache-beam-xxx-sources.zip and it would be clearer to dev. > > >>>>>>> > > >>>>>>> Thoughts ? > > >>>>>>> > > >>>>>>> Regards > > >>>>>>> JB > > >>>>>>> > > >>>>>>> > > >>>>>>> On 06/02/2016 03:10 PM, Jean-Baptiste Onofré wrote: > > >>>>>>> > > >>>>>>> > > >>>>>>>> Another annoying thing is the main parent POM artifactId. > > >>>>>>>> > > >>>>>>>> Now, it's just "parent". What do you think about renaming to > > >>>>>>>> "beam-parent" ? > > >>>>>>>> > > >>>>>>>> Regarding the source distribution name, I would cancel this > > staging > > >>>>>>>> > > >>>>>>> to > > >>> > > >>>> fix that (I will have a PR ready soon). > > >>>>>>>> > > >>>>>>>> Thoughts ? > > >>>>>>>> > > >>>>>>>> Regards > > >>>>>>>> JB > > >>>>>>>> > > >>>>>>>> On 06/02/2016 03:46 AM, Davor Bonaci wrote: > > >>>>>>>> > > >>>>>>>> > > >>>>>>>>> Hi everyone! > > >>>>>>>>> We've started the release process for our first release, > > >>>>>>>>> 0.1.0-incubating. > > >>>>>>>>> > > >>>>>>>>> To recap previous discussions, we don't have particular > > functional > > >>>>>>>>> goals > > >>>>>>>>> for this release. Instead, we'd like to make available what's > > >>>>>>>>> currently in > > >>>>>>>>> the repository, as well as work through the release process. > > >>>>>>>>> > > >>>>>>>>> With this in mind, we've: > > >>>>>>>>> * branched off the release branch [1] at master's commit > 8485272, > > >>>>>>>>> * updated master to prepare for the second release, > > >>>>>>>>> > > >>>>>>>> 0.2.0-incubating, > > >>> > > >>>> * built the first release candidate, RC1, and deployed it to a > > >>>>>>>>> > > >>>>>>>> staging > > >>>> > > >>>>> repository [2]. > > >>>>>>>>> > > >>>>>>>>> We are not ready to start a vote just yet -- we've already > > >>>>>>>>> > > >>>>>>>> identified > > >>> > > >>>> a few > > >>>>>>>>> issues worth fixing. That said, I'd like to invite everybody to > > >>>>>>>>> > > >>>>>>>> take > > >>> > > >>>> a > > >>>> > > >>>>> peek > > >>>>>>>>> and comment. I'm hoping we can address as many issues as > possible > > >>>>>>>>> before we > > >>>>>>>>> start the voting process. > > >>>>>>>>> > > >>>>>>>>> Please let us know if you see any issues. > > >>>>>>>>> > > >>>>>>>>> Thanks, > > >>>>>>>>> Davor > > >>>>>>>>> > > >>>>>>>>> [1] > > >>>>>>>>> > > >>>>>>>>> > > >>>> > > https://github.com/apache/incubator-beam/tree/release-0.1.0-incubating > > >>>> > > >>>>> [2] > > >>>>>>>>> > > >>>>>>>>> > > >>>> > > https://repository.apache.org/content/repositories/orgapachebeam-1000/ > > >>>> > > >>>>> > > >>>>>>>>> > > >>>>>>>>> > > >>>>>>>> -- > > >>>>>>> Jean-Baptiste Onofré > > >>>>>>> jbono...@apache.org > > >>>>>>> http://blog.nanthrax.net > > >>>>>>> Talend - http://www.talend.com > > >>>>>>> > > >>>>>>> > > >>>>>> -- > > >>>>> Jean-Baptiste Onofré > > >>>>> jbono...@apache.org > > >>>>> http://blog.nanthrax.net > > >>>>> Talend - http://www.talend.com > > >>>>> > > >>>>> > > >>>> > > >>> > > >> > > > -- > > > Jean-Baptiste Onofré > > > jbono...@apache.org > > > http://blog.nanthrax.net > > > Talend - http://www.talend.com > > > > > >
