Re: [JPP-Devel] Do we have a winner? (Migration to Subversion)
Hello Sascha, "Sascha L. Teichmann" <[EMAIL PROTECTED]>, [20070619 - 18:34:27] > The ChangeLog failed, because Andreas did a commit. > > @Stephan Holl and @Andreas: > > Do you repair this yourself? As Andreas saif, Yes, we do that. We will see who is first :-) I can do that on friday though. Stephan -- Stephan Holl <[EMAIL PROTECTED]>, http://intevation.de/~stephan Tel: +49 (0)541-33 50 8 32 | Intevation GmbH | AG Osnabrück - HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] CVS to SVN Migration...Are we done yet?
One other thing, I think we should add some directories to svn:ignore (such as build, or target (if people use maven)) so that people don't accidentally commit their compiled sources. Paul Sunburned Surveyor wrote: > I moved the [/tags] folder under [/core] as Paul had suggested. I > don't think there were any other suggestions I missed, except for the > plug-in folders, which we've discussed. > > Does anyone else see a reason why we can't start using the SVN > repository? (I want to make sure I'm not forgetting something.) > > The Sunburned Surveyor > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] CVS to SVN Migration...Are we done yet?
Looks good to me Paul Sunburned Surveyor wrote: > I moved the [/tags] folder under [/core] as Paul had suggested. I > don't think there were any other suggestions I missed, except for the > plug-in folders, which we've discussed. > > Does anyone else see a reason why we can't start using the SVN > repository? (I want to make sure I'm not forgetting something.) > > The Sunburned Surveyor > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] A new ThreadQueue
Hi Larry,
this all fits together very well and I have
a couple of comments/ideas. This is most radical one:
Let me switch to "software designer mode" for a moment.
(This is what my company is paying me for besides working
with legacy code... ;-)
We have actually two problems:
1 - We cannot determine exactly when a rendering
has ended (successfully or not).
This is important for e.g. printing and zooming+flashing.
The 'wakeup' Runnable trick only works if all jobs are
processed in a serial manner. It fails when DB or WMS layers
are involved because these are processed truly parallel.
What we really want is some kind of a reliable barrier
mechanism that triggers certain things after a rendering.
(unlocking a wait in the printing case and flashing in case of
zoom to selection)
2 - We have a javax,swing.Timer in RenderingManager
that triggers a repaint any x ms.
To what value we should set x?
A x too large makes the the GUI feels sluggish. x choosen too
small costs a lot of performance. I've got interesting profiling
numbers from JProbe that told me that the copyTo() stuff can
take up to 25% of the rendering time when you set x too low.
If we ask how we have to set x, we're asking the wrong question.
The question should state:
Has a renderer made enough progress to do a repaint?
If the on screen differences between two repaints would be too
small, why should we waste time to do a redraw? Only a significant
change (say a quarter of features drawn more) is worth this expense.
With a fixed scheduled timer you cannot test this efficiently.
This has to be done in cooperation with the particular renderer.
How to address these issues?
In my "software designer" dreamland i would propose the following:
1 - Remove the fixed scheduled timer
2 - Change the Renderer interface (Gulp!)
I would introduce an inner interface 'RenderingMaster':
interface RenderingMaster {
void doRepaint(Renderer thisRenderer);
void renderingDone(Renderer thisRenderer, boolean success);
}
and change the signature of createRunnable() to:
Runnable createRunnable(RenderingMaster master);
The idea of this extra callback should be pretty obvious.
Each time a renderer has produced a significant part of
output it calls master.doRepaint(this). On the implementors
side of RenderingMaster we can do a repaint.
If a renderer finished its job it calls
master.renderingDone(this, true). (false after canceling)
On the implementors side of RenderingMaster we can do some
reference counting and kick some listeners when all jobs are
done.
>From designer dreamland back to the reality of legacy code:
I would estimate about 1-2 days of work to refactor the core code
to use this new pattern + some testing.
The real problem arises from the fact that there is a sky
full of JUMPs and a lot of non-core Renderers out there.
This modification would be a heavy one and I
don't really dare to think about the consequences ...
Things like mouse wheel zooming may profit from this change too.
So I don't want to wipe off this idea.
Any comments?
Regards,
Sascha
PS: If you don't like it all I have some 'workaround' ideas too ...
Larry Becker schrieb:
> Hi Sascha,
>
>I have figured out what is different about rendering timing in
> SkyJUMP and OpenJump. The randomly delayed drawing in OpenJump is
> caused by the repaintTimer in RenderingManager. In OpenJump and JUMP it
> is set to 1 second, and in SkyJUMP it is set to 400 ms. This makes
> SkyJUMP rendering more responsive to support Mouse Wheel zooming,
> although still somewhat random.
>
> When the number of items withing the current window for a given layer
> falls below the maxFeatures threshold, the
> simpleFeatureCollectionRenderer is used, otherwise
> imageCachingFeatureCollectionRenderer is used. Image Caching implies
> that we have to wait for the repaintTimer to expire before all of the
> results of render operations are guaranteed to be copied on screen.
> When image Caching is disabled, drawing is synchronized but unresponsive
> because nothing appears on the screen until the end of the process.
>
> I'm not sure we can do anything about the repaintTimer's apparent
> randomness. The whole point of having a repaint timer is to be
> unsynchronized with the layer rendering process. Setting the timer
> value to 400 ms seems to make it responsive enough for the
> ZoomToSelectedItemsPlugIn. We'll need to do that anyway when mouse
> wheel zooming in ported over.
>
> regards,
> Larry
>
> On 6/18/07, *Larry Becker* <[EMAIL PROTECTED]
> > wrote:
>
> Sascha,
>
>I replaced the ThreadQueue.Listener with the following code:
>
> panel.getRenderingManager().getDefaultRendererThreadQueue().add(
> new Runnable() {
> public void ru
[JPP-Devel] CVS to SVN Migration...Are we done yet?
I moved the [/tags] folder under [/core] as Paul had suggested. I don't think there were any other suggestions I missed, except for the plug-in folders, which we've discussed. Does anyone else see a reason why we can't start using the SVN repository? (I want to make sure I'm not forgetting something.) The Sunburned Surveyor - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] A new ThreadQueue
Hi Sascha,
I have figured out what is different about rendering timing in SkyJUMP
and OpenJump. The randomly delayed drawing in OpenJump is caused by the
repaintTimer in RenderingManager. In OpenJump and JUMP it is set to 1
second, and in SkyJUMP it is set to 400 ms. This makes SkyJUMP rendering
more responsive to support Mouse Wheel zooming, although still somewhat
random.
When the number of items withing the current window for a given layer
falls below the maxFeatures threshold, the simpleFeatureCollectionRenderer
is used, otherwise imageCachingFeatureCollectionRenderer is used. Image
Caching implies that we have to wait for the repaintTimer to expire before
all of the results of render operations are guaranteed to be copied on
screen. When image Caching is disabled, drawing is synchronized but
unresponsive because nothing appears on the screen until the end of the
process.
I'm not sure we can do anything about the repaintTimer's apparent
randomness. The whole point of having a repaint timer is to be
unsynchronized with the layer rendering process. Setting the timer value to
400 ms seems to make it responsive enough for the
ZoomToSelectedItemsPlugIn. We'll need to do that anyway when mouse wheel
zooming in ported over.
regards,
Larry
On 6/18/07, Larry Becker <[EMAIL PROTECTED]> wrote:
Sascha,
I replaced the ThreadQueue.Listener with the following code:
panel.getRenderingManager().getDefaultRendererThreadQueue().add(
new Runnable() {
public void run() {
try {
flash(geometries, panel);
} catch (NoninvertibleTransformException e) {};
}
});
This works great in SkyJUMP where I also used it to fix my refresh timer
and ZoomRealtime, however although it is better than the Listener in
OpenJump, it still occasionally flashes first and then zooms. Clearly there
is something wrong, but it is not in your ThreadQueue code. I'll look some
more tomorrow.
regards,
Larry
On 6/18/07, Larry Becker <[EMAIL PROTECTED]> wrote:
>
> Sascha,
>
> > Don't you have the same effects with the original one?
>
>I begin to see... I can reproduce flash problems easily in JUMP
> and OpenJump, but not in SkyJUMP. That explains why we are both
> surprised. I have no idea why there is a difference, but I will
> investigate further.
>
> regards,
> Larry
>
> On 6/18/07, Sascha L. Teichmann <[EMAIL PROTECTED] > wrote:
> > Larry,
> >
> > _exactly_ this the thread lottery we are playing with the
> > assumption that no running threads means there no more rendering jobs!
> >
> > I get the same irritating behavior with the original ThreadQueue.
> > I put an System.err.println("flash!") into the listener of
> > the zoom plug-in. Sometimes it gets printed before the display
> > is in the right 'mood' to display a flash. Result: no visible
> > flash or only a shortened variant.
> >
> > Don't you have the same effects with the original one?
> > I have!
> >
> > Register a println Listener yourself to the ThreadQueue
> > and be surprised how often it is called.
> >
> > The zoom plug-in builds on this assumption the even more venturous
> > assumption that the zoom is done when there no more running threads.
> > It does not take into account that the hole repaint()/erase()/copyTo()
>
> > stuff also takes some time. The invokeLater() call does not make it
> > more predictable.
> >
> > Let us compare the TQs:
> >
> > 1) Original TQ:
> >
> > public void add(final Runnable runnable) {
> > queuedRunnables.add(new Runnable() {
> > public void run() {
> >try {
> > runnable.run();
> >} finally {
> > setRunningThreads(getRunningThreads() - 1);
> > processQueue();
> >}
> > }
> > });
> > processQueue();
> > }
> >
> > private void setRunningThreads(int runningThreads) {
> > this.runningThreads = runningThreads;
> > if (runningThreads == 0) { fireAllRunningThreadsFinished(); }
> > }
> >
> > The defaultRenderingThread has only one Thread running.
> > -> runningThreads == 1 during try block of new Runnable.run().
> >
> > setRunningThread() in the finally sets it to zero
> > -> listeners get there kick.
> >
> > This means that after each and every job the listeners get kicked.
> >
> > 2) New TQ: (in worker thread's run())
> >
> > for (;;) {
> > // unimportant part
> > try {
> >runnable.run();
> > }
> > catch (Exception e) {
> > e.printStackTrace();
> > }
> >
> > boolean lastRunningThread;
> > synchronized (runningThreads) {
> >lastRunningThread = runningThreads[0] == 1;
> > }
> > if (lastRunningThread) {
> >fireAllRunningThreadsFinished();
> > }
> > }
> >
> > The defaultRenderingThread has only one Thread running.
> > -> runningThreads[0] == 1
> >
> > afte
Re: [JPP-Devel] Do we have a winner? (Migration to Subversion)
Sascha L. Teichmann wrote: Hi, > - WFSPlugin failed with: > > ./WFSPlugin/lib/commons-codec-1.3.jar: FAILED > ./WFSPlugin/lib/vecmath.jar: FAILED > ./WFSPlugin/lib/commons-httpclient-2.0.2-deegreeversion.jar: FAILED > ./WFSPlugin/lib/commons-logging.jar: FAILED > ./WFSPlugin/lib/jaxen-1.1-beta-8.jar: FAILED > ./WFSPlugin/lib/deegree2.jar: FAILED > ./WFSPlugin/src/de/latlon/deejump/ui/messages.properties: FAILED > ./WFSPlugin/src/de/latlon/deejump/ui/messages_fr.properties: FAILED > ./WFSPlugin/src/de/latlon/deejump/ui/messages_de.properties: FAILED > ./WFSPlugin/ChangeLog: FAILED > > The ChangeLog failed, because Andreas did a commit. > > @Stephan Holl and @Andreas: > > Do you repair this yourself? sure, I can do this next week. Best regards, Andreas -- l a t / l o n GmbH Aennchenstrasse 19 53177 Bonn, Germany phone ++49 +228 18496-11 fax ++49 +228 1849629 http://www.lat-lon.dehttp://www.deegree.org - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] GeoTools Graph Code
I don't think the GeoTools Graph code will be immediately useful to me. I think it might come in handy when working on network topology. There might also be a way to apply it to linear referencing or route stationing. I'm not sure though. It seems to be a rather abstract and technical concept. It seems like it would be a lot of work to use it to model the relationships between a group of classes, instead embedding that information in the objects themselves. I'm sure this apprehension is due to my lack of education and/or experience in modeling. Is this code being used for anything other than linear networks? Maybe another example of an application would clarify things for me. Thanks, The Sunburned Surveyor - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Structure of plug-in modules in the JPP Subversion repository.
I have no problem with implementing the [/trunk /braches /tag] structure for development of plug-in modules. All of our main developers should now have write access to the SVN so they may modify their own respective plug-in modules if they wish to do so. (If you need help doing this with SVN please let me know.) If there is a plug-in that is no longer actively developed or maintained we can make the same changes. I only ask that you post to the list first to make sure no one claims the plug-in module that you want to change. I believe this should take care of the changes that I needed to make to complete our migration. (I still need to move the /tags folder under the /core folder.) I want to thank everyone for their patience, helpful suggestions, and direct assistance. This was definitely a team effort. :] The Sunburned Surveyor - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
[JPP-Devel] Can I get you some fries with that? (SVN Notification Mailing List)
I have set up the e-mail list for notifications on our new SVN repository. You can subscribe to the list here: http://lists.sourceforge.net/mailman/listinfo/jump-pilot-svn-notify Please note that SourceForge said it will take 4 to 6 hours for this new mailing list to be set up. We may not get notifications in that time period. The Sunburned Surveyor - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Do we have a winner? (Migration to Subversion)
Hi again! Sunburned Surveyor schrieb: > Sascha wrote: "Binaries must be marked as binaries in CVS. I guess someone has > forgotten to set the binary flag when the libs were checked in. > Now they are messed. I can do so checksumming ... again" > > I appreciate this offer of assistance. If the binary files are > corrupted we can simply replace them with current versions, correct? Correct. I checked out the hole SVN and compared all none *.java files with the latest from CVS. - The core is okay - All plug-ins without WFSPlugin are okay - WFSPlugin failed with: ./WFSPlugin/lib/commons-codec-1.3.jar: FAILED ./WFSPlugin/lib/vecmath.jar: FAILED ./WFSPlugin/lib/commons-httpclient-2.0.2-deegreeversion.jar: FAILED ./WFSPlugin/lib/commons-logging.jar: FAILED ./WFSPlugin/lib/jaxen-1.1-beta-8.jar: FAILED ./WFSPlugin/lib/deegree2.jar: FAILED ./WFSPlugin/src/de/latlon/deejump/ui/messages.properties: FAILED ./WFSPlugin/src/de/latlon/deejump/ui/messages_fr.properties: FAILED ./WFSPlugin/src/de/latlon/deejump/ui/messages_de.properties: FAILED ./WFSPlugin/ChangeLog: FAILED The ChangeLog failed, because Andreas did a commit. @Stephan Holl and @Andreas: Do you repair this yourself? > Sascha wrote: "Stephan is talking about an equivalent to the > jump-pilot-cvslog list, > not the jump-pilot-devel list. > > And yes, such a list is very useful to get on top with recent changes. > Not everybody scans the ChangeLogs regularly. An e-mail notification > would be nice." > > O.K. I just get a lot of these messages from the GeoTools list, which > is rather irritating. I suppose it wouldn't be to bad if it was on a > separate mailing list. Does someone have time to look into setting > this up? I'd like to get back to Giuseppe before he looses that > enthusiasm for documentation. :] (Actually, I had better check it out, > because you probably need admin permissions to do it.) Stefan Steiniger set up the CVS log list. I don't know if I have enough rights to do it. > Sascha wrote: "Don't you want it or don't you know how to do it? I > think Paul's and > Stephan's idea is worth thinking about." > > I think I've learned enough about SVN to handle this task. But like I > said, most of our plug-ins our not really developed by the communuity > in the same way OpenJUMP is, and don't want to step on anyones toes. > I'd prefer to have the current plug-in developers comment on this. If > a plug-in has been "abandoned" or is no longer being developed we can > mess with the structure of its code in the SVN all we want. I can speak for the Print/Layout plug-in (and for the WFS plug-in too). They are really developed by and for the community! If we'd wanted to have our thumb on this could have set up our own repository elsewhere with ease (We have our own GForge infrastructure on wald.intevation.de which hosts e.g. deegree's SVN). We only take the lead in the development to bring the plug-ins to life. We would _really_ appreciate it if there were more contributors. This is the way FLOSS works ... by working together! Regards, Sascha - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Initial Phase of Subversion Migration
Paul, I made this change in my working copy at home this morning, but it looks like I forgot to commit it. I will do this when I get home tonight. Thanks for catching this mistake. The Sunburned Surveyor On 6/19/07, Paul Austin <[EMAIL PROTECTED]> wrote: > The tags folder also needs to be moved under core, other than that looks > good > > Paul > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Do we have a winner? (Migration to Subversion)
Sascha wrote: "Binaries must be marked as binaries in CVS. I guess someone has forgotten to set the binary flag when the libs were checked in. Now they are messed. I can do so checksumming ... again" I appreciate this offer of assistance. If the binary files are corrupted we can simply replace them with current versions, correct? Sascha wrote: "Stephan is talking about an equivalent to the jump-pilot-cvslog list, not the jump-pilot-devel list. And yes, such a list is very useful to get on top with recent changes. Not everybody scans the ChangeLogs regularly. An e-mail notification would be nice." O.K. I just get a lot of these messages from the GeoTools list, which is rather irritating. I suppose it wouldn't be to bad if it was on a separate mailing list. Does someone have time to look into setting this up? I'd like to get back to Giuseppe before he looses that enthusiasm for documentation. :] (Actually, I had better check it out, because you probably need admin permissions to do it.) Sascha wrote: "Don't you want it or don't you know how to do it? I think Paul's and Stephan's idea is worth thinking about." I think I've learned enough about SVN to handle this task. But like I said, most of our plug-ins our not really developed by the communuity in the same way OpenJUMP is, and don't want to step on anyones toes. I'd prefer to have the current plug-in developers comment on this. If a plug-in has been "abandoned" or is no longer being developed we can mess with the structure of its code in the SVN all we want. The Sunburned Surveyor On 6/19/07, Sascha L. Teichmann <[EMAIL PROTECTED]> wrote: > Hi SS, > > Sunburned Surveyor schrieb: > > [...] > > Stephan wrote: "What about the binary-libs? I encountered broken libs > > at least under WFSPlugin/libs/*.jar. It seems they were not commited > > as binary in CVS." > > > > I didn't think that CVS could store binary files like SVN. Or at least > > I thought CVS couldn't version binary files like SVN. Perhaps this was > > the problem? At any rate, I don't think that this will prevent us from > > using the SVN repository for development now, though we should fix it > > at some point. (Any volunteers?) :] > > Binaries must be marked as binaries in CVS. I guess someone has > forgotten to set the binary flag when the libs were checked in. > Now they are messed. I can do so checksumming ... again. > > > Stephan wrote: "Is it possible to have the commit-emails sent to the > > mailing list as it was with CVS?" > > > > I'm not sure about this one. I never noticed commit e-mails coming to > > this mailing list from the JPP CVS Repository. (Maybe I wasn't paying > > attention?) If this is something the developers would like I can look > > into it. I'm sure that there is a way to do it with SourceForge. I > > don't personally prefer these types of messages and I don't know that > > we need them if everyone is disciplined and uses the changelog text > > file. > > > > What do you guys think? Do we want to have SVN commit messages sent to > > the mailing list? > > Stephan is talking about an equivalent to the jump-pilot-cvslog list, > not the jump-pilot-devel list. > > And yes, such a list is very useful to get on top with recent changes. > Not everybody scans the ChangeLogs regularly. An e-mail notification > would be nice. > > > Stephan wrote: "Asked that I think that the plugins should have its own > > trunk|tags|branches-tree like Paul suggested. I know it is a little > > more work, but separate releases of the plugins are then possible and > > more transparent." > > > > Please see my comments to Paul above. I don't really want to dictate > > structure to the plug-in developers. > > Don't you want it or don't you know how to do it? I think Paul's and > Stephan's idea is worth thinking about. > > Regards, > Sascha > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Initial Phase of Subversion Migration
The tags folder also needs to be moved under core, other than that looks good Paul - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Do we have a winner? (Migration to Subversion)
Hi SS, Sunburned Surveyor schrieb: > [...] > Stephan wrote: "What about the binary-libs? I encountered broken libs > at least under WFSPlugin/libs/*.jar. It seems they were not commited > as binary in CVS." > > I didn't think that CVS could store binary files like SVN. Or at least > I thought CVS couldn't version binary files like SVN. Perhaps this was > the problem? At any rate, I don't think that this will prevent us from > using the SVN repository for development now, though we should fix it > at some point. (Any volunteers?) :] Binaries must be marked as binaries in CVS. I guess someone has forgotten to set the binary flag when the libs were checked in. Now they are messed. I can do so checksumming ... again. > Stephan wrote: "Is it possible to have the commit-emails sent to the > mailing list as it was with CVS?" > > I'm not sure about this one. I never noticed commit e-mails coming to > this mailing list from the JPP CVS Repository. (Maybe I wasn't paying > attention?) If this is something the developers would like I can look > into it. I'm sure that there is a way to do it with SourceForge. I > don't personally prefer these types of messages and I don't know that > we need them if everyone is disciplined and uses the changelog text > file. > > What do you guys think? Do we want to have SVN commit messages sent to > the mailing list? Stephan is talking about an equivalent to the jump-pilot-cvslog list, not the jump-pilot-devel list. And yes, such a list is very useful to get on top with recent changes. Not everybody scans the ChangeLogs regularly. An e-mail notification would be nice. > Stephan wrote: "Asked that I think that the plugins should have its own > trunk|tags|branches-tree like Paul suggested. I know it is a little > more work, but separate releases of the plugins are then possible and > more transparent." > > Please see my comments to Paul above. I don't really want to dictate > structure to the plug-in developers. Don't you want it or don't you know how to do it? I think Paul's and Stephan's idea is worth thinking about. Regards, Sascha - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Do we have a winner? (Migration to Subversion)
O.K. - I guess we aren't complete, but hopefully we are getting closer. :] I am getting better at changing things in a Subversion repository. Lot's of practice... Paul wrote: "I still think we should have the core and each module have it's own trunk, branches and tags, that way each one can have it's own releases." This is now done. (Except for the plug-ins. I think it would be best to allow each plug-in developer to decide on their module structure, although it would make sense for them to follow the same pattern as the core. That is /trunk /branches /tags.) Stephan wrote: "What about the binary-libs? I encountered broken libs at least under WFSPlugin/libs/*.jar. It seems they were not commited as binary in CVS." I didn't think that CVS could store binary files like SVN. Or at least I thought CVS couldn't version binary files like SVN. Perhaps this was the problem? At any rate, I don't think that this will prevent us from using the SVN repository for development now, though we should fix it at some point. (Any volunteers?) :] Stephan wrote: "Is it possible to have the commit-emails sent to the mailing list as it was with CVS?" I'm not sure about this one. I never noticed commit e-mails coming to this mailing list from the JPP CVS Repository. (Maybe I wasn't paying attention?) If this is something the developers would like I can look into it. I'm sure that there is a way to do it with SourceForge. I don't personally prefer these types of messages and I don't know that we need them if everyone is disciplined and uses the changelog text file. What do you guys think? Do we want to have SVN commit messages sent to the mailing list? Stephan wrote: "Asked that I think that the plugins should have its own trunk|tags|branches-tree like Paul suggested. I know it is a little more work, but separate releases of the plugins are then possible and more transparent." Please see my comments to Paul above. I don't really want to dictate structure to the plug-in developers. The Sunburned Surveyor On 6/19/07, Stephan Holl <[EMAIL PROTECTED]> wrote: > Hello Sunburned, > > "Sunburned Surveyor" <[EMAIL PROTECTED]>, [20070618 - > 21:29:21] > > > I think I have completed the migration to Subversion. Please check it > > out when you get a chance and let me know if you see something wrong. > > > > You will find the main sport for development commits in /trunk/core. > > There is also a spot for plug-in development in /trunk/plug-ins. > > > > The stable branch for OpenJUMP 1.2 is in openjump_stable_1_2. > > > > Please let me know if you have any questions on how the SVN repository > > was set up. > > What about the binary-libs? I encountered broken libs at least under > WFSPlugin/libs/*.jar. It seems they were not commited as binary in CVS. > > > I want to thank Stefan, Andreas, and Sascha for all of their help. I > > couldn't have done this properly without their assistance. > > Is it possible to have the commit-emails sent to the mailinglist as it > was with CVS? > > Does your Email I am replying to sais that the 'work' on the repository > is done and we can continue committing? > Asked that I think that the plugins should have its own > trunk|tags|branches-tree like Paul suggested. I know it is a little > more work, but separate releases of the plugins are then possible and > more transparent. > Anyway, thanks for your efforts!! > > Best > Stephan > > -- > Stephan Holl <[EMAIL PROTECTED]>, http://intevation.de/~stephan > Tel: +49 (0)541-33 50 8 32 | Intevation GmbH | AG Osnabrück - HR B 18998 > Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Re: [JPP-Devel] Do we have a winner? (Migration to Subversion)
Hello Sunburned, "Sunburned Surveyor" <[EMAIL PROTECTED]>, [20070618 - 21:29:21] > I think I have completed the migration to Subversion. Please check it > out when you get a chance and let me know if you see something wrong. > > You will find the main sport for development commits in /trunk/core. > There is also a spot for plug-in development in /trunk/plug-ins. > > The stable branch for OpenJUMP 1.2 is in openjump_stable_1_2. > > Please let me know if you have any questions on how the SVN repository > was set up. What about the binary-libs? I encountered broken libs at least under WFSPlugin/libs/*.jar. It seems they were not commited as binary in CVS. > I want to thank Stefan, Andreas, and Sascha for all of their help. I > couldn't have done this properly without their assistance. Is it possible to have the commit-emails sent to the mailinglist as it was with CVS? Does your Email I am replying to sais that the 'work' on the repository is done and we can continue committing? Asked that I think that the plugins should have its own trunk|tags|branches-tree like Paul suggested. I know it is a little more work, but separate releases of the plugins are then possible and more transparent. Anyway, thanks for your efforts!! Best Stephan -- Stephan Holl <[EMAIL PROTECTED]>, http://intevation.de/~stephan Tel: +49 (0)541-33 50 8 32 | Intevation GmbH | AG Osnabrück - HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
