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

Reply via email to