Thanks Ron.
I've thought a bit about this; avoiding copying those resources is not
easily doable due to classloading issues; so I would propose the changes
that you can see at
https://github.com/resteasy/Resteasy/pull/926 (I
just modified the resteasy-netty4 module, if we agree on this I can fix
all other modules). The most important change is to run the resources
cleanup in prepare-package maven phase, so that a mvn package / mvn
install / mvn integration-test run does not leave the project "dirty"
with test resources in the main tree (no need to rely on next mvn clean
run).
Sounds good. Don't know why I didn't think of that ...
On top of that I would refactor all TestMessages_* test into
I18nTestMessages_* in order to run them in a separate maven surefire
execution; that way only the i18n tests would need to run in fork mode.
I could be wrong, but I think that, in branch 3.0.x, at least, all of
the i18n tests would be in org/jboss/resteasy/test/i18n/**. That may not
be true after refactoring, though.
Afterwards, we could even decide to enable the i18n profile on Travis CI
runs.
WDYT?
Cheers
Alessio
Il 03/09/2016 18:07, Ron Sigal ha scritto:
> Hi Alessio,
>
>
> On 09/02/2016 06:33 PM, Alessio Soldano wrote:
>> OK, cool, thanks for explanation, now it's a bit clearer to me (and this
>> adds to what Martin was writing in the other thread "Re: RESTEasy
>> providers tests refactoring" few days ago).
>> What is actually tested though? Isn't JBoss Logging generating the
>> needed i18n classes for us?
> Well, yes and no. In the absence of message bundles, JBoss Logging will
> just use the default values in, for example,
> org.jboss.resteasy.resteasy_jaxrs.i18n.Messages in resteasy-jaxrs. If
> you want anything other than the default, you have to create message
> bundle files, and JBoss Logging can create a template bundle file. I
> don't remember the exact mechanism at the moment, but it's how I
> created, for example,
> resteasy-jaxrs/src/test/resources/i18n/Messages.i18n_xx.properties, by
> modifying the template file.
>> Do we really need those tests to cover any
>> i18n message that we add?
> Well, no, not really. Changing
> org.jboss.resteasy.resteasy_jaxrs.i18n.Messages, for examples, would
> change the message bundle template, so one could generate new message
> bundles, but, in fact, I have almost never (or maybe never) done that.
> The tests mostly test the first and last messages, plus a few that
> looked a little special for some reason or other. For example, a message
> with an unusual character, or with more than the usual parameters. So,
> adding a new message, unless it's a new last message, wouldn't affect
> the test. Of course, if a new message is special in some way, it might
> be worth testing. That would require rebuilding the message bundles in
> src/test/resources.
>
> Really, the point of the tests was to make sure i18n was working when I
> first did it. Just adding a new message isn't likely to break it.
>
>> This said, perhaps we can figure out a way to avoid copying test
>> resources into main tree, I might try an alternative approach here by
>> tuning the classloader that's used in the test to load resources, so
>> that it picks them where they are in test area. Will think about it in
>> the future...
>>
>> Cheers
>> Alessio
>>
>> Il 02/09/2016 23:20, Ron Sigal ha scritto:
>>> Hey Alessio,
>>>
>>> Those i18n profiles are used to test logging in the presence of a
>>> non-default locale. In particular, the tests set a locale which brings
>>> in message bundles from src/main/resources. Most of the time, the
>>> bundles live in src/test/resources because they are purely for testing
>>> and shouldn't ship in the jars. Notice the presence of
>>>
>>>> <plugin>
>>>> <artifactId>maven-clean-plugin</artifactId>
>>>> <configuration>
>>>> <filesets>
>>>> <fileset>
>>>> <directory>src/main/resources</directory>
>>>> <includes>
>>>> <include>org/**</include>
>>>> </includes>
>>>> </fileset>
>>>> </filesets>
>>>> </configuration>
>>>> </plugin>
>>> in Resteasy/pom.xml, which cleans up the bundles whenever mvn clean is
>>> executed.
>>>
>>> One other issue, by the way, is the fact that, as far as I can tell,
>>> setting a default locale in a JVM can't be reversed. The i18n tests use
>>> multiple default locales, e.g., "en" and "xx", to bring
in different
>>> message bundles, so they need separate JVMs. That's why the i18n
>>> profiles set
>>>
>>>> <plugin>
>>>> <groupId>org.apache.maven.plugins</groupId>
>>>> <artifactId>maven-surefire-plugin</artifactId>
>>>> <configuration>
>>>> <reuseForks>false</reuseForks>
>>>> </configuration>
>>>> </plugin>
>>> <reuseForks/> to false.
>>>
>>> These i18n profiles have been sitting there quietly for quite a while
>>> now. They were added mostly to test that I did the i18n conversion
>>> properly. Since then, there hasn't really been any reason to run them,
>>> except, maybe every couple of years, we add a new log message. ;-)
>>>
>>> Or, in Latin, mea culpa. Hope that helps.
>>>
>>> -Ron
>>>
>>> On 09/02/2016 12:15 PM, Alessio Soldano wrote:
>>>> Hi,
>>>>
>>>> while fixing an issue with i18n messages in the Vert.x server adapter
>>>> (basically the same base id of Netty4 adapter was used, hence resulting
>>>> in id clashes), I stumbled upon the i18n maven profile that can be found
>>>> in many pom.xml files in the project. Can anybody please explain
>>>> how/when that is used?
>>>>
>>>> In particular, when that profile is on, I find what the
>>>> maven-resources-plugin does a bit suspicious; see for example
>>>>
https://github.com/resteasy/Resteasy/blob/5b4823ff60d73fdf48f7c0b70b2b4ee...
>>>> , files from the test tree are copied into the main tree (hence
>>>> potentially polluting the built artifacts).
>>>>
>>>> Thanks
>>>>
>>>> Alessio
>>>>