+1
it looks good to me:
- all files have incubating
- signatures check out (asc, md5, sha1) (and KEYS there)
- disclaimer exists
- LICENSE and NOTICE good
- No unexpected binary in source
- All ASF licensed files have ASF headers
- Source distribution is available, with a correct name, and correct
content:
https://repository.apache.org/content/repositories/orgapachebeam-1001/org/apache/beam/apache-beam/0.1.0-incubating/apache-beam-0.1.0-incubating-src.zip
I'm more comfortable to move forward on a formal release vote with this
staging, and forward to the IPMC review.
Thanks all and especially to Davor (to support me when I bother him
bunch of times a day ;)).
Regards
JB
On 06/07/2016 08:58 PM, Davor Bonaci wrote:
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
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
