On 03.07.2011 17:44, Michaël Michaud wrote: > Hi, >> this exists two times. one time for linearring, the other for >> linestring. the difference is subtle, agreed ;) > OK, did not see the difference, here is the fixed file >>> When you will be OK, I'll update >>> http://jump-pilot.sourceforge.net/download and >>> http://jump-pilot.sourceforge.net/download/extensioncatalog.xml >>> to be able to upload your plugin with the extension manager. >> i was not aware that this existed. you can try, but it will >> probably not work anymore, because the extensions use several files >> (including the language) beside the library jars, that reside in >> subfolders. > It's also the first time I have a closer look at this extension > manager :-) Being able to read language files embeded in the jar or > in an external directory seems the best option to me. If I remember > correctly *you* contributed to make it work this way for OpenJUMP > (with priority to external properties file).
actually the reason mainly was to be able to use the same libraries independently in separate extensions. > >> while i like the idea, i don't like the implementation of this >> manager. a) the presentation of available extensions lacks >> accessible information about what the extension does, even if the >> info resides in the xml file. b) it does not really install an >> extension, but tries to start the extension from the given file. c) >> installed extensions cannot be deactivated, although it looks like >> it is possible. > I agree this plugin lacks some capabilies, but I think such a plugin > is a must-have for a soft like OpenJUMP. >> this i'd argue is clearly a candidate that needs some love and >> attention and should be removed from oj in this state. > Why do you think it should be removed if it already can install > simple one-jar extensions from one location ? minus two of my extensions, there is one extension leftover in the repository. the representation (information,usability) of this extension does not meet a minimal level of usability i would expect and does not compare to the rest of oj's quality. we are short on man power and i argue we should rather spend the effort in the suggested than on maintaining one repository for an inferior extension. >> at last: is geomconv still on the way to be integrated in 1.4.2? > Ah yes. In fact, I was originally thinking of 1.4.2-s version > (OpenJUMP including most useful extensions), but as you made many > improvements, it could be included in 1.4.1-s version (I'm preparing > today and will hopefully release it today or tomorrow) and in OJ core > 1.4.2. In the last case, you may have to prefix your language file > keys before including them in the main language file. > how about integrating the latest version by using the latest distro and i will integrate geomconv into trunk sometime soon. any reason not to put the language files under src/language/geomconv ? the main files are overcrowded already. ede ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Jump-pilot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
