I have updated the proposal with notes reflecting Justin's questions:
- http://docs.codehaus.org/display/GEOTOOLS/Refactor+OpenGIS
Please review and vote accordingly; I think I have enough votes to proceed
currently.
I am going to rename to "gt-opengis" now; and will try and look closely at why
gt-api depends on coverage; referencing and metadata. If the opportunity is
there to combine with gt-api I will do so.
Cheers,
Jody
On 05/01/2011, at 9:08 PM, Jody Garnett wrote:
> Thanks Justin; that is what I needed (I have the commit ready but it was
> waiting a few +1 votes).
> The code is considered stable; no api change as the proposal states.
>
> I could not use the gt-api module as it depends on metadata; coverage and
> others. We may be able to refactor once we have all the code in place; but
> not now.
>
> Jody
>
> On 05/01/2011, at 3:31 AM, Justin Deoliveira wrote:
>
>> Apologies for being behind on this proposal. I don't know if anything went
>> forward on this. I don't seen any commits that indicate so. Here is my
>> feedback.
>>
>> * +1 on the idea as a whole of ditching geoapi
>> * +0 on a new opengis module. I personally would rather see them in the
>> geotools api module in favor of adding yet another "infrastructure" module.
>> * +1 on referring to the interfaces as opengis rather than geoapi
>> * -1 on any package name changes. We already burned all our cred when we
>> switched from org.geotools to org.opengis. I don't want to see us do all
>> that again by switching back again.
>>
>> 2c.
>>
>> -Justin
>>
>>
>> On Sun, Jan 2, 2011 at 1:00 AM, Jody Garnett <jody.garn...@gmail.com> wrote:
>> okay so if we can get a number of +1s I can go ahead and commit.
>>
>> Jody
>>
>> On 01/01/2011, at 9:03 PM, Andrea Aime wrote:
>>
>> > On Fri, Dec 31, 2010 at 10:39 PM, Jody Garnett <jody.garn...@gmail.com>
>> > wrote:
>> >> Thanks for the input Simone.
>> >> We cannot merge them with the existing gt-api module due to some circular
>> >> dependencies; but perhaps that could be teased apart.
>> >> We can call it "opengis" to match the package structure; which should
>> >> reduce confusion.
>> >
>> > Sounds like a good name. But I would not merge that with the EMF based
>> > models that are used just for
>> > parsing purposes, I'd put it into core/library instead
>> >
>> > Cheers
>> > Andrea
>> >
>> > -----------------------------------------------------
>> > Ing. Andrea Aime
>> > Senior Software Engineer
>> >
>> > GeoSolutions S.A.S.
>> > Via Poggio alle Viti 1187
>> > 55054 Massarosa (LU)
>> > Italy
>> >
>> > phone: +39 0584962313
>> > fax: +39 0584962313
>> >
>> > http://www.geo-solutions.it
>> > http://geo-solutions.blogspot.com/
>> > http://www.linkedin.com/in/andreaaime
>> > http://twitter.com/geowolf
>> >
>> > -----------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------------
>> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
>> to consolidate database storage, standardize their database environment, and,
>> should the need arise, upgrade to a full multi-node Oracle RAC database
>> without downtime or disruption
>> http://p.sf.net/sfu/oracle-sfdevnl
>> _______________________________________________
>> Geotools-devel mailing list
>> Geotools-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>>
>>
>> --
>> Justin Deoliveira
>> OpenGeo - http://opengeo.org
>> Enterprise support for open source geospatial.
>>
>
------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
