This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
| Summary: | I18N - maven projects don't use feq if default encoding property changed | ||
|---|---|---|---|
| Product: | projects | Reporter: | Ken Frank <kfrank> |
| Component: | Maven | Assignee: | Milos Kleint <mkleint> |
| Status: | RESOLVED FIXED | ||
| Severity: | blocker | Keywords: | I18N |
| Priority: | P3 | ||
| Version: | 6.x | ||
| Hardware: | Sun | ||
| OS: | All | ||
| Issue Type: | DEFECT | Exception Reporter: | |
|
Description
Ken Frank
2008-12-31 17:37:05 UTC
1. IMHO not behaving as the ant project of netbeans is correct. We want the command line tool to behave in exactly the same way as netbeans behaves and have never netbeans to break the project. At the same time the creation of the project is performed by 3rd party tool that doesn't take encoding into account. 2. possibly a bug related to the way maven currently handles encoding. if you change the encoding of the project and examine the pom.xml file afterwards, you will see that we've changed the configuration of the maven-compiler plugin and maven-resources-plugin. These handle (by default) folders src/main/java, src/test/java and src/main/resources, src/test/resources respectively. The jsp are in src/main/webapp folder however which is handled by the war-plugin. I haven't found how that one can be configured for non-default encoding though. http://maven.apache.org/plugins/maven-war-plugin/war-mojo.html The whole maven encoding story is sort of confusing, there's an ongoing effort to unify approach to encoding, see http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding for more details. The new approach is to have one place in the pom to declare the project's encoding and all plugins to recognize it. AFAIK not all plugin have been converted and even if there are, people out there might still be using the old version which doesn't. The current approach in netbeans is to use the project.build.sourceEncoding property only as fallback. Only if the property is set in the project, changing the UI will change this property. By default it's not there. if you follow the link above, you will be shown a way how toadd the property. The jsp usecase shall start working then in the IDE. The reason why it's not the default behaviour is that it might break your project's binaries if all the relevant plugins you you in your project don't understand the newly introduced property. I think we shall at least check before 7.0 gets out and reevaluate, maybe have some kind of transition where the property is used but the important plugin configurations are also used. 3. no again. the projects created by the 3rd-party tool generate files and we would have to change the encoding afterward. IMHO that would break the already generated files. (if there are not already broken by generating an UTF-8 file on a system with UTF-16 anyway?) Milos, thanks for the explanation ! since am not familiar with the pom structure, and it was not clear to me from the web page, can you send me snippet that can be added to pom.xml about this default encoding property and I will add it to my pom.xml for testing ? (also where in pom.xml it should go) -- and I will assume going forward that its needed if we want feq will be used as to created files and other operations if project encoding is different than platform one -- and I can later write faq question about it for wiki. ken.frank@sun.com the snippet to be added would be
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
in http://hg.netbeans.org/main/rev/02b6baa9dc62 I've changed the logic to always generate the
project.build.sourceEncoding property by the IDE and still generate the plugin configuration snippets if not there yet
(see commit log for full logic description)
That should 1. have the encoding from FEQ to be consistent for the whole project (unless overriden manually by the user)
and also at build times it should generally work (as long as proper plugin versions are used or it's delegated to the
property). the only real problem is the compiler plugin, the rest might be corner cases..
Integrated into 'main-golden', will be available in build *200901091401* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/02b6baa9dc62 User: Milos Kleint <mkleint@netbeans.org> Log: #156203 change the encoding settings logic, 1. always set the property. 2. if property didn't exist, also create teh compiler and resources plugin snippets 3. if only updating property, check if the plugins define the encoding parameter, if so, update, otherwise ignore and don't readd. |