Paolo,
This is some awesome feedback. I will try to write a blog post about this
and some other comments that I have received in the next couple of days.
The Sunburned Surveyor
On 2/16/07, P.Rizzi Ag.Mobilità Ambiente <[EMAIL PROTECTED]> wrote:
Hi Landon,
I read your PDF and found it good, but here follows my idea.
I think there should exist _no_ different code bases at all, there has to
be only _one_ core!!!
I think all organizations developing JUMP versions would be better served
off by sharing efforts
into a common project, instead of dissipating resources to mantain
different code bases,
but they may have a different idea about this.
Anyway it's important to discover why people started independent cores in
the first place!!!
.) Was it because the fuctionalities they needed were _impossible_ to
implement as plugins???
.) Or was it only too _difficult_???
.) Or they simply didn't know better???
To solve the first case and, partially, the second, the common core should
be re-engineered
so that future functionalities will not be _impossible_ or _difficult_ to
implement as plugins.
To solve the third case and, partially, the second, better documentation
should be available
_and_ precise procedures like the ones you outlined.
Summing up, there are four things I think should be done:
1) All special features currently available inside "proprietary" cores
must be
integrated into the common core
2) The common core must be re-engineered so that modifications to it will
not be necessary (almost) anymore
3) All new functionalities must be implemented _only_ as plugins
4) If some modification to the core is _absolutely_ necessary, it has to
be implemented directly by whoever needs it directly inside the common
core
Points 1 and 4 needs an agreement by every involved party and it may not
be feasible at all.
Point 1 and 2 require someone actually working on them, but it will be a
one-time work.
But the beauty of this is Point 3!!! From then on all functionalities will
always be available to every JUMP version!!!
Ok, this is what I think, but it's probably impracticable, so I will
support whatever you decide.
My contribution will be the continued development of the Datastore plugin
(PostGIS and Oracle).
I may also try and look into point 2, at least to solve the I18N question.
I think it's very important, to facilitate plugins compatibility, that even
if we don't come out
with a common core, we ensure that all existing cores support I18N.
Bye
Paolo Rizzi
-----Messaggio originale-----
*Da:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] conto di *Sunburned
Surveyor
*Inviato:* mercoledì 14 febbraio 2007 20.57
*A:* List for discussion of JPP development and use.
*Oggetto:* [JPP-Devel] Collaborative Development Of OpenJUMP
You can find a post about my suggested procedures for collaborative
development of OpenJUMP on my blog:
http://openjump.blogspot.com/
The blog contains a link to the PDF file with the suggested procedures. If
you are developing a JUMP "brand" or are working on OpenJUMP I encourage you
to read it and give me your comments. Please tear into the document. Tell me
what you like, and what you don't like. (Just make sure you tell me why...)
Tell me what will work for your development team, and what won't.
I make a special entreaty to those organizations or companies that are
using JUMP, OpenJUMP, or some flavor of the two programs to produce
commercial products or services to read the document and become involved in
the discussion. I really believe more collaborative development of OpenJUMP
is in your best financial interest.
If we can't get some procedures that are similar in purpose to the ones I
described nailed down I will commit to tracking the differences among JUMP,
OpenJUMP, and the different JUMP "brands". I will also put some time in to
tracking the changes to those code bases. I'm willing to test plug-ins for
compatibility with JUMP and OpenJUMP. But I will need cooperating from the
different development teams, especially if Stefan leaves us in October.
The Sunburned Surveyor
P.S. - Can you guys let me know what JUMP flavors are still active? I'd
like to put together some invitations to a new JPP Development Committee,
but I've lost track of which projects are still active. (I already have
SkyJUMP and Kosmo on my list. What about SIGLE and DeeJUMP? Are they still
active? Are there others I should know about?
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share
your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
