You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by df...@apache.org on 2005/02/15 15:38:37 UTC
svn commit: r153937 - jakarta/commons/sandbox/i18n/trunk/project.properties
jakarta/commons/sandbox/i18n/trunk/project.xml
Author: dflorey
Date: Tue Feb 15 06:38:33 2005
New Revision: 153937
URL: http://svn.apache.org/viewcvs?view=rev&rev=153937
Log:
Added JUnit-Test infrastructure
Modified:
jakarta/commons/sandbox/i18n/trunk/project.properties
jakarta/commons/sandbox/i18n/trunk/project.xml
Modified: jakarta/commons/sandbox/i18n/trunk/project.properties
URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/i18n/trunk/project.properties?view=diff&r1=153936&r2=153937
==============================================================================
--- jakarta/commons/sandbox/i18n/trunk/project.properties (original)
+++ jakarta/commons/sandbox/i18n/trunk/project.properties Tue Feb 15 06:38:33 2005
@@ -27,8 +27,3 @@
# M A V E N J A R O V E R R I D E
# ------------------------------------------------------------------------
maven.jar.override = on
-
-# ------------------------------------------------------------------------
-# Jars set explicity by path.
-# ------------------------------------------------------------------------
-maven.jar.commons-xmlio = ${basedir}/lib/commons-xmlio-0.1pre.jar
Modified: jakarta/commons/sandbox/i18n/trunk/project.xml
URL: http://svn.apache.org/viewcvs/jakarta/commons/sandbox/i18n/trunk/project.xml?view=diff&r1=153936&r2=153937
==============================================================================
--- jakarta/commons/sandbox/i18n/trunk/project.xml (original)
+++ jakarta/commons/sandbox/i18n/trunk/project.xml Tue Feb 15 06:38:33 2005
@@ -32,7 +32,7 @@
<shortDescription>Commons I18n</shortDescription>
<description>Internationalization package</description>
- <currentVersion>0.2</currentVersion>
+ <currentVersion>0.3</currentVersion>
<versions>
<version>
<id>1</id>
@@ -73,15 +73,25 @@
</contributors>
<dependencies>
- <dependency>
- <id>commons-xmlio</id>
- <version>0.1pre</version>
- </dependency>
</dependencies>
<build>
<nagEmailAddress>commons-dev@jakarta.apache.org</nagEmailAddress>
<sourceDirectory>src/java</sourceDirectory>
+ <unitTestSourceDirectory>src/test</unitTestSourceDirectory>
+
+ <!-- Unit test cases -->
+ <unitTest>
+ <includes>
+ <include>**/*Test.java</include>
+ </includes>
+<resources>
+ <resource>
+ <directory>${basedir}/src/test</directory>
+ </resource>
+ </resources>
+
+ </unitTest>
</build>
<reports>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
AW: [i18n] man available
Posted by Daniel Florey <da...@web.de>.
Hi Woody,
Thanks for your help! See comments inline...
Daniel
> -----Ursprüngliche Nachricht-----
> Von: commons-dev-return-68013-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-68013-daniel.florey=web.de@jakarta.apache.org]
> Im Auftrag von Anaximandro (Woody)
> Gesendet: Mittwoch, 16. Februar 2005 11:17
> An: Jakarta Commons Developers List
> Betreff: Re: [i18n] man available
>
> Hello Daniel,
>
> Yup, the ConfigManager not prove to be very usefull. This class is
> increasing the coupling level to give me a few features set (the con
> figuration features itself) and gave me much more code to delegate ...
>
> But you don't think necessary some code to configure the behaviours of
> this component? For instance: in your version when the component not
> find one message id they throw one unchecked exception. The component
> dont't force me to write one try catch block for each LocalizedEntry but
> force me to write all messages ids in their respective resource to avoid
> one exception. Avoid try catch blocks is cool, very cool, but this only
> make my code more clean, however the cost to do this is high: I must write
> the messages id (at least) to don't break the application, but if I forget
> one id the application will break in same mode.
I'll add some examples to the website that show how to deal with missing
messages, ok?
>
> Using some code to configure this helps in this situation. I can talk to
> component: hey pal, use the message id or entry id as default when you not
> find someone. Don't throw an exception, instead, write this in log. I
> will write these messages later ok?
I try to avoid including logging into the i18n component as there are so
many different loggers around. I just removed the commons-xmlio dependencies
by using sax-parsing instead, so my goal is to achieve a component with no
dependencies.
If we need logging, I'd vote for standard jdk 1.4-logging. What do you
think?
>
> Hence I think is better to leave this decision to the user component. I
> know you wanna a small and easy to use component, I want the same think,
> but ... I think is more easy to use a componente wich can be configured
> than one wich we can't do this.
>
> Sorry if I'm talking to much, I really wanna help but my english make this
> more hard than really is.
>
> Only one MessageManager? no getInstance? As I see the problem exists
> when many threads (with different Locales) try to get a message. I don't
> see any problem with diferent applications (sure, the unique ID is requi
> red). If you use only one MessageManager you will need to always provide
> the desired Locale (in constructor or in getXXX method) because there is
> no more a place to store a default Locale info since the older place
> (setLocale/getLocale) will be shared by this threads. More than this,
> doing this will bestrew Locale info in resulting client code making this
> more hard to update. Well, this is just my opinion.
It is necessary to provide the desired locale in each getXXX method of the
LocalizedBundle-subclasses. I just removed the ones using the default locale
as this causes additional confusion. If you really want to specify a
thread-specific locale (??) then you need to store it in ThreadLocal.
I'll add a method to set the default locale in the MessageManager if it
should be something different than the VM default locale.
>
> I try to solve this writing the getInstance (as you suggest in email)
> but with this I create another problem: how to link a message with their
> respective manager? Passing this guy as parameter? nope, this is ugly. So
> writing some method to returns the current manager? Yes, make sense, then:
> getCurrentInstance, but, again, I created another problem: I need to write
> monitor code to lock unlock the instance to avoid data corruption (between
> threads). I think this is the last thing I need to close my version. I
> will
> do this (is a little hard to me because I never do this before).
>
> I'm right im my point? I miss something?
>
> Did you find some good idea in my code? If you do I can revise and
> generate
> the apropriate patch to you.
Yes, thanks. I'll add some LocalizedRuntimeException, LocalizedError etc.
and rename the LocalizedError to something more speaking.
>
> Good luck with envinronment (to be honest I need to learn maven, I just
> used eclipse, always redoing the configuration when I need).
Maven is a nice tool, but very bad documented indeed. So it's hard to figure
out how to achieved the desired stuff...
>
> Woody
>
> >Hi Woody,
> >I'm currently trying to improve the maven environment, so that releases
> and
> >tests can easily be done.
> >My goal is to complete the component in the actual state in order to
> build
> a
> >usable release as soon as possible.
> >I've already had a look at your proposed changes. I'd like to include
> some
> >changes into the current version (LocalizedRuntimeException), but I'm not
> >sure with the ConfigManager. This one introduces a lot of complexity.
> >In order to keep the i18n-component very simple my suggestions would be
> to
> >keep only one MessageManager with static methods and advice the user to
> use
> >unique message keys (comparable to java package names). This should avoid
> >trouble when using multiple applications. Agreed?
> >Next steps are to remove misleading methods (as we discussed earlier) and
> to
> >complete the javadocs and provide some more tutorials. This is the part
> >where help would be very much appreciated ;-)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [i18n] man available
Posted by "Anaximandro (Woody)" <ag...@globo.com>.
Hello Daniel,
Yup, the ConfigManager not prove to be very usefull. This class is
increasing the coupling level to give me a few features set (the con
figuration features itself) and gave me much more code to delegate ...
But you don't think necessary some code to configure the behaviours of
this component? For instance: in your version when the component not
find one message id they throw one unchecked exception. The component
dont't force me to write one try catch block for each LocalizedEntry but
force me to write all messages ids in their respective resource to avoid
one exception. Avoid try catch blocks is cool, very cool, but this only
make my code more clean, however the cost to do this is high: I must write
the messages id (at least) to don't break the application, but if I forget
one id the application will break in same mode.
Using some code to configure this helps in this situation. I can talk to
component: hey pal, use the message id or entry id as default when you not
find someone. Don't throw an exception, instead, write this in log. I
will write these messages later ok?
Hence I think is better to leave this decision to the user component. I
know you wanna a small and easy to use component, I want the same think,
but ... I think is more easy to use a componente wich can be configured
than one wich we can't do this.
Sorry if I'm talking to much, I really wanna help but my english make this
more hard than really is.
Only one MessageManager? no getInstance? As I see the problem exists
when many threads (with different Locales) try to get a message. I don't
see any problem with diferent applications (sure, the unique ID is requi
red). If you use only one MessageManager you will need to always provide
the desired Locale (in constructor or in getXXX method) because there is
no more a place to store a default Locale info since the older place
(setLocale/getLocale) will be shared by this threads. More than this,
doing this will bestrew Locale info in resulting client code making this
more hard to update. Well, this is just my opinion.
I try to solve this writing the getInstance (as you suggest in email)
but with this I create another problem: how to link a message with their
respective manager? Passing this guy as parameter? nope, this is ugly. So
writing some method to returns the current manager? Yes, make sense, then:
getCurrentInstance, but, again, I created another problem: I need to write
monitor code to lock unlock the instance to avoid data corruption (between
threads). I think this is the last thing I need to close my version. I will
do this (is a little hard to me because I never do this before).
I'm right im my point? I miss something?
Did you find some good idea in my code? If you do I can revise and generate
the apropriate patch to you.
Good luck with envinronment (to be honest I need to learn maven, I just
used eclipse, always redoing the configuration when I need).
Woody
>Hi Woody,
>I'm currently trying to improve the maven environment, so that releases and
>tests can easily be done.
>My goal is to complete the component in the actual state in order to build
a
>usable release as soon as possible.
>I've already had a look at your proposed changes. I'd like to include some
>changes into the current version (LocalizedRuntimeException), but I'm not
>sure with the ConfigManager. This one introduces a lot of complexity.
>In order to keep the i18n-component very simple my suggestions would be to
>keep only one MessageManager with static methods and advice the user to use
>unique message keys (comparable to java package names). This should avoid
>trouble when using multiple applications. Agreed?
>Next steps are to remove misleading methods (as we discussed earlier) and
to
>complete the javadocs and provide some more tutorials. This is the part
>where help would be very much appreciated ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
AW: [i18n] man available
Posted by Daniel Florey <da...@web.de>.
Hi Woody,
I'm currently trying to improve the maven environment, so that releases and
tests can easily be done.
My goal is to complete the component in the actual state in order to build a
usable release as soon as possible.
I've already had a look at your proposed changes. I'd like to include some
changes into the current version (LocalizedRuntimeException), but I'm not
sure with the ConfigManager. This one introduces a lot of complexity.
In order to keep the i18n-component very simple my suggestions would be to
keep only one MessageManager with static methods and advice the user to use
unique message keys (comparable to java package names). This should avoid
trouble when using multiple applications. Agreed?
Next steps are to remove misleading methods (as we discussed earlier) and to
complete the javadocs and provide some more tutorials. This is the part
where help would be very much appreciated ;-)
Cheers,
Daniel
> -----Ursprüngliche Nachricht-----
> Von: commons-dev-return-67988-daniel.florey=web.de@jakarta.apache.org
> [mailto:commons-dev-return-67988-daniel.florey=web.de@jakarta.apache.org]
> Im Auftrag von agodinhost@globo.com
> Gesendet: Dienstag, 15. Februar 2005 15:51
> An: Jakarta Commons Developers List
> Betreff: [i18n] man available
>
> Hi Daniel,
> Can I help?
>
> Woody
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
[i18n] man available
Posted by ag...@globo.com.
Hi Daniel,
Can I help?
Woody
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org