To translate my RCP App. I would like to use fragments. I have followed this tip from vogella.com to translate SWT and JFace and it worked very fine.
Now I would like to translate workbench. Using the same approach, I have created a fragment project, and put properties files along with their packages extracted from related babel project: org.eclipse.ui.workbench.nl_XXXX.
The properties files are located inside packages named equally to the ones in the host plugin
I've added a fragment to the RCP feature project
I've added a fragment to the launch configuration
But it doesn't work!
Does someone have any idea what I'm doing wrong and if my solution is the right approach?
Eclipse workbench translations can be obtained from the Babel project, including fragments for SWT.
Unfortunately, it seems that at least for the Oxygen release the SWT fragments do not (yet) contain the actual properties files with the translated messages.
However, SWT provides its own translation fragments, that can be obtained from http://eclipse.org/swt/language.php
Note that the Babel project is mainly a community effort and since Oxygen is relatively new, it might take some time for the language packs to catch up with the latest release.
Related
I have two pairs of projects that I develop in NetBeans, both of which have a GUI project, and a library project, where the GUI project depends on the library one. In one of them, NetBeans recognizes that the dependency is local, and indicates as such with an Ma symbol, as seen below, with the dependency project in green:
This provides some nice functionality, most notably that the "Navigate to" (ctrl+click) functionality from the GUI project takes me to the source code in the library project. I also don't have to manually rebuild the library project for the GUI project to pick up any changes.
However, for the other pair of projects, NetBeans will pick up that the dependency is in my local Maven repo, but does not recognize that the source code is a Maven project that it also has open:
I've tried looking through all the right-click menu options, removing and re-adding the dependency from the NetBeans GUI, comparing the pom.xml, comparing nb-actions.xml, and nb-configuration.xml, but cannot find any explanation of why one library is recognized as local, but the other is not. The only information I've found online is at http://wiki.netbeans.org/MavenBestPractices, where it notes:
"Hint: If you open a project that other projects depend on, the icon in other projects changes to a "maven project" icon to denote that the IDE knows about link between the projects. However such a link is only established when the groupId, artifactId and version all match in the dependency and project declaration. Frequently occurring problem is that you change an API signature in your library project, but the application is not picking up. Often it's caused by the fact that the application is using an older version of the library artifact. The artifact icon can help you track down these problems."
However, I've verified that the pom.xml of the GUI project depends on the version being built in the library project, and even made the versions identical between the GUI project and library, and the "maven project" icon still doesn't show up.
Does anyone know how to debug this issue, or if there's a magic setting somewhere that I'm missing for how to make this link work? I've been trying with both NetBeans 8.2 and 8.1, and am compiling with Java 8 for both the successful pair of projects, and the unsuccessful ones.
Revisiting the project a couple years later, I finally figured out a way to get the dependency to connect locally.
Change the artifact ID of the dependency, and update the dependent pom to match the new name.
This is admittedly bypassing the root issue rather than addressing it, but given the inability to pinpoint the root cause, seems the best option at this time.
I found this note in the Maven's documentation:
You can add elements to this classloader by extensions. These are loaded into the same place as ${maven.home}/lib and hence are available to the Maven core and all plugins for the current project and subsequent projects (in future, we plan to remove it from subsequent projects).
I couldn't understand what they mean by "subsequent projects" here. As far as I understand, extensions are enhancements to lifecycle phases of Maven and are not project specific. So it makes sense to work for all the Maven projects.
Question: Can anyone explain what this statement means "in future, we plan to remove it from subsequent projects"
First an extensions can be extensions of a life cycle but not need to. You can implement an extensions also as an EventSpy for example.
This documentation is related to the Core Classloader which is available within such extensions and makes it also possible to enhance it via an extensions. This classloader contains those files from ${maven.home}/lib which is not a good idea and not necessary. It would be better having only the Maven Plugin API there and it's instances which are currently used and not more...
There existing some extensions like Wagon which are using to make a transport in special cases possible which could be project specific.
Starting with Maven 3.3.1 the core extensions mechanism has been improved to make loading project specific extensions more simpler which means they are located into ${maven.projectBasedir}/.mvn/extensions.xml file and also being loading from an repository. Before 3.3.1 you need to do that manually via mvn -Dmaven.ext.class.path=extension.jar.
does anybody know a maven plugin that tests all my language properties files? I want to test that every language in my project contains all keys.
Use cases:
Figure out if so. added a key to the default file and forgot to add to any of the other language files.
Figure out if so. dropped a key in one of the files and forgot to drop it in all the other files.
It is not that difficult to write my own small maven plugin, but I would prefer an already existing one. Haven't found one so far.
Or: How do you test your files? Manually / automated / not at all?
Eric
You should give a try to the i18n-maven-plugin. In the build (process-resources phase), all your Java classes, JSP will be parsed to find all the i18n keys in your project (according to your pom).
The plugin will add all the i18n keys that are missing in all you bundles. There is also a strict mode that remove all the i18n keys that are no longer found in your application from your bundles so you can be sure that 100% of the keys are both used in your app and translated in every language.
For a working, real-life example, feel free to check out this application:
svn checkout https://svn.codelutin.com/wao/tags/wao-4.0.4/
mvn clean process-resources -Di18n.verbose
Funny - I gave my project the same name a couple of years ago. https://github.com/hoereth/i18n-maven-plugin
This plugin serves me well on numerous projects. It turns around the concept of properties files 180 degrees. You maintain a well structured XMl file with your translations and the plugin will create all properties files for you during build time. No need for validation at his point. It can also create a Java class which holds all translation keys - thus enabling you to compile-check your translation calls.
Believe me - this takes away the pain of translating from a technical point of view. :)
Why there's a difference in Default Source Lookup Path between GWT and java launch configurations?
In multi-module projects instead of containing projects, the Default folder contains the class folders of those projects!
It causes "Source not found" errors when the debugger steps into a dependency project.
I know I can add projects manually. Just want to know why this difference is needed.
The only project in the list is the associated with the .launch.
GWT needs '.java' source files of dependencies to be able to compile (translate to js) while the Java launcher needs only '.class' compiled files.
I suppose you know GWT has a different way to manage dependencies (through modules within the same project), which is good for some advanced GWT practices like loading a module's js lazily (this feature doesn't work with "foreign" libs/projects).
So this could also be an answer for why eclipse GWT doesn't suppose you will have more projects (but more modules instead)
Finally if you really have an independent GWT lib that you're maintaining this is an issue as you said.
There are two main approaches when developing an OSGi application with Maven: POM-first and MANIFEST first.
I'm looking for an answer that is in a form of a table that shows pros and cons of each method.
To be more specific, I would also like to know how it relates to:
Maturity of toolset
Vendor independence
Development ease (which includes finding people who can do the development on the tooling)
Compatibility
Avoiding ClassNotFound
Avoiding manual work
At present this is what I can come up with
POM-First Pros (using maven-bundle-plugin)
Leverages existing Maven skills, repositories and tooling.
Likely easier to find people who know how to manage pom.xml rather than MANIFEST.MF along with pom.xml
Most of the information in MANIFEST.MF can be obtained from the pom.xml itself.
Can work with other IDEs not just Eclipse based ones.
Less invasive, just add the single plugin and change the packaging type to "bundle"
POM-First Cons
ClassNotFoundException more likely to occur at runtime. However, this can be mitigated using pax-exam (although it is very complicated to set up).
Still need to understand how the MANIFEST is setup to make sure the instructions configuration element is set correctly.
MANIFEST-first Pros (using tycho-maven-plugin)
Seems to be the recommended approach, or at least talked about as the recommended approach, but I can't really see why it has significant benefit. (Hence why this question was asked).
Good for developing Eclipse plugins and integrates well with PDE
Provides tooling for testing thus allowing ClassNotFoundException to appear during JUnit testing rather than runtime.
MANIFEST-first Cons
Seems to only work well on Eclipse based IDEs. You don't have to use Eclipse, but without the PDE would you want to?
Violates DRY principles since I have to do put keep the names and versions from the POM and MANIFEST.MF in sync.
Need to name things in a specific fashion
You cannot mix, meaning existing Maven multi-project installations cannot just tack on OSGi support
A lot more configuration compared to maven-bundle-plugin is needed to get less warnings: http://wiki.eclipse.org/Tycho/Reference_Card#Examplary_parent_POM
Have to make test cases a separate project. It won't run when built in src/test/java.
Seems that it will only test classes that are exposed, in other words those in ".internal." is not testable.
If I were asked for a recommendation for an enterprise that is using Maven already and want to move to OSGi then it would be POM first
If I were asked for a recommendation for someone who is doing Eclipse plugin development, then it is Manifest first -- with tycho
I think you should choose by use case. For server side OSGi projects I favour the pom first style. It nicely matches the maven builds and is much less error prone than Manifest first.
In fact bnd which is behind the maven bundle plugin gets the Manifest right for most cases without any additional config. The trick is to use some naming rules. For example if you name internal package impl or internal the will not be exported. Using this style you can not use the Eclipse plugin perspective (at least without bndtools which I do not like) but I did not yet miss this perspective. I am a developer in the Apache Karaf, CXF and Camel projects where we use this style and it works great. Especially for CXF and Camel it is great that we can support OSGi and non OSGi deployments with the same build and tools.
For Eclipse RCP applications Manifest first is the way to go as you need the plugin perspective and the Eclipse IDE tools. If you want to combine that with maven then tycho is probably the way to go.
MANIFEST first does not lock you to Eclipse (although I'd be surprised if more than a tiny minority would use anything else). The MANIFEST is the file that counts, and needs to be added to a jar, regardless how you do that.
On the other hand, POM first completely locks you to Maven, you lose the advantage that an OSGi bundle is a regular jar you can make any way you want.
I've tried both, I really prefer MANIFEST first. The MANIFEST file is a really important file, I prefer to craft that file over crafting a file that produces that file. If something weird happens, (and it will at some point) the MANIFEST file is the first to check, it's just easier if it's your own file. Besides, you will have to be familiar with it anyway.
So, if Maven is your alpha and omega, POM first will suit you best, but you'll still need to have in-depth understanding of the MANIFEST file.