Menu
▾
▴
geotools-devel
|
From: Michael B. <mic...@gm...> - 2010-03-13 05:08:16
|
Hello all, In the thread "gt-postgis + hibernate-spatial pom dependency conflict" Andrea wrote: > gt-postgis should not be used anymore, we don't maintain it anymore > since its replacement, gt-jdbc-postgis, has reached maturity. > I keep on forgetting to move it into unsupported land. > There have been a few questions on the user list lately about what it means for a module to be 'unsupported'. Looking at my replies I see explained it as if 'unsupported' means 'incubator'. On the other hand it seems that it can also mean 'place where modules go to die'. What about having separate directories for these two purposes ? Michael |
|
From: Andrea A. <aa...@op...> - 2010-03-13 07:29:26
|
Michael Bedward ha scritto: > Hello all, > > In the thread "gt-postgis + hibernate-spatial pom dependency conflict" > Andrea wrote: > >> gt-postgis should not be used anymore, we don't maintain it anymore >> since its replacement, gt-jdbc-postgis, has reached maturity. >> I keep on forgetting to move it into unsupported land. >> > > There have been a few questions on the user list lately about what it > means for a module to be 'unsupported'. Looking at my replies I see > explained it as if 'unsupported' means 'incubator'. On the other hand > it seems that it can also mean 'place where modules go to die'. > > What about having separate directories for these two purposes ? Mixed feeling about this. On one side, it's another thing we have to explain. On the other side, it's a clear warning: "someone pick up this module or it's going to die soon". However, in the specific case of the JDBC data stores, it's not like there is any salvation possibility, the module has been replaced and it's going to be removed, end of story. It would be a third, which would be "last step before certain death". There are also a few modules that have been in unsupported forever, and their status is unclear. Think of the pg-versioning module, not good enough to be declared stable, dependend on a module that's going to die, yet with enough interest around it to keep it barely alive. Same goes for the OGR module, that has not even compiled for a lifetime, and now it's back and can compile and we have a story to move it to supported land (once imageio-ext switches to GDAL 1.7.1). So I have the impression that each module in unsupported has kind of its personal story, and the reasons for not being part of supported code are many. Unsupported is at the same time nursery, limbo and cemetery (with the occasional module coming back from the dead). Scary! (which is why we don't release anything from it) :-) Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. |
|
From: Michael B. <mic...@gm...> - 2010-03-13 07:47:46
|
Yes, all good points. I'll edit that into an FAQ entry so we can just point people to it from now on. Michael |
|
From: Jody G. <jod...@gm...> - 2010-03-13 08:16:47
|
I agree with the story aspect! Could we use the pom description to explain what is going on? Jody On 13/03/2010, at 6:28 PM, Andrea Aime wrote: > Michael Bedward ha scritto: >> Hello all, >> >> In the thread "gt-postgis + hibernate-spatial pom dependency conflict" >> Andrea wrote: >> >>> gt-postgis should not be used anymore, we don't maintain it anymore >>> since its replacement, gt-jdbc-postgis, has reached maturity. >>> I keep on forgetting to move it into unsupported land. >>> >> >> There have been a few questions on the user list lately about what it >> means for a module to be 'unsupported'. Looking at my replies I see >> explained it as if 'unsupported' means 'incubator'. On the other hand >> it seems that it can also mean 'place where modules go to die'. >> >> What about having separate directories for these two purposes ? > > Mixed feeling about this. > On one side, it's another thing we have to explain. > On the other side, it's a clear warning: "someone pick up this module > or it's going to die soon". > > However, in the specific case of the JDBC data stores, it's not like > there is any salvation possibility, the module has been replaced and > it's going to be removed, end of story. > > It would be a third, which would be "last step before certain death". > > There are also a few modules that have been in unsupported forever, > and their status is unclear. Think of the pg-versioning module, > not good enough to be declared stable, dependend on a module > that's going to die, yet with enough interest around it to keep > it barely alive. Same goes for the OGR module, that has not even > compiled for a lifetime, and now it's back and can compile and we > have a story to move it to supported land (once imageio-ext switches > to GDAL 1.7.1). > > So I have the impression that each module in unsupported has kind > of its personal story, and the reasons for not being part of supported > code are many. > > Unsupported is at the same time nursery, limbo and cemetery (with > the occasional module coming back from the dead). > Scary! (which is why we don't release anything from it) :-) > > Cheers > Andrea > > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel |
|
From: Andrea A. <aa...@op...> - 2010-03-13 10:50:43
|
Jody Garnett ha scritto: > I agree with the story aspect! Could we use the pom description to explain what is going on? Process process... we already have enough that it's hard to make it respected. If people want to note somewhere about the history of a module that's fine, but I would leave it up to module maintainers. I personally would go for old fashioned README files, but again, up to the maintainer. People interested in unsupported module can just also go and ask. Or be creative and do an "svn log" seeing who worked on it, when, and what he did (assuming people use self explanatory commit messages, which thankfully often happens around here) Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. |
|
From: Simone G. <sim...@ge...> - 2010-03-13 11:58:45
|
Suggestion, what if we separate concerns here and we split modules that are dying or that are zombies from modules that are being worked on or close to be supported? The apache foundation does something similar, we could use a similar approach. It might probably be easier to explain why something is part of "dormant" or "legacy" rather than mixing up things that are leaving with things that are entering like now. We could do: - incubator, about to enter - dormant, unsupported, not yet to be removed - legacy. unsopported, about to be removed In the end it just means to split unsupported. Simone. ------------------------------------------------------- Ing. Simone Giannecchini GeoSolutions S.A.S. Founder - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini http://twitter.com/simogeo ------------------------------------------------------- On Sat, Mar 13, 2010 at 11:50 AM, Andrea Aime <aa...@op...> wrote: > Jody Garnett ha scritto: >> I agree with the story aspect! Could we use the pom description to explain what is going on? > > Process process... we already have enough that it's hard > to make it respected. > > If people want to note somewhere about the history of a > module that's fine, but I would leave it up to module maintainers. > > I personally would go for old fashioned README files, but again, > up to the maintainer. > People interested in unsupported module can just also go and ask. > Or be creative and do an "svn log" seeing who worked on it, when, > and what he did (assuming people use self explanatory commit messages, > which thankfully often happens around here) > > Cheers > Andrea > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > |
|
From: Justin D. <jde...@op...> - 2010-03-19 13:01:34
|
On 3/13/10 6:58 AM, Simone Giannecchini wrote: > Suggestion, > what if we separate concerns here and we split modules that are dying > or that are zombies from modules that are being worked on or close to > be supported? > The apache foundation does something similar, we could use a similar approach. > > It might probably be easier to explain why something is part of > "dormant" or "legacy" rather than mixing up things that are leaving > with things that are entering like now. > > We could do: > > - incubator, about to enter > - dormant, unsupported, not yet to be removed > - legacy. unsopported, about to be removed > > In the end it just means to split unsupported. +1 to this idea. There is definitely need of an incubator space since they should really be treated differently from unsupported. I would be happy leaving unsupported as is but adding an incubator section for new modules and experimentation. > > Simone. > ------------------------------------------------------- > Ing. Simone Giannecchini > GeoSolutions S.A.S. > Founder - Software Engineer > Via Carignoni 51 > 55041 Camaiore (LU) > Italy > > phone: +39 0584983027 > fax: +39 0584983027 > mob: +39 333 8128928 > > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.linkedin.com/in/simonegiannecchini > http://twitter.com/simogeo > > ------------------------------------------------------- > > > > On Sat, Mar 13, 2010 at 11:50 AM, Andrea Aime<aa...@op...> wrote: >> Jody Garnett ha scritto: >>> I agree with the story aspect! Could we use the pom description to explain what is going on? >> >> Process process... we already have enough that it's hard >> to make it respected. >> >> If people want to note somewhere about the history of a >> module that's fine, but I would leave it up to module maintainers. >> >> I personally would go for old fashioned README files, but again, >> up to the maintainer. >> People interested in unsupported module can just also go and ask. >> Or be creative and do an "svn log" seeing who worked on it, when, >> and what he did (assuming people use self explanatory commit messages, >> which thankfully often happens around here) >> >> Cheers >> Andrea >> >> -- >> Andrea Aime >> OpenGeo - http://opengeo.org >> Expert service straight from the developers. >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Geotools-devel mailing list >> Geo...@li... >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. |
|
From: Michael B. <mic...@gm...> - 2010-03-19 14:06:51
|
On 20 March 2010 00:01, Justin Deoliveira wrote: > +1 to this idea. There is definitely need of an incubator space since > they should really be treated differently from unsupported. I would be > happy leaving unsupported as is but adding an incubator section for new > modules and experimentation. I quite like this idea too and I think users would find it easier to work with. Michael |
|
From: Simone G. <sim...@ge...> - 2010-03-19 17:51:34
|
now, should we request a formal proposal to investigate this better or do you suggest a more agile apporach? I am assuming anyway, that whatever we will do, will happen on trunk. Simone. ------------------------------------------------------- Ing. Simone Giannecchini GeoSolutions S.A.S. Founder - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini http://twitter.com/simogeo ------------------------------------------------------- On Fri, Mar 19, 2010 at 3:06 PM, Michael Bedward <mic...@gm...> wrote: > On 20 March 2010 00:01, Justin Deoliveira wrote: >> +1 to this idea. There is definitely need of an incubator space since >> they should really be treated differently from unsupported. I would be >> happy leaving unsupported as is but adding an incubator section for new >> modules and experimentation. > > I quite like this idea too and I think users would find it easier to work with. > > Michael > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > |
|
From: Jody G. <jod...@gm...> - 2010-03-20 01:56:27
|
Could we put this off until right before an actual trunk release? Or we may wish to do this for both 2.6.x and trunk in one go (in order to have an easier time applying patches). There seems to be agreement on the email list here that it is a worthwhile change. Should probably still make a proposal. Jody On 20/03/2010, at 4:51 AM, Simone Giannecchini wrote: > now, should we request a formal proposal to investigate this better or > do you suggest a more agile apporach? > I am assuming anyway, that whatever we will do, will happen on trunk. > > Simone. > ------------------------------------------------------- > Ing. Simone Giannecchini > GeoSolutions S.A.S. > Founder - Software Engineer > Via Carignoni 51 > 55041 Camaiore (LU) > Italy > > phone: +39 0584983027 > fax: +39 0584983027 > mob: +39 333 8128928 > > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.linkedin.com/in/simonegiannecchini > http://twitter.com/simogeo > > ------------------------------------------------------- > > > > On Fri, Mar 19, 2010 at 3:06 PM, Michael Bedward > <mic...@gm...> wrote: >> On 20 March 2010 00:01, Justin Deoliveira wrote: >>> +1 to this idea. There is definitely need of an incubator space since >>> they should really be treated differently from unsupported. I would be >>> happy leaving unsupported as is but adding an incubator section for new >>> modules and experimentation. >> >> I quite like this idea too and I think users would find it easier to work with. >> >> Michael >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Geotools-devel mailing list >> Geo...@li... >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel |
|
From: Simone G. <sim...@ge...> - 2010-03-22 23:30:32
|
trunk release? Can you please clarify? I would suggest to do this asap, it does not look like it can represent a big impediment for patches to me. Simone. ------------------------------------------------------- Ing. Simone Giannecchini GeoSolutions S.A.S. Founder - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini http://twitter.com/simogeo ------------------------------------------------------- On Sat, Mar 20, 2010 at 2:55 AM, Jody Garnett <jod...@gm...> wrote: > Could we put this off until right before an actual trunk release? Or we may wish to do this for both 2.6.x and trunk in one go (in order to have an easier time applying patches). > > There seems to be agreement on the email list here that it is a worthwhile change. Should probably still make a proposal. > > Jody > > On 20/03/2010, at 4:51 AM, Simone Giannecchini wrote: > >> now, should we request a formal proposal to investigate this better or >> do you suggest a more agile apporach? >> I am assuming anyway, that whatever we will do, will happen on trunk. >> >> Simone. >> ------------------------------------------------------- >> Ing. Simone Giannecchini >> GeoSolutions S.A.S. >> Founder - Software Engineer >> Via Carignoni 51 >> 55041 Camaiore (LU) >> Italy >> >> phone: +39 0584983027 >> fax: +39 0584983027 >> mob: +39 333 8128928 >> >> >> http://www.geo-solutions.it >> http://geo-solutions.blogspot.com/ >> http://www.linkedin.com/in/simonegiannecchini >> http://twitter.com/simogeo >> >> ------------------------------------------------------- >> >> >> >> On Fri, Mar 19, 2010 at 3:06 PM, Michael Bedward >> <mic...@gm...> wrote: >>> On 20 March 2010 00:01, Justin Deoliveira wrote: >>>> +1 to this idea. There is definitely need of an incubator space since >>>> they should really be treated differently from unsupported. I would be >>>> happy leaving unsupported as is but adding an incubator section for new >>>> modules and experimentation. >>> >>> I quite like this idea too and I think users would find it easier to work with. >>> >>> Michael >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> Geotools-devel mailing list >>> Geo...@li... >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Geotools-devel mailing list >> Geo...@li... >> https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > |
|
From: Jody G. <jod...@gm...> - 2010-03-23 03:01:53
|
> trunk release? When we eventually release a 2.7-M1 or something. > Can you please clarify? I would suggest to do this asap, it does not > look like it can represent a big impediment for patches to me. So the other alternative (in order to easily apply patches to both) would be to perform the move to 2.6.x and trunk. Jody > Simone. > ------------------------------------------------------- > Ing. Simone Giannecchini > GeoSolutions S.A.S. > Founder - Software Engineer > Via Carignoni 51 > 55041 Camaiore (LU) > Italy > > phone: +39 0584983027 > fax: +39 0584983027 > mob: +39 333 8128928 > > > http://www.geo-solutions.it > http://geo-solutions.blogspot.com/ > http://www.linkedin.com/in/simonegiannecchini > http://twitter.com/simogeo > > ------------------------------------------------------- > > > > On Sat, Mar 20, 2010 at 2:55 AM, Jody Garnett <jod...@gm...> wrote: >> Could we put this off until right before an actual trunk release? Or we may wish to do this for both 2.6.x and trunk in one go (in order to have an easier time applying patches). >> >> There seems to be agreement on the email list here that it is a worthwhile change. Should probably still make a proposal. >> >> Jody >> >> On 20/03/2010, at 4:51 AM, Simone Giannecchini wrote: >> >>> now, should we request a formal proposal to investigate this better or >>> do you suggest a more agile apporach? >>> I am assuming anyway, that whatever we will do, will happen on trunk. >>> >>> Simone. >>> ------------------------------------------------------- >>> Ing. Simone Giannecchini >>> GeoSolutions S.A.S. >>> Founder - Software Engineer >>> Via Carignoni 51 >>> 55041 Camaiore (LU) >>> Italy >>> >>> phone: +39 0584983027 >>> fax: +39 0584983027 >>> mob: +39 333 8128928 >>> >>> >>> http://www.geo-solutions.it >>> http://geo-solutions.blogspot.com/ >>> http://www.linkedin.com/in/simonegiannecchini >>> http://twitter.com/simogeo >>> >>> ------------------------------------------------------- >>> >>> >>> >>> On Fri, Mar 19, 2010 at 3:06 PM, Michael Bedward >>> <mic...@gm...> wrote: >>>> On 20 March 2010 00:01, Justin Deoliveira wrote: >>>>> +1 to this idea. There is definitely need of an incubator space since >>>>> they should really be treated differently from unsupported. I would be >>>>> happy leaving unsupported as is but adding an incubator section for new >>>>> modules and experimentation. >>>> >>>> I quite like this idea too and I think users would find it easier to work with. >>>> >>>> Michael >>>> >>>> ------------------------------------------------------------------------------ >>>> Download Intel® Parallel Studio Eval >>>> Try the new software tools for yourself. Speed compiling, find bugs >>>> proactively, and fine-tune applications for parallel performance. >>>> See why Intel Parallel Studio got high marks during beta. >>>> http://p.sf.net/sfu/intel-sw-dev >>>> _______________________________________________ >>>> Geotools-devel mailing list >>>> Geo...@li... >>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>>> >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> Geotools-devel mailing list >>> Geo...@li... >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Geotools-devel mailing list >> Geo...@li... >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > |
|
From: Andrea A. <aa...@op...> - 2010-03-23 09:24:59
|
Jody Garnett ha scritto: >> trunk release? > > When we eventually release a 2.7-M1 or something. > >> Can you please clarify? I would suggest to do this asap, it does not >> look like it can represent a big impediment for patches to me. > > So the other alternative (in order to easily apply patches to both) > would be to perform the move to 2.6.x and trunk. Since the contents of "unsupported" are not released anyways, I personally don't see a problem with doing the split on 2.6.x as well. Just my 2 cents Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. |
|
From: Ben Caradoc-D. <Ben...@cs...> - 2010-03-23 09:48:05
|
On 23/03/10 17:24, Andrea Aime wrote: > Since the contents of "unsupported" are not released anyways, Except app-schema ... -- Ben Caradoc-Davies <Ben...@cs...> Software Engineering Team Leader CSIRO Earth Science and Resource Engineering Australian Resources Research Centre |
|
From: Michael B. <mic...@gm...> - 2010-03-23 01:02:46
|
On 23 March 2010 10:30, Simone Giannecchini wrote: > > Can you please clarify? I would suggest to do this asap, it does not > look like it can represent a big impediment for patches to me. > I'd like to see this happen now on trunk as well. The following is based on a quick look at the svn logs and some guesses. Please edit... Incubator (active development) ======================= app-schema caching coverage-experiment coverageio coverageio-netcdf coveragetools directory epsg-h2 idl-process jai-tools jdbc-ng matfile5 ogr process swing wfs Dormant (keep for the moment) ======================= epsg-oracle geometry geometryless gpx2 jts-wrapper mysql oracle-spatial postgis-versioned shapefile-renderer sql-datastore wps Legacy (to be removed) ================== edigeo example vpf widgets-swing widgets-swing-pending |
|
From: Ben Caradoc-D. <Ben...@cs...> - 2010-03-23 02:20:46
|
On 23/03/10 09:02, Michael Bedward wrote: > I'd like to see this happen now on trunk as well. The following is > based on a quick look at the svn logs and some guesses. Please edit... > > Incubator (active development) > ======================= > app-schema That is correct. We will probably migrate the best bits to extension some time this year. I would like to keep some cruftier submodules in unsupported/dormant. -- Ben Caradoc-Davies <Ben...@cs...> Software Engineering Team Leader CSIRO Earth Science and Resource Engineering Australian Resources Research Centre |
|
From: Andrea A. <aa...@op...> - 2010-03-23 09:23:53
|
Michael Bedward ha scritto:
> On 23 March 2010 10:30, Simone Giannecchini wrote:
>> Can you please clarify? I would suggest to do this asap, it does not
>> look like it can represent a big impediment for patches to me.
>>
>
> I'd like to see this happen now on trunk as well. The following is
> based on a quick look at the svn logs and some guesses. Please edit...
>
> Incubator (active development)
> =======================
> app-schema
> caching
> coverage-experiment
> coverageio
> coverageio-netcdf
> coveragetools
> directory
> epsg-h2
> idl-process
> jai-tools
> jdbc-ng
> matfile5
> ogr
> process
> swing
> wfs
>
> Dormant (keep for the moment)
> =======================
> epsg-oracle
> geometry
> geometryless
> gpx2
> jts-wrapper
> mysql
> oracle-spatial
> postgis-versioned
> shapefile-renderer
> sql-datastore
> wps
>
> Legacy (to be removed)
> ==================
> edigeo
> example
> vpf
> widgets-swing
> widgets-swing-pending
A few corrections:
- edigeo afaik is used by Camp2Camp in their
Talend ETL product so it may be more
of dormant, but I may be wrong
- mysql, oracle-spatial and also postgis (which
is still in plugins) should become legacy
on trunk. But probably not on 2.6.x
(should not affect merges, there is no
development going on for those modules)
I have doubts about the coverage* modules,
I have the feeling they are more or
legacy material, but I'll let Simone and
Daniele speak about them.
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
|
|
From: Andrea A. <aa...@op...> - 2010-03-23 09:51:10
|
Ben Caradoc-Davies ha scritto: > On 23/03/10 17:24, Andrea Aime wrote: >> Since the contents of "unsupported" are not released anyways, > > Except app-schema ... It is part of the GeoTools binary release despite being in unsupported? That's irregular... Cheers Andrea -- Andrea Aime OpenGeo - http://opengeo.org Expert service straight from the developers. |
|
From: Jody G. <jod...@gm...> - 2010-03-23 10:16:37
|
I deploy to the maven repository; but do not include in the binary download. On Tue, Mar 23, 2010 at 8:50 PM, Andrea Aime <aa...@op...> wrote: > Ben Caradoc-Davies ha scritto: >> >> On 23/03/10 17:24, Andrea Aime wrote: >>> >>> Since the contents of "unsupported" are not released anyways, >> >> Except app-schema ... > > It is part of the GeoTools binary release despite being > in unsupported? That's irregular... > > Cheers > Andrea > > > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > |
|
From: Simone G. <sim...@ge...> - 2010-03-23 17:55:00
|
On Tue, Mar 23, 2010 at 2:02 AM, Michael Bedward <mic...@gm...> wrote: > On 23 March 2010 10:30, Simone Giannecchini wrote: >> >> Can you please clarify? I would suggest to do this asap, it does not >> look like it can represent a big impediment for patches to me. >> > > I'd like to see this happen now on trunk as well. The following is > based on a quick look at the svn logs and some guesses. Please edit... > > Incubator (active development) > ======================= > app-schema > caching > coverage-experiment > coverageio > coverageio-netcdf I would move this two to legacy > coveragetools > directory > epsg-h2 > idl-process > jai-tools > jdbc-ng > matfile5 > ogr > process > swing > wfs > > Dormant (keep for the moment) > ======================= > epsg-oracle > geometry > geometryless > gpx2 > jts-wrapper > mysql > oracle-spatial > postgis-versioned > shapefile-renderer > sql-datastore > wps > > Legacy (to be removed) > ================== > edigeo > example > vpf > widgets-swing > widgets-swing-pending > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > |
|
From: Simone G. <sim...@ge...> - 2010-03-23 17:55:34
|
new list Incubator (active development) ======================= app-schema caching coverage-experiment coveragetools directory epsg-h2 idl-process jai-tools jdbc-ng matfile5 ogr process swing wfs Dormant (keep for the moment) ======================= epsg-oracle geometry geometryless gpx2 jts-wrapper mysql oracle-spatial postgis-versioned shapefile-renderer sql-datastore wps Legacy (to be removed) ================== coverageio coverageio-netcdf edigeo example vpf widgets-swing widgets-swing-pending Simone. ------------------------------------------------------- Ing. Simone Giannecchini GeoSolutions S.A.S. Founder - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini http://twitter.com/simogeo ------------------------------------------------------- On Tue, Mar 23, 2010 at 6:54 PM, Simone Giannecchini <sim...@ge...> wrote: > On Tue, Mar 23, 2010 at 2:02 AM, Michael Bedward > <mic...@gm...> wrote: >> On 23 March 2010 10:30, Simone Giannecchini wrote: >>> >>> Can you please clarify? I would suggest to do this asap, it does not >>> look like it can represent a big impediment for patches to me. >>> >> >> I'd like to see this happen now on trunk as well. The following is >> based on a quick look at the svn logs and some guesses. Please edit... >> >> Incubator (active development) >> ======================= >> app-schema >> caching >> coverage-experiment > >> coverageio >> coverageio-netcdf > > I would move this two to legacy > > >> coveragetools >> directory >> epsg-h2 >> idl-process >> jai-tools >> jdbc-ng >> matfile5 >> ogr >> process >> swing >> wfs >> >> Dormant (keep for the moment) >> ======================= >> epsg-oracle >> geometry >> geometryless >> gpx2 >> jts-wrapper >> mysql >> oracle-spatial >> postgis-versioned >> shapefile-renderer >> sql-datastore >> wps >> >> Legacy (to be removed) >> ================== >> edigeo >> example >> vpf >> widgets-swing >> widgets-swing-pending >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Geotools-devel mailing list >> Geo...@li... >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > |
|
From: Michael B. <mic...@gm...> - 2010-03-24 00:38:12
|
New new list... Incubator (active development) ======================= app-schema caching coverage-experiment coveragetools directory epsg-h2 idl-process jai-tools jdbc-ng matfile5 ogr process swing wfs Dormant (keep for the moment) ======================= edigeo epsg-oracle geometry geometryless gpx2 jts-wrapper mysql (on 2.6.x) oracle-spatial (on 2.6.x) postgis (2.6.x) postgis-versioned (on 2.6.x) shapefile-renderer sql-datastore wps Legacy (to be removed) ================== coverageio coverageio-netcdf example mysql (on trunk) oracle-spatial (on trunk) postgis (on trunk) postgis-versioned (on trunk) vpf widgets-swing widgets-swing-pending |
|
From: Michael B. <mic...@gm...> - 2010-05-10 02:32:58
|
Hi all, Just bumping this discussion from March about splitting up unsupported, following Ben's comment about issues with these modules and the idea of publishing GeoTools to Maven Central. Michael On 24 March 2010 10:31, Michael Bedward <mic...@gm...> wrote: > New new list... > > Incubator (active development) > ======================= > app-schema > caching > coverage-experiment > coveragetools > directory > epsg-h2 > idl-process > jai-tools > jdbc-ng > matfile5 > ogr > process > swing > wfs > > Dormant (keep for the moment) > ======================= > edigeo > epsg-oracle > geometry > geometryless > gpx2 > jts-wrapper > mysql (on 2.6.x) > oracle-spatial (on 2.6.x) > postgis (2.6.x) > postgis-versioned (on 2.6.x) > shapefile-renderer > sql-datastore > wps > > Legacy (to be removed) > ================== > > coverageio > coverageio-netcdf > example > mysql (on trunk) > oracle-spatial (on trunk) > postgis (on trunk) > postgis-versioned (on trunk) > vpf > widgets-swing > widgets-swing-pending > |
|
From: Simone G. <sim...@ge...> - 2010-05-10 05:13:52
|
Ciao Michaek, do you have a plan for this? Simone. ------------------------------------------------------- Ing. Simone Giannecchini GeoSolutions S.A.S. Founder - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob: +39 333 8128928 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini http://twitter.com/simogeo ------------------------------------------------------- On Mon, May 10, 2010 at 4:32 AM, Michael Bedward <mic...@gm...> wrote: > Hi all, > > Just bumping this discussion from March about splitting up > unsupported, following Ben's comment about issues with these modules > and the idea of publishing GeoTools to Maven Central. > > Michael > > On 24 March 2010 10:31, Michael Bedward <mic...@gm...> wrote: >> New new list... >> >> Incubator (active development) >> ======================= >> app-schema >> caching >> coverage-experiment >> coveragetools >> directory >> epsg-h2 >> idl-process >> jai-tools >> jdbc-ng >> matfile5 >> ogr >> process >> swing >> wfs >> >> Dormant (keep for the moment) >> ======================= >> edigeo >> epsg-oracle >> geometry >> geometryless >> gpx2 >> jts-wrapper >> mysql (on 2.6.x) >> oracle-spatial (on 2.6.x) >> postgis (2.6.x) >> postgis-versioned (on 2.6.x) >> shapefile-renderer >> sql-datastore >> wps >> >> Legacy (to be removed) >> ================== >> >> coverageio >> coverageio-netcdf >> example >> mysql (on trunk) >> oracle-spatial (on trunk) >> postgis (on trunk) >> postgis-versioned (on trunk) >> vpf >> widgets-swing >> widgets-swing-pending >> > > ------------------------------------------------------------------------------ > > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > |
|
From: Michael B. <mic...@gm...> - 2010-05-10 05:53:50
|
Hi Simone, I confess that it had fallen out the back of my head until I saw Ben's reply to Jody about the problem of some unsupported modules not meeting Maven Central criteria. I guess the most useful thing to do is for me to draft a proposal. Michael On 10 May 2010 15:13, Simone Giannecchini wrote: > Ciao Michaek, > do you have a plan for this? > > Simone. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X