Re: [JPP-Devel] Moving some org.openjump.core.apitools members to com.vividsolutions.jump.util.CollectionUtil.
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 Beckerbecker.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. -- ___
Re: [JPP-Devel] Moving some org.openjump.core.apitools members to com.vividsolutions.jump.util.CollectionUtil.
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 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 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
Re: [JPP-Devel] Moving some org.openjump.core.apitools members to com.vividsolutions.jump.util.CollectionUtil.
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 Beckerbecker.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 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 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
Re: [JPP-Devel] Moving some org.openjump.core.apitools members to com.vividsolutions.jump.util.CollectionUtil.
Hi SS and Larry, I often feel uncomfortable having a com.vividsolutions tree structure and a org.openjump tree structure (this is confusing, more difficult to find existing code, a risk to create redundant methods...) But this would be much work to refactor all the code, and most developpers seem to accomodate the basic rule to let vividsolutions code base as is. As Larry do, I just wonder what is so special with those methods... Michaël Larry Becker a écrit : 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 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
Re: [JPP-Devel] Moving some org.openjump.core.apitools members to com.vividsolutions.jump.util.CollectionUtil.
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 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 Beckerbecker.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 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 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 -- 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
