Not Central, Apache SNAPSHOT repo.
Regards
JB
On 03/21/2016 11:12 PM, Andreas Veithen wrote:
On Mon, Mar 21, 2016 at 11:54 AM, Jean-Baptiste Onofré
wrote:
Thinking about this, I would prefer 0.1.0-incubating-SNAPSHOT, as it will
also indicate that the SNAPSHOTs (on
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
+1 for knowledge-sharing and getting to know other pieces of our code base.
I would definitely be interested in getting to know Beam better, apart from
the parts a runner developer deals with.
On Mon, Mar 21, 2016, 20:19 Kenneth Knowles wrote:
> +1 for emphasizing the
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".
+1 for emphasizing the knowledge-sharing aspect of review.
I think it is the most important for project health, and the most fun too!
I love the chance to learn about a new piece of code (or learn how I messed
up in my own code :-)
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
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
Yes, it's what I used for now (sdk-java-extensions). And you are right,
it's enough for now.
We will create a dedicated component when the number of IOs (and
different extensions) will come.
Regards
JB
On 03/21/2016 05:57 PM, Frances Perry wrote:
The original plan was that IOs would just
The original plan was that IOs would just be in the library extensions
(e.g. sdk-java-extensions). It'd fine to subdivide that further if needed,
but maybe we should wait until it gets a bit bigger? Dan, what do you
think, as component owner?
On Mon, Mar 21, 2016 at 2:33 AM, Jean-Baptiste Onofré
Thanks, all!
On Fri, Mar 18, 2016 at 6:46 AM Amit Sela wrote:
> Looks great!
> I think it's the best way to give a clear picture of capabilities for users
> and runner developers.
> And as always, Love the colours ;)
>
>
> On Fri, Mar 18, 2016 at 3:33 PM Kostas Kloudas <
>
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
Thinking about this, I would prefer 0.1.0-incubating-SNAPSHOT, as it
will also indicate that the SNAPSHOTs (on Central) are from incubating.
So, I would propose 0.1.0-incubating-SNAPSHOT (and 0.1.0-incubating for
the release).
Regards
JB
On 03/21/2016 12:32 PM, Maximilian Michels wrote:
If
Hi beamers !
I started to work on the directories re-organization, and especially,
I'm moving the different IOs in their own folder.
As we can bet on contribution on IO, maybe it would make sense to create
the IO component in Jira.
Thoughts ?
Regards
JB
--
Jean-Baptiste Onofré
13 matches
Mail list logo