+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 >
