You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@devicemap.apache.org by Reza <re...@yahoo.com.INVALID> on 2014/07/08 21:03:10 UTC
DeviceMap data and java client 1.0.0 release review ready
I have updated the devicemap data and java client release:
http://www.rezsoft.org/devicemap/
Changes:
-fixed the LICENSE, NOTICE, DISCLAIMER. I also added these to individual projects to simplify releasing.
-added a README
-removed all the @author comments
-changed version from 1.0 to 1.0.0
-I changed the java client artifact id from devicemap-java to devicemap-client
-I moved some classes around in the loader package so they are better organized
If all looks good, I will create the tag for this release.
Re: DeviceMap data and java client 1.0.0 release review ready
Posted by Reza <re...@yahoo.com.INVALID>.
So I went back and matched the tags to the release.
java client: http://svn.apache.org/viewvc/incubator/devicemap/tags/devicemap/java/1.0.0/classifier/
data: http://svn.apache.org/viewvc/incubator/devicemap/tags/data/1.0.0/device-data/
So trunk is a few commits ahead now, so those changes will be picked up in the next release... obviously :)
Already got some new device data and java client enhancements ready, so the next release is on the horizon. I will make jira tickets to track the additions and enhancements in the coming days.
________________________________
From: Reza <re...@yahoo.com>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>
Sent: Tuesday, July 15, 2014 10:56 AM
Subject: Re: DeviceMap data and java client 1.0.0 release review ready
I have moved the java and data release preview here:
http://devicemap-vm.apache.org/releases/1.0.0/
I am working thru the svn changes since the release. I should have everything sorted out by tonite. I will likely have to revert some changes to the svn trunk since they are not reflected in this initial release and they will cause a branch.
I added my key to my profile, so it should show up in the project keys shortly.
Also, I was on vacation this weekend and used it as a good opportunity to let things "settle down" since some of our discussions from last week were not very productive. While I feel things have settled down, some of the discussions are still not positive towards myself or towards the device map project. I think its really important that we all have positive contributions to this project. That does not mean we have to agree on everything, but it means that we have to communicate and interact in a positive fashion.
I really dont want to rehash why the java client was rewritten or when w3c support will be re-integrated. Those matters have already been discussed ad nauseam and if there is a need to discuss them more, lets do so in a civil and positive light.
________________________________
From: Bertrand Delacretaz <bd...@apache.org>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>
Sent: Wednesday, July 9, 2014 5:25 PM
Subject: Re: DeviceMap data and java client 1.0.0 release review ready
On Wed, Jul 9, 2014 at 4:16 PM, Reza <re...@yahoo.com.invalid> wrote:
> FYI, incase this got lost in all
the discussions, this release is (still) ready...
Thanks, I have reviewed the below archives and they look good to me:
MD5 (devicemap-client-java-1.0.0.tar.gz) = d63a03e553ea1ef72612dc4fa697e5ba
MD5 (devicemap-data-1.0.0.tar.gz) = 243628c8ff31ff7d9ee76624da8c11ad
I'm just missing svn tags that point to the exact same code, under
http://svn.apache.org/repos/asf/incubator/devicemap/tags/ - I suggest
giving them the same names than the release archives, so creating
devicemap-client-java-1.0.0 and
devicemap-data-1.0.0 folders there
that point to the appropriate svn revisions. Reza, I'm not sure what
those revisions are, could you create those tags? Or let me know the
revision numbers and I'll create them.
Once that's done you can IMO create a [VOTE] thread to approve those
releases, there's an example of that at http://s.apache.org/lk2
-Bertrand
Re: release script
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Jul 16, 2014 at 4:25 AM, Reza <re...@yahoo.com.invalid> wrote:
> ...Regarding the md5 and sha1 filenames, so my release script is using
> plain md5sum and sha1sum which includes the filename...
IMO it would be better to use the Maven release plugins going forward,
at least for the java stuff.
That's what we do in Sling (which does very frequent releases of many
modules) and combined with the staging features of
repository.apache.org that's really useful.
http://sling.apache.org/documentation/development/release-management.html
has more info and the Sling parent pom is at
http://svn.apache.org/repos/asf/sling/trunk/parent/pom.xml
I wasn't much involved in setting that up but IIRC the key is using
the org.apache:apache:14 pom as the parent of the parent pom to enable
the repository.apache.org staging.
-Bertrand
Re: release script
Posted by Reza <re...@yahoo.com.INVALID>.
Nice, just ran the script, everything checked out (minus the filenames in the checksums).
Regarding the md5 and sha1 filenames, so my release script is using plain md5sum and sha1sum which includes the filename. How are you generating the release? Can you check that script in too? This way we can standardize.
Projects seem to vary in the md5 used:
https://www.apache.org/dist/tomcat/tomcat-7/v7.0.54/bin/apache-tomcat-7.0.54.tar.gz.md5
http://www.apache.org/dist/ant/binaries/apache-ant-1.9.4-bin.zip.md5
________________________________
From: Radu Cotescu <ra...@apache.org>
To: Reza <re...@yahoo.com>
Cc: devicemap-dev <de...@incubator.apache.org>
Sent: Tuesday, July 15, 2014 5:32 PM
Subject: Re: DeviceMap data and java client 1.0.0 release review ready
Hi Reza,
I've committed a UNIX script that can be used to easily check the integrity
of a staged release at [0].
Since sha1sum and md5sum are not available on Mac OS X I'd advise on just
outputting the checksums in the *.md5 / *.sha1 files. The script uses
openssl for calculating the artifacts' checksums and compares them to the
value from the artifacts' corresponding checksum files.
Cheers,
Radu
[0] -
http://svn.apache.org/repos/asf/incubator/devicemap/trunk/check_staged_release.sh
On Tue, Jul 15, 2014 at 5:56 PM, Reza <re...@yahoo.com.invalid>
wrote:
> I have moved the java and data release preview here:
>
> http://devicemap-vm.apache.org/releases/1.0.0/
>
Re: DeviceMap data and java client 1.0.0 release review ready
Posted by Radu Cotescu <ra...@apache.org>.
Hi Reza,
I've committed a UNIX script that can be used to easily check the integrity
of a staged release at [0].
Since sha1sum and md5sum are not available on Mac OS X I'd advise on just
outputting the checksums in the *.md5 / *.sha1 files. The script uses
openssl for calculating the artifacts' checksums and compares them to the
value from the artifacts' corresponding checksum files.
Cheers,
Radu
[0] -
http://svn.apache.org/repos/asf/incubator/devicemap/trunk/check_staged_release.sh
On Tue, Jul 15, 2014 at 5:56 PM, Reza <re...@yahoo.com.invalid>
wrote:
> I have moved the java and data release preview here:
>
> http://devicemap-vm.apache.org/releases/1.0.0/
>
Re: DeviceMap data and java client 1.0.0 release review ready
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi Reza,
On Tue, Jul 15, 2014 at 4:56 PM, Reza <re...@yahoo.com.invalid> wrote:
> I have moved the java and data release preview here:
> http://devicemap-vm.apache.org/releases/1.0.0/
Thanks! I have checked the release according to
http://incubator.apache.org/guides/releasemanagement.html#check-list
and except for a minor file naming issue I think it's ready for a
[VOTE] here.
I checked the following archives:
SHA1(devicemap-client-java-1.0.0.tar.gz)=
47d1b3a0fa6120510c0f56160b363261a9ace888
SHA1(devicemap-data-1.0.0.tar.gz)= f646e5d919a97864ea16af26a72fc62608110a15
Signatures and digests match, PGP key is available at
https://people.apache.org/keys/group/devicemap.asc
The archive contents match the following svn tags:
http://svn.apache.org/repos/asf/incubator/devicemap/tags/devicemap/java/1.0.0/classifier/
http://svn.apache.org/repos/asf/incubator/devicemap/tags/data/1.0.0/device-data/
The build with "mvn clean install" works, building the device-data
module first as mentioned in the devicemap-client-java instructions.
DISCLAIMER, NOTICE and LICENCE look good to me.
All source files have the ASF license headers.
There's just one issue that I forgot to check earlier, the archive
files should include "-incubating" in their name. So once renamed I
would vote +1 on releasing those two archives, and they look good for
passing the Incubator PMC vote that's also required for incubating
projects.
So as far as I'm concerned you can proceed to the [VOTE], and once
that passes proceed to the Incubator PMC vote. The docs about this at
[1] are a bit complicated, basically once our own vote passes you need
to subscribe to general@incubator.apache.org and start a [VOTE] thread
there referencing our own vote thread, [2] is a good example of that
(and BTW http://s.apache.org/ is useful to shorten URLs here).
-Bertrand
[1] http://incubator.apache.org/guides/releasemanagement.html#best-practice-incubator-release-vote
[2] http://markmail.org/thread/5kakbbbjy36lidhk
Re: DeviceMap data and java client 1.0.0 release review ready
Posted by Werner Keil <we...@gmail.com>.
Reza/all,
Thanks, making it available on the Apache Server is a Good step.
I recently tagged test-data with 1.0.0, too. Would it be possible to create
an archive? It's mainly a convenience for apps using both, otherwise they
need to maintain two versions and as some build issues showed, it can be
tricky to maintain them
If there's a Problem including test-data, I'd remove the Tag. I trust, the
archives are signed as Bertrand suggested, and it Matches a tag in SVN. As
long as there's no "bridge" to W3C implementations, let's offer the Simple
DDR in parallel as Bertrand also suggested. If they can be merged in a
future release function-wise, there's always a chance to "freeze" the W3C
part. In fact while W3C doesn't provide much New to this Spec it may not
get many Upgrades here, but graduating to 1.0.0 seems essential to
acceptance by the Community.
I can prepare files for this artifact once I'm back from the conference.
Cheers,
Werner
Am 15.07.2014 16:57 schrieb "Reza" <re...@yahoo.com.invalid>:
> I have moved the java and data release preview here:
>
> http://devicemap-vm.apache.org/releases/1.0.0/
>
>
> I am working thru the svn changes since the release. I should have
> everything sorted out by tonite. I will likely have to revert some changes
> to the svn trunk since they are not reflected in this initial release and
> they will cause a branch.
>
> I added my key to my profile, so it should show up in the project keys
> shortly.
>
> Also, I was on vacation this weekend and used it as a good opportunity to
> let things "settle down" since some of our discussions from last week were
> not very productive. While I feel things have settled down, some of the
> discussions are still not positive towards myself or towards the device map
> project. I think its really important that we all have positive
> contributions to this project. That does not mean we have to agree on
> everything, but it means that we have to communicate and interact in a
> positive fashion.
>
> I really dont want to rehash why the java client was rewritten or when w3c
> support will be re-integrated. Those matters have already been discussed ad
> nauseam and if there is a need to discuss them more, lets do so in a civil
> and positive light.
>
>
> ________________________________
> From: Bertrand Delacretaz <bd...@apache.org>
> To: "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>
> Sent: Wednesday, July 9, 2014 5:25 PM
> Subject: Re: DeviceMap data and java client 1.0.0 release review ready
>
>
> On Wed, Jul 9, 2014 at 4:16 PM, Reza <re...@yahoo.com.invalid>
> wrote:
>
> > FYI, incase this got lost in all the discussions, this release is
> (still) ready...
>
> Thanks, I have reviewed the below archives and they look good to me:
>
> MD5 (devicemap-client-java-1.0.0.tar.gz) = d63a03e553ea1ef72612dc4fa697e5ba
> MD5 (devicemap-data-1.0.0.tar.gz) = 243628c8ff31ff7d9ee76624da8c11ad
>
> I'm just missing svn tags that point to the exact same code, under
> http://svn.apache.org/repos/asf/incubator/devicemap/tags/ - I suggest
> giving them the same names than the release archives, so creating
> devicemap-client-java-1.0.0 and devicemap-data-1.0.0 folders there
> that point to the appropriate svn revisions. Reza, I'm not sure what
> those revisions are, could you create those tags? Or let me know the
> revision numbers and I'll create them.
>
> Once that's done you can IMO create a [VOTE] thread to approve those
> releases, there's an example of that at http://s.apache.org/lk2
>
> -Bertrand
Re: DeviceMap data and java client 1.0.0 release review ready
Posted by Reza <re...@yahoo.com.INVALID>.
I have moved the java and data release preview here:
http://devicemap-vm.apache.org/releases/1.0.0/
I am working thru the svn changes since the release. I should have everything sorted out by tonite. I will likely have to revert some changes to the svn trunk since they are not reflected in this initial release and they will cause a branch.
I added my key to my profile, so it should show up in the project keys shortly.
Also, I was on vacation this weekend and used it as a good opportunity to let things "settle down" since some of our discussions from last week were not very productive. While I feel things have settled down, some of the discussions are still not positive towards myself or towards the device map project. I think its really important that we all have positive contributions to this project. That does not mean we have to agree on everything, but it means that we have to communicate and interact in a positive fashion.
I really dont want to rehash why the java client was rewritten or when w3c support will be re-integrated. Those matters have already been discussed ad nauseam and if there is a need to discuss them more, lets do so in a civil and positive light.
________________________________
From: Bertrand Delacretaz <bd...@apache.org>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>
Sent: Wednesday, July 9, 2014 5:25 PM
Subject: Re: DeviceMap data and java client 1.0.0 release review ready
On Wed, Jul 9, 2014 at 4:16 PM, Reza <re...@yahoo.com.invalid> wrote:
> FYI, incase this got lost in all the discussions, this release is (still) ready...
Thanks, I have reviewed the below archives and they look good to me:
MD5 (devicemap-client-java-1.0.0.tar.gz) = d63a03e553ea1ef72612dc4fa697e5ba
MD5 (devicemap-data-1.0.0.tar.gz) = 243628c8ff31ff7d9ee76624da8c11ad
I'm just missing svn tags that point to the exact same code, under
http://svn.apache.org/repos/asf/incubator/devicemap/tags/ - I suggest
giving them the same names than the release archives, so creating
devicemap-client-java-1.0.0 and devicemap-data-1.0.0 folders there
that point to the appropriate svn revisions. Reza, I'm not sure what
those revisions are, could you create those tags? Or let me know the
revision numbers and I'll create them.
Once that's done you can IMO create a [VOTE] thread to approve those
releases, there's an example of that at http://s.apache.org/lk2
-Bertrand
Re: DeviceMap data and java client 1.0.0 release review ready
Posted by Reza <re...@yahoo.com.INVALID>.
Sounds good. I will track down the svn commit # tomorrow and make the tag.
thanks!
________________________________
From: Bertrand Delacretaz <bd...@apache.org>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>
Sent: Wednesday, July 9, 2014 5:25 PM
Subject: Re: DeviceMap data and java client 1.0.0 release review ready
On Wed, Jul 9, 2014 at 4:16 PM, Reza <re...@yahoo.com.invalid> wrote:
> FYI, incase this got lost in all the discussions, this release is (still) ready...
Thanks, I have reviewed the below archives and they look good to me:
MD5 (devicemap-client-java-1.0.0.tar.gz) = d63a03e553ea1ef72612dc4fa697e5ba
MD5 (devicemap-data-1.0.0.tar.gz) = 243628c8ff31ff7d9ee76624da8c11ad
I'm just missing svn tags that point to the exact same code, under
http://svn.apache.org/repos/asf/incubator/devicemap/tags/ - I suggest
giving them the same names than the release archives, so creating
devicemap-client-java-1.0.0 and devicemap-data-1.0.0 folders there
that point to the appropriate svn revisions. Reza, I'm not sure what
those revisions are, could you create those tags? Or let me know the
revision numbers and I'll create them.
Once that's done you can IMO create a [VOTE] thread to approve those
releases, there's an example of that at http://s.apache.org/lk2
-Bertrand
Re: DeviceMap data and java client 1.0.0 release review ready
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Jul 9, 2014 at 4:16 PM, Reza <re...@yahoo.com.invalid> wrote:
> FYI, incase this got lost in all the discussions, this release is (still) ready...
Thanks, I have reviewed the below archives and they look good to me:
MD5 (devicemap-client-java-1.0.0.tar.gz) = d63a03e553ea1ef72612dc4fa697e5ba
MD5 (devicemap-data-1.0.0.tar.gz) = 243628c8ff31ff7d9ee76624da8c11ad
I'm just missing svn tags that point to the exact same code, under
http://svn.apache.org/repos/asf/incubator/devicemap/tags/ - I suggest
giving them the same names than the release archives, so creating
devicemap-client-java-1.0.0 and devicemap-data-1.0.0 folders there
that point to the appropriate svn revisions. Reza, I'm not sure what
those revisions are, could you create those tags? Or let me know the
revision numbers and I'll create them.
Once that's done you can IMO create a [VOTE] thread to approve those
releases, there's an example of that at http://s.apache.org/lk2
-Bertrand
Re: Legacy ODDR java client and w3c jar in our repo
Posted by Werner Keil <we...@gmail.com>.
You forget, that every single "Data" contribution (and until someone
provides a proper Web service or process to do it here, it will remain the
ONLY contribution[?]) comes from OpenDDR with my initial contribution. The
"alternate" client uses this file, otherwise it would have no data
whatsoever, so I guess that explains what I and OpenDDR provided here.
Without data the best API is worth crap[?]
Unlike the "new client" the OpenDDR based filter also works out of the box
from here:
http://svn.apache.org/viewvc/incubator/devicemap/trunk/contrib/web/webfilter/
Towards a 1.0.0 release the web servlets, JSP, Spring or whatever you chose
for a demo application should match the API and work out of the box, at
least based on som manual steps.
The only example you provided for the 1.0.0 client is on "rezasoft", which
is not a proper SVN repo of Apache AFAIK, so could you please migrate that
to the "example" root under the trunk or another appropriate place?
Except for the prior place (you'll notice, the last improvements happened 2
weeks ago, not 2 years, and the "contrib" sources always worked since the
initial contribution[?]) they were always 1.0 ready and still are. So the
"new client" is an alternate way to access the resources OpenDDR donated,
but it's not W3C compliant.
If Eberhard's .NET client is, then the biggest distraction for people is
that they neither have a working example web application to test this
(having some tomcat on apache.org is nice, but the real value is to use it
in THEIR site[?]) nor a consistent API compared to the .NET platform.
Werner
On Wed, Jul 9, 2014 at 5:26 PM, Reza <re...@yahoo.com.invalid> wrote:
> You did not answer #2 or #3.
>
> So is this project the best place to support the legacy oddr java client?
> Would it not be better for you to support the ODDR effort back at the oddr
> github page: https://github.com/OpenDDRdotORG/OpenDDR-Java.
>
> Its been inactive for 2 years. So as to why you are now pushing oddr front
> and center of the DeviceMap project is puzzling... Why are you not focusing
> on our 1.0.0 release and the DeviceMap project?
>
> Why are you on this project...? What value are you adding here? This is a
> huge distraction. You are constantly breaking the java client codebase
> which is another big waste of my time. I just dont see the value of any of
> this.
>
> ------------------------------
> *From:* Werner Keil <we...@gmail.com>
> *To:* "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>; Reza <re...@yahoo.com>
> *Sent:* Wednesday, July 9, 2014 11:11 AM
>
> *Subject:* Re: Legacy ODDR java client and w3c jar in our repo
>
> Equally important is, how the .NET and Java clients are similar or not?
>
> if Eberhard's .NET client supports W3C DDR Specs then the Java API also
> should. And
>
> As for 1) the answer is, I am also currently the only active OpenDDR
> contributor, so what I'm allowed and supposed to do with OpenDDR Data
> (contribute into this project as a contributor to both) I also can and will
> do in case of the Java API.
>
> Werner
>
> On Wed, Jul 9, 2014 at 4:56 PM, Reza <re...@yahoo.com.invalid>
> wrote:
>
> ok, lets try this again, please answer these questions:
>
> 1) Do we plan on supporting the legacy openddr java client? If so, who
> will support it?
>
> 2) Do we plan on re-releasing the legacy openddr java client?
>
> 3) If we support and release the legacy openddr java client (your answer
> to #1 and #2 is yes), what is the transition plan to get these legacy users
> off openddr and onto the devicemap client? Or no plan, we support both
> openddr users and devicemap users?
>
> ------------------------------
> *From:* Werner Keil <we...@gmail.com>
> *To:* "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>; Reza <re...@yahoo.com>
> *Sent:* Wednesday, July 9, 2014 10:45 AM
> *Subject:* Re: Legacy ODDR java client and w3c jar in our repo
>
> As mentioned and discussed with Bertrand in the other thread, myriads of
> Apache projects, see Tomcat, etc. use "lib" folders for dependencies, JSP,
> CSS, etc.
> The W3C license is among the ones supported by ASF, so using the lib in a
> downstream implementation is perfectly fine.
>
> The relation between the "old" and "new" client are a bit like JSP vs.
> JSF. Both are Java EE standards allowing you to accomplish the same thing,
> but believe it or not, the current ThoughtWorks Radar still has JSF on
> "Hold" (explained as "widely adopted but we still feel it's a bit immature"
> )
>
> The same applies to the "new" client I'm afraid, especially with regards
> to W3C compatibility. Many big sites and projects of various sizes use
> OpenDDR now. So unless you offer them a 100% compatible Drop-in-replacement
> in the "new" client, that is not usable to them in existing code without
> rewriting the whole application.
>
> If we want to abandon and ignore these users and leave them with the
> existing OpenDDR project rather than offering a "bridge" (and chance to
> eventually migrate to the new one) that could mean leaving Simple DDR, but
> I don't know if we want to do that.
>
> Bertrand, WDYT?
>
>
>
> On Wed, Jul 9, 2014 at 4:36 PM, Reza <re...@yahoo.com.invalid>
> wrote:
>
> Why is the legacy ODDR java client still in our repo?
>
>
> http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/simpleddr/
>
> Do we plan on supporting it? If so, who will support it? Did I not rewrite
> the client last year because of all of the issues this legacy client has.
>
> Do you (we) plan on re-releasing the legacy ODDR client as well? That
> would mean we now have 2 java clients...
>
> Also, you checked in the w3c jar here:
>
>
> http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/simpleddr/lib/
>
> Once again, what is the point of trying to bring this old client back from
> the dead? I will investigate what is needed to get w3c compatibility into
> the new client. Checking this old client into our repo with the w3c jar is
> likely not needed...
>
> ------------------------------
> *From:* Werner Keil <we...@gmail.com>
> *To:* "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>; Reza <re...@yahoo.com>
> *Sent:* Wednesday, July 9, 2014 10:25 AM
> *Subject:* Re: DeviceMap data and java client 1.0.0 release review ready
>
> We don't rely on the W3C JAR to be on Maven repo. The only slight
> inconvenience (though the "addjars-maven-plugin" explains well, how this
> could be done on a POM level for multiple modules, have not tried that one
> yet) could be having to keep the tiny W3C JAR both in "Client" and
> "SimpleDDR", but the issue of using the JAR in its binary form (that's how
> W3C provides it) is solved
>
> If you can explore how W3C or any of the old WG members could still put
> that to MavenCentral, more than just the DeviceMap project would welcome
> (otherwise the guy who put it to GitHub would never have bothered) but it
> is not a showstopper for 1.0.
>
> Werner
>
>
>
>
>
>
>
>
Re: Legacy ODDR java client and w3c jar in our repo
Posted by Reza <re...@yahoo.com.INVALID>.
You did not answer #2 or #3.
So is this project the best place to support the legacy oddr java client? Would it not be better for you to support the ODDR effort back at the oddr github page: https://github.com/OpenDDRdotORG/OpenDDR-Java.
Its been inactive for 2 years. So as to why you are now pushing oddr front and center of the DeviceMap project is puzzling... Why are you not focusing on our 1.0.0 release and the DeviceMap project?
Why are you on this project...? What value are you adding here? This is a huge distraction. You are constantly breaking the java client codebase which is another big waste of my time. I just dont see the value of any of this.
________________________________
From: Werner Keil <we...@gmail.com>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>; Reza <re...@yahoo.com>
Sent: Wednesday, July 9, 2014 11:11 AM
Subject: Re: Legacy ODDR java client and w3c jar in our repo
Equally important is, how the .NET and Java clients are similar or not?
if Eberhard's .NET client supports W3C DDR Specs then the Java API also should. And
As for 1) the answer is, I am also currently the only active OpenDDR contributor, so what I'm allowed and supposed to do with OpenDDR Data (contribute into this project as a contributor to both) I also can and will do in case of the Java API.
Werner
On Wed, Jul 9, 2014 at 4:56 PM, Reza <re...@yahoo.com.invalid> wrote:
ok, lets try this again, please answer these questions:
>
>
>1) Do we plan on supporting the legacy openddr java client? If so, who will support it?
>
>
>2) Do we plan on re-releasing the legacy openddr java client?
>
>
>3) If we support and release the legacy openddr java client (your answer to #1 and #2 is yes), what is the transition plan to get these legacy users off openddr and onto the devicemap client? Or no plan, we support both openddr users and devicemap users?
>
>
>
>________________________________
>
>From: Werner Keil <we...@gmail.com>
>To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>; Reza <re...@yahoo.com>
>Sent: Wednesday, July 9, 2014 10:45 AM
>Subject: Re: Legacy ODDR java client and w3c jar in our repo
>
>
>
>As mentioned and discussed with Bertrand in the other thread, myriads of Apache projects, see Tomcat, etc. use "lib" folders for dependencies, JSP, CSS, etc.
>The W3C license is among the ones supported by ASF, so using the lib in a downstream implementation is perfectly fine.
>
>
>The relation between the "old" and "new" client are a bit like JSP vs. JSF. Both are Java EE standards allowing you to accomplish the same thing, but believe it or not, the current ThoughtWorks Radar still has JSF on "Hold" (explained as "widely adopted but we still feel it's a bit immature")
>
>
>The same applies to the "new" client I'm afraid, especially with regards to W3C compatibility. Many big sites and projects of various sizes use OpenDDR now. So unless you offer them a 100% compatible Drop-in-replacement in the "new" client, that is not usable to them in existing code without rewriting the whole application.
>
>
>If we want to abandon and ignore these users and leave them with the existing OpenDDR project rather than offering a "bridge" (and chance to eventually migrate to the new one) that could mean leaving Simple DDR, but I don't know if we want to do that.
>
>
>Bertrand, WDYT?
>
>
>
>
>
>On Wed, Jul 9, 2014 at 4:36 PM, Reza <re...@yahoo.com.invalid> wrote:
>
>Why is the legacy ODDR java client still in our repo?
>>
>>
>>http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/simpleddr/
>>
>>
>>
>>Do we plan on supporting it? If so, who will support it? Did I not rewrite the client last year because of all of the issues this legacy client has.
>>
>>
>>Do you (we) plan on re-releasing the legacy ODDR client as well? That would mean we now have 2 java clients...
>>
>>
>>Also, you checked in the w3c jar here:
>>
>>
>>http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/simpleddr/lib/
>>
>>
>>
>>Once again, what is the point of trying to bring this old client back from the dead? I will investigate what is needed to get w3c compatibility into the new client. Checking this old client into our repo with the w3c jar is likely not needed...
>>
>>
>>
>>________________________________
>> From: Werner Keil <we...@gmail.com>
>>To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>; Reza <re...@yahoo.com>
>>Sent: Wednesday, July 9, 2014 10:25 AM
>>Subject: Re: DeviceMap data and java client 1.0.0 release review ready
>>
>>
>>
>>We don't rely on the W3C JAR to be on Maven repo. The only slight inconvenience (though the "addjars-maven-plugin" explains well, how this could be done on a POM level for multiple modules, have not tried that one yet) could be having to keep the tiny W3C JAR both in "Client" and "SimpleDDR", but the issue of using the JAR in its binary form (that's how W3C provides it) is solved
>>
>>
>>If you can explore how W3C or any of the old WG members could still put that to MavenCentral, more than just the DeviceMap project would welcome (otherwise the guy who put it to GitHub would never have bothered) but it is not a showstopper for 1.0.
>>
>>
>>Werner
>>
>
>
>
Re: Legacy ODDR java client and w3c jar in our repo
Posted by Werner Keil <we...@gmail.com>.
Equally important is, how the .NET and Java clients are similar or not?
if Eberhard's .NET client supports W3C DDR Specs then the Java API also
should. And
As for 1) the answer is, I am also currently the only active OpenDDR
contributor, so what I'm allowed and supposed to do with OpenDDR Data
(contribute into this project as a contributor to both) I also can and will
do in case of the Java API.
Werner
On Wed, Jul 9, 2014 at 4:56 PM, Reza <re...@yahoo.com.invalid> wrote:
> ok, lets try this again, please answer these questions:
>
> 1) Do we plan on supporting the legacy openddr java client? If so, who
> will support it?
>
> 2) Do we plan on re-releasing the legacy openddr java client?
>
> 3) If we support and release the legacy openddr java client (your answer
> to #1 and #2 is yes), what is the transition plan to get these legacy users
> off openddr and onto the devicemap client? Or no plan, we support both
> openddr users and devicemap users?
>
> ------------------------------
> *From:* Werner Keil <we...@gmail.com>
> *To:* "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>; Reza <re...@yahoo.com>
> *Sent:* Wednesday, July 9, 2014 10:45 AM
> *Subject:* Re: Legacy ODDR java client and w3c jar in our repo
>
> As mentioned and discussed with Bertrand in the other thread, myriads of
> Apache projects, see Tomcat, etc. use "lib" folders for dependencies, JSP,
> CSS, etc.
> The W3C license is among the ones supported by ASF, so using the lib in a
> downstream implementation is perfectly fine.
>
> The relation between the "old" and "new" client are a bit like JSP vs.
> JSF. Both are Java EE standards allowing you to accomplish the same thing,
> but believe it or not, the current ThoughtWorks Radar still has JSF on
> "Hold" (explained as "widely adopted but we still feel it's a bit immature"
> )
>
> The same applies to the "new" client I'm afraid, especially with regards
> to W3C compatibility. Many big sites and projects of various sizes use
> OpenDDR now. So unless you offer them a 100% compatible Drop-in-replacement
> in the "new" client, that is not usable to them in existing code without
> rewriting the whole application.
>
> If we want to abandon and ignore these users and leave them with the
> existing OpenDDR project rather than offering a "bridge" (and chance to
> eventually migrate to the new one) that could mean leaving Simple DDR, but
> I don't know if we want to do that.
>
> Bertrand, WDYT?
>
>
>
> On Wed, Jul 9, 2014 at 4:36 PM, Reza <re...@yahoo.com.invalid>
> wrote:
>
> Why is the legacy ODDR java client still in our repo?
>
>
> http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/simpleddr/
>
> Do we plan on supporting it? If so, who will support it? Did I not rewrite
> the client last year because of all of the issues this legacy client has.
>
> Do you (we) plan on re-releasing the legacy ODDR client as well? That
> would mean we now have 2 java clients...
>
> Also, you checked in the w3c jar here:
>
>
> http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/simpleddr/lib/
>
> Once again, what is the point of trying to bring this old client back from
> the dead? I will investigate what is needed to get w3c compatibility into
> the new client. Checking this old client into our repo with the w3c jar is
> likely not needed...
>
> ------------------------------
> *From:* Werner Keil <we...@gmail.com>
> *To:* "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>; Reza <re...@yahoo.com>
> *Sent:* Wednesday, July 9, 2014 10:25 AM
> *Subject:* Re: DeviceMap data and java client 1.0.0 release review ready
>
> We don't rely on the W3C JAR to be on Maven repo. The only slight
> inconvenience (though the "addjars-maven-plugin" explains well, how this
> could be done on a POM level for multiple modules, have not tried that one
> yet) could be having to keep the tiny W3C JAR both in "Client" and
> "SimpleDDR", but the issue of using the JAR in its binary form (that's how
> W3C provides it) is solved
>
> If you can explore how W3C or any of the old WG members could still put
> that to MavenCentral, more than just the DeviceMap project would welcome
> (otherwise the guy who put it to GitHub would never have bothered) but it
> is not a showstopper for 1.0.
>
> Werner
>
>
>
>
>
Re: Legacy ODDR java client and w3c jar in our repo
Posted by Reza <re...@yahoo.com.INVALID>.
ok, lets try this again, please answer these questions:
1) Do we plan on supporting the legacy openddr java client? If so, who will support it?
2) Do we plan on re-releasing the legacy openddr java client?
3) If we support and release the legacy openddr java client (your answer to #1 and #2 is yes), what is the transition plan to get these legacy users off openddr and onto the devicemap client? Or no plan, we support both openddr users and devicemap users?
________________________________
From: Werner Keil <we...@gmail.com>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>; Reza <re...@yahoo.com>
Sent: Wednesday, July 9, 2014 10:45 AM
Subject: Re: Legacy ODDR java client and w3c jar in our repo
As mentioned and discussed with Bertrand in the other thread, myriads of Apache projects, see Tomcat, etc. use "lib" folders for dependencies, JSP, CSS, etc.
The W3C license is among the ones supported by ASF, so using the lib in a downstream implementation is perfectly fine.
The relation between the "old" and "new" client are a bit like JSP vs. JSF. Both are Java EE standards allowing you to accomplish the same thing, but believe it or not, the current ThoughtWorks Radar still has JSF on "Hold" (explained as "widely adopted but we still feel it's a bit immature")
The same applies to the "new" client I'm afraid, especially with regards to W3C compatibility. Many big sites and projects of various sizes use OpenDDR now. So unless you offer them a 100% compatible Drop-in-replacement in the "new" client, that is not usable to them in existing code without rewriting the whole application.
If we want to abandon and ignore these users and leave them with the existing OpenDDR project rather than offering a "bridge" (and chance to eventually migrate to the new one) that could mean leaving Simple DDR, but I don't know if we want to do that.
Bertrand, WDYT?
On Wed, Jul 9, 2014 at 4:36 PM, Reza <re...@yahoo.com.invalid> wrote:
Why is the legacy ODDR java client still in our repo?
>
>
>http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/simpleddr/
>
>
>
>Do we plan on supporting it? If so, who will support it? Did I not rewrite the client last year because of all of the issues this legacy client has.
>
>
>Do you (we) plan on re-releasing the legacy ODDR client as well? That would mean we now have 2 java clients...
>
>
>Also, you checked in the w3c jar here:
>
>
>http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/simpleddr/lib/
>
>
>
>Once again, what is the point of trying to bring this old client back from the dead? I will investigate what is needed to get w3c compatibility into the new client. Checking this old client into our repo with the w3c jar is likely not needed...
>
>
>
>________________________________
> From: Werner Keil <we...@gmail.com>
>To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>; Reza <re...@yahoo.com>
>Sent: Wednesday, July 9, 2014 10:25 AM
>Subject: Re: DeviceMap data and java client 1.0.0 release review ready
>
>
>
>We don't rely on the W3C JAR to be on Maven repo. The only slight inconvenience (though the "addjars-maven-plugin" explains well, how this could be done on a POM level for multiple modules, have not tried that one yet) could be having to keep the tiny W3C JAR both in "Client" and "SimpleDDR", but the issue of using the JAR in its binary form (that's how W3C provides it) is solved
>
>
>If you can explore how W3C or any of the old WG members could still put that to MavenCentral, more than just the DeviceMap project would welcome (otherwise the guy who put it to GitHub would never have bothered) but it is not a showstopper for 1.0.
>
>
>Werner
>
Re: Legacy ODDR java client and w3c jar in our repo
Posted by Werner Keil <we...@gmail.com>.
As mentioned and discussed with Bertrand in the other thread, myriads of
Apache projects, see Tomcat, etc. use "lib" folders for dependencies, JSP,
CSS, etc.
The W3C license is among the ones supported by ASF, so using the lib in a
downstream implementation is perfectly fine.
The relation between the "old" and "new" client are a bit like JSP vs. JSF.
Both are Java EE standards allowing you to accomplish the same thing, but
believe it or not, the current ThoughtWorks Radar still has JSF on "Hold"
(explained as "widely adopted but we still feel it's a bit immature"[?])
The same applies to the "new" client I'm afraid, especially with regards to
W3C compatibility. Many big sites and projects of various sizes use OpenDDR
now. So unless you offer them a 100% compatible Drop-in-replacement in the
"new" client, that is not usable to them in existing code without rewriting
the whole application.
If we want to abandon and ignore these users and leave them with the
existing OpenDDR project rather than offering a "bridge" (and chance to
eventually migrate to the new one) that could mean leaving Simple DDR, but
I don't know if we want to do that.
Bertrand, WDYT?
On Wed, Jul 9, 2014 at 4:36 PM, Reza <re...@yahoo.com.invalid> wrote:
> Why is the legacy ODDR java client still in our repo?
>
>
> http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/simpleddr/
>
> Do we plan on supporting it? If so, who will support it? Did I not rewrite
> the client last year because of all of the issues this legacy client has.
>
> Do you (we) plan on re-releasing the legacy ODDR client as well? That
> would mean we now have 2 java clients...
>
> Also, you checked in the w3c jar here:
>
>
> http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/simpleddr/lib/
>
> Once again, what is the point of trying to bring this old client back from
> the dead? I will investigate what is needed to get w3c compatibility into
> the new client. Checking this old client into our repo with the w3c jar is
> likely not needed...
>
> ------------------------------
> *From:* Werner Keil <we...@gmail.com>
> *To:* "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>; Reza <re...@yahoo.com>
> *Sent:* Wednesday, July 9, 2014 10:25 AM
> *Subject:* Re: DeviceMap data and java client 1.0.0 release review ready
>
> We don't rely on the W3C JAR to be on Maven repo. The only slight
> inconvenience (though the "addjars-maven-plugin" explains well, how this
> could be done on a POM level for multiple modules, have not tried that one
> yet) could be having to keep the tiny W3C JAR both in "Client" and
> "SimpleDDR", but the issue of using the JAR in its binary form (that's how
> W3C provides it) is solved
>
> If you can explore how W3C or any of the old WG members could still put
> that to MavenCentral, more than just the DeviceMap project would welcome
> (otherwise the guy who put it to GitHub would never have bothered) but it
> is not a showstopper for 1.0.
>
> Werner
>
>
Legacy ODDR java client and w3c jar in our repo
Posted by Reza <re...@yahoo.com.INVALID>.
Why is the legacy ODDR java client still in our repo?
http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/simpleddr/
Do we plan on supporting it? If so, who will support it? Did I not rewrite the client last year because of all of the issues this legacy client has.
Do you (we) plan on re-releasing the legacy ODDR client as well? That would mean we now have 2 java clients...
Also, you checked in the w3c jar here:
http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/simpleddr/lib/
Once again, what is the point of trying to bring this old client back from the dead? I will investigate what is needed to get w3c compatibility into the new client. Checking this old client into our repo with the w3c jar is likely not needed...
________________________________
From: Werner Keil <we...@gmail.com>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>; Reza <re...@yahoo.com>
Sent: Wednesday, July 9, 2014 10:25 AM
Subject: Re: DeviceMap data and java client 1.0.0 release review ready
We don't rely on the W3C JAR to be on Maven repo. The only slight inconvenience (though the "addjars-maven-plugin" explains well, how this could be done on a POM level for multiple modules, have not tried that one yet) could be having to keep the tiny W3C JAR both in "Client" and "SimpleDDR", but the issue of using the JAR in its binary form (that's how W3C provides it) is solved
If you can explore how W3C or any of the old WG members could still put that to MavenCentral, more than just the DeviceMap project would welcome (otherwise the guy who put it to GitHub would never have bothered) but it is not a showstopper for 1.0.
Werner
Re: DeviceMap data and java client 1.0.0 release review ready
Posted by Werner Keil <we...@gmail.com>.
We don't rely on the W3C JAR to be on Maven repo. The only slight
inconvenience (though the "addjars-maven-plugin" explains well, how this
could be done on a POM level for multiple modules, have not tried that one
yet) could be having to keep the tiny W3C JAR both in "Client" and
"SimpleDDR", but the issue of using the JAR in its binary form (that's how
W3C provides it) is solved[?]
If you can explore how W3C or any of the old WG members could still put
that to MavenCentral, more than just the DeviceMap project would welcome
(otherwise the guy who put it to GitHub would never have bothered[?]) but it
is not a showstopper for 1.0.
Werner
On Wed, Jul 9, 2014 at 4:16 PM, Reza <re...@yahoo.com.invalid> wrote:
> FYI, incase this got lost in all the discussions, this release is (still)
> ready.
>
> So in regard to the w3c simple ddr issue, that does not block this release
> or any future releases. It only poses an issue when we try to make
> DeviceMap w3c compatible. I would like to make it w3c compatible, so I just
> need to do some more research in the coming weeks to see what the effort
> is. Right now the main issue is that the w3c java api was never published
> to a maven repo, need to still understand what that means in regard to w3c
> compatibility. So thats my TODO.
>
>
> ________________________________
> From: Reza <re...@yahoo.com.INVALID>
> To: Apache Device Map DEV <de...@incubator.apache.org>
> Sent: Tuesday, July 8, 2014 3:03 PM
> Subject: DeviceMap data and java client 1.0.0 release review ready
>
>
> I have updated the devicemap data and java client release:
>
> http://www.rezsoft.org/devicemap/
>
>
> Changes:
>
> -fixed the LICENSE, NOTICE, DISCLAIMER. I also added these to individual
> projects to simplify releasing.
> -added a README
> -removed all the @author comments
> -changed version from 1.0 to 1.0.0
> -I changed the java client artifact id from devicemap-java to
> devicemap-client
> -I moved some classes around in the loader package so they are better
> organized
>
> If all looks good, I will create the tag for this release.
>
Re: DeviceMap data and java client 1.0.0 release review ready
Posted by Reza <re...@yahoo.com.INVALID>.
FYI, incase this got lost in all the discussions, this release is (still) ready.
So in regard to the w3c simple ddr issue, that does not block this release or any future releases. It only poses an issue when we try to make DeviceMap w3c compatible. I would like to make it w3c compatible, so I just need to do some more research in the coming weeks to see what the effort is. Right now the main issue is that the w3c java api was never published to a maven repo, need to still understand what that means in regard to w3c compatibility. So thats my TODO.
________________________________
From: Reza <re...@yahoo.com.INVALID>
To: Apache Device Map DEV <de...@incubator.apache.org>
Sent: Tuesday, July 8, 2014 3:03 PM
Subject: DeviceMap data and java client 1.0.0 release review ready
I have updated the devicemap data and java client release:
http://www.rezsoft.org/devicemap/
Changes:
-fixed the LICENSE, NOTICE, DISCLAIMER. I also added these to individual projects to simplify releasing.
-added a README
-removed all the @author comments
-changed version from 1.0 to 1.0.0
-I changed the java client artifact id from devicemap-java to devicemap-client
-I moved some classes around in the loader package so they are better organized
If all looks good, I will create the tag for this release.
Re: DeviceMap data and java client 1.0.0 release review ready
Posted by Werner Keil <we...@gmail.com>.
How about the "examples" repo, that does not seem to be in the official SVN
yet?
On Tue, Jul 8, 2014 at 9:29 PM, Werner Keil <we...@gmail.com> wrote:
> It is not exposed to the outside e.g. via Maven artifactId, but would you
> consider changing the module name from "classifier" to something like
> "client", too?
>
>
>
> On Tue, Jul 8, 2014 at 9:27 PM, Werner Keil <we...@gmail.com> wrote:
>
>> It so far is a detail of the implementation that's not exposed. Only a
>> private method refers to it. How would that change?
>>
>>
>> On Tue, Jul 8, 2014 at 9:15 PM, Reza <re...@yahoo.com.invalid>
>> wrote:
>>
>>> I saw it. You had moved it into the loader.impl package. It doesnt
>>> belong there because its not a loader implementation. It goes into the
>>> loader.parser package since its a parser... When we add more parsers, they
>>> will go into that package as well.
>>>
>>> ------------------------------
>>> *From:* Werner Keil <we...@gmail.com>
>>> *To:* "devicemap-dev@incubator.apache.org" <
>>> devicemap-dev@incubator.apache.org>; Reza <re...@yahoo.com>
>>> *Sent:* Tuesday, July 8, 2014 3:11 PM
>>> *Subject:* Re: DeviceMap data and java client 1.0.0 release review ready
>>>
>>> OK, I did the refactoring of the parser, you'll noticed it during the
>>> commit/update.
>>>
>>> Actually it seems you missed it Please try to update before the next
>>> commit, so a tagged version no longer exposes a class that's not used
>>> outside...
>>>
>>>
>>>
>>> On Tue, Jul 8, 2014 at 9:03 PM, Reza <re...@yahoo.com.invalid>
>>> wrote:
>>>
>>> I have updated the devicemap data and java client release:
>>>
>>> http://www.rezsoft.org/devicemap/
>>>
>>>
>>> Changes:
>>>
>>> -fixed the LICENSE, NOTICE, DISCLAIMER. I also added these to individual
>>> projects to simplify releasing.
>>> -added a README
>>> -removed all the @author comments
>>> -changed version from 1.0 to 1.0.0
>>> -I changed the java client artifact id from devicemap-java to
>>> devicemap-client
>>> -I moved some classes around in the loader package so they are better
>>> organized
>>>
>>> If all looks good, I will create the tag for this release.
>>>
>>>
>>>
>>>
>>>
>>
>
Re: DeviceMap data and java client 1.0.0 release review ready
Posted by Werner Keil <we...@gmail.com>.
It is not exposed to the outside e.g. via Maven artifactId, but would you
consider changing the module name from "classifier" to something like
"client", too?
On Tue, Jul 8, 2014 at 9:27 PM, Werner Keil <we...@gmail.com> wrote:
> It so far is a detail of the implementation that's not exposed. Only a
> private method refers to it. How would that change?
>
>
> On Tue, Jul 8, 2014 at 9:15 PM, Reza <re...@yahoo.com.invalid>
> wrote:
>
>> I saw it. You had moved it into the loader.impl package. It doesnt belong
>> there because its not a loader implementation. It goes into the
>> loader.parser package since its a parser... When we add more parsers, they
>> will go into that package as well.
>>
>> ------------------------------
>> *From:* Werner Keil <we...@gmail.com>
>> *To:* "devicemap-dev@incubator.apache.org" <
>> devicemap-dev@incubator.apache.org>; Reza <re...@yahoo.com>
>> *Sent:* Tuesday, July 8, 2014 3:11 PM
>> *Subject:* Re: DeviceMap data and java client 1.0.0 release review ready
>>
>> OK, I did the refactoring of the parser, you'll noticed it during the
>> commit/update.
>>
>> Actually it seems you missed it Please try to update before the next
>> commit, so a tagged version no longer exposes a class that's not used
>> outside...
>>
>>
>>
>> On Tue, Jul 8, 2014 at 9:03 PM, Reza <re...@yahoo.com.invalid>
>> wrote:
>>
>> I have updated the devicemap data and java client release:
>>
>> http://www.rezsoft.org/devicemap/
>>
>>
>> Changes:
>>
>> -fixed the LICENSE, NOTICE, DISCLAIMER. I also added these to individual
>> projects to simplify releasing.
>> -added a README
>> -removed all the @author comments
>> -changed version from 1.0 to 1.0.0
>> -I changed the java client artifact id from devicemap-java to
>> devicemap-client
>> -I moved some classes around in the loader package so they are better
>> organized
>>
>> If all looks good, I will create the tag for this release.
>>
>>
>>
>>
>>
>
Re: moving XMLParser.java to loader.impl
Posted by Werner Keil <we...@gmail.com>.
Went into wrong Mylyn context, sorry, I am just fixing the problem of the
JAR in a proper way.
On Tue, Jul 8, 2014 at 10:04 PM, Reza <re...@yahoo.com.invalid>
wrote:
> So why are you singling out XMLParser.java and not any of the other public
> classes in the project? If we need to follow Law of Demeter, then we need
> to put all classes into a single package and make them private. No?
>
> Also, your commit message for the move is:
>
> "DMAP-38: Integrate W3C Simple DDR library
>
> Task-Url: https://issues.apache.org/jira/browse/DMAP-38"
>
> You did not address DMAP-38 in moving the XMLParser to the loader.impl
> package. So this is a completely invalid commit message. If you are going
> to commit a change, please use a proper commit message.
>
> If commits like this continue, then we will have to put commits thru a
> code review process. Lets try and not take this step :)
>
>
> ________________________________
> From: Werner Keil <we...@gmail.com>
> To: "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>; Reza <re...@yahoo.com>
> Sent: Tuesday, July 8, 2014 3:53 PM
> Subject: Re: DeviceMap data and java client 1.0.0 release review ready
>
>
>
> According to "Demeter's Law" (http://en.wikipedia.org/wiki/Law_of_Demeter)
> as few as possible public APIs should be exposed. Putting classes into
> different packages makes is hard under Java to accomplish that. Only let's
> say OSGi enabled projects (something we could add if using them e.g. in a
> container like Felix/Caraf is of interest) manage to declare some packages
> as "internal" by simply not exposing them in the OSGi "bundle".
>
> If a parser is already or very soon meant to be used in the signatures of
> public methods, then why not offer them a separate packge. Otherwise we
> could wait and leave it with "impl".
>
>
> On Tue, Jul 8, 2014 at 9:39 PM, Reza <re...@yahoo.com.invalid>
> wrote:
>
> Technically 90% of the classes in the project are details of the
> implementation and are not exposed, does that mean that all those classes
> need to go into the same package? :)
> >
> >
> >The packages are there for better organization and separation of work and
> interests. Parsers go into a parsers package, not the loader implementation
> package. At least, thats the way I have always done it.
> >
> >
> >>> module name
> >
> >
> >As for the svn project name, sure.
> >
> >
> >
> >
> >
> >
> >________________________________
> >
> >From: Werner Keil <we...@gmail.com>
> >To: "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>; Reza <re...@yahoo.com>
> >Sent: Tuesday, July 8, 2014 3:27 PM
> >
> >Subject: Re: DeviceMap data and java client 1.0.0 release review ready
> >
> >
> >
> >It so far is a detail of the implementation that's not exposed. Only a
> private method refers to it. How would that change?
> >
> >
> >
> >
> >On Tue, Jul 8, 2014 at 9:15 PM, Reza <re...@yahoo.com.invalid>
> wrote:
> >
> >I saw it. You had moved it into the loader.impl package. It doesnt belong
> there because its not a loader implementation. It goes into the
> loader.parser package since its a parser... When we add more parsers, they
> will go into that package as well.
> >>
> >>
> >>
> >>________________________________
> >> From: Werner Keil <we...@gmail.com>
> >>To: "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>; Reza <re...@yahoo.com>
> >>Sent: Tuesday, July 8, 2014 3:11 PM
> >>Subject: Re: DeviceMap data and java client 1.0.0 release review ready
> >>
> >>
> >>
> >>OK, I did the refactoring of the parser, you'll noticed it during the
> commit/update.
> >>
> >>
> >>Actually it seems you missed it Please try to update before the next
> commit, so a tagged version no longer exposes a class that's not used
> outside...
> >>
> >>
> >>
> >>
> >>
> >>On Tue, Jul 8, 2014 at 9:03 PM, Reza <re...@yahoo.com.invalid>
> wrote:
> >>
> >>I have updated the devicemap data and java client release:
> >>>
> >>>http://www.rezsoft.org/devicemap/
> >>>
> >>>
> >>>Changes:
> >>>
> >>>-fixed the LICENSE, NOTICE, DISCLAIMER. I also added these to
> individual projects to simplify releasing.
> >>>-added a README
> >>>-removed all the @author comments
> >>>-changed version from 1.0 to 1.0.0
> >>>-I changed the java client artifact id from devicemap-java to
> devicemap-client
> >>>-I moved some classes around in the loader package so they are better
> organized
> >>>
> >>>If all looks good, I will create the tag for this release.
> >>>
> >>
> >>
> >>
> >
> >
> >
Re: moving XMLParser.java to loader.impl
Posted by Reza <re...@yahoo.com.INVALID>.
So why are you singling out XMLParser.java and not any of the other public classes in the project? If we need to follow Law of Demeter, then we need to put all classes into a single package and make them private. No?
Also, your commit message for the move is:
"DMAP-38: Integrate W3C Simple DDR library
Task-Url: https://issues.apache.org/jira/browse/DMAP-38"
You did not address DMAP-38 in moving the XMLParser to the loader.impl package. So this is a completely invalid commit message. If you are going to commit a change, please use a proper commit message.
If commits like this continue, then we will have to put commits thru a code review process. Lets try and not take this step :)
________________________________
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 3:53 PM
Subject: Re: DeviceMap data and java client 1.0.0 release review ready
According to "Demeter's Law" (http://en.wikipedia.org/wiki/Law_of_Demeter) as few as possible public APIs should be exposed. Putting classes into different packages makes is hard under Java to accomplish that. Only let's say OSGi enabled projects (something we could add if using them e.g. in a container like Felix/Caraf is of interest) manage to declare some packages as "internal" by simply not exposing them in the OSGi "bundle".
If a parser is already or very soon meant to be used in the signatures of public methods, then why not offer them a separate packge. Otherwise we could wait and leave it with "impl".
On Tue, Jul 8, 2014 at 9:39 PM, Reza <re...@yahoo.com.invalid> wrote:
Technically 90% of the classes in the project are details of the implementation and are not exposed, does that mean that all those classes need to go into the same package? :)
>
>
>The packages are there for better organization and separation of work and interests. Parsers go into a parsers package, not the loader implementation package. At least, thats the way I have always done it.
>
>
>>> module name
>
>
>As for the svn project name, sure.
>
>
>
>
>
>
>________________________________
>
>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 3:27 PM
>
>Subject: Re: DeviceMap data and java client 1.0.0 release review ready
>
>
>
>It so far is a detail of the implementation that's not exposed. Only a private method refers to it. How would that change?
>
>
>
>
>On Tue, Jul 8, 2014 at 9:15 PM, Reza <re...@yahoo.com.invalid> wrote:
>
>I saw it. You had moved it into the loader.impl package. It doesnt belong there because its not a loader implementation. It goes into the loader.parser package since its a parser... When we add more parsers, they will go into that package as well.
>>
>>
>>
>>________________________________
>> 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 3:11 PM
>>Subject: Re: DeviceMap data and java client 1.0.0 release review ready
>>
>>
>>
>>OK, I did the refactoring of the parser, you'll noticed it during the commit/update.
>>
>>
>>Actually it seems you missed it Please try to update before the next commit, so a tagged version no longer exposes a class that's not used outside...
>>
>>
>>
>>
>>
>>On Tue, Jul 8, 2014 at 9:03 PM, Reza <re...@yahoo.com.invalid> wrote:
>>
>>I have updated the devicemap data and java client release:
>>>
>>>http://www.rezsoft.org/devicemap/
>>>
>>>
>>>Changes:
>>>
>>>-fixed the LICENSE, NOTICE, DISCLAIMER. I also added these to individual projects to simplify releasing.
>>>-added a README
>>>-removed all the @author comments
>>>-changed version from 1.0 to 1.0.0
>>>-I changed the java client artifact id from devicemap-java to devicemap-client
>>>-I moved some classes around in the loader package so they are better organized
>>>
>>>If all looks good, I will create the tag for this release.
>>>
>>
>>
>>
>
>
>
Re: DeviceMap data and java client 1.0.0 release review ready
Posted by Werner Keil <we...@gmail.com>.
According to "Demeter's Law" (http://en.wikipedia.org/wiki/Law_of_Demeter)
as few as possible public APIs should be exposed. Putting classes into
different packages makes is hard under Java to accomplish that. Only let's
say OSGi enabled projects (something we could add if using them e.g. in a
container like Felix/Caraf is of interest) manage to declare some packages
as "internal" by simply not exposing them in the OSGi "bundle".
If a parser is already or very soon meant to be used in the signatures of
public methods, then why not offer them a separate packge. Otherwise we
could wait and leave it with "impl".
On Tue, Jul 8, 2014 at 9:39 PM, Reza <re...@yahoo.com.invalid> wrote:
> Technically 90% of the classes in the project are details of the
> implementation and are not exposed, does that mean that all those classes
> need to go into the same package? :)
>
> The packages are there for better organization and separation of work and
> interests. Parsers go into a parsers package, not the loader implementation
> package. At least, thats the way I have always done it.
>
> >> module name
>
> As for the svn project name, sure.
>
>
>
> ------------------------------
> *From:* Werner Keil <we...@gmail.com>
> *To:* "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>; Reza <re...@yahoo.com>
> *Sent:* Tuesday, July 8, 2014 3:27 PM
>
> *Subject:* Re: DeviceMap data and java client 1.0.0 release review ready
>
> It so far is a detail of the implementation that's not exposed. Only a
> private method refers to it. How would that change?
>
>
> On Tue, Jul 8, 2014 at 9:15 PM, Reza <re...@yahoo.com.invalid>
> wrote:
>
> I saw it. You had moved it into the loader.impl package. It doesnt belong
> there because its not a loader implementation. It goes into the
> loader.parser package since its a parser... When we add more parsers, they
> will go into that package as well.
>
> ------------------------------
> *From:* Werner Keil <we...@gmail.com>
> *To:* "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>; Reza <re...@yahoo.com>
> *Sent:* Tuesday, July 8, 2014 3:11 PM
> *Subject:* Re: DeviceMap data and java client 1.0.0 release review ready
>
> OK, I did the refactoring of the parser, you'll noticed it during the
> commit/update.
>
> Actually it seems you missed it Please try to update before the next
> commit, so a tagged version no longer exposes a class that's not used
> outside...
>
>
>
> On Tue, Jul 8, 2014 at 9:03 PM, Reza <re...@yahoo.com.invalid>
> wrote:
>
> I have updated the devicemap data and java client release:
>
> http://www.rezsoft.org/devicemap/
>
>
> Changes:
>
> -fixed the LICENSE, NOTICE, DISCLAIMER. I also added these to individual
> projects to simplify releasing.
> -added a README
> -removed all the @author comments
> -changed version from 1.0 to 1.0.0
> -I changed the java client artifact id from devicemap-java to
> devicemap-client
> -I moved some classes around in the loader package so they are better
> organized
>
> If all looks good, I will create the tag for this release.
>
>
>
>
>
>
>
>
Re: DeviceMap data and java client 1.0.0 release review ready
Posted by Reza <re...@yahoo.com.INVALID>.
Technically 90% of the classes in the project are details of the implementation and are not exposed, does that mean that all those classes need to go into the same package? :)
The packages are there for better organization and separation of work and interests. Parsers go into a parsers package, not the loader implementation package. At least, thats the way I have always done it.
>> module name
As for the svn project name, sure.
________________________________
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 3:27 PM
Subject: Re: DeviceMap data and java client 1.0.0 release review ready
It so far is a detail of the implementation that's not exposed. Only a private method refers to it. How would that change?
On Tue, Jul 8, 2014 at 9:15 PM, Reza <re...@yahoo.com.invalid> wrote:
I saw it. You had moved it into the loader.impl package. It doesnt belong there because its not a loader implementation. It goes into the loader.parser package since its a parser... When we add more parsers, they will go into that package as well.
>
>
>
>________________________________
> 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 3:11 PM
>Subject: Re: DeviceMap data and java client 1.0.0 release review ready
>
>
>
>OK, I did the refactoring of the parser, you'll noticed it during the commit/update.
>
>
>Actually it seems you missed it Please try to update before the next commit, so a tagged version no longer exposes a class that's not used outside...
>
>
>
>
>
>On Tue, Jul 8, 2014 at 9:03 PM, Reza <re...@yahoo.com.invalid> wrote:
>
>I have updated the devicemap data and java client release:
>>
>>http://www.rezsoft.org/devicemap/
>>
>>
>>Changes:
>>
>>-fixed the LICENSE, NOTICE, DISCLAIMER. I also added these to individual projects to simplify releasing.
>>-added a README
>>-removed all the @author comments
>>-changed version from 1.0 to 1.0.0
>>-I changed the java client artifact id from devicemap-java to devicemap-client
>>-I moved some classes around in the loader package so they are better organized
>>
>>If all looks good, I will create the tag for this release.
>>
>
>
>
Re: DeviceMap data and java client 1.0.0 release review ready
Posted by Werner Keil <we...@gmail.com>.
It so far is a detail of the implementation that's not exposed. Only a
private method refers to it. How would that change?
On Tue, Jul 8, 2014 at 9:15 PM, Reza <re...@yahoo.com.invalid> wrote:
> I saw it. You had moved it into the loader.impl package. It doesnt belong
> there because its not a loader implementation. It goes into the
> loader.parser package since its a parser... When we add more parsers, they
> will go into that package as well.
>
> ------------------------------
> *From:* Werner Keil <we...@gmail.com>
> *To:* "devicemap-dev@incubator.apache.org" <
> devicemap-dev@incubator.apache.org>; Reza <re...@yahoo.com>
> *Sent:* Tuesday, July 8, 2014 3:11 PM
> *Subject:* Re: DeviceMap data and java client 1.0.0 release review ready
>
> OK, I did the refactoring of the parser, you'll noticed it during the
> commit/update.
>
> Actually it seems you missed it Please try to update before the next
> commit, so a tagged version no longer exposes a class that's not used
> outside...
>
>
>
> On Tue, Jul 8, 2014 at 9:03 PM, Reza <re...@yahoo.com.invalid>
> wrote:
>
> I have updated the devicemap data and java client release:
>
> http://www.rezsoft.org/devicemap/
>
>
> Changes:
>
> -fixed the LICENSE, NOTICE, DISCLAIMER. I also added these to individual
> projects to simplify releasing.
> -added a README
> -removed all the @author comments
> -changed version from 1.0 to 1.0.0
> -I changed the java client artifact id from devicemap-java to
> devicemap-client
> -I moved some classes around in the loader package so they are better
> organized
>
> If all looks good, I will create the tag for this release.
>
>
>
>
>
Re: DeviceMap data and java client 1.0.0 release review ready
Posted by Reza <re...@yahoo.com.INVALID>.
I saw it. You had moved it into the loader.impl package. It doesnt belong there because its not a loader implementation. It goes into the loader.parser package since its a parser... When we add more parsers, they will go into that package as well.
________________________________
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 3:11 PM
Subject: Re: DeviceMap data and java client 1.0.0 release review ready
OK, I did the refactoring of the parser, you'll noticed it during the commit/update.
Actually it seems you missed it Please try to update before the next commit, so a tagged version no longer exposes a class that's not used outside...
On Tue, Jul 8, 2014 at 9:03 PM, Reza <re...@yahoo.com.invalid> wrote:
I have updated the devicemap data and java client release:
>
>http://www.rezsoft.org/devicemap/
>
>
>Changes:
>
>-fixed the LICENSE, NOTICE, DISCLAIMER. I also added these to individual projects to simplify releasing.
>-added a README
>-removed all the @author comments
>-changed version from 1.0 to 1.0.0
>-I changed the java client artifact id from devicemap-java to devicemap-client
>-I moved some classes around in the loader package so they are better organized
>
>If all looks good, I will create the tag for this release.
>
Re: DeviceMap data and java client 1.0.0 release review ready
Posted by Werner Keil <we...@gmail.com>.
OK, I did the refactoring of the parser, you'll noticed it during the
commit/update.
Actually it seems you missed it[?] Please try to update before the next
commit, so a tagged version no longer exposes a class that's not used
outside...
On Tue, Jul 8, 2014 at 9:03 PM, Reza <re...@yahoo.com.invalid> wrote:
> I have updated the devicemap data and java client release:
>
> http://www.rezsoft.org/devicemap/
>
>
> Changes:
>
> -fixed the LICENSE, NOTICE, DISCLAIMER. I also added these to individual
> projects to simplify releasing.
> -added a README
> -removed all the @author comments
> -changed version from 1.0 to 1.0.0
> -I changed the java client artifact id from devicemap-java to
> devicemap-client
> -I moved some classes around in the loader package so they are better
> organized
>
> If all looks good, I will create the tag for this release.
>