devicemap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Keil <werner.k...@gmail.com>
Subject Re: [DISCUSS] svn layout
Date Tue, 21 Apr 2015 08:30:48 GMT
Sounds like a good idea.
A good practice vor every Maven project unless they benefit from sharing a
parent POM (e.g. "examples") is to use an Apache-parent POM. I think all
Mavenized projects do.

The only question is, does the clients/devicemap aim to have W3C compliant
modules or extensions (like /devicemap/java/classifier_w3c_simple/) ?
Reza mentioned before, there could be a bit of confusion, so if both
variants co-exist, what could be a place or name for the "wrapper"?

Thinking beyond other languages, could we call the clients/devicemap
clients/java, too?
That does not prohibit the clients/w3c-ddr or a possible clients/groovy
(which may in fact simply be a wrapper or bridge like we saw for Clojure)
but "everything is devicemap" so why would only the Java client be called
"devicemap" and e.g. a VB, Ruby, Groovy or others use their respective
language names?

I know W3C-DDR deserves a special treatment based on both the W3C license.
And although binaries don't exist other than for Java, the W3C Spec may be
applied by other languages, too, so there it makes sense.

Aside from that it looks fine to me.

Werner

On Tue, Apr 21, 2015 at 9:49 AM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:

> Hi,
>
> Here's a proposal based on Reza's ideas, but slightly different in
> that it keeps all the code under /trunk while providing good isolation
> between the devicemap and w3c-ddr clients.
>
> I suggest keeping the existing top-level folders under
> https://svn.apache.org/repos/asf/devicemap/ , we can clarify their
> usage once we agree on the basic structure.
>
> Then, put all software under
> https://svn.apache.org/repos/asf/devicemap/trunk, under the following
> top folders:
>
> *** svn trunk structure proposal ***
> browsermap: that module, as is today
>
> data: the device data, probably with 1.0 and 2.0 subfolders to keep
> both formats easily accessible during the transition, 1.0 being
> retired later
>
> clients/devicemap: the main Java client, what's currently under
> devicemap/java/classifier
>
> clients/csharp, clients/vbnet: the clients in those languages, moved
> from their current locations
>
> clients/w3c-ddr: the W3C DDR client that's currently under
> devicemap/java/simpleddr
>
> contrib: unsupported or archived modules that the project only
> maintains on a best effort basis
>
> docs: various technical docs
>
> examples: various examples that do not belong in their respective
> modules folders
>
> The clients/devicemap and clients/w3c-ddr java modules do *not* share
> a common pom, so they are completely isolated.
> *** svn trunk structure proposal ***
>
> I think this provides good separation without the additional
> complexity of multiple svn top-level folders.
>
> Maybe work in Review-Then-Commit mode [1] on the data folder if people
> want strict control of what goes in there.
>
> We can discuss artifact names and version numbers later, IMO the first
> thing is to agree on this layout.
>
> WDYT?
> -Bertrand
>
> [1] https://www.apache.org/foundation/glossary.html - search for "RTC"
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message