Hei, I was traveling for a few days.
I would prefer to have everything in the org packages but not removing anything from the "com" package. So a "worst" case is to duplicate the vividsolution classes into the "org" package, but not removing stuff in either of those packages. I sometimes see that still a-lot of people use JUMP for custom development. So for me a) staying more or less backward compatible is important, b) everything new should go into org.openjump, One may not believe in it - but I also don't know if it is necessary in future to make a sync between JUMP (and derivatives) and OpenJUMP again. And then it helps to have things this way. but we are *a group* of maintainers, so this is just my oppinion and the oppinion of the majority counts :) stefan Larry Becker schrieb: > > I think it would be better to have a > org.openjump.core.util.CollectionUtil class, where all new utility > methods dealing with collections could be stored. > > I don't have a problem with that. > > regards, > Larry > > On Wed, Jun 24, 2009 at 4:19 PM, Sunburned Surveyor > <sunburned.surve...@gmail.com <mailto:sunburned.surve...@gmail.com>> wrote: > > Larry wrote: "I think we should look at the vividsolutions code base > as legacy - to be maintained but not extended much." > > I'm OK with that philosphy. It would provide better separation between > Vivid's code and code contributed by the community if copyright or > other legal issues ever come up. > > Larry wrote: "What is it about these two methods that doesn't fit this > paradigm?" > > Both of the methods deal with arrays/collections, but are found in > different classes. I think it would be better to have a > org.openjump.core.util.CollectionUtil class, where all new utility > methods dealing with collections could be stored. > > Ideally, I'd like to see the utility methods packaged in another JAR, > so they could be distributed independently of the other JUMP code, but > that might be asking for too much. My ultimate goal is to have utility > code found in as few places as possible. This will reduce the amount > of duplication. > > I know this thinking rubs against the grain. The consensus of the > majority in the past has been to leave things alone so nothing gets > broken. I'm going to occassionaly push for some refactoring as I work > on my own fork of the code base, but I don't expect any of my changes > to be adopted by the group. They are just suggestions. I wouldn't do > anything until Stefan had a chance to comment, at any rate. > > I dream of a leaner and meaner OpenJUMP. :] > > SS > > > > On Wed, Jun 24, 2009 at 1:38 PM, Larry Becker<becker.la...@gmail.com > <mailto:becker.la...@gmail.com>> wrote: > > I think we should look at the vividsolutions code base as legacy > - to be > > maintained but not extended much. New stuff should generally go into > > openjump.core. What is it about these two methods that doesn't > fit this > > paradigm? > > > > regards, > > Larry > > > > On Wed, Jun 24, 2009 at 2:54 PM, Sunburned Surveyor > > <sunburned.surve...@gmail.com > <mailto:sunburned.surve...@gmail.com>> wrote: > >> > >> There are two (2) methods in the org.openjump.core.apitools that I > >> think we should move to the > >> com.vividsolutions.jump.util.CollectionUtil class. The first > method is > >> the org.openjump.core.apitools.CollectionTools.addArrayToList > method. > >> The second is the > >> org.openjump.core.apitools.FeatureCollectionTools.resizeArray > method. > >> > >> I'm willing to make this move in OpenJUMP and ensure it doesn't > break > >> anything in the core. It will be a little more difficult to ensure > >> things don't break in the PIROL plug-ins. > >> > >> We can certainly leave things the way they are, but I'd really > like to > >> consolidate some of the utility methods we've got laying all around > >> the core. I think this type of maintenance needs to be done at some > >> point, or the stink in our code base will only get worse with time. > >> > >> If someone is willing to help me track down the source code for the > >> PIROL plug-ins, I would be willing to refactor them with the > change as > >> well. > >> > >> Let me know what you guys think. > >> > >> SS > >> > >> > >> > > ------------------------------------------------------------------------------ > >> _______________________________________________ > >> Jump-pilot-devel mailing list > >> Jump-pilot-devel@lists.sourceforge.net > <mailto:Jump-pilot-devel@lists.sourceforge.net> > >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > > > -- > > Larry Becker > > Integrated Systems Analysts, Inc. > > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > <mailto:Jump-pilot-devel@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > <mailto:Jump-pilot-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > -- > Larry Becker > Integrated Systems Analysts, Inc. > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel ------------------------------------------------------------------------------ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
