But how does building help? Eclipse will show you if you have introduce a compilation error. You can run it without building to test changes. When it fails to build, it only exposes a problem with the build process, which is usually fixed by adding whatever library you are now referencing.
Incidentally, I believe you are "tilting at windmills" in trying to separate the GUI from the application in JUMP. One of the things that makes JUMP great is the tight (almost unprecedented) integration between the GUI and the application. If you do manage to separate them somehow, you will inevitably lose some of that user-friendliness that makes JUMP the program that it is. You might end up with a nice GIS, but it won't be JUMP-like. regards, Larry On Tue, Dec 30, 2008 at 1:14 PM, Sunburned Surveyor < sunburned.surve...@gmail.com> wrote: > Larry wrote: "Maybe this is a silly question, but why do you build at all?" > > Based on my past experiences none of your questions are silly, and > they usually expose flaws in my reasoning. > > I will likely build after most changes to make sure that things still > work. One personal challenge I have with programming OJ's core is a > lack of a comprehensive unit testing suite. Of course, some of the > binding between the programs model and GUI makes this unit testing a > challenge to begin with, and I am hoping to fix that. > > So the short answer to your question is: I will build the core with my > changes incrementally to make sure it still works. > > I realize I can still miss some bugs, but without a comprehensive test > suite, I don't know that there is another option. > > I pretty sure that their will be problems getting everyone to approve > my refactorings in the core, so I think a separate "branch" of the > core will be needed. It doesn't really matter to me if this branch is > in the JPP SVN or in the SurveyOS SVN. Maybe SVN has a built-in > feature that will handle my problem, that is part of the reason I > thought I'd ask you guys before I cooked something up. > > I bought the Apress book on Subversion, but it hasn't arrived yet. :] > > SS > > On Tue, Dec 30, 2008 at 11:00 AM, Larry Becker <becker.la...@gmail.com> > wrote: > > Maybe this is a silly question, but why do you build at all? It isn't > like > > you are going to distribute every iteration and change. > > > > Larry > > > > On Tue, Dec 30, 2008 at 12:51 PM, Sunburned Surveyor > > <sunburned.surve...@gmail.com> wrote: > >> > >> I'm trying to figure out the best way to manage version control for my > >> refactoring of OpenJUMP. When I was originally thinking about the > >> refactoring, this wasn't an issue, because I was going to start with a > >> blank slate and add parts as I went along. I've decided it would be > >> better to start with the complete core and slowly integrate my > >> changes, making sure that things build and run along the way. > >> > >> This leaves me with an interesting source code version control > >> challenge. I'll really need to manage two (2) versions of OpenJUMP's > >> core. The first version is the core in the JPP SVN repository. This is > >> where most of our community's development work takes place. The second > >> version will be in my own SVN repository. This is where I will be > >> making all of the changes for the refactoring. What I would like to do > >> is synch these two (2) repository so I can overwrite existing code > >> with my changes but still stay up to date with all the other > >> improvements being made. This shouldn't be a major problem, because > >> I'll only be tweaking about 10% to 20% of the core, and I can still > >> suck in the improvements made to the other 80% or 90%. > >> > >> Here is an example of what I'll want to do: > >> > >> I'm refactoring out an Application class from the JUMPWorkbench that > >> will represent the "model" of the application and will separate it > >> cleanly from the GUI. I'll want to add my Application.java file and > >> overwrite the existing JUMPWorkbench.java in my copy of the JPP SVN. > >> I'll need to do this while using the latest versions of all the other > >> classes in the package that contains the JUMPWorkbench.java file. > >> > >> My build process will run something like this: > >> > >> [1] Download the latest copy of the core from the JPP SVN. > >> [2] Download the latest copy of the refactored classes from the core > >> in the SurveyOS SVN. > >> [3] Copy over the refactored classes to the copy of the core from the > >> JPP SVN, overwriting existing classes when necessary. > >> [4] Build the merged core to produce the executable program. > >> > >> I'm thinking I can write a fairly simple Ant Task that will perform > >> the last two steps automatically. I can just work with two (2) Eclipse > >> projects linked to the two (2) SVN repositories like I normally do, > >> but I'll run the build script with my custom task when building the > >> executable program. > >> > >> I'm wondering if there is already and existing tool (Ant Task or other > >> tool) or existing functionality in the SVN program that will allow me > >> to work with two (2) repositories in this way. I don't want to > >> reinvent the wheel. > >> > >> Please let me know if you have any suggestions. If not, I'll work on > >> creating my custom Ant Task for this work over the next couple of > >> weeks. > >> > >> Thanks, > >> > >> The Sunburned Surveyor > >> > >> P.S. - All of my work will be taking place in a WORKING COPY of the > >> JPP SVN. I'm not talking about making any changes to the core the > >> other programmers use, unless my changes are first approved by our > >> community. In this case, I would commit my changes directly to the JPP > >> SVN. > >> > >> > >> > ------------------------------------------------------------------------------ > >> _______________________________________________ > >> Jump-pilot-devel mailing list > >> Jump-pilot-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > > > -- > > http://amusingprogrammer.blogspot.com/ > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 > -- http://amusingprogrammer.blogspot.com/
------------------------------------------------------------------------------
_______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
