Peppe has identified two (2) good opportunities for collaboration, aside from the aspect of library design that I mentioned earlier.
[1] Common file formats. [2] Common plug-in model. These were excellent ideas by Peppe. (I would point out that if Kosmo and OpenJUMP can share file formats, for things like projects, as an example, then we can also share libraries for the maniplation of these file formats at a lower level.) Here is a question for Kosmo. How is their project format file different from the one currently used in OpenJUMP? How have they changed the plug-in framework? Having the answers to those questions would put us on a path to some real discussion about how to preserve compatibility and cooperation in at least these to areas. Good work Peppe? Any comments? The Sunburned Surveyor On Mon, Mar 17, 2008 at 11:55 AM, Giuseppe Aruta <[EMAIL PROTECTED]> wrote: > Dear all, > > while waiting other opinions, I want to give "my 2 > cents" to this discussion. > > I think there is no need to derfine a "long" term > project with the integration of tools from one > softwere to the other. > > If I see the story of Jump and its "sons" and plugins, > I image that the main problem is that Jump software > suffered loosing of compatibility with the former > versions, expecially plugin. > > This happend with Kosmo and OJ, but this is happening > with OJ 1.2 NB if we considerer that, with the new > improvements, many plugin do not work (expecially > Pirol's ones which represent one of the most > specialized OJ "battlefront"). > > I image that a "short" term common project between > Kosmo and OpenJUMP would be to work on a common way to > open/save projects. If Kosmo could open OJ project and > "viceversa" it will give a great benefits for the > user who can switch between the two software and use > what they need. This probabily won't effect on any > other prblem (comatibility/client driven/etc) > > Is it practicable? > > Regards > > Peppe > > > > > Dear Antonio, > > > > I thank you for your comments. It is always good to > > know your (positive) > > perspective on such a colaboration. > > > > stefan > > > > listas schrieb: > > > Hi all. > > > > > > First time, many thanks to Peppe, not only for > > your nice collaboration > > > with Kosmo, but for your interest in find "a > > common area for the > > > development of both brother" (I really like that > > definition). > > > > > > I would like to share some ideas/feeling about > > your comments. > > > > > > As you said, Kosmo is developed by project needs, > > but maybe it is better > > > to explain a little more the meaningful (our > > meaningful) of "project > > > needs and project driven development": > > > > > > Our main objective is not to develop Kosmo itself. > > Our main objetives > > > are the "client driven projects". To be able of > > realize correctly those > > > projects, we need continuously build and improve > > Kosmo. So, about a > > > "strict schedule" (a good subject to analyze), > > this exist, but mainly > > > for those projects. So, strict schedule for Kosmo > > exist only for what > > > is neccesary to carry out our commitment with > > clients. Without clients > > > we could not maintain Kosmo project. We are just > > a small company who > > > think we are able to work and live in a free > > software model, and return > > > to community all we can. > > > > > > About community, Kosmo is not only focused on a > > spanish user community. > > > In fact, in the last 1.2 versión it has been > > translated into italian > > > (thanks to Peppe), russian (thanks to Sergey > > Smirnov), german (thanks to > > > Johannes Sommer), brasilian portuguese (thanks to > > Territoriolivre.net > > > people), baske (thanks to baske administration > > people). Some other new > > > languajes are coming soon (czech, slovak...).. We > > directly maintain > > > both, english and spanish version. > > > > > > As you said, we have an important developmet team, > > because we have > > > client driven projects that let us to maintain it. > > We think other way > > > it is not possible for us to improve and to let > > Kosmo growing. > > > > > > We have translated/included a lot of code/tools > > from > > > OpenJUMP/Jump/DeeJump/Pirol/Sigle projects (and > > other no Jump family > > > utilities). > > > > > > Like some of you we would have liked a better > > cooperation. We still > > > would like it. > > > > > > -Maybe all we (you and us) have been, and will > > continue very busy to do > > > enough work in draw a common way to work together. > > > -Maybe it is not very easy. > > > -Maybe we too could do an additional effort and > > collaborate in help > > > translate and merge OpenJUMP into Kosmo. > > > -Maybe would be neccesary strict schedule only for > > those who need to > > > attend different/external Kosmo project commitment > > (private commitment), > > > and absolutely free to dedicate the time they > > want, when they want for > > > people developing Kosmo itself. In other words, > > none strict schedule > > > for Kosmo itself. > > > > > > About Intevation/LatLon and SkyJUMP team, we think > > it would be a very > > > good opportunity to get a positive synergy between > > us. > > > > > > We are not sure how easy/difficult arrive to this > > objective could be. > > > If we are able to arrive, there will be a new star > > in the GIS world. We > > > are sure walking the road in this way could be > > very exciting. > > > > > > Best regards > > > Antonio Muñoz > > > > > > > > > Sunburned Surveyor escribió: > > >> I must agree with many of the points made by > > Stefan and Michael. I > > >> know the language would be a barrier for me. :] > > >> > > >> I think someone (I can't remember who) looked at > > this issue rather > > >> closely and decided that it would be a huge > > amount of work to > > >> integrate the Kosmo changes into OpenJUMP. > > >> > > >> Having said that, I'm always looking for > > opportunities to share code > > >> with GeoTools, Deegree, Kosmo and others. Paul's > > work on the > > >> DataObjects framework should help with that, as > > it will allow us to > > >> overcome some of the challenges presented by the > > different feature > > >> models. > > >> > > >> I don't know that we need to "merge" Kosmo and > > OpenJUMP. What would > > >> really benefit everyone is if Kosmo and OpenJUMP > > programmers could > > >> develop libraries that could be shared between > > programs. We can do > > >> this by splitting out the lower level compontents > > that could then be > > >> used by different programs. Take, as an example, > > Java code that would > > >> work with TINs. You could separate the code for > > TIN model I/O and > > >> manipulation into a separate API that could be > > used by different > > >> programs, and then build a separate > > program-specific plug-in/user > > >> interface for Kosmo, UDig, and OpenJUMP. > > >> > > >> I think the only obstacle to this type of thing > > is better > > >> communications between projects. I'd love to hear > > suggestions on how > > >> that can be improved. I'm already subscribed to > > the UDig, Deegree, and > > >> GeoTools mailing lists. > > >> > > >> Maybe each project could appoint a volunteer to > > coordinate new > > >> functionality being incorporated into each > > project. Or maybe we try > > >> and host a quarterly online meeting to discuss > > opportunities for > > >> collaboration? > > >> > > >> I think we could accomplish a lot by changing our > > library design to > > >> share low-level components. > > >> > > >> The Sunburned Surveyor > > >> > > >> On Sat, Mar 15, 2008 at 1:26 PM, Michaël Michaud > > >> <[EMAIL PROTECTED]> wrote: > > >> > > >>> Hi, > > >>> > > >>> Kosmo benefits an important developper team, and > > I would have liked a > > >>> better cooperation between OpenJUMP and Kosmo. > > >>> I think the main problem is that kosmo started > > its development from an > > >>> old version of Jump, and when the first > > opensource version of kosmo was > > >>> published, jump and openjump had already made > > good progresses. > > >>> Now, it would be a lot of work to merge all > > openJUMP improvments into > > >>> kosmo (or the opposite). > > >>> I think OpenJUMP lacks development power to > > proceed to a big change like > > >>> integrating all kosmo's improvements or merging > > openjump goodies into > > >>> kosmo's core. > > >>> The way kosmo is driven maybe another > > difficulty (highlighted by > > >>> Stefan), and language and code comments may be > > another difficulty (I did > > >>> not check how kosmo code is documented). > > >>> Other comments from OJ's active developpers ? > > >>> > > >>> my 2 cents > > >>> > > > === message truncated === > > > > Inviato da Yahoo! Mail. > Il servizio di posta con lo spazio illimitato. > http://it.docs.yahoo.com/mail/overview/index.html > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
