Indeed, the current directory structure is very Java-centric. We are in
process of fixing that.
We are thinking of going somewhere along the lines of:
sdks
java
py
examples
java
java8
py
runners
google-cloud-dataflow
flink
spark
In a way, we are thinking of having
+1 JB.
If it works for other incubating projects, then I'm happy to proceed.
On Mon, Mar 21, 2016 at 1:00 PM, Jean-Baptiste Onofré
wrote:
> Hi Ben,
>
> it works fine with Maven >= 3.2.x (current version is 3.3.9).
>
> Most of incubator projects use x.x.x-incubating-SNAPSHOT:
>
>
> https://git1-
On Mon, Mar 21, 2016 at 10:24 AM, Jean-Baptiste Onofré
wrote:
> Hi Ben,
>
> 1. True for Python, but it can go in a folder in sdk (sdk/python) anyway. I
> think the DSLs (Java based) and other languages that we might introduce
> (Scala, ...) can be the same.
Python would certainly want to be on P
Upon further discussion, I'd like to propose that we adopt JB's proposal
and use "-incubating-SNAPSHOT" style while we are an incubating project.
There are pros and cons on both sides. Based on the information so far, a
category of stakeholders who'll need to upgrade their Maven installation is
sm
Hi Ben,
it works fine with Maven >= 3.2.x (current version is 3.3.9).
Most of incubator projects use x.x.x-incubating-SNAPSHOT:
https://git1-us-west.apache.org/repos/asf?p=incubator-batchee.git;a=blob_plain;f=pom.xml;hb=HEAD
https://git1-us-west.apache.org/repos/asf?p=incubator-apex-core.git;a
On Mon, Mar 21, 2016 at 6:22 PM, Ben Chambers
wrote:
> I don't think Maven will recognize 0.1.0-incubating-SNAPSHOT as a snapshot.
> It will recognize it as 0.1.0 with the "incubating-SNAPSHOT" qualifier.
>
> For instance, looking at the code for parsing qualifiers, it only handles
> the string "
Many issues have been raised here and I cannot tell the direction
people are working now on the PR. So here is my current thinking,
which may be a +1 to some things or may be different.
1. Versions
- This seems odd: 0.1.0-incubating < 0.1.0-SNAPSHOT
It mostly shouldn't matter but seems better
I would be in favor of one group id. For the developer, hierarchies
are really important. They are visible in the directory layout of the
Maven project and in the dependency tree. For the user, it shouldn't
matter how the project is structured. He pulls in artifacts simply
from the "org.apache.beam
I don't think Maven will recognize 0.1.0-incubating-SNAPSHOT as a snapshot.
It will recognize it as 0.1.0 with the "incubating-SNAPSHOT" qualifier.
For instance, looking at the code for parsing qualifiers, it only handles
the string "SNAPSHOT" specially, not "incubating-SNAPSHOT".
http://maven.apa
Hi Ben,
1. True for Python, but it can go in a folder in sdk (sdk/python)
anyway. I think the DSLs (Java based) and other languages that we might
introduce (Scala, ...) can be the same.
2. The incubating has to be in the released filenames. So it can be in
the version or name. Anyway, my pro
1. Regarding "java" as a module -- are we sure that other languages will be
packaged using Maven as well? For instance, Python has its own ecosystem
which likely doesn't play well with Python.
2. Using the literal "SNAPSHOT" as the qualifier has special meaning Maven
-- it is newer than all other
Hi Lukasz,
both are possible.
Some projects use different groupId. It's the case for Karaf or Camel
for instance:
http://repo.maven.apache.org/maven2/org/apache/karaf/
You can see there the different groupId, containing the different artifacts.
On the other hand, other projects use an uniqu
I like the single groupId since it makes it simpler to find all related
components for a project.
Is there a common practice in maven for multi-module vs inheritance
projects for choosing the groupId?
On Mon, Mar 21, 2016 at 7:32 AM, Jean-Baptiste Onofré
wrote:
> Hi beamers,
>
> I updated the P
Hi beamers,
I updated the PR according to your comments.
I have couple of points I want to discuss:
1. All modules use the same groupId (org.apache.beam). In order to have
a cleaner structure on the Maven repo, I wonder if it's not better to
have different groupId depending of the artifacts.
Hi Davor,
thank you so much for your comments. I'm updating the PR according to
your PR (and will provide explanation to some changes).
Thanks dude !
Regards
JB
On 03/21/2016 06:29 AM, Davor Bonaci wrote:
I left a few comments on PR #46.
Thanks JB for doing this; a clear improvement.
On M
I left a few comments on PR #46.
Thanks JB for doing this; a clear improvement.
On Mon, Mar 14, 2016 at 6:04 PM, Jean-Baptiste Onofré
wrote:
> Hi all,
>
> I started the renaming process from Dataflow to Beam.
>
> I submitted a first PR about the Maven coordinates:
>
> https://github.com/apache/
Hi all,
I started the renaming process from Dataflow to Beam.
I submitted a first PR about the Maven coordinates:
https://github.com/apache/incubator-beam/pull/46
I will start the packages renaming (updating the same PR). For the
directories structure, I would like to talk with Frances, Dan,
17 matches
Mail list logo
