[Math] What about issue 361?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[Math] What about issue 361?

Gilles Sadowski
Hi.

There haven't been any comments about the demo files I've uploaded
on April 1, concerning this issue:
  https://issues.apache.org/jira/browse/MATH-361

Is there an implied policy of "silence gives consent"?

Someone had suggested creating a branch. That would be a way to set up a
fully working demo of the proposed changes.
I would also need someone knowledgeable in Maven to perform modifications
that would allow the creation of multiple JARs, and set a dependency to the
"CAL10N" library. [A compile-time dependency for Commons-Math itself, and a
runtime dependency for the code that will be a bridge to the "CAL10N"
external library.]


Best regards,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] What about issue 361?

sebb-2-2
On 27/04/2010, Gilles Sadowski <[hidden email]> wrote:
> Hi.
>
>  There haven't been any comments about the demo files I've uploaded
>  on April 1, concerning this issue:
>   https://issues.apache.org/jira/browse/MATH-361
>
>  Is there an implied policy of "silence gives consent"?
>

Apache does have a concept of lazy consensus, but that applies to
votes, and the vote e-mail will say that it is using lazy consensus.

I don't think it normally applies to JIRA issues.

>  Someone had suggested creating a branch. That would be a way to set up a
>  fully working demo of the proposed changes.

It will be much easier to understand the changes if they are presented as code.

It would also be possible to set up a sandbox project containing a few
example classes from the Math codebase. That might be easier to
comprehend as it would be a lot smaller.

By the way, there are no AL headers in the code. These need to be added.

Also, the Cal10nAdapter class is in a strange package - why not put it
in a commons package?

>  I would also need someone knowledgeable in Maven to perform modifications
>  that would allow the creation of multiple JARs, and set a dependency to the
>  "CAL10N" library. [A compile-time dependency for Commons-Math itself, and a
>  runtime dependency for the code that will be a bridge to the "CAL10N"
>  external library.]

Not sure why you need multiple jars.

>
>  Best regards,
>  Gilles
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: [hidden email]
>  For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] What about issue 361?

Gilles Sadowski
> >  There haven't been any comments about the demo files I've uploaded
> >  on April 1, concerning this issue:
> >   https://issues.apache.org/jira/browse/MATH-361
> >
> >  Is there an implied policy of "silence gives consent"?
> >
>
> Apache does have a concept of lazy consensus, but that applies to
> votes, and the vote e-mail will say that it is using lazy consensus.
>
> I don't think it normally applies to JIRA issues.
>
> >  Someone had suggested creating a branch. That would be a way to set up a
> >  fully working demo of the proposed changes.
>
> It will be much easier to understand the changes if they are presented as code.

They are, in the files posted on the JIRA page of the issue.
The sample code is fully working.

> It would also be possible to set up a sandbox project containing a few
> example classes from the Math codebase. That might be easier to
> comprehend as it would be a lot smaller.
>
> By the way, there are no AL headers in the code. These need to be added.
>
> Also, the Cal10nAdapter class is in a strange package - why not put it
> in a commons package?

As I stated, this is a demo code, not a patch and not intended to be
included as is.

> >  I would also need someone knowledgeable in Maven to perform modifications
> >  that would allow the creation of multiple JARs, and set a dependency to the
> >  "CAL10N" library. [A compile-time dependency for Commons-Math itself, and a
> >  runtime dependency for the code that will be a bridge to the "CAL10N"
> >  external library.]
>
> Not sure why you need multiple jars.

To enable runtime selection of the L10N implementation, letting the user
choose whether he wants to depend on the CAL10N external library or whether
he is happy with the default (English) message text.

The functionality is probably not easily figured out from a quick glance at
the code, that's why I'm asking how we can proceed from here so that people
can try it out without too much extra work (such as I did to test the files
I uploaded to JIRA).


--
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] What about issue 361?

Luc Maisonobe

----- "Gilles Sadowski" <[hidden email]> a écrit :

> > >  There haven't been any comments about the demo files I've
> uploaded
> > >  on April 1, concerning this issue:
> > >   https://issues.apache.org/jira/browse/MATH-361

I'm sorry, but I simply didn't find time. I am very busy these times and will not find much time before a few weeks. I'll try to have a look though.

> > >
> > >  Is there an implied policy of "silence gives consent"?
> > >
> >
> > Apache does have a concept of lazy consensus, but that applies to
> > votes, and the vote e-mail will say that it is using lazy
> consensus.
> >
> > I don't think it normally applies to JIRA issues.
> >
> > >  Someone had suggested creating a branch. That would be a way to
> set up a
> > >  fully working demo of the proposed changes.
> >
> > It will be much easier to understand the changes if they are
> presented as code.
>
> They are, in the files posted on the JIRA page of the issue.
> The sample code is fully working.
>
> > It would also be possible to set up a sandbox project containing a
> few
> > example classes from the Math codebase. That might be easier to
> > comprehend as it would be a lot smaller.
> >
> > By the way, there are no AL headers in the code. These need to be
> added.
> >
> > Also, the Cal10nAdapter class is in a strange package - why not put
> it
> > in a commons package?
>
> As I stated, this is a demo code, not a patch and not intended to be
> included as is.
>
> > >  I would also need someone knowledgeable in Maven to perform
> modifications
> > >  that would allow the creation of multiple JARs, and set a
> dependency to the
> > >  "CAL10N" library. [A compile-time dependency for Commons-Math
> itself, and a
> > >  runtime dependency for the code that will be a bridge to the
> "CAL10N"
> > >  external library.]
> >
> > Not sure why you need multiple jars.
>
> To enable runtime selection of the L10N implementation, letting the
> user
> choose whether he wants to depend on the CAL10N external library or
> whether
> he is happy with the default (English) message text.

I think I may have missed something here. Do you say that if we go this way it will mean people should either have to have an additional dependency or no translation at all ? This would be a very bad thing to me. My previous understanding was that the external dependency simply improved development and languages plugin, but that the system could still work without it.

Luc

>
> The functionality is probably not easily figured out from a quick
> glance at
> the code, that's why I'm asking how we can proceed from here so that
> people
> can try it out without too much extra work (such as I did to test the
> files
> I uploaded to JIRA).
>
>
> --
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] What about issue 361?

Gilles Sadowski
> > > [...]
> > >
> > > Not sure why you need multiple jars.
> >
> > To enable runtime selection of the L10N implementation, letting the
> > user
> > choose whether he wants to depend on the CAL10N external library or
> > whether
> > he is happy with the default (English) message text.
>
> I think I may have missed something here. Do you say that if we go this
> way it will mean people should either have to have an additional
> dependency or no translation at all ? This would be a very bad thing
> to me. My previous understanding was that the external dependency
> simply improved development and languages plugin, but that the system
> could still work without it.

Well, my point (cf. the lengthy mail referred to on the JIRA page) was that
"translation" is an additional functionality layer. Now, the library
"CAL10N" offers:
 - easy testing of translation coverage (compile-time or, more exactly,
   development-time if end-users don't want to be able to run the Junit
   tests)
 - translation at runtime (i.e. a runtime external dependency)

So I don't see why we should re-invent the wheel just to avoid an optional
dependency on a tiny special-purpose external library.

Of course, if you insist on doing that, you will always be able to provide
a "home-made" implementation of the "Framework" (i.e. in place of using
"CAL10N"). But this implementation must also be optional, so that it must
be provided in a separate JAR which the user can declare in his dependencies
if he wants to use it instead of the default error handling (which will be:
no dependency, no translation).
I think that this is arguably the most flexible position: You don't impose
translation while providing an easy, free software, means to get
functionality.


Best,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] What about issue 361?

sebb-2-2
In reply to this post by Gilles Sadowski
On 27/04/2010, Gilles Sadowski <[hidden email]> wrote:

> > >  There haven't been any comments about the demo files I've uploaded
>  > >  on April 1, concerning this issue:
>  > >   https://issues.apache.org/jira/browse/MATH-361
>  > >
>  > >  Is there an implied policy of "silence gives consent"?
>  > >
>  >
>  > Apache does have a concept of lazy consensus, but that applies to
>  > votes, and the vote e-mail will say that it is using lazy consensus.
>  >
>  > I don't think it normally applies to JIRA issues.
>  >
>  > >  Someone had suggested creating a branch. That would be a way to set up a
>  > >  fully working demo of the proposed changes.
>  >
>  > It will be much easier to understand the changes if they are presented as code.
>
>
> They are, in the files posted on the JIRA page of the issue.
>  The sample code is fully working.

There don't seem to be any properties files.
It would be helpful to have say French and English files for testing.

>
>  > It would also be possible to set up a sandbox project containing a few
>  > example classes from the Math codebase. That might be easier to
>  > comprehend as it would be a lot smaller.
>  >
>  > By the way, there are no AL headers in the code. These need to be added.
>  >
>  > Also, the Cal10nAdapter class is in a strange package - why not put it
>  > in a commons package?
>
>
> As I stated, this is a demo code, not a patch and not intended to be
>  included as is.
>
>
>  > >  I would also need someone knowledgeable in Maven to perform modifications
>  > >  that would allow the creation of multiple JARs, and set a dependency to the
>  > >  "CAL10N" library. [A compile-time dependency for Commons-Math itself, and a
>  > >  runtime dependency for the code that will be a bridge to the "CAL10N"
>  > >  external library.]
>  >
>  > Not sure why you need multiple jars.
>
>
> To enable runtime selection of the L10N implementation, letting the user
>  choose whether he wants to depend on the CAL10N external library or whether
>  he is happy with the default (English) message text.

Might be possible to do that by checking if the CAL10N jar is present
- if not, fall back on the default.

But I'm not sure it's worth having special processing just some users
of the English version don't have to download the additional jar.

AIUI, the English messages will need to be defined both in the
standalone NoDepFramework class and in the math_messages_en.properties
file. That is just making extra work.

Either we do this and include the CAL10N dependency, or we don't use
this method at all.

>  The functionality is probably not easily figured out from a quick glance at
>  the code, that's why I'm asking how we can proceed from here so that people
>  can try it out without too much extra work (such as I did to test the files
>  I uploaded to JIRA).
>

That's why I suggested a sandbox project.

>
>  --
>
> Gilles
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: [hidden email]
>  For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] What about issue 361?

Bill Barker


--------------------------------------------------
From: "sebb" <[hidden email]>
Sent: Tuesday, April 27, 2010 4:57 PM
To: "Commons Developers List" <[hidden email]>
Subject: Re: [Math] What about issue 361?

> On 27/04/2010, Gilles Sadowski <[hidden email]> wrote:
>> > >  There haven't been any comments about the demo files I've uploaded
>>  > >  on April 1, concerning this issue:
>>  > >   https://issues.apache.org/jira/browse/MATH-361
>>  > >
>>  > >  Is there an implied policy of "silence gives consent"?
>>  > >
>>  >
>>  > Apache does have a concept of lazy consensus, but that applies to
>>  > votes, and the vote e-mail will say that it is using lazy consensus.
>>  >
>>  > I don't think it normally applies to JIRA issues.
>>  >
>>  > >  Someone had suggested creating a branch. That would be a way to set
>> up a
>>  > >  fully working demo of the proposed changes.
>>  >
>>  > It will be much easier to understand the changes if they are presented
>> as code.
>>
>>
>> They are, in the files posted on the JIRA page of the issue.
>>  The sample code is fully working.
>
> There don't seem to be any properties files.
> It would be helpful to have say French and English files for testing.
>
>>
>>  > It would also be possible to set up a sandbox project containing a few
>>  > example classes from the Math codebase. That might be easier to
>>  > comprehend as it would be a lot smaller.
>>  >
>>  > By the way, there are no AL headers in the code. These need to be
>> added.
>>  >
>>  > Also, the Cal10nAdapter class is in a strange package - why not put it
>>  > in a commons package?
>>
>>
>> As I stated, this is a demo code, not a patch and not intended to be
>>  included as is.
>>
>>
>>  > >  I would also need someone knowledgeable in Maven to perform
>> modifications
>>  > >  that would allow the creation of multiple JARs, and set a
>> dependency to the
>>  > >  "CAL10N" library. [A compile-time dependency for Commons-Math
>> itself, and a
>>  > >  runtime dependency for the code that will be a bridge to the
>> "CAL10N"
>>  > >  external library.]
>>  >
>>  > Not sure why you need multiple jars.
>>
>>
>> To enable runtime selection of the L10N implementation, letting the user
>>  choose whether he wants to depend on the CAL10N external library or
>> whether
>>  he is happy with the default (English) message text.
>
> Might be possible to do that by checking if the CAL10N jar is present
> - if not, fall back on the default.
>
> But I'm not sure it's worth having special processing just some users
> of the English version don't have to download the additional jar.
>
> AIUI, the English messages will need to be defined both in the
> standalone NoDepFramework class and in the math_messages_en.properties
> file. That is just making extra work.
>
> Either we do this and include the CAL10N dependency, or we don't use
> this method at all.
>

Yes, I agree.  But would also be -0.5 on changing the packaging before
math-3.0.

>>  The functionality is probably not easily figured out from a quick glance
>> at
>>  the code, that's why I'm asking how we can proceed from here so that
>> people
>>  can try it out without too much extra work (such as I did to test the
>> files
>>  I uploaded to JIRA).
>>
>
> That's why I suggested a sandbox project.
>

+1

>>
>>  --
>>
>> Gilles
>>
>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: [hidden email]
>>  For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] What about issue 361?

Gilles Sadowski
In reply to this post by sebb-2-2
> > They are, in the files posted on the JIRA page of the issue.
> >  The sample code is fully working.
>
> There don't seem to be any properties files.
> It would be helpful to have say French and English files for testing.

You are right; sorry. I've just attached an example.

> >  [...]
> >  > Not sure why you need multiple jars.
> >
> >
> > To enable runtime selection of the L10N implementation, letting the user
> >  choose whether he wants to depend on the CAL10N external library or whether
> >  he is happy with the default (English) message text.
>
> Might be possible to do that by checking if the CAL10N jar is present
> - if not, fall back on the default.

The advantage of the proposed "trick" is that you don't have to write any
checking code.

> But I'm not sure it's worth having special processing just some users
> of the English version don't have to download the additional jar.

What special processing?

The flexibility is to account for user who don't want a runtime dependency.

> AIUI, the English messages will need to be defined both in the
> standalone NoDepFramework class and in the math_messages_en.properties
> file.

That's true. But I don't think it's a big problem. Again, that's the (small)
price to pay for being able to propose a library without localization and
zero dependency while allowing a "pluggable" translation feature.

> That is just making extra work.

I'm willing to do it (it's just writing a few words!). Moreover part of
the proposed changes involves a drastic reduction of the number of messages
(without loosing anything).

> Either we do this and include the CAL10N dependency, or we don't use
> this method at all.
>
> >  The functionality is probably not easily figured out from a quick glance at
> >  the code, that's why I'm asking how we can proceed from here so that people
> >  can try it out without too much extra work (such as I did to test the files
> >  I uploaded to JIRA).
> >
>
> That's why I suggested a sandbox project.

Yes, and how do I do that?


Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] What about issue 361?

sebb-2-2
On 28/04/2010, Gilles Sadowski <[hidden email]> wrote:

> > > They are, in the files posted on the JIRA page of the issue.
>  > >  The sample code is fully working.
>  >
>  > There don't seem to be any properties files.
>  > It would be helpful to have say French and English files for testing.
>
>
> You are right; sorry. I've just attached an example.
>
>  > >  [...]
>
> > >  > Not sure why you need multiple jars.
>  > >
>  > >
>  > > To enable runtime selection of the L10N implementation, letting the user
>  > >  choose whether he wants to depend on the CAL10N external library or whether
>  > >  he is happy with the default (English) message text.
>  >
>  > Might be possible to do that by checking if the CAL10N jar is present
>  > - if not, fall back on the default.
>
>
> The advantage of the proposed "trick" is that you don't have to write any
>  checking code.
>

But it's more effort to build the code, and possibly more effort for the user.

>  > But I'm not sure it's worth having special processing just some users
>  > of the English version don't have to download the additional jar.
>
>
> What special processing?

Creating the extra jars.
Maintaining two copies of the English messages.

>  The flexibility is to account for user who don't want a runtime dependency.
>
>
>  > AIUI, the English messages will need to be defined both in the
>  > standalone NoDepFramework class and in the math_messages_en.properties
>  > file.
>
>
> That's true. But I don't think it's a big problem. Again, that's the (small)
>  price to pay for being able to propose a library without localization and
>  zero dependency while allowing a "pluggable" translation feature.
>
>
>  > That is just making extra work.
>
>
> I'm willing to do it (it's just writing a few words!).

But AFAICT some of the work is ongoing - every new English message has
to be added to two files; any changes likewise.

>  Moreover part of
>  the proposed changes involves a drastic reduction of the number of messages
>  (without loosing anything).
>
>
>  > Either we do this and include the CAL10N dependency, or we don't use
>  > this method at all.
>  >
>  > >  The functionality is probably not easily figured out from a quick glance at
>  > >  the code, that's why I'm asking how we can proceed from here so that people
>  > >  can try it out without too much extra work (such as I did to test the files
>  > >  I uploaded to JIRA).
>  > >
>  >
>  > That's why I suggested a sandbox project.
>
>
> Yes, and how do I do that?

I think you can just create it; best to ask in a separate thread.

>
>  Gilles
>
>  ---------------------------------------------------------------------
>  To unsubscribe, e-mail: [hidden email]
>  For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] What about issue 361?

Gilles Sadowski
> > The advantage of the proposed "trick" is that you don't have to write any
> >  checking code.
> >
>
> But it's more effort to build the code,

Is your computer threatening to go on strike? ;-)

> and possibly more effort for the user.

Certainly: he'll have to add 1 "dependency" line...

> >  > But I'm not sure it's worth having special processing just some users
> >  > of the English version don't have to download the additional jar.
> >
> >
> > What special processing?
>
> Creating the extra jars.

Several JARs are already created (classes, javadoc, sources).
Would it be overly complicated to add the appropriate invocations
to create one other set, for the bridge to "CAL10N"?

> Maintaining two copies of the English messages.

I'll do it. [I bet that arguing on this has already taken more time than
several revisions of these files.]
I must add that maintaining these 2 copies is still *much* less work that
the current way of having a "bundle" for each language, repeating the
English message text in each language file.  Well, in fact, there is already
2 copies of the English messages (one in the code and one in the
"messages_fr" file). So from this particular point-of-view, right now my
proposal is on a par with the current way, and it wan only be better as more
translations are added!

> >  The flexibility is to account for user who don't want a runtime dependency.
> >
> >
> >  > AIUI, the English messages will need to be defined both in the
> >  > standalone NoDepFramework class and in the math_messages_en.properties
> >  > file.
> >
> >
> > That's true. But I don't think it's a big problem. Again, that's the (small)
> >  price to pay for being able to propose a library without localization and
> >  zero dependency while allowing a "pluggable" translation feature.
> >
> >
> >  > That is just making extra work.
> >
> >
> > I'm willing to do it (it's just writing a few words!).
>
> But AFAICT some of the work is ongoing - every new English message has
> to be added to two files; any changes likewise.

It seems that you over-estimate the work, because of the current way of
doing it in CM (cf. the original mail of my proposal).
In the new way, only the creator of a new exception class will have to deal
with the text messages (1 default in the Java code + 1 in the English file
+ 1 for each other language file). From that point on, developers will just
deal with the constructor of that exception class (no text message
involved).

> > Yes, and how do I do that?
>
> I think you can just create it; best to ask in a separate thread.

I can create a project???
Or is it a svn branch?  Even so, I don't think I have the rights to do it.

Best,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] What about issue 361?

sebb-2-2
On 28/04/2010, Gilles Sadowski <[hidden email]> wrote:
> > > The advantage of the proposed "trick" is that you don't have to write any
>  > >  checking code.
>  > >
>  >
>  > But it's more effort to build the code,
>
>
> Is your computer threatening to go on strike? ;-)

No, but you already said that you don't know how to update the Maven
builds to cope with the extra jars.

Also, the standard commons download page generation may need to be
changed to deal with the extra jars.

>
>  > and possibly more effort for the user.
>
>
> Certainly: he'll have to add 1 "dependency" line...
>
>
>  > >  > But I'm not sure it's worth having special processing just some users
>  > >  > of the English version don't have to download the additional jar.
>  > >
>  > >
>  > > What special processing?
>  >
>  > Creating the extra jars.
>
>
> Several JARs are already created (classes, javadoc, sources).
>  Would it be overly complicated to add the appropriate invocations
>  to create one other set, for the bridge to "CAL10N"?

See above.

>
>  > Maintaining two copies of the English messages.
>
>
> I'll do it. [I bet that arguing on this has already taken more time than
>  several revisions of these files.]

This is getting a bit away from the the point.

I think we should either go for CAL10N entirely, or not at all.
Having a fallback that is not essential AND requires ongoing extra
work does not seem sensible to me.

>  I must add that maintaining these 2 copies is still *much* less work that
>  the current way of having a "bundle" for each language, repeating the
>  English message text in each language file.  Well, in fact, there is already
>  2 copies of the English messages (one in the code and one in the
>  "messages_fr" file). So from this particular point-of-view, right now my
>  proposal is on a par with the current way, and it wan only be better as more
>  translations are added!

Yes, but why make it less efficient than it need be?

>
>  > >  The flexibility is to account for user who don't want a runtime dependency.
>  > >
>  > >
>  > >  > AIUI, the English messages will need to be defined both in the
>  > >  > standalone NoDepFramework class and in the math_messages_en.properties
>  > >  > file.
>  > >
>  > >
>  > > That's true. But I don't think it's a big problem. Again, that's the (small)
>  > >  price to pay for being able to propose a library without localization and
>  > >  zero dependency while allowing a "pluggable" translation feature.
>  > >
>  > >
>  > >  > That is just making extra work.
>  > >
>  > >
>  > > I'm willing to do it (it's just writing a few words!).
>  >
>  > But AFAICT some of the work is ongoing - every new English message has
>  > to be added to two files; any changes likewise.
>
>
> It seems that you over-estimate the work, because of the current way of
>  doing it in CM (cf. the original mail of my proposal).
>  In the new way, only the creator of a new exception class will have to deal
>  with the text messages (1 default in the Java code + 1 in the English file
>  + 1 for each other language file). From that point on, developers will just
>  deal with the constructor of that exception class (no text message
>  involved).

I think this will all become a lot clearer when the sandbox project is
established.

We can then see how many SVN updates are needed to maintain the code.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Math] What about issue 361?

Gilles Sadowski
Hi.

> >  > But it's more effort to build the code,
> >
> >
> > Is your computer threatening to go on strike? ;-)
>
> No, but you already said that you don't know how to update the Maven
> builds to cope with the extra jars.

Does that mean "Don't propose anything unless you are able to carry it on
all by yourself"?

> Also, the standard commons download page generation may need to be
> changed to deal with the extra jars.

Hmm, let's go back a little. The proposed mechanism was aimed at providing a
self-contained version of CM, to which some people hold dearly. Now is it
still true that some users *require* a zero-dependency CM? At least I'm not
one of them.
If we remove the "no-dependency" requirement and select CAL10N as our
library of choice for localization, then there is no need for the several
JARs.

> [...]
>
> >  > Maintaining two copies of the English messages.
> >
> >
> > I'll do it. [I bet that arguing on this has already taken more time than
> >  several revisions of these files.]
>
> This is getting a bit away from the the point.
>
> I think we should either go for CAL10N entirely, or not at all.
> Having a fallback that is not essential AND requires ongoing extra
> work does not seem sensible to me.

So does one priority (zero dependency) override the other (extra work)?
I proposed a middle-ground solution, but as I said, I have no problem with
your first alternative. It is indeed easier to implement, and there is
nothing to explain to users.

> >  I must add that maintaining these 2 copies is still *much* less work that
> >  the current way of having a "bundle" for each language, repeating the
> >  English message text in each language file.  Well, in fact, there is already
> >  2 copies of the English messages (one in the code and one in the
> >  "messages_fr" file). So from this particular point-of-view, right now my
> >  proposal is on a par with the current way, and it wan only be better as more
> >  translations are added!
>
> Yes, but why make it less efficient than it need be?

Because of diverse requirements, maybe?

> > It seems that you over-estimate the work, because of the current way of
> >  doing it in CM (cf. the original mail of my proposal).
> >  In the new way, only the creator of a new exception class will have to deal
> >  with the text messages (1 default in the Java code + 1 in the English file
> >  + 1 for each other language file). From that point on, developers will just
> >  deal with the constructor of that exception class (no text message
> >  involved).
>
> I think this will all become a lot clearer when the sandbox project is
> established.

In light of your comments, I now think that we should first decide on
whether external dependencies are acceptable. If they are, then setting up
the Maven system to produce unnecessary artefacts is obviously not a
priority.

> We can then see how many SVN updates are needed to maintain the code.

I don't understand this. [In the code, the overwhelming majority of changes
will be the modification of the "throw" statements. Afterwards, with or
without the "bridge" part of the code, the maintenance will be almost the
same (i.e. apart from the "extra" update of the English properties file).]


Regards,
Gilles

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]