Re: 0.1.0-incubating release

[Jean-Baptiste Onofré]

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

  
 
   
 maven-assembly-plugin
 
   apache-beam
 
   
 
  

Thanks,
Thomas

On Fri, Jun 3, 2016 at 9:39 AM, Davor Bonaci 
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é 
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é 

Re: [PROPOSAL] New Beam website design?

[Jean-Baptiste Onofré]

Hi James,

very good idea !

Couple of month ago, I completely revamped the Karaf website:

http://karaf.apache.org/

It could be a good skeleton in term of sections/pages.

IMHO, for Beam, at least for the home page, we should have:
1. a clear message about what Beam is from an user perspective: why 
should I use Beam and write pipelines, what's the value, etc. The runner 
writers, or DSL writers will find their resources but not on the 
homepage (on dedicated section of the website).


In term of sections, we could propose
1.1. Overview (with the three perspective/type of users)
1.2. Libraries: SDKs, DSLs, IOs, Runners
1.3. Documentation: Dev Guide, Samples, Runners Writer guide, ...
1.4. Community: mailing list, contribution guide, ...
1.5. Apache (link to ASF)

2. a look'n feel should be clean and professional, at least for the home 
page.


I would love to help here !

Regards
JB

On 06/06/2016 05:29 PM, James Malone wrote:

Hello everyone!

The current design of the Apache Beam website[1] is based on the a basic
Bootstrap/Jekyll theme. While this made getting an initial site out quickly
pretty easy, the site itself is a little bland (in my opinion :). I propose
we create a new design (layout templates, color schemes, visual design) for
the Beam website.

Since the website is currently using Bootstrap and Jekyll, this should be a
relatively easy process. Getting this done will require a new design and
some CSS/HTML work. Additionally, before a design is put in place, I think
it makes sense to discuss any ideas about a future design first.

So, I think there are two open questions behind this proposal:

1. Is there anyone within the community who would be interested in creating
a design proposal or two and sharing them with the community?
2. Are there any ideas, opinions, and thoughts around what the design of
the site *should* be?

What does everyone think?

Cheers!

James

[1]: http://beam.incubator.apache.org



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

[PROPOSAL] New Beam website design?

[James Malone]

Hello everyone!

The current design of the Apache Beam website[1] is based on the a basic
Bootstrap/Jekyll theme. While this made getting an initial site out quickly
pretty easy, the site itself is a little bland (in my opinion :). I propose
we create a new design (layout templates, color schemes, visual design) for
the Beam website.

Since the website is currently using Bootstrap and Jekyll, this should be a
relatively easy process. Getting this done will require a new design and
some CSS/HTML work. Additionally, before a design is put in place, I think
it makes sense to discuss any ideas about a future design first.

So, I think there are two open questions behind this proposal:

1. Is there anyone within the community who would be interested in creating
a design proposal or two and sharing them with the community?
2. Are there any ideas, opinions, and thoughts around what the design of
the site *should* be?

What does everyone think?

Cheers!

James

[1]: http://beam.incubator.apache.org

Jenkins build is back to normal : beam_Release_NightlySnapshot #62

[Apache Jenkins Server]

See