Vincent Heurteaux ha scritto:
> Hi,
>
>> But thanks for the compliments anyways, so is life, someone
>> is enlightened by birth, and someone else is condemned to grovel
>> in the mud for his entire life :(
>> The nice thing about grovelling in the mud is that you don't feel
>> alone, Jesse and Jam
Martin Desruisseaux ha scritto:
> Andrea Aime a écrit :
>> Incorrect. The LiteRenderer was there before in gt2, we learned
>> about Martin's one later (not sure if the renderer still was in
>> SeaGIS or it was in Gt2 already but we did not notice it), and I
>> also spent time trying to integrate it
Hi,
> But thanks for the compliments anyways, so is life, someone
> is enlightened by birth, and someone else is condemned to grovel
> in the mud for his entire life :(
> The nice thing about grovelling in the mud is that you don't feel
> alone, Jesse and James tried to use J2D as well, but you kn
Andrea Aime a écrit :
> Incorrect. The LiteRenderer was there before in gt2, we learned
> about Martin's one later (not sure if the renderer still was in
> SeaGIS or it was in Gt2 already but we did not notice it), and I
> also spent time trying to integrate it into gt2 (SLD styling)
> before givin
johann.sorel ha scritto:
> Andrea Aime a écrit :
>> What's more painful is to have all this duplication around
>> (gtxml vs jaxb, streaming renderer vs go renderer, ...) but it
>> seems like the only way we can collaborate. We need more interfaces
>> so keep everybody working on its implementations
Andrea Aime a écrit :
> What's more painful is to have all this duplication around
> (gtxml vs jaxb, streaming renderer vs go renderer, ...) but it
> seems like the only way we can collaborate. We need more interfaces
> so keep everybody working on its implementations, eventually
> we may end up ha
Thanks for the great discussion today guys :-)
I just have one comment about duplicating work / functionality. I really
like the idea of duplicate renderers - it makes our interfaces so much
stronger.
A quick example is the go-1 renderer; without the go-1 renderer in
recent years (ie two rende
Vincent Heurteaux ha scritto:
> De-facto standards are always good because they reflect what users
> really need, I'm ok with you on that point. But what concern's me is
> thas usually de-facto standards have been developed to achieve a
> particular goal and after, they've been adopted by the m
Jody Garnett a écrit :
>> * We are not replacing existing technology. We are enabling a
>> functionality bundled in Java 6. This is equivalent to "implements
>> java.io.Serializable" to existing classes.
> Not quite; you are binding the java bean to one schema; ie Filter is
> written in Filter
Hello Andrea,
> Vincent, I wasn't meaning literally. I meant Tomcat is important
> and relevant out there, Glassfish much less so, as the numbers
> of users of the two show up. When you say standard you're
> meaning international standards, when I say standard I mean de-facto
> ones.
Yes of cours
Vincent Heurteaux ha scritto:
> Hello guy's
>
> Le 26 juin 08 à 08:54, Andrea Aime a écrit :
>> Glassfish is not the standard, Tomcat is.
> Wrong, JEE is a standard Tomcat is not.
> Glassfish is not a standard but is the reference implementation of JEE5
Vincent, I wasn't meaning literally. I mean
On Thu, Jun 26, 2008 at 2:14 PM, Vincent Heurteaux
<[EMAIL PROTECTED]> wrote:
> Hey don't tempt me, you know, now this is my everyday job :-P
:D
>
>
> Le 26 juin 08 à 13:48, Simone Giannecchini a écrit :
>
>> On Thu, Jun 26, 2008 at 1:43 PM, Vincent Heurteaux
>> <[EMAIL PROTECTED]> wrote:
>>>
>>>
Hey don't tempt me, you know, now this is my everyday job :-P
Le 26 juin 08 à 13:48, Simone Giannecchini a écrit :
> On Thu, Jun 26, 2008 at 1:43 PM, Vincent Heurteaux
> <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>>> With all due respect, you guys are going beyond any possible line
>>> that
>>> we c
On Thu, Jun 26, 2008 at 1:43 PM, Vincent Heurteaux
<[EMAIL PROTECTED]> wrote:
> Hi,
>
>> With all due respect, you guys are going beyond any possible line that
>> we could have drawn.
>> I am not a fun of forks but given your attitude, or at least the one
>> you have shwon lately, go head, I wish y
This is an odd case were both of you are right but are in opposition :-)
I assume you can both see the other persons point of view and why that
is a viable concern for any Java EE project? ie as library needs to work
with both these groups; standards and "defacto" standards.
Cheers,
Jody
Vince
Hi,
> With all due respect, you guys are going beyond any possible line that
> we could have drawn.
> I am not a fun of forks but given your attitude, or at least the one
> you have shwon lately, go head, I wish you all the best.
Great, but I can affirm that you personnaly will not get benefits o
Hello guy's
Le 26 juin 08 à 08:54, Andrea Aime a écrit :
> Glassfish is not the standard, Tomcat is.
Wrong, JEE is a standard Tomcat is not.
Glassfish is not a standard but is the reference implementation of JEE5
> EJB3 is not the standard, Spring and Hibernate are.
Wrong again, Spring and Hibern
As I have already said,
I am not against JAXB at all, I am just asking if you could avoid
annotating core modules because these of these objections:
- we are making tech choice and forcing or at least strongly
suggesting (a user who wants to choose another technology will feel
like taking the wron
Martin Desruisseaux ha scritto:
> * On "Why JAXB and not Hibernate", Andrea said that there
>is standardized annotations that Hibernate recognizes.
>If this is standard, then I'm all for declaring them.
>Are they standard? I mean the annotations AND the
>database schema. With JAXB
Okay, one last try to explain:
* You objected that putting JAXB annotations would
prevent usage of other annotations like Hibernete
WRONG: Each annotations live in their own packages.
* You objected that putting JAXB annotations would prevent
users to extend those classes with their own
Simone Giannecchini a écrit :
> With all due respect, you guys are going beyond any possible line that
> we could have drawn.
Simone, Adrian posted emails about your arguments, and you replied by personal
attacks against him. Adrian has never posted any personal attack against you,
*NEVER*.
> I
With all due respect, you guys are going beyond any possible line that
we could have drawn.
I am not a fun of forks but given your attitude, or at least the one
you have shwon lately, go head, I wish you all the best.
Simone.
On Thu, Jun 26, 2008 at 10:55 AM, Martin Desruisseaux
<[EMAIL PROTECTED
Andrea Aime a écrit :
> and how much time it's taking
> to realize that JODA time is an order of magnitude better
> than standard Java date/time handling just to provide a
> few examples.
Andrea, again you are unfair. Sun is well aware of limitation in date/time
handling for years. There is attem
Andrea Aime ha scritto:
> http://www.google.com/trends?q=tomcat%2C+glassfish%2C+jboss%2C+jetty%2C+weblogic%2C+websphere+
Doh, Andrea Antonello just made me notice that Tomcat
term is too general and catches also the Jet fighter.
I can refine the search like this:
http://www.google.com/trends?q=ap
Andrea Aime ha scritto:
> 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,
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
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
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 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
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
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
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
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
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?
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 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
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
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
55 matches
Mail list logo
