Hei Larry,

Want I meant is a bit different (sorry for all the spelling errors). My 
problem is that I want to provide 2 property files. In Eclipse I tried 
it with 2 times calling -properties with different files, but then it 
picks only the first one.

Stefan

Larry Becker wrote:
> There is always the " -properties workbench-properties.xml" switch. Just 
> modify it to point to another path.
> 
> Larry
> 
> On Wed, Jul 2, 2008 at 10:36 PM, Stefan Steiniger <[EMAIL PROTECTED] 
> <mailto:[EMAIL PROTECTED]>> wrote:
> 
>     Ok... now the big question:
> 
>     how can tell OJ to use two workbecnh-properties files?
>     because I don't want to mix up the OJ plugins with my own plugins that I
>      programmed over the years?
> 
>     If one could use multiple files, then this would also make Larrys note
>     obsolete.
> 
>     Stefan
> 
>     Larry Becker schrieb:
>      > Hi Stefan,
>      >
>      >   Nice work.  I can think of one small issue related to the
>     installer.
>      > It will now be necessary to distribute the workbench-properties.xml
>      > file.  This means that if someone customizes their file, it will be
>      > replaced on the next update, as this will be necessary to get new
>      > features in new releases.  People will have to get used to keeping an
>      > old copy of their customizations and reapplying them after each
>     update.
>      >
>      > regards,
>      > Larry
>      >
>      > On Tue, Jul 1, 2008 at 7:07 PM, Stefan Steiniger
>     <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>      > <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
>      >
>      >     Hei,
>      >
>      >     @Paolo... I think I regard your points as nice to have (with
>     respect to
>      >     server-client stuff: although I know that Jump has been also
>     used as
>      >     base for a web-gis-server ;)
>      >
>      >     @all:
>      >     I moved today the workbench-properties.xml around to the bin
>     folder. So
>      >     if the next nightly build works with test plugin (I found a
>     very olf
>      >     "Magnifyer" function ;o) we can start moving first the
>     additional OJ
>      >     plugins (except data IO). Then we need to check how it will
>     affect the
>      >     ordering of the functions in the menus. I expect a lot of
>     refactoring
>      >     just for that. But I think we will not break anything, as the
>     changes
>      >     will be only for the (new to add) initialize methods, i.e. on
>     the gui
>      >     side only.
>      >
>      >     => any comments on that?
>      >     mhm.. may be one from myself: The removal of menus such as
>     suggested by
>      >     Carl will not be possible (e.g. the complete removal of tht
>     "Tools"
>      >     menu), except we are able to move all functions into the xml
>     file for
>      >     one menu.
>      >
>      >     Something different: I also moved some of the functions in
>      >     tools/analysis/ to two new submenus.
>      >
>      >     stefan
>      >
>      >     P.Rizzi Ag.Mobilità Ambiente schrieb:
>      >      > If I can tell my opinion the whole configuraiton should be
>     in the
>      >     xml file.
>      >      > I don't like the way some plugins are "hardly" configured
>     in Java
>      >     code.
>      >      >
>      >      > There should be nothing really "basic" and hardly configured,
>      >     because it
>      >      > will be impossible to remove that and, besides, what is really
>      >     "basic"
>      >      > depends upon what each person would do with OJ.
>      >      >
>      >      > Then a series of pre-canned XML file could be prepared so that
>      >     several
>      >      > "common" OJ configuration could be started, by choosing
>     one of them.
>      >      >
>      >      > Problem is plugin dependency, but that could be leaved in the
>      >     hand of the user,
>      >      > or whoever prepare the XML file, so that each configuration is
>      >     coherent
>      >      > and working. Or a real third-party container can be used, but
>      >     that would be
>      >      > a very big change in code and philosophy...
>      >      >
>      >      > I'm sorry this is just my vision, but I can't put any
>     effort into
>      >     it :-(
>      >      >
>      >      > Bye
>      >      > Paolo Rizzi
>      >      >
>      >      >
>      >      > P.S: And if one day OJ would be so modular that it can be
>      >     splitted into
>      >      > a server part and a client (GUI) part, a special XML file
>     would
>      >     be used
>      >      > to launch a server-only configuration, and then a Web UI
>     could be
>      >     developed,
>      >      > or any WMS client may connect to it.
>      >      >
>      >      >
>      >      >> -----Messaggio originale-----
>      >      >> Da: [EMAIL PROTECTED]
>     <mailto:[EMAIL PROTECTED]>
>      >     <mailto:[EMAIL PROTECTED]
>     <mailto:[EMAIL PROTECTED]>>
>      >      >> [mailto:[EMAIL PROTECTED]
>     <mailto:[EMAIL PROTECTED]>
>      >     <mailto:[EMAIL PROTECTED]
>     <mailto:[EMAIL PROTECTED]>>]Per conto di
>      >      >> Stefan Steiniger
>      >      >> Inviato: lunedì 30 giugno 2008 18.27
>      >      >> A: OpenJump develop and use
>      >      >> Oggetto: Re: [JPP-Devel] disable/deactivate menu with plugin?
>      >      >>
>      >      >>
>      >      >> my 2 cents:
>      >      >>
>      >      >> . Yes for porting the functionality (didn't we ported
>     already)
>      >      >> . Question: what do we do then? Move all of the stuff in
>      >      >> OpenJUMP/Jump
>      >      >> configuration which is not "basic" (basic could be
>     anything that is
>      >      >> tools) to the xml file?
>      >      >> . @Larry:
>      >      >> - Can you send such xml file? I would like to see how it
>      >      >> looks like. [or
>      >      >> is it in fact looking exactly like the
>     workbench-properties.xml
>      >     file?]
>      >      >>
>      >      >> stefan
>      >      >>
>      >      >> Sunburned Surveyor wrote:
>      >      >>> I second the comments from Andreas. If I could help port
>     this
>      >      >>> functionality from SkyJUMP, let me know.
>      >      >>>
>      >      >>> But perhaps we should hear what Stefan thinks first...
>      >      >>>
>      >      >>> The Sunburned Surveyor
>      >      >>>
>      >      >>> On Mon, Jun 30, 2008 at 1:22 AM, Andreas Schmitz
>      >      >> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>     <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
>      >      >>>> Larry Becker wrote:
>      >      >>>>
>      >      >>>> Hi,
>      >      >>>>
>      >      >>>>>   I can't think of a way without modifying
>      >      >> OpenJumpConfiguration.  If this
>      >      >>>>> is a popular requirement, we could add functionality via
>      >      >> the editable
>      >      >>>>> workbench-properties.xml file instead of the
>      >      >> OpenJumpConfiguration class (as
>      >      >>>>> SkyJUMP does).  This would make it possible for users to
>      >      >> add or remove
>      >      >>>>> functionality at will.
>      >      >>>> Yes, that would definitely be a nice feature. If I can be
>      >      >> of aid in transporting
>      >      >>>> it from SkyJUMP, please let me know.
>      >      >>>>
>      >      >>>> Best regards, Andreas
>      >      >>>> --
>      >      >>>> l a t / l o n  GmbH
>      >      >>>> Aennchenstrasse 19           53177 Bonn, Germany
>      >      >>>> phone ++49 +228 18496-12     fax ++49 +228 1849629
>      >      >>>> http://www.lat-lon.de        http://www.deegree.org
>      >      >>>>
>      >      >>>> -----BEGIN PGP SIGNATURE-----
>      >      >>>> Version: GnuPG v1.4.6 (GNU/Linux)
>      >      >>>>
>      >      >>>>
>     iD8DBQFIaJet737OVr+Ru7oRAhlBAJ93q7eNaMJyAej/+kqp0DHGHqCCjACghiZS
>      >      >>>> 3TYFjI8suDYMLQ+ac8GrNnM=
>      >      >>>> =vh1b
>      >      >>>> -----END PGP SIGNATURE-----
>      >      >>>>
>      >      >>>>
>      >
> 
>     -------------------------------------------------------------------------
>     Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>     Studies have shown that voting for your favorite open source project,
>     along with a healthy diet, reduces your potential for chronic lameness
>     and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>     _______________________________________________
>     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
> 
> 
> 
> 
> -- 
> http://amusingprogrammer.blogspot.com/
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel

Reply via email to