You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.fr> on 2012/10/08 18:26:18 UTC
Back to metadata soon
I realize that I committed lot of utility classes recently and not much
geographic stuff yet, sorry for that...
Unless I forgot some aspects, there is about 3 last classes I would like
to commit in the utility module, and then I would be back to metadata.
There is also some other utility classes for which there is no immediate
use in metadata, but could be of interest (and would be needed later
anyway). For example an AngleFormat class (an implementation of
java.text.Format), and an other class for formatting tables. Do people
prefer to hold on for a while on the utility module until those classes
are needed, or is it okay to port them anyway (because they are easy to
port)?
Martin
Re: Android branch?
Posted by Peter K <pe...@yahoo.de>.
Hi Martin,
>> isn't the jdk6 branch sufficient? or shouldn't it be a goal of such a
>> branch to be android compatible?
>
> The Android API is a subset of the JDK6 API. For example the Android
> branch would have all JAXB annotations removed (at least for current
> Android releases). They were no SQL neither prior Android 4; instead
> Google defined its own package for using their embedded SQLite.
>
> Other example: the referencing module relies extensively on affine
> transforms. The JDK branches use java.awt.geom.AffineTransform. But
> the Android API excluded the full Java2D API - instead, they define
> their own Affine transform class. So the Android branch have to use
> the Google flavour of Affine transforms instead than the Java2D one.
Ah, ok I see. In GraphHopper I could handle the Android stuff by putting
the dependencies (only logging) together when packaging, so I could
avoid a separate branch.
In SIS it could be done with sql and jaxb in the same manner but if
android has its own probably hardware boosted geometry package that is
not an option, I guess.
Peter.
Re: Android branch?
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Hello Peter
Le 09/10/12 17:43, Peter K a écrit :
> isn't the jdk6 branch sufficient? or shouldn't it be a goal of such a
> branch to be android compatible?
The Android API is a subset of the JDK6 API. For example the Android
branch would have all JAXB annotations removed (at least for current
Android releases). They were no SQL neither prior Android 4; instead
Google defined its own package for using their embedded SQLite.
Other example: the referencing module relies extensively on affine
transforms. The JDK branches use java.awt.geom.AffineTransform. But the
Android API excluded the full Java2D API - instead, they define their
own Affine transform class. So the Android branch have to use the Google
flavour of Affine transforms instead than the Java2D one.
Martin
Re: Android branch?
Posted by Peter K <pe...@yahoo.de>.
Am 09.10.2012 10:23, schrieb Martin Desruisseaux:
> Le 09/10/12 01:44, Mattmann, Chris A (388J) a écrit :
>> +1 to moving forward, no need to hold off. You are doing great and I
>> don't
>> think there are any objections to the code.
>
> Thanks a lot :-)
>
> I was also considering creating one more branch. But this one would be
> experimental and I don't know if it would survive. Any objection to
> try an "Android" branch derived from the trunk?
isn't the jdk6 branch sufficient? or shouldn't it be a goal of such a
branch to be android compatible?
Peter.
Re: Android branch?
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
No objection on my part! :)
Cheers,
Chris
On Oct 9, 2012, at 1:23 AM, Martin Desruisseaux wrote:
> Le 09/10/12 01:44, Mattmann, Chris A (388J) a écrit :
>> +1 to moving forward, no need to hold off. You are doing great and I don't
>> think there are any objections to the code.
>
> Thanks a lot :-)
>
> I was also considering creating one more branch. But this one would be experimental and I don't know if it would survive. Any objection to try an "Android" branch derived from the trunk?
>
> Martin
>
Android branch?
Posted by Martin Desruisseaux <ma...@geomatys.fr>.
Le 09/10/12 01:44, Mattmann, Chris A (388J) a écrit :
> +1 to moving forward, no need to hold off. You are doing great and I don't
> think there are any objections to the code.
Thanks a lot :-)
I was also considering creating one more branch. But this one would be
experimental and I don't know if it would survive. Any objection to try
an "Android" branch derived from the trunk?
Martin
Re: Back to metadata soon
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hey Martin,
+1 to moving forward, no need to hold off. You are doing great and I don't
think there are any objections to the code.
+1! :)
Cheers,
Chris
On Oct 8, 2012, at 9:26 AM, Martin Desruisseaux wrote:
> I realize that I committed lot of utility classes recently and not much geographic stuff yet, sorry for that...
>
> Unless I forgot some aspects, there is about 3 last classes I would like to commit in the utility module, and then I would be back to metadata.
>
> There is also some other utility classes for which there is no immediate use in metadata, but could be of interest (and would be needed later anyway). For example an AngleFormat class (an implementation of java.text.Format), and an other class for formatting tables. Do people prefer to hold on for a while on the utility module until those classes are needed, or is it okay to port them anyway (because they are easy to port)?
>
> Martin
>