[VOTE] Promote Localization Tools Maven Plugin from the sandbox

[dennisl-2]

Hi

I'd like to move towards a first release of Localization Tools Maven
Plugin. The first step is to promote it out of the sandbox. A SNAPSHOT
of the latest source has been deployed to the SNAPSHOT-repository and
the site has been deployed here:

   http://mojo.codehaus.org/l10n-maven-plugin/

Please vote for the promotion of l10n plugin from the sandbox:

+1 [ ]
  0 [ ]
-1 [ ]

The vote is open for at least 72 hours.


+1 from me

--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Vincent Siveton]

+1

Vincent

2008/3/8, Dennis Lundberg <dennisl@...>:

> Hi
>
>  I'd like to move towards a first release of Localization Tools Maven
>  Plugin. The first step is to promote it out of the sandbox. A SNAPSHOT
>  of the latest source has been deployed to the SNAPSHOT-repository and
>  the site has been deployed here:
>
>    http://mojo.codehaus.org/l10n-maven-plugin/
>
>  Please vote for the promotion of l10n plugin from the sandbox:
>
>  +1 [ ]
>   0 [ ]
>  -1 [ ]
>
>  The vote is open for at least 72 hours.
>
>
>  +1 from me
>
>
>  --
>  Dennis Lundberg
>
>  ---------------------------------------------------------------------
>  To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Benjamin Bentmann]

> Please vote for the promotion of l10n plugin from the sandbox:

+1, any plugin out of the sandbox is less hassle for uses to use it and
provide feedback.

Before the actual release, somebody could take care of these:

Both mojos use j.l.String instead of j.i.File for file parameters and are
therefore subject to relative path issues.

The status report has a user-accessible parameter taking model.Resource
which is a further source of relative paths and needs manual resolving (like
in MRESOURCES-32).

It seems odd that the l10n:pseudo operates on "target/classes" (hence taking
generated/filtered resources into account) while l10n:report by default only
operates on the static resources in "src/main/resources" etc.

The plugin's own localization support should be completed
(L10NStatusReport.java:559)

A sample report from the plugin about its own bundles would be a nice
addition to its own site docs. I guess we could find some cute guys to add
further bundles to make it more interesting ;-)

Checkstyle errors could be fixed. Especially the report's renderBody() might
benefit from refactoring out the analysis stuff from the actual report
generation.


Benjamin


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[dennisl-2]

Benjamin Bentmann wrote:
>> Please vote for the promotion of l10n plugin from the sandbox:
>
> +1, any plugin out of the sandbox is less hassle for uses to use it and
> provide feedback.
>
> Before the actual release, somebody could take care of these:

Thanks for pointing these out!

> Both mojos use j.l.String instead of j.i.File for file parameters and are
> therefore subject to relative path issues.

Fixed

> The status report has a user-accessible parameter taking model.Resource
> which is a further source of relative paths and needs manual resolving
> (like
> in MRESOURCES-32).

I'm not sure that this really needs to be accessible to the user. If it
doesn't need to, we can make it read-only. That would solve the problem,
right?

> It seems odd that the l10n:pseudo operates on "target/classes" (hence
> taking
> generated/filtered resources into account) while l10n:report by default
> only
> operates on the static resources in "src/main/resources" etc.

Not sure why it is like that.

> The plugin's own localization support should be completed
> (L10NStatusReport.java:559)

Fixed

> A sample report from the plugin about its own bundles would be a nice
> addition to its own site docs. I guess we could find some cute guys to
> add further bundles to make it more interesting ;-)

Report added. Now I'm waiting for translations ;-)

> Checkstyle errors could be fixed. Especially the report's renderBody()
> might
> benefit from refactoring out the analysis stuff from the actual report
> generation.

That is one big method! I don't dare chop that up.

> Benjamin

--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Benjamin Bentmann]

>> The status report has a user-accessible parameter taking model.Resource
>> which is a further source of relative paths and needs manual resolving
>> (like
>> in MRESOURCES-32).
>
> I'm not sure that this really needs to be accessible to the user. If it
> doesn't need to, we can make it read-only.

Although the Maven Resources Plugin allows to customize its corresponding
parameter via its plugin config, too, I agree its best to make this list
read-only. The POM already provides a central means to specify resources and
given the plugin's support to specify includes/excludes, I see no need for
the resources parameter.

Besides, hiding this parameter from the user would allow us to transparently
switch l10n:report to use "target/classes" like l10n:pseudo does already.

> That would solve the problem, right?

Yes. The background: The resources a plugin retrieves via
${project.build.resources} are properly resolved thanks to the
DefaultPathTranslator.alignToBaseDirectory(), i.e. Resource.getDirectory()
will always deliver absolute paths here. However, path translation does not
kick in if a user manually specifies Resource in the plugin config because
the directory field is for some unlucky reason only a String and not a File
such that it doesn't get aligned automatically.

>> It seems odd that the l10n:pseudo operates on "target/classes" (hence
>> taking
>> generated/filtered resources into account) while l10n:report by default
>> only
>> operates on the static resources in "src/main/resources" etc.
>
> Not sure why it is like that.

Switching to "target/classes" is also a good preparation if (someday) the
plugin wanted to analyze all derivates of ResourceBundle, i.e. include
class-based bundles like subclasses of ListResourceBundle, too.

> Report added. Now I'm waiting for translations ;-)

German translation is up.

> I don't dare chop that up.

That's how the maintenance nightmare starts... :(

A final note: The plugin's report cannot be run by direct invocation from
the command line for the same reason MCHANGES-88 hit.


Benjamin


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[dennisl-2]

Benjamin Bentmann wrote:

>>> The status report has a user-accessible parameter taking model.Resource
>>> which is a further source of relative paths and needs manual
>>> resolving (like
>>> in MRESOURCES-32).
>>
>> I'm not sure that this really needs to be accessible to the user. If
>> it doesn't need to, we can make it read-only.
>
> Although the Maven Resources Plugin allows to customize its
> corresponding parameter via its plugin config, too, I agree its best to
> make this list read-only. The POM already provides a central means to
> specify resources and given the plugin's support to specify
> includes/excludes, I see no need for the resources parameter.

Done

> Besides, hiding this parameter from the user would allow us to
> transparently switch l10n:report to use "target/classes" like
> l10n:pseudo does already.
>
>> That would solve the problem, right?
>
> Yes. The background: The resources a plugin retrieves via
> ${project.build.resources} are properly resolved thanks to the
> DefaultPathTranslator.alignToBaseDirectory(), i.e.
> Resource.getDirectory() will always deliver absolute paths here.
> However, path translation does not kick in if a user manually specifies
> Resource in the plugin config because the directory field is for some
> unlucky reason only a String and not a File such that it doesn't get
> aligned automatically.
>
>>> It seems odd that the l10n:pseudo operates on "target/classes" (hence
>>> taking
>>> generated/filtered resources into account) while l10n:report by
>>> default only
>>> operates on the static resources in "src/main/resources" etc.
>>
>> Not sure why it is like that.
>
> Switching to "target/classes" is also a good preparation if (someday)
> the plugin wanted to analyze all derivates of ResourceBundle, i.e.
> include class-based bundles like subclasses of ListResourceBundle, too.

Would that mean throwing out the resources parameter and replacing it
with an inputDirectory parameter, similar to the pseudo mojo?

Milos, what do you think about that?

>> Report added. Now I'm waiting for translations ;-)
>
> German translation is up.

Thanks!

>> I don't dare chop that up.
>
> That's how the maintenance nightmare starts... :(

Right, perhaps Milos can have a look at it?

> A final note: The plugin's report cannot be run by direct invocation
> from the command line for the same reason MCHANGES-88 hit.

I fixed this by downgrading to doxia 1.0-alpha-7.

>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Benjamin Bentmann]

>> Switching to "target/classes" is also a good preparation if (someday) the
>> plugin wanted to analyze all derivates of ResourceBundle, i.e. include
>> class-based bundles like subclasses of ListResourceBundle, too.
>
> Would that mean throwing out the resources parameter and replacing it with
> an inputDirectory parameter, similar to the pseudo mojo?

Yes, we would this way unify the configuration of both mojos regarding their
inputs (maybe allow some code sharing?). If we do the switch, the report
would also need
  @execute phase="process-resources"
to ensure the stuff is really there.


Benjamin


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[dennisl-2]

The vote to promote Localization Tools Maven Plugin from the sandbox has
passed with the following votes:

+1: Dennis Lundberg, Vincent Siveton, Benjamin Bentmann

No other votes.

I'll proceed with the promotion.

Dennis Lundberg wrote:

> Hi
>
> I'd like to move towards a first release of Localization Tools Maven
> Plugin. The first step is to promote it out of the sandbox. A SNAPSHOT
> of the latest source has been deployed to the SNAPSHOT-repository and
> the site has been deployed here:
>
>   http://mojo.codehaus.org/l10n-maven-plugin/
>
> Please vote for the promotion of l10n plugin from the sandbox:
>
> +1 [ ]
>  0 [ ]
> -1 [ ]
>
> The vote is open for at least 72 hours.
>
>
> +1 from me
>

--
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

On Sun, Mar 9, 2008 at 1:10 PM, Dennis Lundberg <dennisl@...> wrote:

> Benjamin Bentmann wrote:
>  >>> The status report has a user-accessible parameter taking model.Resource
>  >>> which is a further source of relative paths and needs manual
>  >>> resolving (like
>  >>> in MRESOURCES-32).
>  >>
>  >> I'm not sure that this really needs to be accessible to the user. If
>  >> it doesn't need to, we can make it read-only.
>  >
>  > Although the Maven Resources Plugin allows to customize its
>  > corresponding parameter via its plugin config, too, I agree its best to
>  > make this list read-only. The POM already provides a central means to
>  > specify resources and given the plugin's support to specify
>  > includes/excludes, I see no need for the resources parameter.
>
>  Done
>
>
>  > Besides, hiding this parameter from the user would allow us to
>  > transparently switch l10n:report to use "target/classes" like
>  > l10n:pseudo does already.
>  >
>  >> That would solve the problem, right?
>  >
>  > Yes. The background: The resources a plugin retrieves via
>  > ${project.build.resources} are properly resolved thanks to the
>  > DefaultPathTranslator.alignToBaseDirectory(), i.e.
>  > Resource.getDirectory() will always deliver absolute paths here.
>  > However, path translation does not kick in if a user manually specifies
>  > Resource in the plugin config because the directory field is for some
>  > unlucky reason only a String and not a File such that it doesn't get
>  > aligned automatically.
>  >
>  >>> It seems odd that the l10n:pseudo operates on "target/classes" (hence
>  >>> taking
>  >>> generated/filtered resources into account) while l10n:report by
>  >>> default only
>  >>> operates on the static resources in "src/main/resources" etc.
>  >>
>  >> Not sure why it is like that.
>  >
>  > Switching to "target/classes" is also a good preparation if (someday)
>  > the plugin wanted to analyze all derivates of ResourceBundle, i.e.
>  > include class-based bundles like subclasses of ListResourceBundle, too.
>
>  Would that mean throwing out the resources parameter and replacing it
>  with an inputDirectory parameter, similar to the pseudo mojo?
>
>  Milos, what do you think about that?
>

possibly. I've started out with the pseudolocalization and that one
needs all the resources to end up in the right place for the inclusion
in the jar. And it seemed that processing resources is somewhat
unreliable as the resources can be filtered, can be dumped in
different location than in the sources etc. So I took the actual
output as processed by the resources plugin and did my own tweaks
there.

The report doesn't have this constraint (as it's own output doesn't
end up in the jar and can be aligned with the original sources in
src/main/resources. The processing done by resources-plugin doesn't
matter here..

>
>  >> Report added. Now I'm waiting for translations ;-)
>  >
>  > German translation is up.
>
>  Thanks!
>
>
>  >> I don't dare chop that up.
>  >
>  > That's how the maintenance nightmare starts... :(
>
>  Right, perhaps Milos can have a look at it?

and what's the problem there?


Milos

>
>
>  > A final note: The plugin's report cannot be run by direct invocation
>  > from the command line for the same reason MCHANGES-88 hit.
>
>  I fixed this by downgrading to doxia 1.0-alpha-7.
>
>
>  >
>  >
>  > Benjamin
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe from this list, please visit:
>  >
>  >    http://xircles.codehaus.org/manage_email
>  >
>  >
>  >
>
>
>  --
>  Dennis Lundberg
>
>
>
>  ---------------------------------------------------------------------
>  To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

a late +1 from and and thanks to Dennis for making it happen.

Milos

On Tue, Mar 11, 2008 at 7:47 PM, Dennis Lundberg <dennisl@...> wrote:

> The vote to promote Localization Tools Maven Plugin from the sandbox has
>  passed with the following votes:
>
>  +1: Dennis Lundberg, Vincent Siveton, Benjamin Bentmann
>
>  No other votes.
>
>  I'll proceed with the promotion.
>
>
>
>  Dennis Lundberg wrote:
>  > Hi
>  >
>  > I'd like to move towards a first release of Localization Tools Maven
>  > Plugin. The first step is to promote it out of the sandbox. A SNAPSHOT
>  > of the latest source has been deployed to the SNAPSHOT-repository and
>  > the site has been deployed here:
>  >
>  >   http://mojo.codehaus.org/l10n-maven-plugin/
>  >
>  > Please vote for the promotion of l10n plugin from the sandbox:
>  >
>  > +1 [ ]
>  >  0 [ ]
>  > -1 [ ]
>  >
>  > The vote is open for at least 72 hours.
>  >
>  >
>  > +1 from me
>  >
>
>
>  --
>  Dennis Lundberg
>
>  ---------------------------------------------------------------------
>  To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email