Same question stated another way: Can an Eclipse project be both a plugin project and a feature project?
We have 3 Eclipse projects in our source code for every component in an application, like this:
pkg.component.name
pkg.component.name.rcp
pkg.component.name.rcp.feature
pkg.component.name is a plugin project that contains all of the non-rcp Java source code for the component.
pkg.component.name.rcp is a plugin project that contains the RCP-specific Java source code.
pkg.component.name.rcp.feature is a feature project that only contains two files: build.properties and feature.xml. build.properties contains one line: bin.includes = feature.xml
Is there any reason why we can't define the feature in the pkg.component.name.rcp project?
Reducing our project count by roughly a third would be nice.
One of my colleagues told me he had problems doing that and I don't want to troubleshoot something that isn't possible or that is proscribed just to have fewer projects.
It's not possible to do. While plugins use the MANIFEST.MF and plugin.xml and features use the feature.xml, both use the build.properties (to allow building) and they both need to fill it with different things. They also both have different .project information (different builders, different natures) for use within eclipse.
Related
I'm trying out Java 9 Jigsaw module system (no module experience yet) and would like to use it for capsuling the classes within my project, but it's confusing.
According to this article it should be possible to have multiple modules within ONE project. I made a new project in Eclipse Oxygen (Java 9 is supported) with the same structure as shown in the article. But Eclipse keeps telling me that I must not have more than one module-info.java in a project.
I really don't know how to tell Eclipse that it should use the "multi-module-mode". And I really would appreciate not having to create a new project for every single module.
This works:
This not:
But according to this article something like that should work:
And how about deployment of a modularized project with Eclipse? There is nothing to see about the new jmod extension. Do I still export it as a runnable JAR file like before?
Notice that my questions refer to working with the IDE (no command line, I mean with an IDE that should be possible, right?) Thank you for enlightening me.
Currently, Eclipse requires you to create a separate project for each module (e. g. because each module has its own Java Build Path).
To understand this design decision, consider that Java modules correspond to OSGi bundles / Eclipse plug-ins and it has always been to have a separate project for each bundle/plug-in. If you come from the Maven world, you would probably expect a deeper folder structure instead. But modules are self-contained and combining several modules into one project would only add an additional folder level without meaning. However, Eclipse supports nested projects and so-called working sets if you need an additional folder level.
Exporting modules as images is planned for Eclipse 2019-03 (4.11), on March 20, 2019 (see Eclipse bug 518445). Exporting modules as JARs that can be used on the modulepath (-m) already works (see my video).
I don't know if this question is still open for an answer, but you can solve this problem by simply removing all source folders on the build path. At least this works for Eclipse 2021-12 version.
As you can see this is a demo project from the Official Gradle Guide Book and it has multiple modules. Each module has its own module-info.java.
project structure in IntelliJ IDEA
If I open this project in Eclipse it will give me the 'duplicated entries on module-info.java' error.
Eclipse shows the error
But if I delete all the source folders on the build path, the error is gone and the project can be built and run without problem.
project properties: Java build path
The only problem is that you have to build the project with Gradle so that it will produce the .jar of each module and you have to include them in the libraries later.
include all the .jar in libraries
I think this is probably the same solution mentioned by howlger above.
is it possible to add multiple nature to a single project in eclipse ?
eg: i want to add Python and Ruby nature to a Java project.
the purpose.
I have solutions to projecteuler.net problems in Java,Ruby,Scala,Clojure and Python.
But the solutions are in different projects.
I need them in a single project.
The GUI does not have any option for creating such a multilanguage projects.
However, technically, project natures can be added independently from each other. So if you manage to programmatically create the required environment, it would work. If you want to do it manually, find the .project file in the project root, and add all natures and builders to one (you can look the required elements from other projects - do a copy-paste).
This would add the project natures and builders, but not any additional configuration required - e.g. in Java projects .classpath files are used to describe the source folders, in other languages different configurations are needed.
Alltogether, if you need to do this multiple times, create a plug-in that manages this configuration for you; if you need it for a single project, think about it whether it is worth the huge effort required.
When sharing a project with team members through version control, it is customary to include the .project in the source under version control. This makes sure that others on the team get all the dependencies and resources for the project. But the .project uses full/rooted paths to the resource, and not all members of a team will be working in the same environment. Even if all the members are on the same platform, the paths can often be in the user's home directory.
For the .classpath file, we can get around this problem by using build path variables. Each member defines the path to location of dependent libraries on their system, and the .classpath only refers to the variable.
This is a particular concern for Grails project - when we add a plugin, it updates the .project accordingly.
IMO resources themselves should not be part of the project at all. There is excellent plugin called m2eclipse which simplifies such tasks using Maven. It will immensely simplify your dependency management. All you'd have to keep in your version control system, besides your source code, is project configuration (pom.xml) - all the dependencies will be downloaded and cached automatically no matter what environment developer works in. There a lot more advantages in this approach - just read up on it :)
UPDATE: Just noticed "grails" tag on your question. if you're using Groovy - Maven can be replaced with Gradle. STS is probably the best Eclipse build to use if you're coding in Groovy. Next version of STS will have Gradle support.
General Approach
As others have mentioned, you should not keep the IDE files in VCS, you should keep an IDE-agnostic description of the project in VCS and generate the IDE-specific project files from them.
Java-Maven Example
Keep the pom.xml file(s) in VCS and generate the Eclipse files by running mvn eclipse:eclipse
Grails Example
A Grails project is described by application.properties and grails-app/conf/BuildConfig.groovy. These files are present in every Grails application. You can generate the Eclipse project descriptions from them by running:
grails integrate-with --eclipse
This command also supports other tools such as IntelliJ and Textmate
I don't think its standard practice to include the project file. I personally tell my VCS to ignore all IDE files, and just use VCS for the source. I include at the root level a README telling others how to configure the project (e.g. jars are in lib)
The resource links feature that you are referring to also has ability to use path variables. These are defined under Preferences -> General -> Workspace -> Linked Resources.
You could try keeping the project files in a shared Dropbox with an agreed upon path for each developer.
With the maven-eclipse-plugin, using mvn eclipse:eclipse, you can specifiy eclipse project natures and builders that will automatically be added to the eclipse project.
Earlier versions of m2eclipse used the configuration block of the maven-eclipse-plugin and also let you activate natures and builders using the same mechanisms. This seems to no longer be the case because a) I can't find any reference to maven-eclipse-plugin in the m2eclipse sources and b) it just doesn't work :-)
So this is my question: is there any way to configure the eclipse project generated by m2eclipse from the pom.xml? Specifically: project builders and natures, but I'd be interested in other options as well.
The following thread summarizes almost everything. First, it explains that m2eclipse doesn't and won't support anything from the Maven Eclipse Plugin anymore because:
Sonatype doesn't maintain it.
It causes them too much troubles.
Second, it states that the m2eclipse way to handle additional project natures and builders is to write project configurators:
(...) we encourage writing configurators to add the natures and builders you want based on what it available in the POM.
See this link for a guide and this project for some existing configurators for checkstyle, findbugs, pmd.
I have now implemented this as a maven plugin I call maven-eclipseconf-plugin.
Unfortunately it's proprietary work for a client, so I can't share it. But let me describe what I do:
Tied to the lifecycle verify, I check for the existence of an eclipse .project file. If it's there, I check it for the presence of the builders and natures I want to automatically add (and you can deactivate this behavior by using a maven property or a stop file with a configurable name). You can also define configuration files that will be written (like .pmd, which is related to this other question of mine). The contents of the Configuration files can be specified inline, it can come from an external file, or from a URL. I also tried to introduce variable substitution in the config files where a special placeholder would be replaced with a multi-moduke-project's root folder, but I had to give up on that approach.
Anyway, the plugin gives me pretty much all the functionality of the maven-eclipse-plugin I ever used (of course there is a lot more though) and I'm happy with that. Perhaps I will build something similar once more in open source when this contract is finished.
Project configurators are the proposed approach. But the latest version of m2e-extensions is from early 2010 and developed against m2eclipse 0.10.x. There is a successor project called m2e-code-quality which is more recent and active and developed against m2eclipse 0.12.x.
But neither m2e-extensions nor m2e-code-quality do support FindBugs at the moment. And there are some other limitations with header files, exclusions and modified JARs.
I have successfully used a universal approach with AntRun, Ant and XMLTask to automatically add project natures, builders and configuration files for Eclipse plugins from pom.xml.
How do I externalize strings in my Eclipse plugin's plugin.xml?
Right-clicking on the plugin project > PDE Tools > Externalize Strings does not show up my plugin.
I'm trying to do this manually now. I added entries in plugin.properties and replaced the equivalent string in plugin.xml with a % sign followed by the string key. But that does not seem to work. What am I missing here?
I finally figured out how to manually externalize the plugin.
Eclipse, it turns out, externalizes plugin.xml this way:
In the plugin manifest (META-INF/MANIFEST.MF), add the following line
Bundle-Localization: plugin
where you intend to store the externalized strings in a file called "plugin.properties" (Turns out this was the missing piece).
Add the externalized string key-value pairs in plugin.properties.
Replace the actual strings in plugin.xml with the keys from plugin.properties (prefixed with %).
If your working set have plugin projects in it, the Externalize Strings wizard to help externalize strings in your Manifest and plugin.xml files should be available.
Externalizing manifest files extracts translatable strings and stores them in a properties file for multi-language support.
The wizard is available under the PDE Tools menu in the context menu of a PDE project's MANIFEST.MF or plugin.xml files.
(source: eclipse.org)
Be aware that there were some bugs related to detecting all non-externalized attributes/values of the <extension-point> and <extension> elements, or showing up un-externalized names of extension(-point), which are only solved in 3.4 or very recent 3.5M4.
However, if the "Externalize Strings" menu does not show up at all on your plugin projects, may be its "project nature" is corrupted somehow, may be your former Java project is not properly converted to a PDE project ?
So two suggestions:
try with a fresh install of an eclipse3.5M4
import your plugin project and check its nature
And then tell us if that menu is still unavailable.
As you mention in your own answer, the externalization process is declared by the string
Bundle-Localization: plugin
in the MANIFEST.MF file, as mentioned in this message.
A bug has been created, but:
The localization is not something specific to PDE but instead the OSGI specification
that line is not always in the MANIFEST:
Prior to 3.3, we created all our manifests by creating a plugin.xml and then
converting it. The converter always added "Bundle-Localization: plugin" to the
Manifest, since that is the default location if the plug-in has no Manifest.
If a plug-in had no translations files, this header was unnecessary bloat.
In 3.3, we created plug-in projects by creating Manifest directly, which means we
decided to create only the headers necessary for project creation.
it is likely to be an issue for those that have created bundles with
externalization < 3.2, and then not being able to see them when running in 3.3.