data and java api 1.0 release ready

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

Release is ready here for review:

http://www.rezsoft.org/devicemap/

I spent a good bit of time finalizing the java api. I think it came out really nice... loaders are all working, exceptions are all correct, and performance and accuracy is great.

As for the device data, I went ahead and fixed a few of the problematic patterns (ex: Sony X 10 matching on OS X 10). I also added the generic fallback patterns to the patch files. This is really important in catching generic devices which fall thru the cracks.

Re: data and java api 1.0 release ready

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

No problem, I will try and have all of these fixed today. So im just going to put a copy of the LICENSE, NOTICE, README, etc, at the root of both of these sub projects. This way, I can more easily script the export and release since the repo has all the files it needs.

I will shoot out an email when its ready.


________________________________
 From: Bertrand Delacretaz <bd...@apache.org>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org> 
Sent: Monday, July 7, 2014 3:29 AM
Subject: Re: data and java api 1.0 release ready
 

Hi Reza,




On Sun, Jul 6, 2014 at 1:52 AM, Reza <re...@yahoo.com.invalid> wrote:
> Release is ready here for review:
> http://www.rezsoft.org/devicemap/

Thanks for this, here are a few comments.

On MD5 (devicemap-data-1.0.tar.gz) = 86a596167277dc3e2801cf4855f402f0

1) Did you create svn tags for each of the release archives? I'd
expect something like data/devicemap-data-1.0 under
http://svn.apache.org/repos/asf/incubator/devicemap/tags/ - needed to
verify that the released code matches what we have in svn. The code in
your release archives matches revision 1608287 so if you didn't create
a tag yet you can just create one from that revision.

2) In ./devicemap-data/CREDITS.txt I would remove the OpenDDR license
info. That data is now released under Apache License, those mentions
are confusing IMO. Ok to keep the credits of course.

3) devicemap-data doesn't need references to Modernizr and
matchMedia.js in NOTICE, it does not use them.

Apart from that the devicemap-data archive looks good to me.


On MD5 (devicemap-java-1.0.tar.gz) = 33efb7aa9b86fe16c0e1264ab8ae4b4b

4) I'd remove the CREDITS.txt file from devicemap-java as that doesn't
contain anything that was donated by OpenDDR

5) Same as 3) about NOTICE

6) I suggest removing the @author tags from the code, we can discuss
it separately, in general we don't have them in Apache code. Not
urgent, can be done after the release

So those are all minor things related to the "release metadata" files,
once this is fixed IMO we're go for voting on those releases here and
having the Incubator PMC vote on them.

-Bertrand

Re: data and java api 1.0 release ready

[Bertrand Delacretaz <bd...@apache.org>]

Hi Reza,

On Sun, Jul 6, 2014 at 1:52 AM, Reza <re...@yahoo.com.invalid> wrote:
> Release is ready here for review:
> http://www.rezsoft.org/devicemap/

Thanks for this, here are a few comments.

On MD5 (devicemap-data-1.0.tar.gz) = 86a596167277dc3e2801cf4855f402f0

1) Did you create svn tags for each of the release archives? I'd
expect something like data/devicemap-data-1.0 under
http://svn.apache.org/repos/asf/incubator/devicemap/tags/ - needed to
verify that the released code matches what we have in svn. The code in
your release archives matches revision 1608287 so if you didn't create
a tag yet you can just create one from that revision.

2) In ./devicemap-data/CREDITS.txt I would remove the OpenDDR license
info. That data is now released under Apache License, those mentions
are confusing IMO. Ok to keep the credits of course.

3) devicemap-data doesn't need references to Modernizr and
matchMedia.js in NOTICE, it does not use them.

Apart from that the devicemap-data archive looks good to me.


On MD5 (devicemap-java-1.0.tar.gz) = 33efb7aa9b86fe16c0e1264ab8ae4b4b

4) I'd remove the CREDITS.txt file from devicemap-java as that doesn't
contain anything that was donated by OpenDDR

5) Same as 3) about NOTICE

6) I suggest removing the @author tags from the code, we can discuss
it separately, in general we don't have them in Apache code. Not
urgent, can be done after the release

So those are all minor things related to the "release metadata" files,
once this is fixed IMO we're go for voting on those releases here and
having the Incubator PMC vote on them.

-Bertrand

Re: data and java api 1.0 release ready

["reza.naghibi@yahoo.com.INVALID" <re...@yahoo.com.INVALID>]

Yes. Also got to update the webapp example.

I should have the updated release ready this afternoon.

Re: data and java api 1.0 release ready

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

Reza,

Do you think you can move the example project
http://www.rezsoft.org/devicemap/example/
to the official DeviceMap repo
https://svn.apache.org/repos/asf/incubator/devicemap/trunk/examples?

That was reserved for examples so far in the "contrib" area, there's only a
parent POM, so you could put it there it would be great.
I proposed "org.apache.devicemap.examples" as groupdId, but if we really
want to keep everything in a single space ("org.apache.devicemap") feel
free to adjust that.
The parent POM needs to be included with the root build POM and contain the
example modules you want Jenkins to build, then it'll become part of the
build chain like everything else.

Werner

On Mon, Jul 7, 2014 at 10:59 PM, Werner Keil <we...@gmail.com> wrote:

> Kevan/all,
>
> About the final 1.0 tag, I see there are different patterns across Apache
> projects. Cordova uses a simple "1.x.x" pattern for almost every tag, while
> many other projects from Geronimo to TomEE chose a "project-1.x.x" tag
> naming.
>
> So it would be either "1.0.0" or "devicemap-1.0.0". Not sure, if we'd add
> something like "devicemap-data" in case of sub-repositories. ActiveMQ did
> that rather fine grained for sub-projects like "activemq-cpp".
>
> While leaving existing incubator tags seems fine, we should stick to a
> consistent line from 1.0 on if possible[?]
>
> Werner
>
> On Mon, Jul 7, 2014 at 8:12 PM, Werner Keil <we...@gmail.com> wrote:
>
>> Kevan/all,
>>
>> Thanks for the effort (Reza) and positive feedback. The reason that at
>> least the "DDR Simple" part of the "java" tree is currently disabled and
>> was not tagged is a dependency to W3C DDR itself that doesn't exist in a
>> Maven-compatible form:
>>  <dependency>
>> <groupId>org.w3c</groupId>
>> <artifactId>ddr-simple</artifactId>
>>  <version>20081205</version>
>> </dependency>
>>
>> It was made available on GitHub: https://github.com/fnk/w3c-ddr
>> but e.g.  the repository from that Readme no longer exists. I placed a
>> copy under /contrib/w3c but we need to find proper handling of such
>> mandatory 3rd party library that so far has not been published to
>> MavenCentral or a similar place by the W3C. Eclipse calls this type of
>> repository "Orbit", I can't say, if a similar default place for 3rd party
>> dependencies exists at Apache. Since this was released by W3C (AFAIK the
>> version we have is the most recent one) we must treat it as external
>> depencendy, but either through our Maven build chain or independently
>> ensure, that modules like the DDR Client for Java can access it.
>>
>> The parent POM in theory could have been tagged together with the
>> artifact that's part of the release, but if that is not a problem now, we
>> could do that as soon as the best way is found for the DDR Simple client.
>>
>> Regards,
>> Werner
>>
>> On Mon, Jul 7, 2014 at 6:01 PM, Kevan Miller <ke...@gmail.com>
>> wrote:
>>
>>> On Sun, Jul 6, 2014 at 5:14 PM, Reza <re...@yahoo.com.invalid>
>>> wrote:
>>>
>>> > oops :) I forgot to put in the LICENSE/NOTICE the 2nd time around. It
>>> was
>>> > in there the first time. I just updated it, so its in now.
>>> >
>>> > So Bertrand said he wanted a release "preview" before we do our first
>>> > initial release. This is the preview.
>>> >
>>>
>>> Yep, which is great. Happy to see the progress. And thanks for pulling
>>> this
>>> together!
>>>
>>> I saw that the *java* release was not a full subset of the "java" tree.
>>> Which is all fine. Just wanted to be sure there was an understanding...
>>>
>>>
>>> >
>>> > >>Can you explain how these releases relate to the current trunk in
>>> svn?
>>> >
>>> > So we have a handful of different subprojects in the svn. This is the
>>> data
>>> > component and the java api.
>>> >
>>> >
>>> http://svn.apache.org/viewvc/incubator/devicemap/trunk/data/device-data
>>> >
>>> >
>>> >
>>> http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/classifier
>>> >
>>> >
>>> > >> 1
>>> >
>>> > Fixed. My mistake.
>>> >
>>> > >> 2
>>> >
>>> > I pulled everything out of the trunk, so if something needs to be
>>> fixed,
>>> > no problem.
>>> >
>>>
>>> If the Modernizr and matchMedia.js licenses are removed from the NOTICE
>>> (as
>>> noted by Bertrand) in all locations (trunk, tags, source releases),
>>> things
>>> should be good.
>>>
>>> --kevan
>>>
>>>
>>> >
>>> > >> 3
>>> >
>>> > I did not include a README inside the tarball. For now, its on my
>>> website
>>> > link:
>>> >
>>> > http://www.rezsoft.org/devicemap/
>>> >
>>>
>>
>>
>

Re: data and java api 1.0 release ready

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

Kevan/all,

About the final 1.0 tag, I see there are different patterns across Apache
projects. Cordova uses a simple "1.x.x" pattern for almost every tag, while
many other projects from Geronimo to TomEE chose a "project-1.x.x" tag
naming.

So it would be either "1.0.0" or "devicemap-1.0.0". Not sure, if we'd add
something like "devicemap-data" in case of sub-repositories. ActiveMQ did
that rather fine grained for sub-projects like "activemq-cpp".

While leaving existing incubator tags seems fine, we should stick to a
consistent line from 1.0 on if possible[?]

Werner

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

> Kevan/all,
>
> Thanks for the effort (Reza) and positive feedback. The reason that at
> least the "DDR Simple" part of the "java" tree is currently disabled and
> was not tagged is a dependency to W3C DDR itself that doesn't exist in a
> Maven-compatible form:
>  <dependency>
> <groupId>org.w3c</groupId>
> <artifactId>ddr-simple</artifactId>
>  <version>20081205</version>
> </dependency>
>
> It was made available on GitHub: https://github.com/fnk/w3c-ddr
> but e.g.  the repository from that Readme no longer exists. I placed a
> copy under /contrib/w3c but we need to find proper handling of such
> mandatory 3rd party library that so far has not been published to
> MavenCentral or a similar place by the W3C. Eclipse calls this type of
> repository "Orbit", I can't say, if a similar default place for 3rd party
> dependencies exists at Apache. Since this was released by W3C (AFAIK the
> version we have is the most recent one) we must treat it as external
> depencendy, but either through our Maven build chain or independently
> ensure, that modules like the DDR Client for Java can access it.
>
> The parent POM in theory could have been tagged together with the artifact
> that's part of the release, but if that is not a problem now, we could do
> that as soon as the best way is found for the DDR Simple client.
>
> Regards,
> Werner
>
> On Mon, Jul 7, 2014 at 6:01 PM, Kevan Miller <ke...@gmail.com>
> wrote:
>
>> On Sun, Jul 6, 2014 at 5:14 PM, Reza <re...@yahoo.com.invalid>
>> wrote:
>>
>> > oops :) I forgot to put in the LICENSE/NOTICE the 2nd time around. It
>> was
>> > in there the first time. I just updated it, so its in now.
>> >
>> > So Bertrand said he wanted a release "preview" before we do our first
>> > initial release. This is the preview.
>> >
>>
>> Yep, which is great. Happy to see the progress. And thanks for pulling
>> this
>> together!
>>
>> I saw that the *java* release was not a full subset of the "java" tree.
>> Which is all fine. Just wanted to be sure there was an understanding...
>>
>>
>> >
>> > >>Can you explain how these releases relate to the current trunk in svn?
>> >
>> > So we have a handful of different subprojects in the svn. This is the
>> data
>> > component and the java api.
>> >
>> > http://svn.apache.org/viewvc/incubator/devicemap/trunk/data/device-data
>> >
>> >
>> >
>> http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/classifier
>> >
>> >
>> > >> 1
>> >
>> > Fixed. My mistake.
>> >
>> > >> 2
>> >
>> > I pulled everything out of the trunk, so if something needs to be fixed,
>> > no problem.
>> >
>>
>> If the Modernizr and matchMedia.js licenses are removed from the NOTICE
>> (as
>> noted by Bertrand) in all locations (trunk, tags, source releases), things
>> should be good.
>>
>> --kevan
>>
>>
>> >
>> > >> 3
>> >
>> > I did not include a README inside the tarball. For now, its on my
>> website
>> > link:
>> >
>> > http://www.rezsoft.org/devicemap/
>> >
>>
>
>

Re: data and java api 1.0 release ready

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

Kevan/all,

Thanks for the effort (Reza) and positive feedback. The reason that at
least the "DDR Simple" part of the "java" tree is currently disabled and
was not tagged is a dependency to W3C DDR itself that doesn't exist in a
Maven-compatible form:
<dependency>
<groupId>org.w3c</groupId>
<artifactId>ddr-simple</artifactId>
<version>20081205</version>
</dependency>

It was made available on GitHub: https://github.com/fnk/w3c-ddr
but e.g.  the repository from that Readme no longer exists. I placed a copy
under /contrib/w3c but we need to find proper handling of such mandatory
3rd party library that so far has not been published to MavenCentral or a
similar place by the W3C. Eclipse calls this type of repository "Orbit", I
can't say, if a similar default place for 3rd party dependencies exists at
Apache. Since this was released by W3C (AFAIK the version we have is the
most recent one) we must treat it as external depencendy, but either
through our Maven build chain or independently ensure, that modules like
the DDR Client for Java can access it.

The parent POM in theory could have been tagged together with the artifact
that's part of the release, but if that is not a problem now, we could do
that as soon as the best way is found for the DDR Simple client.

Regards,
Werner

On Mon, Jul 7, 2014 at 6:01 PM, Kevan Miller <ke...@gmail.com> wrote:

> On Sun, Jul 6, 2014 at 5:14 PM, Reza <re...@yahoo.com.invalid>
> wrote:
>
> > oops :) I forgot to put in the LICENSE/NOTICE the 2nd time around. It was
> > in there the first time. I just updated it, so its in now.
> >
> > So Bertrand said he wanted a release "preview" before we do our first
> > initial release. This is the preview.
> >
>
> Yep, which is great. Happy to see the progress. And thanks for pulling this
> together!
>
> I saw that the *java* release was not a full subset of the "java" tree.
> Which is all fine. Just wanted to be sure there was an understanding...
>
>
> >
> > >>Can you explain how these releases relate to the current trunk in svn?
> >
> > So we have a handful of different subprojects in the svn. This is the
> data
> > component and the java api.
> >
> > http://svn.apache.org/viewvc/incubator/devicemap/trunk/data/device-data
> >
> >
> >
> http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/classifier
> >
> >
> > >> 1
> >
> > Fixed. My mistake.
> >
> > >> 2
> >
> > I pulled everything out of the trunk, so if something needs to be fixed,
> > no problem.
> >
>
> If the Modernizr and matchMedia.js licenses are removed from the NOTICE (as
> noted by Bertrand) in all locations (trunk, tags, source releases), things
> should be good.
>
> --kevan
>
>
> >
> > >> 3
> >
> > I did not include a README inside the tarball. For now, its on my website
> > link:
> >
> > http://www.rezsoft.org/devicemap/
> >
>

Re: data and java api 1.0 release ready

[Kevan Miller <ke...@gmail.com>]

On Sun, Jul 6, 2014 at 5:14 PM, Reza <re...@yahoo.com.invalid> wrote:

> oops :) I forgot to put in the LICENSE/NOTICE the 2nd time around. It was
> in there the first time. I just updated it, so its in now.
>
> So Bertrand said he wanted a release "preview" before we do our first
> initial release. This is the preview.
>

Yep, which is great. Happy to see the progress. And thanks for pulling this
together!

I saw that the *java* release was not a full subset of the "java" tree.
Which is all fine. Just wanted to be sure there was an understanding...


>
> >>Can you explain how these releases relate to the current trunk in svn?
>
> So we have a handful of different subprojects in the svn. This is the data
> component and the java api.
>
> http://svn.apache.org/viewvc/incubator/devicemap/trunk/data/device-data
>
>
> http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/classifier
>
>
> >> 1
>
> Fixed. My mistake.
>
> >> 2
>
> I pulled everything out of the trunk, so if something needs to be fixed,
> no problem.
>

If the Modernizr and matchMedia.js licenses are removed from the NOTICE (as
noted by Bertrand) in all locations (trunk, tags, source releases), things
should be good.

--kevan


>
> >> 3
>
> I did not include a README inside the tarball. For now, its on my website
> link:
>
> http://www.rezsoft.org/devicemap/
>

Re: data and java api 1.0 release ready

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

Bertrand/Reza/all,

Thanks for the effort to get a release out.


4) I'd remove the CREDITS.txt file from devicemap-java as that doesn't
contain anything that was donated by OpenDDR

For the "qualifier" module Reza and maybe a few others contributed to,
that's correct, but I recal the "java" module is the one OpenDDR
contributed almost 1:1. The W3C DDR Simple client and at least one web app
related to it. Those should keep the credits in README or similar files,
all other modules that were contributed elsewhere or written on a "green
field" shouldn't.

Cheers,
Werner

On Mon, Jul 7, 2014 at 9:30 AM, Bertrand Delacretaz <bd...@apache.org>
wrote:

> On Mon, Jul 7, 2014 at 2:14 AM, Reza <re...@yahoo.com.invalid>
> wrote:
> > ...I did not include a README inside the tarball. For now, its on my
> website link:
> > http://www.rezsoft.org/devicemap/
>
> I agree that having a README in the released archive is better, but
> that's not critical IMO for this first release.
>
> -Bertrand
>

Re: data and java api 1.0 release ready

[Bertrand Delacretaz <bd...@apache.org>]

On Mon, Jul 7, 2014 at 2:14 AM, Reza <re...@yahoo.com.invalid> wrote:
> ...I did not include a README inside the tarball. For now, its on my website link:
> http://www.rezsoft.org/devicemap/

I agree that having a README in the released archive is better, but
that's not critical IMO for this first release.

-Bertrand

Re: data and java api 1.0 release ready

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

oops :) I forgot to put in the LICENSE/NOTICE the 2nd time around. It was in there the first time. I just updated it, so its in now.

So Bertrand said he wanted a release "preview" before we do our first initial release. This is the preview.

>>Can you explain how these releases relate to the current trunk in svn?

So we have a handful of different subprojects in the svn. This is the data component and the java api.

http://svn.apache.org/viewvc/incubator/devicemap/trunk/data/device-data

http://svn.apache.org/viewvc/incubator/devicemap/trunk/devicemap/java/classifier


>> 1

Fixed. My mistake.

>> 2

I pulled everything out of the trunk, so if something needs to be fixed, no problem.

>> 3

I did not include a README inside the tarball. For now, its on my website link:

http://www.rezsoft.org/devicemap/




________________________________
 From: Kevan Miller <ke...@gmail.com>
To: "devicemap-dev@incubator.apache.org" <de...@incubator.apache.org>; Reza <re...@yahoo.com> 
Sent: Sunday, July 6, 2014 8:04 PM
Subject: Re: data and java api 1.0 release ready
 

Hi Reza,
Can you explain how these releases relate to the current trunk in svn?

Now would be a good time to review --
http://incubator.apache.org/guides/releasemanagement.html

And http://www.apache.org/dev/licensing-howto.html

A few quick notes:

1) the source distributions don't contain a LICENSE/NOTICE file
2) I notice the LICENSE/NOTICE file in svn trunk is not correct. The notice
file contains license information which should be in the LICENSE (assuming
the licensing information is accurate).
3) README's or some sort of documentation/instructions would be useful. But
that's really up to you and the rest of the community.

--kevan


On Sun, Jul 6, 2014 at 1:12 PM, Reza <re...@yahoo.com.invalid> wrote:

> I found a bug related to the hashmap ordering of keys which could cause
> the wrong pattern to be picked if multiple patterns hit. This effects
> certain jvm architectures, so this could cause the unit tests to fail on
> these architectures. So I updated the release below.
>
>
> ________________________________
>  From: Reza <re...@yahoo.com>
> To: Apache Device Map DEV <de...@incubator.apache.org>
> Sent: Saturday, July 5, 2014 7:52 PM
> Subject: data and java api 1.0 release ready
>
>
>
> Release is ready here for review:
>
> http://www.rezsoft.org/devicemap/
>
> I spent a good bit of time finalizing the java api. I think it came out
> really nice... loaders are all working, exceptions are all correct, and
> performance and accuracy is great.
>
> As for the device data, I went ahead and fixed a few of the problematic
> patterns (ex: Sony X 10 matching on OS X 10). I also added the generic
> fallback patterns to the patch files. This is really important in catching
> generic devices which fall thru the cracks.
>

Re: data and java api 1.0 release ready

[Kevan Miller <ke...@gmail.com>]

Hi Reza,
Can you explain how these releases relate to the current trunk in svn?

Now would be a good time to review --
http://incubator.apache.org/guides/releasemanagement.html

And http://www.apache.org/dev/licensing-howto.html

A few quick notes:

1) the source distributions don't contain a LICENSE/NOTICE file
2) I notice the LICENSE/NOTICE file in svn trunk is not correct. The notice
file contains license information which should be in the LICENSE (assuming
the licensing information is accurate).
3) README's or some sort of documentation/instructions would be useful. But
that's really up to you and the rest of the community.

--kevan

On Sun, Jul 6, 2014 at 1:12 PM, Reza <re...@yahoo.com.invalid> wrote:

> I found a bug related to the hashmap ordering of keys which could cause
> the wrong pattern to be picked if multiple patterns hit. This effects
> certain jvm architectures, so this could cause the unit tests to fail on
> these architectures. So I updated the release below.
>
>
> ________________________________
>  From: Reza <re...@yahoo.com>
> To: Apache Device Map DEV <de...@incubator.apache.org>
> Sent: Saturday, July 5, 2014 7:52 PM
> Subject: data and java api 1.0 release ready
>
>
>
> Release is ready here for review:
>
> http://www.rezsoft.org/devicemap/
>
> I spent a good bit of time finalizing the java api. I think it came out
> really nice... loaders are all working, exceptions are all correct, and
> performance and accuracy is great.
>
> As for the device data, I went ahead and fixed a few of the problematic
> patterns (ex: Sony X 10 matching on OS X 10). I also added the generic
> fallback patterns to the patch files. This is really important in catching
> generic devices which fall thru the cracks.
>

Re: data and java api 1.0 release ready

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

I found a bug related to the hashmap ordering of keys which could cause the wrong pattern to be picked if multiple patterns hit. This effects certain jvm architectures, so this could cause the unit tests to fail on these architectures. So I updated the release below.


________________________________
 From: Reza <re...@yahoo.com>
To: Apache Device Map DEV <de...@incubator.apache.org> 
Sent: Saturday, July 5, 2014 7:52 PM
Subject: data and java api 1.0 release ready
 


Release is ready here for review:

http://www.rezsoft.org/devicemap/

I spent a good bit of time finalizing the java api. I think it came out really nice... loaders are all working, exceptions are all correct, and performance and accuracy is great.

As for the device data, I went ahead and fixed a few of the problematic patterns (ex: Sony X 10 matching on OS X 10). I also added the generic fallback patterns to the patch files. This is really important in catching generic devices which fall thru the cracks.