5:51 p.m.
Btw, afaics we have modules having the i18n profile with that
maven-resources-plugin thing, but not having any src/test/resources/i18n
stuff:
alessio@localhost /ssd/resteasy (master) $ tree
resteasy-wadl-undertow-connector/
resteasy-wadl-undertow-connector/
├── pom.xml
└── src
└── main
└── java
└── org
└── jboss
└── resteasy
└── wadl
└── WadlUndertowConnector.java
7 directories, 2 files
alessio@localhost /ssd/resteasy (master) $ tree providers/fastinfoset/
providers/fastinfoset/
├── pom.xml
└── src
└── main
├── java
│ └── org
│ └── jboss
│ └── resteasy
│ └── plugins
│ └── providers
│ ├── fastinfoset
│ │ └── i18n
│ │ └── Messages.java
│ └── jaxb
│ └── fastinfoset
│ ├──
FastInfosetCollectionProvider.java
│ ├── FastinfoSetContext.java
│ ├── FastinfoSetElementProvider.java
│ ├──
FastinfoSetJAXBContextFinder.java
│ ├── FastInfosetMapProvider.java
│ ├── FastinfoSetMarshaller.java
│ ├── FastinfoSetUnmarshaller.java
│ ├──
FastinfoSetXmlRootElementProvider.java
│ ├──
FastinfoSetXmlSeeAlsoProvider.java
│ └── FastinfoSetXmlTypeProvider.java
└── resources
└── META-INF
└── services
└── javax.ws.rs.ext.Providers
15 directories, 13 files
alessio@localhost /ssd/resteasy (master) $ tree
providers/resteasy-validator-provider-11/
providers/resteasy-validator-provider-11/
├── pom.xml
└── src
└── main
├── java
│ └── org
│ └── jboss
│ └── resteasy
│ ├── api
│ │ └── validation
│ │ ├── ResteasyViolationException.java
│ │ ├── ResteasyViolationExceptionMapper.java
│ │ └── ViolationReport.java
│ └── plugins
│ └── validation
│ ├── AbstractValidatorContextResolver.java
│ ├── ConstraintTypeUtil11.java
│ ├── GeneralValidatorImpl.java
│ ├── i18n
│ │ ├── LogMessages.java
│ │ └── Messages.java
│ ├── SimpleViolationsContainer.java
│ ├── ValidatorContextResolverCDI.java
│ └── ValidatorContextResolver.java
└── resources
└── META-INF
└── services
└── javax.ws.rs.ext.Providers
14 directories, 13 files
alessio@localhost /ssd/resteasy (master) $ tree providers/multipart/
providers/multipart/
├── pom.xml
└── src
└── main
├── java
│ └── org
│ └── jboss
│ └── resteasy
│ ├── annotations
│ │ └── providers
│ │ └── multipart
│ │ ├── MultipartForm.java
│ │ ├── PartFilename.java
│ │ ├── PartType.java
│ │ └── XopWithMultipartRelated.java
│ └── plugins
│ └── providers
│ └── multipart
│ ├──
AbstractMultipartFormDataWriter.java
│ ├── AbstractMultipartRelatedWriter.java
│ ├── AbstractMultipartWriter.java
│ ├── ContentIDUtils.java
│ ├── FieldEnablerPrivilegedAction.java
│ ├── HeaderFlushedOutputStream.java
│ ├── i18n
│ │ ├── LogMessages.java
│ │ └── Messages.java
│ ├── InputPart.java
│ ├── ListMultipartReader.java
│ ├── ListMultipartWriter.java
│ ├── MapMultipartFormDataReader.java
│ ├── MapMultipartFormDataWriter.java
│ ├── MimeMultipartProvider.java
│ ├── MultipartConstants.java
│ ├── MultipartFormAnnotationReader.java
│ ├── MultipartFormAnnotationWriter.java
│ ├── MultipartFormDataInputImpl.java
│ ├── MultipartFormDataInput.java
│ ├── MultipartFormDataOutput.java
│ ├── MultipartFormDataReader.java
│ ├── MultipartFormDataWriter.java
│ ├── MultipartInputImpl.java
│ ├── MultipartInput.java
│ ├── MultipartOutput.java
│ ├── MultipartReader.java
│ ├── MultipartRelatedInputImpl.java
│ ├── MultipartRelatedInput.java
│ ├── MultipartRelatedOutput.java
│ ├── MultipartRelatedReader.java
│ ├── MultipartRelatedWriter.java
│ ├── MultipartWriter.java
│ ├── OutputPart.java
│ ├──
XopWithMultipartRelatedJAXBProvider.java
│ ├── XopWithMultipartRelatedReader.java
│ └── XopWithMultipartRelatedWriter.java
└── resources
└── META-INF
└── services
└── javax.ws.rs.ext.Providers
16 directories, 42 files
which means we are already not testing all log messages. Perhaps we
should fix these modules or drop the profiles there. Any thought?
Cheers
Alessio
Il 03/09/2016 00:33, Alessio Soldano ha scritto:
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? Do we really need those tests to cover any
i18n message that we add?
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
>>
--
Alessio Soldano
Web Service Lead, JBoss