Am Donnerstag, 7. Juni 2007 20:21 schrieb Sunburned Surveyor:
> Stefan,
>
> Were you ale to figure out a way to get an unstable/stable bracnh
> working on the OpenJUMP CVS. If you are too busy I wonder if we might
> give Stephan Holl permission to make some changes. It sounds like he
> has more exp
Good point Michael. Stefan is the one that takes care of the CVS. I'd
be willing to care for an SVN repository, but I'd probably need
occassional assistance from more experienced developers.
Let's wait to see what Stefan thinks of this.
The Sunburned Surveyor
P.S - Does anyone have experience se
Hi,
As Stefan knows, I'm not a specialist of cvs/subversion system ;-)
It seems that subversion has a few advantages and I will be happy
to benefit them if some experimented developpers wants to lead
the migration.
Until that, I'd rather give my vote to Stefan, as I know he
has few time to maintai
Alright. We've got three votes for SVN. I'd still like to hear from
our other regular contributors: Stefan, Michael, and perhaps from
Andreas, since he is taking over for Ugo.
If there are no strong objections, perhaps we can consider making the
migration to Subversion at this time.
The Sunburned
I favor SVN too (for a number of reasons)
and a lot of our other professional projects
are already using SVN.
BTW: Jan might remember my astonished scream when we
started with the Print/Layout plug-in:
"What?! They still using CVS?? Oh, no!" ;-)
My 2 cents.
- Sascha
Sunburned Surveyor schrieb:
There is an article I found in Javaworld that explains how to set up a
nightly build using Tomcat and Anthill.
This might be a place to start if we need to set up a new nightly build.
SS
-
This SF.net email is sponsored by D
I put up a post on my OpenJUMP blog about one possible alternative to
a complex feature model.
I haven't thought the idea through completely, and I don't have any
plans on implementing the alternative described, but if you are
interested in having the benefits of a more complex feature model in
Op
Paul,
This idea has been suggested a couple of times, but didn't receive the
best reception from some of the OpenJUMP developers. I'm personally in
favor of it, and I think that it will happen eventually, as more of
our developers begin using SVN at work or on their other projects.
This may be a
I'm going to start putting together a CVS diff for the new Attribute
view and am trying to decide the best packages to put my code, here are
my thoughts.
1. Infrastructure required so that I can add a new tab to the InfoFrame
will go under com.vividsolutions.jump.*
2. The new view pane itself will
Paul,
Thank you very much for your valuable contributions !
Michaël
Paul Austin a écrit :
>Michaël,
>
>I am going to be looking at the editing of attribute values as on the
>DetailView/Edit page soon and will have it so you can customize the edit
>widget used for a specific Java Class and also
My Preference would be to move over to using subversion as our
repository for all development and the stable branch. I find SVN is much
easier for branching and merging than CVS was, especially with the
eclipse SVN plugin.
Paul
Sunburned Surveyor wrote:
> Stefan,
>
> Were you ale to figure out a
Stefan,
Were you ale to figure out a way to get an unstable/stable bracnh
working on the OpenJUMP CVS. If you are too busy I wonder if we might
give Stephan Holl permission to make some changes. It sounds like he
has more experience with CVS that you or I. :]
As an alternative, I have cleaned out
Thank you for giving us that advice David.
The Sunburned Surveyor
On 6/7/07, David Zwiers <[EMAIL PROTECTED]> wrote:
> Just a quick 2 cents -- Geoapi is very complex and should be avoided
> within Jump. The added complexity will only confuse developers,
> increasing there frustration creating wor
Michaël,
I am going to be looking at the editing of attribute values as on the
DetailView/Edit page soon and will have it so you can customize the edit
widget used for a specific Java Class and also on a per FeatureSchema
attribute basis.
Paul
---
Just a quick 2 cents -- Geoapi is very complex and should be avoided
within Jump. The added complexity will only confuse developers,
increasing there frustration creating workable solutions.
We would also need to keep a fork of the code as these interfaces change
all too frequently -- at which tim
15 matches
Mail list logo
