openjump-gis / openjump

OpenJUMP, the Open Source GIS with more than one trick in its kangaroo pocket, takes the leap from svn to git. join the effort!
http://openjump.org
GNU General Public License v2.0
28 stars 14 forks source link

rework I18N as outlined in sf.net ticket #501 #34

Closed edeso closed 3 years ago

edeso commented 3 years ago

https://sourceforge.net/p/jump-pilot/bugs/501/ short summary this'll allow for OJ Core I18N.getInstance().get(String) for instances I18N.getInstance("my.great.extension").get(String) or I18N i18n = I18N.getInstance("my.great.extension") i18n.get(String) i18n.get(String, Object, Object) i18n.get(String, new Object[]{ o1, o2, o3})

edeso commented 3 years ago

This is a RFC. please check if there are any issues you might want resolved.

If it eventually get's committed, let's pls wait with adapting all extensions until the new way to integrate them into the maven build as download-urls is finished, so we can clean up trunk, making it an effectively smaller download in the future (in case some dev just clones the latest commit state for performance reasons).

mukoki commented 3 years ago

Just two questions : In the ticket, you suggested to keep the static get method which would use the default resource bundle, but in the commit, you replaced all I18N.get() call by I18N.getInstance().get() Any reason ?

Can you clarify the procedure for me : am I supposed to merge your PR as soon as this discussion is finished or should I wait for another change ? I'm ready to change extensions code to adapt to this PR, but I'm not sure about the other change you are talking about w.r.t building process.

edeso commented 3 years ago

Just two questions : In the ticket, you suggested to keep the static get method which would use the default resource bundle, but in the commit, you replaced all I18N.get() call by I18N.getInstance().get() Any reason ?

there can be only one method. we can't define a static and an instance with identical signature at the same time

Can you clarify the procedure for me : am I supposed to merge your PR as soon as this discussion is finished or should I wait for another change ? I'm ready to change extensions code to adapt to this PR, but I'm not sure about the other change you are talking about w.r.t building process.

for now, let's talk about it and come to satisfying state (the tests fail currently, working on it).

what i'm envisioning is removing binary-JARs, that currently blow up our Source-Repo (like libs not needed anymore since Maven build works fine, but also Extension-Jars, which can be included via Maven as well), so the Source-Repo will become smaller. ideally we can already include the I18N-fixed extensions that way. two birds, one stone. does that make it clearer?

mukoki commented 3 years ago

Just two questions : In the ticket, you suggested to keep the static get method which would use the default resource bundle, but in the commit, you replaced all I18N.get() call by I18N.getInstance().get() Any reason ?

there can be only one method. we can't define a static and an instance with identical signature at the same time

Of course ;-)

Can you clarify the procedure for me : am I supposed to merge your PR as soon as this discussion is finished or should I wait for another change ? I'm ready to change extensions code to adapt to this PR, but I'm not sure about the other change you are talking about w.r.t building process.

for now, let's talk about it and come to satisfying state (the tests fail currently, working on it).

Any way for me to test ? I can't see the branch your PR is coming from.

what i'm envisioning is removing binary-JARs, that currently blow up our Source-Repo (like libs not needed anymore since Maven build works fine, but also Extension-Jars, which can be included via Maven as well), so the Source-Repo will become smaller. ideally we can already include the I18N-fixed extensions that way. two birds, one stone. does that make it clearer?

Yes, nice ! It means that we have to publish all extensions to a maven repository, right ?

edeso commented 3 years ago

Can you clarify the procedure for me : am I supposed to merge your PR as soon as this discussion is finished or should I wait for another change ? I'm ready to change extensions code to adapt to this PR, but I'm not sure about the other change you are talking about w.r.t building process.

for now, let's talk about it and come to satisfying state (the tests fail currently, working on it).

Any way for me to test ? I can't see the branch your PR is coming from.

small issue. but while at it i'll try to add some junit tests. the branch is in my github account and accessible by all. https://github.com/edeso/openjump/tree/i18n

i prefer to maintain my branches there as to not to clutter the project repo ;)

the link is also below this ticket's headline, on the right side

what i'm envisioning is removing binary-JARs, that currently blow up our Source-Repo (like libs not needed anymore since Maven build works fine, but also Extension-Jars, which can be included via Maven as well), so the Source-Repo will become smaller. ideally we can already include the I18N-fixed extensions that way. two birds, one stone. does that make it clearer?

Yes, nice ! It means that we have to publish all extensions to a maven repository, right ?

thought about it, but that would need packaging them a jar, including accompanying files (think sextantes help files, jython py files etc.). we could probably attach zip's too, but i feel Maven repo would be overkill, so i settled for

at least that's the idea for now. already created a skyprinter test distro https://github.com/openjump-gis/skyprinter-extension/releases