name of java api artifact

[Reza <re...@yahoo.com.INVALID>]

Right now the java api is called "devicemap-java" and its in the "org.apache.devicemap" package. Not sure if this is a good name because the "java" is redundant since the artifact is in a java repo manager. I was thinking of calling it "devicemap-api" or "devicemap-client" or maybe "devicemap-java-api"??? Thoughts?

Not a big deal if we change it later since we are still 1.0, but would like to get things straight before the 1st release.

The data repo is "devicemap-data" and I think thats a well suited artifact id.

Re: name of java api artifact

[Reza <re...@yahoo.com.INVALID>]

>> XMLParser

Yes, good idea, it should be moved into the loader package since its specific to loading.


________________________________
 From: Werner Keil <we...@gmail.com>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>; Reza <re...@yahoo.com> 
Sent: Tuesday, July 8, 2014 1:00 PM
Subject: Re: name of java api artifact
 


P.s.: In case of "devicemap-simpleddr" part of the artifact name also matches the actual subfolder under "java". 
For "classifier" that's no longer the case, so worth a thought if renaming the artifactId also should be done with the folder/module name

Besides, I don't see a strong value in exposing XMLParser in a separate package and public class. It is currently used only by private methods inside DDRLoader, so couldn't the class be package local in its package? There is no reusable "Parser" functionality seen from the class so far, so hiding it from the public API seems better. Otherwise it becomes part of 1.0 and anything we expose now could be used, so it's hard to remove later. Making it public later if required is easier on the other hand


WDYT?

Werner


On Tue, Jul 8, 2014 at 6:26 PM, Werner Keil <we...@gmail.com> wrote:

I codenamed it "devicemap-java-classifier", but used the then common OSGi alike artifactId.
>
>
>"devicemap-java-api", "devicemap-java-client" or even either of those without the "java" seems OK. If the W3C Simple DDR functionality could be 100% available within that artifact, there may not be need for a second/alternate API in the future, as of now, it doesn't seem to provide any of that, so "devicemap-simpleddr" (or with a "-java" if we want to do that consistently?) also has perfect justification. The only reason why it isn't automatically built is the lack of a proper Maven-compliant JAR, see prior message.
>
>
>Werner
>
>
>
>On Tue, Jul 8, 2014 at 6:13 PM, Reza <re...@yahoo.com.invalid> wrote:
>
>Right now the java api is called "devicemap-java" and its in the "org.apache.devicemap" package. Not sure if this is a good name because the "java" is redundant since the artifact is in a java repo manager. I was thinking of calling it "devicemap-api" or "devicemap-client" or maybe "devicemap-java-api"??? Thoughts?
>>
>>Not a big deal if we change it later since we are still 1.0, but would like to get things straight before the 1st release.
>>
>>The data repo is "devicemap-data" and I think thats a well suited artifact id.
>

Re: name of java api artifact

[Werner Keil <we...@gmail.com>]

Last but not least, I can only perform the same actions as before in JIRA.

Commenting on any ticket, closing those I reported myself, but even those I
can't assign to anybody else but the person it's assigned to.
Is this supposed to be only Bertrand who can make assignments?


On Tue, Jul 8, 2014 at 7:00 PM, Werner Keil <we...@gmail.com> wrote:

> P.s.: In case of "devicemap-simpleddr" part of the artifact name also
> matches the actual subfolder under "java".
> For "classifier" that's no longer the case, so worth a thought if renaming
> the artifactId also should be done with the folder/module name[?]
>
> Besides, I don't see a strong value in exposing XMLParser in a separate
> package and public class. It is currently used only by private methods
> inside DDRLoader, so couldn't the class be package local in its package?
> There is no reusable "Parser" functionality seen from the class so far, so
> hiding it from the public API seems better. Otherwise it becomes part of
> 1.0 and anything we expose now could be used, so it's hard to remove later.
> Making it public later if required is easier on the other hand[?]
>
> WDYT?
>
> Werner
>
> On Tue, Jul 8, 2014 at 6:26 PM, Werner Keil <we...@gmail.com> wrote:
>
>> I codenamed it "devicemap-java-classifier", but used the then common OSGi
>> alike artifactId.
>>
>> "devicemap-java-api", "devicemap-java-client" or even either of those
>> without the "java" seems OK. If the W3C Simple DDR functionality could be
>> 100% available within that artifact, there may not be need for a
>> second/alternate API in the future, as of now, it doesn't seem to provide
>> any of that, so "devicemap-simpleddr" (or with a "-java" if we want to do
>> that consistently?[?]) also has perfect justification. The only reason
>> why it isn't automatically built is the lack of a proper Maven-compliant
>> JAR, see prior message.
>>
>> Werner
>>
>>
>> On Tue, Jul 8, 2014 at 6:13 PM, Reza <re...@yahoo.com.invalid>
>> wrote:
>>
>>> Right now the java api is called "devicemap-java" and its in the
>>> "org.apache.devicemap" package. Not sure if this is a good name because the
>>> "java" is redundant since the artifact is in a java repo manager. I was
>>> thinking of calling it "devicemap-api" or "devicemap-client" or maybe
>>> "devicemap-java-api"??? Thoughts?
>>>
>>> Not a big deal if we change it later since we are still 1.0, but would
>>> like to get things straight before the 1st release.
>>>
>>> The data repo is "devicemap-data" and I think thats a well suited
>>> artifact id.
>>
>>
>>
>

Re: name of java api artifact

[Werner Keil <we...@gmail.com>]

P.s.: In case of "devicemap-simpleddr" part of the artifact name also
matches the actual subfolder under "java".
For "classifier" that's no longer the case, so worth a thought if renaming
the artifactId also should be done with the folder/module name[?]

Besides, I don't see a strong value in exposing XMLParser in a separate
package and public class. It is currently used only by private methods
inside DDRLoader, so couldn't the class be package local in its package?
There is no reusable "Parser" functionality seen from the class so far, so
hiding it from the public API seems better. Otherwise it becomes part of
1.0 and anything we expose now could be used, so it's hard to remove later.
Making it public later if required is easier on the other hand[?]

WDYT?

Werner

On Tue, Jul 8, 2014 at 6:26 PM, Werner Keil <we...@gmail.com> wrote:

> I codenamed it "devicemap-java-classifier", but used the then common OSGi
> alike artifactId.
>
> "devicemap-java-api", "devicemap-java-client" or even either of those
> without the "java" seems OK. If the W3C Simple DDR functionality could be
> 100% available within that artifact, there may not be need for a
> second/alternate API in the future, as of now, it doesn't seem to provide
> any of that, so "devicemap-simpleddr" (or with a "-java" if we want to do
> that consistently?[?]) also has perfect justification. The only reason why
> it isn't automatically built is the lack of a proper Maven-compliant JAR,
> see prior message.
>
> Werner
>
>
> On Tue, Jul 8, 2014 at 6:13 PM, Reza <re...@yahoo.com.invalid>
> wrote:
>
>> Right now the java api is called "devicemap-java" and its in the
>> "org.apache.devicemap" package. Not sure if this is a good name because the
>> "java" is redundant since the artifact is in a java repo manager. I was
>> thinking of calling it "devicemap-api" or "devicemap-client" or maybe
>> "devicemap-java-api"??? Thoughts?
>>
>> Not a big deal if we change it later since we are still 1.0, but would
>> like to get things straight before the 1st release.
>>
>> The data repo is "devicemap-data" and I think thats a well suited
>> artifact id.
>
>
>

Re: name of java api artifact

[Werner Keil <we...@gmail.com>]

I codenamed it "devicemap-java-classifier", but used the then common OSGi
alike artifactId.

"devicemap-java-api", "devicemap-java-client" or even either of those
without the "java" seems OK. If the W3C Simple DDR functionality could be
100% available within that artifact, there may not be need for a
second/alternate API in the future, as of now, it doesn't seem to provide
any of that, so "devicemap-simpleddr" (or with a "-java" if we want to do
that consistently?[?]) also has perfect justification. The only reason why
it isn't automatically built is the lack of a proper Maven-compliant JAR,
see prior message.

Werner


On Tue, Jul 8, 2014 at 6:13 PM, Reza <re...@yahoo.com.invalid> wrote:

> Right now the java api is called "devicemap-java" and its in the
> "org.apache.devicemap" package. Not sure if this is a good name because the
> "java" is redundant since the artifact is in a java repo manager. I was
> thinking of calling it "devicemap-api" or "devicemap-client" or maybe
> "devicemap-java-api"??? Thoughts?
>
> Not a big deal if we change it later since we are still 1.0, but would
> like to get things straight before the 1st release.
>
> The data repo is "devicemap-data" and I think thats a well suited artifact
> id.