Martin Desruisseaux ha scritto:
...
> * Why enabling JAXB and not Hibernate? Because JAXB is bundled
> in Java 6 and used by other Sun technologies around Glassfish,
> while Hibernate annotations would introduce a new dependency.
See, that's a critical point, we have total different opinion
on
In GeoTools 3 where everything is beautiful:
- we reduce the number of modules to 7+/-2
- modules "bulk up"; and work out of the box... they may have some
external structure but they produce a single artifact; and they fold in
the some basic plug-ins...
- stable plug-ins will be included in the a
In GeoTools 3 where everything is beautiful:
- We isolate the schema / feature / model concerns up a level away from
the data access
- We treat schema as a first class object; and we respect it
- We make mappings / joins using a domain specific language with a two
part workflow 1) set up the data m
In GeoTools 3 where everything is beautiful
- We reduce data access to the FeatureSource level; using Java Objects /
Class
- We use a visitor rather than subject people to nested try / catch /
finally
- We focus on formats support; leaving the model police to layer on top
- We provide some hooks
In GeoTools 3 where everything is beautiful:
- JTS 2.0 makes interfaces available
- We make use of Simple Features for GML Interfaces from GeoAPI that put
decent names on the terror that is TansfiniteSet
- We delegate to JTS 2.0 code for the flat world case
- ACuster churns out amazing operations f
In GeoTools 3 where everything is beautiful:
- Expression, Filter, Style, Feature are available as EMF models so I
can edit them and get all the events in a consistent fashion (ie so we
can run a user interface)
-
Check out t
In GeoTools 3 where everything is beautiful:
- We adopt OSGi manifests; existing java apps (not running in an OSGi
container) don't notice; for applications that do (uDig and GeoServer)
Martin can finally hide the utility classes at a package level
- Sun and OSGi kiss and make up and the FactoryS
> For now, it's clear we've to deal with the different approach that
> each project has taken, and two solutions are facing us :
> 1) finding a non-blocking solution that satisfy everybody (it seem's
> annotations could let us enough room for that
This one is hard - because the problem is hard;
> 2) starting with a DVCS system and split everything into alternative
> solutions tainted by each group for it's needs.
It looks like we need two bits of "distribution" to keep GeoTools 3
alive and happy - in the future where everything is beautiful.
- distributed revision control so workgroups
> I think we must go back to reason, calm down and define a long terme
> strategy in order to work all together.
Indeed.
> I'm not efficient enough technically speaking, to give you some
> solutions but I'm sure we're going right to the split if we don't take
> the time to define a strategy a
Martin Desruisseaux wrote:
> Sunburned Surveyor a écrit :
>
>> If GeoTools is an OSGeo project, might we consider using the OSGeo
>> wiki? I realize the migration would be a lot of work, but we could at
>> least start putting new content on an OSGeo GeoTools wiki page.
>>
> I love this idea
Hi Martin; apparently we needed you for this discussion - thanks for the
detailed email.
Martin Desruisseaux wrote:
> I may bring nothing new (the last Adrian's email explain well most of
> my views), but I would like to summarize what I think are the most
> important points:
>
> * We are not r
I just found the following buried in the email thread - thanks for
putting up with us Eclesia; it seems we are all surprised by the JAXB
thing and are now talking about it - a positive move that does not
effect your question :-)
> Styles upgrade and release dates
> So, to sum up :
> - My deadlin
Adrian congratulations for getting this far and thanks for all the hard
work.
Yes, Jody's check list looks pretty accurate.
In my role as OSGeo Graduation rep, I'll go through the graduation
checklist criteria and will be looking for documentation indicating that
you have passed each step. (An
Adrian Custer wrote:
> As you said, one can create DTO objects or use a home built parser framework.
> The annotations are in addition to, not in replacement of anything, merely
> another way to benefit from the same code. So JAXB could be written for
> Filter 1.2, a parser could do Filter 1.0,
I (in Australia) had to bow out when it became a 5am meeting (3am in Perth)
! 7am was theoretically possible in summer, but I found I was on the road
virtually all summer -literally travelling every week but about 3, and when
I was at home family breakfasts came higher priority as the result.
gi
I may bring nothing new (the last Adrian's email explain well most of my
views),
but I would like to summarize what I think are the most important points:
* We are not replacing existing technology. We are enabling a
functionality bundled in Java 6. This is equivalent to adding
"implements
> Martin wants *a* set of annotations for the classes of the modules he
> maintains so that they can be used in frameworks that require and
> leverage those JAXB bindings such as Glassfish. So it seems to make
> sense to let him add a language construct *unless* it impacts on others
> in a negativ
Wot
+1000 Andrea
I think we must go back to reason, calm down and define a long terme
strategy in order to work all together.
I'm not efficient enough technically speaking, to give you some
solutions but I'm sure we're going right to the split if we don't take
the time to define a strat
On Wed, 2008-06-25 at 20:36 +0200, Andrea Aime wrote:
> I would urge everybody to calm down and be pragmatic.
> We can work togheter, but to do so, everybody has to
> understand that it takes patience, and that certain
> decision one make affect others and may waste their
> time, so one should be p
On Wed, 2008-06-25 at 14:48 -0400, Jody Garnett wrote:
> Adrian Custer wrote:
> > As I understand Martin's vision, users are not forced to even think
> > about the annotations, which users can happily ignore. They are
> > annotations, not code, and invisible in the javadoc.
> I am not that worrie
Andrea Aime wrote:
> Let me spend a few words, hoping I don't offend anyone, or at least,
> that I offend everyone in the same measure ;)
Thanks Andrea; and yeah I am afraid my terse emails are more blunt then
usual.
> So please, put aside arguments like "my way or the highway" and try
> to wo
Sorry to get inside this interesting dicussion.
I see we are getting very far on a single line of mine : "we use a jaxb
solution."
May we get back to the main subject, and live this for later ?
If the geotools community is not ready to accept our JaxB implementation
yet, that's not a problem, w
Adrian Custer wrote:
> As I understand Martin's vision, users are not forced to even think
> about the annotations, which users can happily ignore. They are
> annotations, not code, and invisible in the javadoc.
I am not that worried about annotations; except that we want to bind the
same beans
Adrian Custer wrote:
> What we could do would be to construct a series of serious technical
> arguments or worries which could each be assessed on their merit. So
> what are your concerns? Does JAXB prevent you from working in some way?
Here is the article I wrote from a while back:
- http://udig
People, can you take a step back from the monitor
and look at the thread again? It's starting to look
like a kindergarden fight.
Let me spend a few words, hoping I don't offend anyone,
or at least, that I offend everyone in the same measure ;)
We have basically one group of people that orbits aro
I want to be able to point Cameron at the following:
- sample download with the headers all fixed up; a release candidate?
- a list of Jira tasks for each problem we found in the review.txt files
- update the incubation status page to reflect we are ready
I think with those two I would be happy to
On Wed, Jun 25, 2008 at 7:05 PM, Adrian Custer <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-06-25 at 18:06 +0200, Simone Giannecchini wrote:
>> On Wed, Jun 25, 2008 at 5:58 PM, Martin Desruisseaux
>> <[EMAIL PROTECTED]> wrote:
>> > Simone Giannecchini a écrit :
>> >>
>> >> My main concern with using J
Can you try a fresh checkout? I hope we did not screw something up...
Jody
> Hi,
> I'm trying to commit some stuff but I'm having
> troubles with svn access.
> Basically, every attempt at svn ci, but also
> svn up (which is read only) asks me about my
> password, and authentication fails!
>
> Chee
On Wed, 2008-06-25 at 18:06 +0200, Simone Giannecchini wrote:
> On Wed, Jun 25, 2008 at 5:58 PM, Martin Desruisseaux
> <[EMAIL PROTECTED]> wrote:
> > Simone Giannecchini a écrit :
> >>
> >> My main concern with using JAXB and its annotations is that it make
> >> hard if not impossible to use others
Hi,
18h (GMT +2) would be perfect for us, at that time it could be easier
for our team to assist at the meeting.
I can't impose them to be there at 9 pm.
Cheers,
Vincent
Le 25 juin 08 à 17:40, Andrea Aime a écrit :
> Simone Giannecchini ha scritto:
>> I would happy with a sooner IRC meeting
Hi,
I'm trying to commit some stuff but I'm having
troubles with svn access.
Basically, every attempt at svn ci, but also
svn up (which is read only) asks me about my
password, and authentication fails!
Cheers
Andrea
-
Check
On Wed, Jun 25, 2008 at 5:58 PM, Martin Desruisseaux
<[EMAIL PROTECTED]> wrote:
> Simone Giannecchini a écrit :
>>
>> My main concern with using JAXB and its annotations is that it make
>> hard if not impossible to use others technologies like hibernate which
>> can use annotations themselves.
>
>
Simone Giannecchini a écrit :
> My main concern with using JAXB and its annotations is that it make
> hard if not impossible to use others technologies like hibernate which
> can use annotations themselves.
As stated in an earlier email, annotations are fully qualified constructs like
any Java cl
Ciao guys,
reporting some quick thoughts (sory to be a bit silent but I am fully
absorbed by non-geo* work :-) )
On Wed, Jun 25, 2008 at 4:50 PM, Adrian Custer <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-06-25 at 10:23 -0400, Chris Holmes wrote:
>> if we're just talking about bringing in yet
>> an
Simone Giannecchini ha scritto:
> I would happy with a sooner IRC meeting time as well.
>
> My ideal time would probably be somewhere near 18:00 GMT+2 (central europe)
End of the day, yes yes yes! :)
Cheers
Andrea
-
Check ou
I would happy with a sooner IRC meeting time as well.
My ideal time would probably be somewhere near 18:00 GMT+2 (central europe)
Simone.
On Wed, Jun 25, 2008 at 1:17 PM, Jody Garnett <[EMAIL PROTECTED]> wrote:
> Martin Desruisseaux wrote:
>> I would be happy with a sooner IRC meeting too. Othe
Andrea Aime wrote:
> Uh, what is not working ok enough for uDig to use? Will you be
> hammering gt2 so that it becomes good enough? And within which timeframe?
I got a short list; on the 2.5.x page; mostly it comes down to DataStore
QA (surprise) and things like feature events. Since this is no
Hey all,
In speaking with FrankW, here's his take on graduation.
For graduation, GeoTools should speak to their mentor. The
mentor should call for a vote on the Incubator list when they think they
are ready.
This normally takes a week, so I'd encourage getting it
underway soon if the recommen
On Wed, 2008-06-25 at 10:23 -0400, Chris Holmes wrote:
> if we're just talking about bringing in yet
> another XML then I think we need to seriously consider the downside of
> requiring our users to learn another technology.
As I understand Martin's vision, users are not forced to even think
ab
Martin Desruisseaux a écrit :
> We annotate classes on an oportunist
> basis because they already exists - we do not create any data-transfert
> classes
> inside the GeoTools project. This is like adding "implements Serializable" to
> existing classes: must users will never use this serializati
Jody Garnett a écrit :
> But martin I thought JaxB was not up to all the uses we have for XML?
> There is a seperate Java project on JaxB bindings for all the OGC stack;
> I ignored it at the time but perhaps you would be interested?
They are not exclusive. With JAXB annotations, we are basicall
I don't have a problem with the name change to GPX Base, or a Java
package structure that started with a prefix like
org.geotools.gpxbase.
I'm not sure about merging the modules though. They take two
approaches to two different problems. I believe the existing GeoTools
module is more tightly integ
Adrian Custer wrote:
> Hey Jody,
>
> This is a surprising email from you, unusually full of stop energy.
>
Oh? I have talked about JaxB and its limitations before; this is why we
don't use it very much ...
> Could you explain why JAXB annotations are not a solution that fits in
> with what GeoT
I am getting a lot of email on and off list about the range of XML
"solutions" in the geotools library. We do need to bet on a horse and
stick with it. I do understand that JaxB being folded into Java is an
attractive target.
But martin I thought JaxB was not up to all the uses we have for XML?
Jody Garnett a écrit :
> I am worried about the direction you are going Martin; it is one thing
> to have problems with the library moving too slow for Java 6. It is
> another to start looking at tech so you can work on your own private
> branch and not have to interact with the community.
My u
Jody Garnett ha scritto:
> Andrea Aime wrote:
>> Jody, deciding to work on geotools trunk for a course is like a russian
>> roulette, you can see by Hudson that it breaks every other day.
>> I understand that for udig you need that, which is kind of one more
>> reason to branch off to 2.5.x and get
Andrea Aime wrote:
> Jody, deciding to work on geotools trunk for a course is like a russian
> roulette, you can see by Hudson that it breaks every other day.
> I understand that for udig you need that, which is kind of one more
> reason to branch off to 2.5.x and get out of the storm?
>
Agreed;
Martin Desruisseaux wrote:
> Fixed, thanks for spotting that. Its look like that test compilation are
> completly skipped in epsg-oracle module?
>
Yes that is because I am stuck on IdentifiedObject lookup; this is the
last *bug* before the referencing work can be integrated :-)
> Now that we a
See http://gridlock.openplans.org:8080/hudson/job/geotools-trunk/753/changes
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforg
Andrea Aime a écrit :
> Jody Garnett ha scritto:
>
>> johann sorel wrote:
>>
>>> We are using a JaxB solution.
>>>
>>>
>> That better be in your own code base then; you can make use of the
>> plug-in system to use your own implementation of the style objects.
>> StyleFactory at
Jody Garnett a écrit :
> Quick question; so I can understand ... how did you plan to use JaxB?
> Near as I can tell you would need jaxb binding for Filter, Expression
> and GML3? Will you be using the GeoAPI Geometry classes for the GML3
> binding; or morphing down to JTS Geometry objects.
We w
On Wed, 2008-06-25 at 07:21 -0400, Jody Garnett wrote:
> johann sorel wrote:
> > We are using a JaxB solution.
> >
> That better be in your own code base then; you can make use of the
> plug-in system to use your own implementation of the style objects.
> StyleFactory at least is ready for you
Jody Garnett ha scritto:
> johann sorel wrote:
>> We are using a JaxB solution.
>>
> That better be in your own code base then; you can make use of the
> plug-in system to use your own implementation of the style objects.
> StyleFactory at least is ready for you to swap implementations in and
Jody Garnett ha scritto:
...
> Still for today I am looking at trunk broken on a day when I need it to
> work in public. Eclipse has identified that a testMetadataAnnotations()
> method is not going to be able to run since it lacks an XMLStreamWriter
> class. What has changed since last week to
Jody Garnett a écrit :
> Andrea Aime wrote:
>
>> I don't have that issue at all... strage. But I'm on Eclipse 3.4rc4,
>> which may explain the issue.
>>
>>
> Good to know.
>
>> For the record, that XMLStreamWriter interface is part of java6 only,
>> but it seems to be included into s
Jody Garnett a écrit :
> Martin did you miss this one? It seems that some API changes hav emessed
> up the following:
>
> assertTrue("Dummy type", factory.getAuthorityCodes(String.class).isEmpty());
Fixed, thanks for spotting that. Its look like that test compilation are
completly skipped in ep
Jody Garnett wrote:
> johann sorel wrote:
>
>> We are using a JaxB solution.
>>
> That better be in your own code base then; you can make use of the
> plug-in system to use your own implementation of the style objects.
> StyleFactory at least is ready for you to swap implementations in
See http://gridlock.openplans.org:8080/hudson/job/geotools-trunk/752/changes
Changes:
[jgarnett] comment out test that fails on xstream
[jgarnett] account for generics no longer letting non identified objects be
managed by factory authority codes
--
[...
Andrea Aime wrote:
> I don't have that issue at all... strage. But I'm on Eclipse 3.4rc4,
> which may explain the issue.
>
Good to know.
> For the record, that XMLStreamWriter interface is part of java6 only,
> but it seems to be included into stax-api.jar as well (I have that
> in my classpath
Martin did you miss this one? It seems that some API changes hav emessed
up the following:
assertTrue("Dummy type", factory.getAuthorityCodes(String.class).isEmpty());
-
Check out the new SourceForge.net Marketplace.
It's t
Martin Desruisseaux wrote:
> The factory would not make any difference for JAXB. It may enable the usage
> of
> gt-xml module however; I don't know yet.
>
> If JAXB on Java 5 is too much a problem, the proposal is to remove it from
> the
> Java 5 branch and move our (at Geomatys) development to
Jody Garnett a écrit :
> Now we let JAXB slide for metadata because you
> guys were on a deadline; but it is not a solution that fits in with what
> this library is for. Please try again...
It was not a matter of deadline. It was a matter of choosing standard Java
solution everytime they are ap
Jody Garnett ha scritto:
> Andrea Aime wrote:
>> For the record, upgrading jdk 1.5 to the 1.5.0_15 version fixed
>> the issue, now Eclipse is happily compiling those modules.
>>
> I also have problems compiling today - which is sad since my class was
> going to check out and build geotools toda
Jody Garnett a écrit :
> Perhaps when Martin has a Factory for gt-metadata he can make a Java 6
> only plug-in for this stuff? Martin I understand that you would like to
> go to JRE6 but I don't feel we have adjusted to the JRE5 change yet (it
> has not been a year and we have not made a release
johann sorel wrote:
> We are using a JaxB solution.
>
That better be in your own code base then; you can make use of the
plug-in system to use your own implementation of the style objects.
StyleFactory at least is ready for you to swap implementations in and out.
We have the need to make SLD1
Martin Desruisseaux wrote:
> I would be happy with a sooner IRC meeting too. Other opinions?
>
Sounds fine. The only reason we chose this "magic" time was so Australia
could even hope to attend; but our friends there seem to be booked up
with work these days ...
Jody
Jody Garnett a écrit :
> I see the following:
> - ColorMap in coverage; marked as since 2.4 - Martin what is your
> integration plan if anything?
This ColorMap handle implementation details for the need of coverage module.
Should probably be hidden. Is not right now because not yet connected to
Andrea Aime wrote:
> I understand this perfectly, that's why I'm open to other solutions,
> such as branching out 2.5.x even before an RC is out to accomodate
> for this particular situation.
>
Agreed; so when we learn more from both groups we can make some
decisions here. Thanks for getting th
Andrea Aime wrote:
> For the record, upgrading jdk 1.5 to the 1.5.0_15 version fixed
> the issue, now Eclipse is happily compiling those modules.
>
I also have problems compiling today - which is sad since my class was
going to check out and build geotools today.
Upgrading to 1.5.0_15 did not
While the JAXB annotations worked well for Maven and NetBeans, it seems to be a
cause of problems with Eclipse. Maybe there is other platforms where similar
problems popup. Since we can not experiment all of them, I came to the feeling
that it would be easier to:
* Create and maintain a GeoTool
Andrea Aime ha scritto:
> Hi,
> I'm having trouble getting Eclipse (3.4rc4) to properly
> compile GeoTools trunk. This is not happening in Maven.
> What I get is a compile error in the org.geotools.util.package-info.java
> file, which contains only annotations.
> The error message is not very helpf
Jody Garnett ha scritto:
> Andrea Aime wrote:
>> Two proposals:
>> * move StyleAttributeExtractor to rendering, there is
>>actually nothing in gt2 using it besides rendering
>>
> Agreed - move it.
Cool
>> * subclass both of those classes in renderer to take
>>care of the dynamic symbol
johann sorel ha scritto:
...
> I guess I could do the work and come back with an svn diff in one week,
> but if the
> answer is "no", I'll have lost my time for nothing.
Ok, no problem with that, I thought you were already working on it,
that's why I asked.
...
> We are using a JaxB solution.
W
Many questions ...
Andrea Aime a écrit :
> Hi,
> here are a couple of bits about the upgrading styles proposal.
> Generally speaking, the proposal sounds nice, and it's going
> to introduce some very interesting new functionality, so
> I'm favourable, but there are a couple of issues preventing
>
I would be happy with a sooner IRC meeting too. Other opinions?
Martin
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourcefo
Hi,
looking at IRC logs posted by Adrian for the June 23 meeting
I could not avoid seeing the following:
"A lazy meeting for a lazy community.
1) Meeting starts 20 minutes late because everyone waits for someone
else to run things.
2) Most of the PMC doesn't show up enough to even say hello, almo
Jody Garnett ha scritto:
> Andrea Aime wrote:
>> The first one is the size of the change. I would like to avoid seeing
>> massive change of code in the
>> gt2 codebase so close to GeoServer 1.7.x freeze. Can you svn diff you
>> changes and post them somewhere?
>> If they are really really big I'd
Hi,
I'm having trouble getting Eclipse (3.4rc4) to properly
compile GeoTools trunk. This is not happening in Maven.
What I get is a compile error in the org.geotools.util.package-info.java
file, which contains only annotations.
The error message is not very helpful, it just says "java.lang.Object
c
Martin Desruisseaux ha scritto:
> Jody Garnett a écrit :
>> Andrea Aime wrote:
>>> Again, I don't know how many people will be affected
>>> by changes in the changes of the metadata module, so I may be
>>> overestimating the issue.
>>>
>> People do use the metadata classes directly; and have to
I do not known GPX at all, but if the proposed module is at a lower level,
would
the following make sense?
* Call it "gpx-base" (or something like that) instead of "gpx2"
* Refactor "gpx" so that it use "gpx-base"
* Maybe (if the modules are small enough) consider merging them together?
Jody Garnett a écrit :
> Andrea Aime wrote:
>> Again, I don't know how many people will be affected
>> by changes in the changes of the metadata module, so I may be
>> overestimating the issue.
>>
> People do use the metadata classes directly; and have to make use of
> constructors to do it - s
Sunburned Surveyor a écrit :
> If GeoTools is an OSGeo project, might we consider using the OSGeo
> wiki? I realize the migration would be a lot of work, but we could at
> least start putting new content on an OSGeo GeoTools wiki page.
I love this idea, but I have to admit that I'm not a big Codeh
83 matches
Mail list logo
