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