You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@devicemap.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2015/04/21 09:49:43 UTC
[DISCUSS] svn layout
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"
Re: [DISCUSS] svn layout
Posted by "eberhard speer jr." <se...@ducis.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
If we go with this compromise, I think this proposal is preferable.
esjr
On 2015-04-21 10:49, Bertrand Delacretaz 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"
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJVNgMiAAoJEOxywXcFLKYcJWUH/2lz0/T8YE3wQQQ+KMDvy8FB
K+L2+nBl8TzGQeuKaugBb+jfG613ZsoZmWrXzYrSO7wFAdRk7e/kp6KXY/zv792q
ujnGn8fNMLJC55VCVDiKg7W1rihz8bayLPDg6TzZXZccFJqzWBIxpNTU42wkCCa+
fFGGBdwrsWsqZQgByShWLuy8r8gvA+/2d5V2yotLjkAmhsZ7et9d8L73NnVqozEs
w2+1ujKjS6yCM0fCXjIzQOBhUvwoBmadd/8iUKItt96ZO13CrPLK0RCwe10TO3NC
R7WuZxEXQmdo6jx2BDtRhCQioPjbwtLYh1r4Fj9NnYIai//fz4E+mPoGicOZDHc=
=XvaW
-----END PGP SIGNATURE-----
Re: [DISCUSS] svn layout
Posted by Werner Keil <we...@gmail.com>.
On Tue, Apr 21, 2015 at 12:41 PM, Bertrand Delacretaz <
bdelacretaz@apache.org> wrote:
> Hi,
>
> On Tue, Apr 21, 2015 at 10:30 AM, Werner Keil <we...@gmail.com>
> wrote:
> >
> > ...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....
>
> Agreed, but each Java module can then decide to do that or not.
>
> If a module has no need for any of the ASF pre-defined things like
Checkstyle plugin, etc. sure, they may ignore it or define it from scratch.
> >... The only question is, does the clients/devicemap aim to have W3C
> compliant
> > modules or extensions...
>
> That's a question for later IMO.
>
Even if Reza or others did not currently spend an effort,
the /devicemap/java/classifier_w3c_simple/ should go "somewhere".
One option (for "dormant" code) would be /contrib/prototypes/
If it's actively maintained, then a proper location under the suggested
/clients folder should be found.
>
> > ...Thinking beyond other languages, could we call the clients/devicemap
> > clients/java, too?...
>
> Maybe...I suggest letting Reza decide this as he did the bulk of the
> work on that module.
>
On ../classifier yes, I don't insist on either name, but "java" simply
tells what's in it. Neither of the other language bindings or ports are any
more or less "devicemap" than the Java parts;-)
>
> -Bertrand
>
Werner
Re: [DISCUSS] svn layout
Posted by Werner Keil <we...@gmail.com>.
One more thing (after SVN refactoring was done) it seems really beneficial
to set up at least 2 or 3 separate Jenkins builds.
Whether or not one "root POM" even still makes sense, please let's discuss
when the time comes, but probably better to use "downstream" jobs like many
other Apache projects do. Including log4net:
https://builds.apache.org/job/log4net-trunk-build/ so either the vbnet or
C# client or both should also be CI capable on a dedicated Jenkins node,
just like the one Log4Net uses.
A "Data x.x" build (over time at least a 1.x and 2.x stream should exist)
triggers all dependent clients if data they use changed.
Clients used by a top level /examples may then be used as their trigger.
You also see this with log4net where the library job triggers "examples"
and "tests" (in Maven usually one build job)
So 1 or more "data" jobs plus a job for each "clients" that can use Jenkins
and maybe one for "examples" sounds reasonable.
Clients or languages that can't build on Jenkins, see Browsermap or
Konstantin's Ruby port on GitHub would just use their CI server like
Travis, those that Jenkins nodes on Apache supports should have Jenkins
jobs at builds.apache.
Let's change the architecture, then I may start a separate thread for this.
Werner
On Wed, Apr 22, 2015 at 3:46 PM, Werner Keil <we...@gmail.com> wrote:
> Ok, that makes it easier. Just recall
> https://www.apache.org/foundation/voting.html said
> 1) Code Modifications, but if that is not binding to any modification or
> "refactoring" like this, then the thread here also showed consensus by all
> who said something.
>
> Whoever does their share, make sure the root POM other than /data which
> should not be subject to change here gets updated. If you need help with
> the
> relationship between devicemap/java/simpleddr and devicemap/java/lib,
> just ask for help.
>
> Otherwise, please move the lib folder under the new clients/w3c-ddr
> without adding the module to the POM yet, I can fix the
> addjars-maven-plugin.
> You will need the same lib folder under classifier_w3c_simple whatever its
> name and location would be, if intended to build. The Maven modules are
> unrelated as Bertrand stated, so unless there was a /clients/lib or
> /clients/shared folder for these things, each module must have its own
> self-contained folders for that. The W3C JAR is also rather small so no big
> overhead.
>
> Werner
>
> On Wed, Apr 22, 2015 at 3:26 PM, Bertrand Delacretaz <
> bdelacretaz@apache.org> wrote:
>
>> Hi,
>>
>> On Wed, Apr 22, 2015 at 3:09 PM, Werner Keil <we...@gmail.com>
>> wrote:
>> > ...I suppose
>> > this being a change to the codebase, a formal vote on the private list
>> > should take place for it...
>>
>> No, we usually vote on the private list only for issues related to
>> people, like elections.
>>
>> In this case, as we seem to have consensus here I don't see a need for a
>> vote.
>>
>> Reza, would you have time to do the svn changes? Otherwise I might be
>> able to do that at the end of this week.
>>
>> -Bertrand
>>
>
>
Re: [DISCUSS] svn layout
Posted by Werner Keil <we...@gmail.com>.
Ok, that makes it easier. Just recall
https://www.apache.org/foundation/voting.html said
1) Code Modifications, but if that is not binding to any modification or
"refactoring" like this, then the thread here also showed consensus by all
who said something.
Whoever does their share, make sure the root POM other than /data which
should not be subject to change here gets updated. If you need help with
the
relationship between devicemap/java/simpleddr and devicemap/java/lib, just
ask for help.
Otherwise, please move the lib folder under the new clients/w3c-ddr without
adding the module to the POM yet, I can fix the addjars-maven-plugin.
You will need the same lib folder under classifier_w3c_simple whatever its
name and location would be, if intended to build. The Maven modules are
unrelated as Bertrand stated, so unless there was a /clients/lib or
/clients/shared folder for these things, each module must have its own
self-contained folders for that. The W3C JAR is also rather small so no big
overhead.
Werner
On Wed, Apr 22, 2015 at 3:26 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> Hi,
>
> On Wed, Apr 22, 2015 at 3:09 PM, Werner Keil <we...@gmail.com>
> wrote:
> > ...I suppose
> > this being a change to the codebase, a formal vote on the private list
> > should take place for it...
>
> No, we usually vote on the private list only for issues related to
> people, like elections.
>
> In this case, as we seem to have consensus here I don't see a need for a
> vote.
>
> Reza, would you have time to do the svn changes? Otherwise I might be
> able to do that at the end of this week.
>
> -Bertrand
>
Re: [DISCUSS] svn layout
Posted by Werner Keil <we...@gmail.com>.
Great, thanks.
As for test-data, Eberhard seems to have collected it mostly. if needed for
some tests, I guess some of us may archive it locally before also the
backup goes away but unless any modules have imminent need for it, we could
do without.
On Thu, Apr 23, 2015 at 7:07 PM, Reza Naghibi <re...@apache.org> wrote:
> I renamed examples/ODDR to examples/w3c-ddr and the backup trunk is now
> trunk_backup. When there is no more need for backup_trunk, we can delete
> it.
>
>
> On Thu, Apr 23, 2015 at 11:31 AM, Werner Keil <we...@gmail.com>
> wrote:
>
> > Bertrand,
> > Seems you missed the counterpart in
> > https://svn.apache.org/viewvc/devicemap/trunk/examples/,
> > still contains an "ODDR" folder.
> >
> > Unless you get a chance to change, I'd be able to fix a bit later today.
> > The top level folder looks like a pure "backup" so not concerned about
> it.
> > I trust eventually someone can deal with that folder. If Jenkins also
> works
> > again;-)
> >
> > Werner
> >
> > On Thu, Apr 23, 2015 at 10:40 AM, Werner Keil <we...@gmail.com>
> > wrote:
> >
> > > Agree, which is why the branch, though it allows commits, too might be
> > > irrelevant now.
> > >
> > > Werner
> > >
> > > On Thu, Apr 23, 2015 at 10:34 AM, Bertrand Delacretaz <
> > > bdelacretaz@apache.org> wrote:
> > >
> > >> On Thu, Apr 23, 2015 at 9:53 AM, Werner Keil <we...@gmail.com>
> > >> wrote:
> > >> > ...One other thing seems to make little sense after Reza split many
> > >> parts into
> > >> > 1.0 / 2.0...
> > >>
> > >> Well, AFAIU the goal of this restructure is to get a nice split
> > >> between the w3c-ddr stuff where you are supposed to work, and the rest
> > >> where others who work on 2.0 can operate.
> > >>
> > >> So I think we can let them decide how to best use "their" space. svn
> > >> branches wouldn't be convenient for that stuff anyway IMO.
> > >>
> > >> -Bertrand
> > >>
> > >
> > >
> >
>
Re: [DISCUSS] svn layout
Posted by Reza Naghibi <re...@apache.org>.
I renamed examples/ODDR to examples/w3c-ddr and the backup trunk is now
trunk_backup. When there is no more need for backup_trunk, we can delete it.
On Thu, Apr 23, 2015 at 11:31 AM, Werner Keil <we...@gmail.com> wrote:
> Bertrand,
> Seems you missed the counterpart in
> https://svn.apache.org/viewvc/devicemap/trunk/examples/,
> still contains an "ODDR" folder.
>
> Unless you get a chance to change, I'd be able to fix a bit later today.
> The top level folder looks like a pure "backup" so not concerned about it.
> I trust eventually someone can deal with that folder. If Jenkins also works
> again;-)
>
> Werner
>
> On Thu, Apr 23, 2015 at 10:40 AM, Werner Keil <we...@gmail.com>
> wrote:
>
> > Agree, which is why the branch, though it allows commits, too might be
> > irrelevant now.
> >
> > Werner
> >
> > On Thu, Apr 23, 2015 at 10:34 AM, Bertrand Delacretaz <
> > bdelacretaz@apache.org> wrote:
> >
> >> On Thu, Apr 23, 2015 at 9:53 AM, Werner Keil <we...@gmail.com>
> >> wrote:
> >> > ...One other thing seems to make little sense after Reza split many
> >> parts into
> >> > 1.0 / 2.0...
> >>
> >> Well, AFAIU the goal of this restructure is to get a nice split
> >> between the w3c-ddr stuff where you are supposed to work, and the rest
> >> where others who work on 2.0 can operate.
> >>
> >> So I think we can let them decide how to best use "their" space. svn
> >> branches wouldn't be convenient for that stuff anyway IMO.
> >>
> >> -Bertrand
> >>
> >
> >
>
Re: [DISCUSS] svn layout
Posted by Werner Keil <we...@gmail.com>.
Bertrand,
Seems you missed the counterpart in
https://svn.apache.org/viewvc/devicemap/trunk/examples/,
still contains an "ODDR" folder.
Unless you get a chance to change, I'd be able to fix a bit later today.
The top level folder looks like a pure "backup" so not concerned about it.
I trust eventually someone can deal with that folder. If Jenkins also works
again;-)
Werner
On Thu, Apr 23, 2015 at 10:40 AM, Werner Keil <we...@gmail.com> wrote:
> Agree, which is why the branch, though it allows commits, too might be
> irrelevant now.
>
> Werner
>
> On Thu, Apr 23, 2015 at 10:34 AM, Bertrand Delacretaz <
> bdelacretaz@apache.org> wrote:
>
>> On Thu, Apr 23, 2015 at 9:53 AM, Werner Keil <we...@gmail.com>
>> wrote:
>> > ...One other thing seems to make little sense after Reza split many
>> parts into
>> > 1.0 / 2.0...
>>
>> Well, AFAIU the goal of this restructure is to get a nice split
>> between the w3c-ddr stuff where you are supposed to work, and the rest
>> where others who work on 2.0 can operate.
>>
>> So I think we can let them decide how to best use "their" space. svn
>> branches wouldn't be convenient for that stuff anyway IMO.
>>
>> -Bertrand
>>
>
>
Re: [DISCUSS] svn layout
Posted by Werner Keil <we...@gmail.com>.
Agree, which is why the branch, though it allows commits, too might be
irrelevant now.
Werner
On Thu, Apr 23, 2015 at 10:34 AM, Bertrand Delacretaz <
bdelacretaz@apache.org> wrote:
> On Thu, Apr 23, 2015 at 9:53 AM, Werner Keil <we...@gmail.com>
> wrote:
> > ...One other thing seems to make little sense after Reza split many
> parts into
> > 1.0 / 2.0...
>
> Well, AFAIU the goal of this restructure is to get a nice split
> between the w3c-ddr stuff where you are supposed to work, and the rest
> where others who work on 2.0 can operate.
>
> So I think we can let them decide how to best use "their" space. svn
> branches wouldn't be convenient for that stuff anyway IMO.
>
> -Bertrand
>
Re: [DISCUSS] svn layout
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Apr 23, 2015 at 9:53 AM, Werner Keil <we...@gmail.com> wrote:
> ...One other thing seems to make little sense after Reza split many parts into
> 1.0 / 2.0...
Well, AFAIU the goal of this restructure is to get a nice split
between the w3c-ddr stuff where you are supposed to work, and the rest
where others who work on 2.0 can operate.
So I think we can let them decide how to best use "their" space. svn
branches wouldn't be convenient for that stuff anyway IMO.
-Bertrand
Re: [DISCUSS] svn layout
Posted by Werner Keil <we...@gmail.com>.
Cool, thanks,
One other thing seems to make little sense after Reza split many parts into
1.0 / 2.0 (similar to Tomcat maybe 1.0.x or 1.x would be better but that I
guess everyone could live with;-) who would use /branches/2.0 now? Not
critical, but seems it can be removed on branches some time.
With regards to descriptive naming, Reza's W3C module (currently not built
by any POM so we can leave it where it is) is really an equivalent to
"Portlet Bridge for JSF", as the Portals project where I'm committer, too
shows: http://portals.apache.org/
It contains sub-projects like "Pluto" or "Bridges". And the latter is for
the Portlet Bridge. Could be a way to tell them apart.
Werner
On Thu, Apr 23, 2015 at 9:31 AM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> Hi,
>
> On Wed, Apr 22, 2015 at 11:36 PM, Werner Keil <we...@gmail.com>
> wrote:
> >...what was the reason to deviate from
> > Bertrand's suggestion like "w3c-ddr" and use an upper-case "ODDR" folder
> > under /clients?...
>
> I agree that w3c-ddr is more neutral, I have made that change in
> revision 1675548.
>
> -Bertrand
>
Re: [DISCUSS] svn layout
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Apr 22, 2015 at 11:36 PM, Werner Keil <we...@gmail.com> wrote:
>...what was the reason to deviate from
> Bertrand's suggestion like "w3c-ddr" and use an upper-case "ODDR" folder
> under /clients?...
I agree that w3c-ddr is more neutral, I have made that change in
revision 1675548.
-Bertrand
Re: [DISCUSS] svn layout
Posted by Werner Keil <we...@gmail.com>.
That indeed goes along the point of having potentially more than one
Jenkins job.
Since Linux makes a difference, what was the reason to deviate from
Bertrand's suggestion like "w3c-ddr" and use an upper-case "ODDR" folder
under /clients?
I would certainly prefer lower-case folder names.
Btw. though it is just a description, note "Apache DeviceMap Java W3C
Simple API" was wrong, the W3C Simple DDR API is the JAR by W3C, any
DeviceMap or other module can only be a "W3C DDR Simple Implementation".
Every DeviceMap project should stay within the Maven
<groupId>org.apache.devicemap</groupId>
The W3C Bridge so far has
<artifactId>devicemap-client-w3c-simple</artifactId>
The W3C Simple DDR Implementation
<artifactId>devicemap-simpleddr</artifactId>
Not sure, if Bertrand can advice, I'd certainly have to consult the folks
at OpenDDR if the naming (upper- or lower-case aside) suggests you think of
an artifactId that contains "oddr" or "openddr" in it? Just like Java or
others there are brand and project names which were not automatically
donated with the code donation. So just like a project outside
org.apache.devicemap should not be called DeviceMap we should not mix it to
create an org.apache.devicemap.openddr hybrid either without risk of name
violations.
The package of the "Simple DDR" module must remain
"org.apache.devicemap.simpleddr",
for the artifactId as long as no brands are violated before a formal
release that would be flexible.
Thoughs, suggestions?
Aside from that looks good.
Thanks,
Werner
On Wed, Apr 22, 2015 at 11:10 PM, Reza Naghibi <re...@apache.org> wrote:
> Due to the re-org, this job is failing:
>
> https://builds.apache.org/job/devicemap-java6/
>
> FYI, I didnt create this job, so I dont have access to fix the path. The
> owner needs to either fix the path or delete the job.
>
> On Wed, Apr 22, 2015 at 4:10 PM, Reza Naghibi <re...@apache.org> wrote:
>
> > ok, this is done.
> >
> > Here is the new trunk:
> >
> > https://svn.apache.org/viewvc/devicemap/trunk/
> >
> > I made a backup of the old trunk here:
> >
> > https://svn.apache.org/viewvc/devicemap/ODDR/
> >
> > On Wed, Apr 22, 2015 at 1:39 PM, Reza Naghibi <re...@apache.org> wrote:
> >
> >> I freed up some time this afternoon, so I will go ahead and give it a
> go.
> >>
> >> Good point regarding the svn mv, will make sure whatever is done can be
> >> undone to the current state if required.
> >>
> >> On Wed, Apr 22, 2015 at 9:37 AM, Bertrand Delacretaz <
> >> bdelacretaz@apache.org> wrote:
> >>
> >>> On Wed, Apr 22, 2015 at 3:36 PM, Reza Naghibi <re...@apache.org>
> wrote:
> >>> > ...I have no problem doing
> >>> > this, but it would be after the weekend...
> >>>
> >>> Ok so let's see if I find some time before that, otherwise I'll let
> >>> you do it, thanks!
> >>>
> >>> Just make sure to use svn mv to preserve history.
> >>>
> >>> -Bertrand
> >>>
> >>
> >>
> >
>
Re: [DISCUSS] svn layout
Posted by Werner Keil <we...@gmail.com>.
OK, leaving the backup copy in the svn root aside for now.
There are several references for backward-compatibility in data that I
guess we'd keep in 1.0 anyway, e.g. oddrVocabulary.xml, or oddr.properties..
so without calling anything "OpenDDR" the abbreviation just like some
"OMAesque" terms like "open_data" stick, so a folder /clients/oddr seems no
harm.
All lower-case please as you won't find a single project name or (looked
into many) sub-folders that are not all lower-case in Apache repositories.
The few exceptions are standard files like LICENCE, NOTICE or README.
Could someone please rename it, will wait now for the night, but since it's
essentially a module I am considered module owner, I would be happy to
change that myself if nobody else does over night.
Werner
On Wed, Apr 22, 2015 at 11:45 PM, Werner Keil <we...@gmail.com> wrote:
> Or is that the "backup" of the ENTIRE trunk?? The name is confusing.
>
> Werner
>
> On Wed, Apr 22, 2015 at 11:44 PM, Werner Keil <we...@gmail.com>
> wrote:
>
>> You mean /contrib/test-data, or which other copy?
>>
>> After asking everyone (and also checking the codebase of all projects
>> including .NET for traces) I had moved test-data into /contrib some while
>> ago.
>> I'm not aware of another one under /trunk.
>>
>> P.s.: there's a redundant folder /devicemap/ODDR parallel to the likes of
>> /trunk or /branches, can this be removed since the true W3C DDR client is
>> under /clients already?
>>
>>
>>
>> On Wed, Apr 22, 2015 at 11:27 PM, Reza Naghibi <re...@apache.org> wrote:
>>
>>> Also, one more thing. Seems like we had like 6 copies of "test-data"
>>> placed
>>> all over the repo. I pruned it down to a single copy in the ODDR backup
>>> directory. This shaved off about 1GB off of our SVN repo...! Not sure
>>> what
>>> piece of code uses that data, but its probably best to keep this kind of
>>> data to a minimum or to use best practices when storing large amounts of
>>> data in svn.
>>>
>>> On Wed, Apr 22, 2015 at 5:10 PM, Reza Naghibi <re...@apache.org> wrote:
>>>
>>> > Due to the re-org, this job is failing:
>>> >
>>> > https://builds.apache.org/job/devicemap-java6/
>>> >
>>> > FYI, I didnt create this job, so I dont have access to fix the path.
>>> The
>>> > owner needs to either fix the path or delete the job.
>>> >
>>> > On Wed, Apr 22, 2015 at 4:10 PM, Reza Naghibi <re...@apache.org>
>>> wrote:
>>> >
>>> >> ok, this is done.
>>> >>
>>> >> Here is the new trunk:
>>> >>
>>> >> https://svn.apache.org/viewvc/devicemap/trunk/
>>> >>
>>> >> I made a backup of the old trunk here:
>>> >>
>>> >> https://svn.apache.org/viewvc/devicemap/ODDR/
>>> >>
>>> >> On Wed, Apr 22, 2015 at 1:39 PM, Reza Naghibi <re...@apache.org>
>>> wrote:
>>> >>
>>> >>> I freed up some time this afternoon, so I will go ahead and give it
>>> a go.
>>> >>>
>>> >>> Good point regarding the svn mv, will make sure whatever is done can
>>> be
>>> >>> undone to the current state if required.
>>> >>>
>>> >>> On Wed, Apr 22, 2015 at 9:37 AM, Bertrand Delacretaz <
>>> >>> bdelacretaz@apache.org> wrote:
>>> >>>
>>> >>>> On Wed, Apr 22, 2015 at 3:36 PM, Reza Naghibi <re...@apache.org>
>>> wrote:
>>> >>>> > ...I have no problem doing
>>> >>>> > this, but it would be after the weekend...
>>> >>>>
>>> >>>> Ok so let's see if I find some time before that, otherwise I'll let
>>> >>>> you do it, thanks!
>>> >>>>
>>> >>>> Just make sure to use svn mv to preserve history.
>>> >>>>
>>> >>>> -Bertrand
>>> >>>>
>>> >>>
>>> >>>
>>> >>
>>> >
>>>
>>
>>
>
Re: [DISCUSS] svn layout
Posted by Werner Keil <we...@gmail.com>.
Or is that the "backup" of the ENTIRE trunk?? The name is confusing.
Werner
On Wed, Apr 22, 2015 at 11:44 PM, Werner Keil <we...@gmail.com> wrote:
> You mean /contrib/test-data, or which other copy?
>
> After asking everyone (and also checking the codebase of all projects
> including .NET for traces) I had moved test-data into /contrib some while
> ago.
> I'm not aware of another one under /trunk.
>
> P.s.: there's a redundant folder /devicemap/ODDR parallel to the likes of
> /trunk or /branches, can this be removed since the true W3C DDR client is
> under /clients already?
>
>
>
> On Wed, Apr 22, 2015 at 11:27 PM, Reza Naghibi <re...@apache.org> wrote:
>
>> Also, one more thing. Seems like we had like 6 copies of "test-data"
>> placed
>> all over the repo. I pruned it down to a single copy in the ODDR backup
>> directory. This shaved off about 1GB off of our SVN repo...! Not sure what
>> piece of code uses that data, but its probably best to keep this kind of
>> data to a minimum or to use best practices when storing large amounts of
>> data in svn.
>>
>> On Wed, Apr 22, 2015 at 5:10 PM, Reza Naghibi <re...@apache.org> wrote:
>>
>> > Due to the re-org, this job is failing:
>> >
>> > https://builds.apache.org/job/devicemap-java6/
>> >
>> > FYI, I didnt create this job, so I dont have access to fix the path. The
>> > owner needs to either fix the path or delete the job.
>> >
>> > On Wed, Apr 22, 2015 at 4:10 PM, Reza Naghibi <re...@apache.org> wrote:
>> >
>> >> ok, this is done.
>> >>
>> >> Here is the new trunk:
>> >>
>> >> https://svn.apache.org/viewvc/devicemap/trunk/
>> >>
>> >> I made a backup of the old trunk here:
>> >>
>> >> https://svn.apache.org/viewvc/devicemap/ODDR/
>> >>
>> >> On Wed, Apr 22, 2015 at 1:39 PM, Reza Naghibi <re...@apache.org>
>> wrote:
>> >>
>> >>> I freed up some time this afternoon, so I will go ahead and give it a
>> go.
>> >>>
>> >>> Good point regarding the svn mv, will make sure whatever is done can
>> be
>> >>> undone to the current state if required.
>> >>>
>> >>> On Wed, Apr 22, 2015 at 9:37 AM, Bertrand Delacretaz <
>> >>> bdelacretaz@apache.org> wrote:
>> >>>
>> >>>> On Wed, Apr 22, 2015 at 3:36 PM, Reza Naghibi <re...@apache.org>
>> wrote:
>> >>>> > ...I have no problem doing
>> >>>> > this, but it would be after the weekend...
>> >>>>
>> >>>> Ok so let's see if I find some time before that, otherwise I'll let
>> >>>> you do it, thanks!
>> >>>>
>> >>>> Just make sure to use svn mv to preserve history.
>> >>>>
>> >>>> -Bertrand
>> >>>>
>> >>>
>> >>>
>> >>
>> >
>>
>
>
Re: [DISCUSS] svn layout
Posted by Werner Keil <we...@gmail.com>.
You mean /contrib/test-data, or which other copy?
After asking everyone (and also checking the codebase of all projects
including .NET for traces) I had moved test-data into /contrib some while
ago.
I'm not aware of another one under /trunk.
P.s.: there's a redundant folder /devicemap/ODDR parallel to the likes of
/trunk or /branches, can this be removed since the true W3C DDR client is
under /clients already?
On Wed, Apr 22, 2015 at 11:27 PM, Reza Naghibi <re...@apache.org> wrote:
> Also, one more thing. Seems like we had like 6 copies of "test-data" placed
> all over the repo. I pruned it down to a single copy in the ODDR backup
> directory. This shaved off about 1GB off of our SVN repo...! Not sure what
> piece of code uses that data, but its probably best to keep this kind of
> data to a minimum or to use best practices when storing large amounts of
> data in svn.
>
> On Wed, Apr 22, 2015 at 5:10 PM, Reza Naghibi <re...@apache.org> wrote:
>
> > Due to the re-org, this job is failing:
> >
> > https://builds.apache.org/job/devicemap-java6/
> >
> > FYI, I didnt create this job, so I dont have access to fix the path. The
> > owner needs to either fix the path or delete the job.
> >
> > On Wed, Apr 22, 2015 at 4:10 PM, Reza Naghibi <re...@apache.org> wrote:
> >
> >> ok, this is done.
> >>
> >> Here is the new trunk:
> >>
> >> https://svn.apache.org/viewvc/devicemap/trunk/
> >>
> >> I made a backup of the old trunk here:
> >>
> >> https://svn.apache.org/viewvc/devicemap/ODDR/
> >>
> >> On Wed, Apr 22, 2015 at 1:39 PM, Reza Naghibi <re...@apache.org> wrote:
> >>
> >>> I freed up some time this afternoon, so I will go ahead and give it a
> go.
> >>>
> >>> Good point regarding the svn mv, will make sure whatever is done can be
> >>> undone to the current state if required.
> >>>
> >>> On Wed, Apr 22, 2015 at 9:37 AM, Bertrand Delacretaz <
> >>> bdelacretaz@apache.org> wrote:
> >>>
> >>>> On Wed, Apr 22, 2015 at 3:36 PM, Reza Naghibi <re...@apache.org>
> wrote:
> >>>> > ...I have no problem doing
> >>>> > this, but it would be after the weekend...
> >>>>
> >>>> Ok so let's see if I find some time before that, otherwise I'll let
> >>>> you do it, thanks!
> >>>>
> >>>> Just make sure to use svn mv to preserve history.
> >>>>
> >>>> -Bertrand
> >>>>
> >>>
> >>>
> >>
> >
>
Re: [DISCUSS] svn layout
Posted by Reza Naghibi <re...@apache.org>.
Also, one more thing. Seems like we had like 6 copies of "test-data" placed
all over the repo. I pruned it down to a single copy in the ODDR backup
directory. This shaved off about 1GB off of our SVN repo...! Not sure what
piece of code uses that data, but its probably best to keep this kind of
data to a minimum or to use best practices when storing large amounts of
data in svn.
On Wed, Apr 22, 2015 at 5:10 PM, Reza Naghibi <re...@apache.org> wrote:
> Due to the re-org, this job is failing:
>
> https://builds.apache.org/job/devicemap-java6/
>
> FYI, I didnt create this job, so I dont have access to fix the path. The
> owner needs to either fix the path or delete the job.
>
> On Wed, Apr 22, 2015 at 4:10 PM, Reza Naghibi <re...@apache.org> wrote:
>
>> ok, this is done.
>>
>> Here is the new trunk:
>>
>> https://svn.apache.org/viewvc/devicemap/trunk/
>>
>> I made a backup of the old trunk here:
>>
>> https://svn.apache.org/viewvc/devicemap/ODDR/
>>
>> On Wed, Apr 22, 2015 at 1:39 PM, Reza Naghibi <re...@apache.org> wrote:
>>
>>> I freed up some time this afternoon, so I will go ahead and give it a go.
>>>
>>> Good point regarding the svn mv, will make sure whatever is done can be
>>> undone to the current state if required.
>>>
>>> On Wed, Apr 22, 2015 at 9:37 AM, Bertrand Delacretaz <
>>> bdelacretaz@apache.org> wrote:
>>>
>>>> On Wed, Apr 22, 2015 at 3:36 PM, Reza Naghibi <re...@apache.org> wrote:
>>>> > ...I have no problem doing
>>>> > this, but it would be after the weekend...
>>>>
>>>> Ok so let's see if I find some time before that, otherwise I'll let
>>>> you do it, thanks!
>>>>
>>>> Just make sure to use svn mv to preserve history.
>>>>
>>>> -Bertrand
>>>>
>>>
>>>
>>
>
Re: [DISCUSS] svn layout
Posted by Reza Naghibi <re...@apache.org>.
Due to the re-org, this job is failing:
https://builds.apache.org/job/devicemap-java6/
FYI, I didnt create this job, so I dont have access to fix the path. The
owner needs to either fix the path or delete the job.
On Wed, Apr 22, 2015 at 4:10 PM, Reza Naghibi <re...@apache.org> wrote:
> ok, this is done.
>
> Here is the new trunk:
>
> https://svn.apache.org/viewvc/devicemap/trunk/
>
> I made a backup of the old trunk here:
>
> https://svn.apache.org/viewvc/devicemap/ODDR/
>
> On Wed, Apr 22, 2015 at 1:39 PM, Reza Naghibi <re...@apache.org> wrote:
>
>> I freed up some time this afternoon, so I will go ahead and give it a go.
>>
>> Good point regarding the svn mv, will make sure whatever is done can be
>> undone to the current state if required.
>>
>> On Wed, Apr 22, 2015 at 9:37 AM, Bertrand Delacretaz <
>> bdelacretaz@apache.org> wrote:
>>
>>> On Wed, Apr 22, 2015 at 3:36 PM, Reza Naghibi <re...@apache.org> wrote:
>>> > ...I have no problem doing
>>> > this, but it would be after the weekend...
>>>
>>> Ok so let's see if I find some time before that, otherwise I'll let
>>> you do it, thanks!
>>>
>>> Just make sure to use svn mv to preserve history.
>>>
>>> -Bertrand
>>>
>>
>>
>
Re: [DISCUSS] svn layout
Posted by Reza Naghibi <re...@apache.org>.
ok, this is done.
Here is the new trunk:
https://svn.apache.org/viewvc/devicemap/trunk/
I made a backup of the old trunk here:
https://svn.apache.org/viewvc/devicemap/ODDR/
On Wed, Apr 22, 2015 at 1:39 PM, Reza Naghibi <re...@apache.org> wrote:
> I freed up some time this afternoon, so I will go ahead and give it a go.
>
> Good point regarding the svn mv, will make sure whatever is done can be
> undone to the current state if required.
>
> On Wed, Apr 22, 2015 at 9:37 AM, Bertrand Delacretaz <
> bdelacretaz@apache.org> wrote:
>
>> On Wed, Apr 22, 2015 at 3:36 PM, Reza Naghibi <re...@apache.org> wrote:
>> > ...I have no problem doing
>> > this, but it would be after the weekend...
>>
>> Ok so let's see if I find some time before that, otherwise I'll let
>> you do it, thanks!
>>
>> Just make sure to use svn mv to preserve history.
>>
>> -Bertrand
>>
>
>
Re: [DISCUSS] svn layout
Posted by Reza Naghibi <re...@apache.org>.
I freed up some time this afternoon, so I will go ahead and give it a go.
Good point regarding the svn mv, will make sure whatever is done can be
undone to the current state if required.
On Wed, Apr 22, 2015 at 9:37 AM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> On Wed, Apr 22, 2015 at 3:36 PM, Reza Naghibi <re...@apache.org> wrote:
> > ...I have no problem doing
> > this, but it would be after the weekend...
>
> Ok so let's see if I find some time before that, otherwise I'll let
> you do it, thanks!
>
> Just make sure to use svn mv to preserve history.
>
> -Bertrand
>
Re: [DISCUSS] svn layout
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Apr 22, 2015 at 3:36 PM, Reza Naghibi <re...@apache.org> wrote:
> ...I have no problem doing
> this, but it would be after the weekend...
Ok so let's see if I find some time before that, otherwise I'll let
you do it, thanks!
Just make sure to use svn mv to preserve history.
-Bertrand
Re: [DISCUSS] svn layout
Posted by Reza Naghibi <re...@apache.org>.
My schedule is kind of busy and I have some guests arriving, so I wont be
free to work on anything until after the weekend. I have no problem doing
this, but it would be after the weekend.
On Wed, Apr 22, 2015 at 9:26 AM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> Hi,
>
> On Wed, Apr 22, 2015 at 3:09 PM, Werner Keil <we...@gmail.com>
> wrote:
> > ...I suppose
> > this being a change to the codebase, a formal vote on the private list
> > should take place for it...
>
> No, we usually vote on the private list only for issues related to
> people, like elections.
>
> In this case, as we seem to have consensus here I don't see a need for a
> vote.
>
> Reza, would you have time to do the svn changes? Otherwise I might be
> able to do that at the end of this week.
>
> -Bertrand
>
Re: [DISCUSS] svn layout
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Apr 22, 2015 at 3:09 PM, Werner Keil <we...@gmail.com> wrote:
> ...I suppose
> this being a change to the codebase, a formal vote on the private list
> should take place for it...
No, we usually vote on the private list only for issues related to
people, like elections.
In this case, as we seem to have consensus here I don't see a need for a vote.
Reza, would you have time to do the svn changes? Otherwise I might be
able to do that at the end of this week.
-Bertrand
Re: [DISCUSS] svn layout
Posted by Werner Keil <we...@gmail.com>.
Though we haven't heard on these 2 detail questions yet, nobody in the
thread had a principal problem with Bertrand's suggestion, so I suppose
this being a change to the codebase, a formal vote on the private list
should take place for it.
The "classifier_w3c_simple" prototype is not built as of now, so regardless
where it ends up, it would not break the build and can be treated later.
So would Bertrand who suggested it run a vote here, please?
Thanks,
Werner
On Tue, Apr 21, 2015 at 3:16 PM, Werner Keil <we...@gmail.com> wrote:
> any thought on
> a) "clients/java" vs. "clients/devicemap"
> b) in what form a W3C "wrapper" (the module currently under
> /devicemap/java/classifier_w3c_simple/ ) could best be handled?
>
> Duplicating e.g. the "lib" folder and all test to verify compliance is not
> really an issue. The question is, whether you see the wrapper and TCK to
> verify it a priority or not?
> Nearly all tests for "native W3C DDR" should be reusable, but if the
> modules are maintained separately they at least have to be copied to
> another place. Unless the "wrapper" would reside under the
> "clients/w3c-simple" folder. With dependencies, but e.g. every client
> depends on a particular version of "data".
>
>
>
> On Tue, Apr 21, 2015 at 1:01 PM, Reza Naghibi <re...@naghibi.com> wrote:
>
>> Im open to trying this.
>>
>> On Tue, Apr 21, 2015 at 6:41 AM, Bertrand Delacretaz <
>> bdelacretaz@apache.org
>> > wrote:
>>
>> > Hi,
>> >
>> > On Tue, Apr 21, 2015 at 10:30 AM, Werner Keil <we...@gmail.com>
>> > wrote:
>> > >
>> > > ...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....
>> >
>> > Agreed, but each Java module can then decide to do that or not.
>> >
>> > >... The only question is, does the clients/devicemap aim to have W3C
>> > compliant
>> > > modules or extensions...
>> >
>> > That's a question for later IMO.
>> >
>> > > ...Thinking beyond other languages, could we call the
>> clients/devicemap
>> > > clients/java, too?...
>> >
>> > Maybe...I suggest letting Reza decide this as he did the bulk of the
>> > work on that module.
>> >
>> > -Bertrand
>> >
>>
>
>
Re: [DISCUSS] svn layout
Posted by Werner Keil <we...@gmail.com>.
any thought on
a) "clients/java" vs. "clients/devicemap"
b) in what form a W3C "wrapper" (the module currently under
/devicemap/java/classifier_w3c_simple/
) could best be handled?
Duplicating e.g. the "lib" folder and all test to verify compliance is not
really an issue. The question is, whether you see the wrapper and TCK to
verify it a priority or not?
Nearly all tests for "native W3C DDR" should be reusable, but if the
modules are maintained separately they at least have to be copied to
another place. Unless the "wrapper" would reside under the
"clients/w3c-simple" folder. With dependencies, but e.g. every client
depends on a particular version of "data".
On Tue, Apr 21, 2015 at 1:01 PM, Reza Naghibi <re...@naghibi.com> wrote:
> Im open to trying this.
>
> On Tue, Apr 21, 2015 at 6:41 AM, Bertrand Delacretaz <
> bdelacretaz@apache.org
> > wrote:
>
> > Hi,
> >
> > On Tue, Apr 21, 2015 at 10:30 AM, Werner Keil <we...@gmail.com>
> > wrote:
> > >
> > > ...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....
> >
> > Agreed, but each Java module can then decide to do that or not.
> >
> > >... The only question is, does the clients/devicemap aim to have W3C
> > compliant
> > > modules or extensions...
> >
> > That's a question for later IMO.
> >
> > > ...Thinking beyond other languages, could we call the clients/devicemap
> > > clients/java, too?...
> >
> > Maybe...I suggest letting Reza decide this as he did the bulk of the
> > work on that module.
> >
> > -Bertrand
> >
>
Re: [DISCUSS] svn layout
Posted by Reza Naghibi <re...@naghibi.com>.
Im open to trying this.
On Tue, Apr 21, 2015 at 6:41 AM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> Hi,
>
> On Tue, Apr 21, 2015 at 10:30 AM, Werner Keil <we...@gmail.com>
> wrote:
> >
> > ...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....
>
> Agreed, but each Java module can then decide to do that or not.
>
> >... The only question is, does the clients/devicemap aim to have W3C
> compliant
> > modules or extensions...
>
> That's a question for later IMO.
>
> > ...Thinking beyond other languages, could we call the clients/devicemap
> > clients/java, too?...
>
> Maybe...I suggest letting Reza decide this as he did the bulk of the
> work on that module.
>
> -Bertrand
>
Re: [DISCUSS] svn layout
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Tue, Apr 21, 2015 at 10:30 AM, Werner Keil <we...@gmail.com> wrote:
>
> ...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....
Agreed, but each Java module can then decide to do that or not.
>... The only question is, does the clients/devicemap aim to have W3C compliant
> modules or extensions...
That's a question for later IMO.
> ...Thinking beyond other languages, could we call the clients/devicemap
> clients/java, too?...
Maybe...I suggest letting Reza decide this as he did the bulk of the
work on that module.
-Bertrand
Re: [DISCUSS] svn layout
Posted by Werner Keil <we...@gmail.com>.
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"
>