On 10 May 2010 16:00, Jody Garnett wrote:
> So Michael I think we need a bit more information:
> - what are the restrictions on publishing to the maven central or sonyatype?
All dependencies of a project published to Central have to also be
available from Central (excepting commercial ones which w
On Mon, May 10, 2010 at 8:00 AM, Jody Garnett wrote:
> Nope this is something that is in the planning stage; welcome to planning
> please enjoy your stay :-)
> So Michael I think we need a bit more information:
> - what are the restrictions on publishing to the maven central or sonyatype?
> - we c
Nope this is something that is in the planning stage; welcome to planning
please enjoy your stay :-)
So Michael I think we need a bit more information:
- what are the restrictions on publishing to the maven central or sonyatype?
- we can marshal our unsupported modules into different piles depend
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
On 10 May 2010 15:35, Simone Giannecchini wrote:
> Well, if you have something in mind, we could reach some consensus on
> the ml and then factor out a proposal.
Ah... I did a quick draft before seeing your reply:
http://docs.codehaus.org/display/GEOTOOLS/Split+up+unsupported+modules
It's not mor
Well, if you have something in mind, we could reach some consensus on
the ml and then factor out a proposal.
I would happy to help as I can to reduce the monster size of
unsupported modules.
Simone.
On Mon, May 10, 2010 at 7:31 AM, Michael Bedward
wrote:
> Hi Simone,
>
> I confess that it had fa
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
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 wrote:
> New new list...
>
> Incubator (active developmen
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
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-wrap
On Tue, Mar 23, 2010 at 2:02 AM, Michael Bedward
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
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 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-sche
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 -
On 23/03/10 17:24, Andrea Aime wrote:
> Since the contents of "unsupported" are not released anyways,
Except app-schema ...
--
Ben Caradoc-Davies
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
-
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 patc
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
> ba
> 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 m
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 migra
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 a
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
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 prop
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 -
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.
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
> ap
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 somethin
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 i
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-p
Yes, all good points. I'll edit that into an FAQ entry so we can just
point people to it from now on.
Michael
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
pr
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
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 h
30 matches
Mail list logo
