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