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 course I was understanding your point of view and my lazyness and schedule constraint didn't let me spend the time to devellop a little. 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 majority for it's needs. The problem here is that we're all working on the same toolkit (and my deep wish is to continue that way) with differents goals. If you come and impose a de-facto standard, there will be cases where it probably could'nt achieve particular goals that other groups want to achieve. That's why we've to discuss to find the approaches that fits for all (that's an hard task I recognize it). An example, (it does'nt reflect the reallity), all your work is done with Tomcat in scope, they're de-facto standards and all your "JEE" work is done with spring/hibernate in mind because it works well on Tomcat. Now on our side we're using EJB3, JPA etc ... for our job, we really need something other than Tomcat to play our solutions. Then it becomes evident that we've to find a field of collaboration to work together. Real standards are ok for that, Tomcat 6 is JEE5 compliant but implements only parts of it and Glassfish Is fully JEE compliant. That sayd it becomes clear that we can collaborate using JEE standard for the common part, and live our own life for the rest. Standards have been done from the begining to give a solution for every use cases you could meet. The direct consequence of that is that it' a mess to follow when you've something simple or realy specific to achieve, but it could be usefull when like here, differents people with differents goals have to deal with the same code base. In that way I think standards are really important for GT, an hear me, I'm speaking about standards not SUN at all. For those reasons, I think GeoAPI and JSR are really important for us because it could cover every use cases we can meet, and give us the opportunity to work together and harden our toolkit. Concerning Sun, the fact is that they're leading a lot of JSR and doing reference implementations, that's why we're using a lot of it's technology, but we're totally open using JSR not leaded by Sun, JSR 275 is an example (ok Martin is on the commitee, but fortunately for us he's not a Sun employee :-) ). I believe that OSGI will be a key technology in the future, it has it's JSR (291 if google serve's me well :) ), and is not leaded by Sun. Don't think we're norrow-minded and applying sun's technology because it's sun, but it's true we're using as much as possible Java Specification Requests. Cheers, Vincent > > >>> EJB3 is not the standard, Spring and Hibernate are. >> Wrong again, Spring and Hibernate are products from one company for >> each, and architecture concepts do not come at the begining from a >> diversified expert group. >> Standards are not about Sun or whatever, they're technology that >> come from experts comming from differents univers and need a >> technology tha rule them all. > > Here is the point were we disagree. Any worthwhile implementation from > my point of view comes from the ground up and has a vibrant community > of developers and users, it's alive, reacts to the needs of the > developers and users quickly. > If it happens it implement an international standard more power to > them, > but that's not what I'm looking for in general when I implement new > software. > > If all of a sudden all the open source community around Java > vanished I would switch to another language right away (a language > that has a vibrant community behind it, such as python). > > Cheers > Andrea > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
