Develop Reference

Eclipse Checkstyle plugin (eclipse-cs) Error Property has not been set

I try to use eclipse-cs (eclipse checkstyle plugin) in our Eclipse 4 teamproject.
The idea is that we define one checkstyle.xml for our team and have this checkstyle.xml under sourcecontrol.
The Project structure looks like this
Root
Checkstyle.xml
PluginProjectFolder1
PluginProjectFolder2
According to the documentation it should be possible defining relative paths with the ${property} style pattern(s)...
When I try to define the location for the checkstyle.xml I get an error "Property xy has not been set".
What I'm doing wrong ?

The documentation you reference says:
To do this use ${property} style pattern(s) in the location string,
these patterns will be resolved from equally named Classpath Variables
or Environment properties (passed into Eclipse via -D parameter)
${project_loc} is not a Classpath variable or an environment property. It is an Eclipse String Variable which is different and the dialog needs to have specifically added code to support it. It looks like this dialog has not done that.
You can define Classpath variables in the Preferences in 'Java > Build Path > Classpath Variables'

I would assume that PluginProjectFolder1, PluginProjectFolder2, and Checkstyle.xml are all inside your Eclipse workspace. If they are not, then that is what you should try to do, e.g. by including an Eclipse project called WorkspaceConfig or some such which includes the checkstyle.xml.
Then, in order to achieve what you describe, you can select "project relative configuration" from the dropdown box. This actually refers to the Eclipse workspace. Select WorkspaceConfig/checkstyle.xml, and there you have it: The checkstyle.xml is under version control, and it will not matter where the developer's workspace is located on his PC.
An added advantage is that such a configuration will work out of the box, without required extra configuration steps such as defining classpath variables.

Eclipse - External jars need to be manually added

I had a question that was answered with adding jfxrt.jar to standard Eclipse build path.
I followed the suggestion, adding the jfxft.jar as an External Jar on the jdk1.7.0_10.jdk JRE i have installed (under Eclipse > Preferences > Java > Installed JREs).
But when I import "javafx.application.Application"
It errors with:
Access Restriction: The type Application is not accessible due to restriction on required library /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/lib/jfxrt.jar
There are posts on this such as Access restriction: Is not accessible due to restriction on required library ..\jre\lib\rt.jar
I can fix this possibly by the suggestions in that thread (though I'm not convinced they are good solutions).
Or I found a better solution of adding the External Jar directly to the project:
- go to the JRE and remove the External Jar as setup above
- Open project properties and go to Java Build Path
- Go to Libraries tab
- Add External JARS... and choose exactly the same jfxrt.jar
No access restrictions now!
Why does it work one way but not the other? The advantage of adding directly to the JRE configuration is that it only needs to be done once.
Thanks,
Hank

I would not recommend adding JARs to the JRE configuration like that, it's just too easy to forget they are there and that can lead to confusing behavior if you don't expect that particular JAR to be on the build path for a particular project. Also, what happens if one project wants to use a different version of the library?
There are at least 2 other options that I would consider:
Define a User Library for JavaFX and then include the User Library on the projects that need it. You still would have to add the User Library to each project that needs it, but that's not such a big deal IMO, as it only has to be done once for each project.
Create a separate project to contain the JAR(s), call it something like "JavaFX Libs." Add the JARs to its build path and make sure to export them on the Order and Export tab; then add "JavaFx Libs" project as a dependency for whatever projects need it.

Eclipse: Get the project name as a VM argument?

Consider a configuration class which needs to parse a different config file for each Eclipse project.
For instance, If Configuration class is called from Project1, it should parse special/path/fileX, and if it is being called from Project2, it should parse special/path/fileY.
I've tried using Eclipse's {project_name}, but surprisingly it is being parsed to the project being highlighted by the cursor, not the parent project of the current class.
Any ideas how can I distinguish one project from another in Eclipse Runtime, preferably using JVM arguments?

This is a workaround to your described problem, but I guess it's a better solution as it's independent from Eclipse and will easily work in production too.
Simply load the same file from the classpath, regardless which Project you're starting this from:
/my/file/from/classpath.txt
But put this file only in Project1 / Project2, such that the various files mutually exclude themselves according to your set-up:
/Project1/src/my/file/from/classpath.txt
/Project2/src/my/file/from/classpath.txt
Where src are Java source folders. Now you can still use your JVM parameter to override this, or to provide a default if the above is missing.

I think the easiest way would be using eclipse's run configurations. Simply create as many configurations as you want, supply all the JVM args you want, and use them to launch. This will also be very close to what you're going to do in production mode

or you can go to your Eclipse' Installed JRE's and have the configuration set as JVMArgs just the way you would have in prod.
If required, you can have diff copy of JREs per env.
Also if running from the IDE, you can get the
System.getProperty("user.dir")
which should be the root of the project.
that system property can be used to track the callee. Better still, set the Installed JRE's JVM Args to be something like this
-Dtheflaginprod=${project_loc}
project_loc = absolute path of the the project (/usr/projects/project1)
project_path = project name relative to the workspace (/project1)

Definining user libraries in Eclipse as part of a project and not a workspace

I saw that in Eclipse I can define User Libraries - to make setting the classpath easier (and probably for other reasons as well).
The problem is, that these libraries are only available in the workspace, and if I want other people using the same project to use them - I need to export my user library and they need to import it.
Is there any functionality like this on the project level? I basically need to have a 'classpath group' - can it be done?
If not, is there an automatic way to auto import the user library to the workspace when importing the project?
I'm using Eclipse 3.6.

JDT has the 2 concepts, user libraries and classpath variables. In the classpath variable, you can add jars to your project. Other team members have to fill in the variables in their workspace so their classpath is complete. This is useful when external jars might be in different locations on each team members local file system.
The USER_LIBRARY is a container for adding a logical group of local jars all at once. For example, the JRE_LIB container represents a number of local jars. But as you've seen, it points to a local set of jars meant to be used in multiple projects (as the JRE is added to multiple projects).
Aside from export/import (which you're already doing), I don't believe you can check CLASS_LIBRARIES into a project's SCM. If there was, the preference page would have a "Configure Project specific settings" link at the top.
Your best bet is to simply add the jars to the project, so they'll be included in the SCM. If they can be in different locations depending on the rest of your team, then use a classpath variable so it can be set in each workspace. That's the least amount of hassle as far as team members checking out the project and being ready to go.

The best way IMO is to use m2eclipse - Maven plugin for eclipse. In Maven all the dependencies are defined in pom.xml and downloaded automatically as needed. This means that the only thing you share with your team is pom.xml - your project definition.
There is a lot more advantages when using m2eclipse vs standard eclipse approch. More information is at http://www.sonatype.com/books/m2eclipse-book/reference/

The way I have used user libraries is for something like Ant. Define a user library "ant" for all the jars in ANT_HOME/lib. If including this in your Eclipse .classpath and then sharing with other users, they will get a build problem report until they create that "ant" user library themselves. It's useful, but you need to share knowledge on how to create the library. If you're using it for simple cases like above, then instructions for adding the right jars to the library are straightforward.
Another approach I've used is to build classpaths pointing into a folder (or folders) defined as a variable in Eclipse. See File -> New Folder -> Advanced -> Link to folder in the file system -> Variables. This lets you setup (again at workspace level) variable references to one or more folders. You can then build your Eclipse classpath/s with reference to the folder/s.
So say in your development environment, everyone needs to have a directory called "thirdparty" containing all the external jars dependencies (probably in hierarchy within that dir: thirdparty/apache; thirdparty/sun; ...). You define "thirdparty" as a variable pointing to wherever that dir is on your current system, you create a folder in your project/s using the variable. You can then setup (and share) classpath using paths into that folder.
It's similar to User Library and with similar limitations. The limitation is that the other users you share your project with must create variable folder/s as you have. But it's more flexible in that they don't have to add the jars explicitly as they do with a library; rather, your classpath/s in Eclipse point into the folder, as required for each project.
Note that although the folder variable is defined at workspace level, it can be reused in multiple projects, each of which builds their classpaths (.classpath files) with different references into the folder).
This is maybe something easier to show than to describe with words, but I hope it makes sense.

Eclipse classpath entries only used for tests

In Maven, you can have compile-time dependencies and test dependencies. This is a feature I love, and the M2Eclipse plugin makes this available in Eclipse, too, which is great. So if I add jmock.jar to my project as a test dependency, it will show up on the classpath for JUnit tests, but won't be present when I'm debugging the application itself.
This is exactly what I'd like to achieve now, but without M2Eclipse or Maven. Is there a way to do this in plain Eclipse? (Possibly without installing any plugins.)

You could separate all your tests into another project and add the main project as a dependency (Project->Properties->Java Build Path->Projects->Add...)
Update: To avoid changing the original project structure, your test projects can use linked locations.
Create the test project as normal, you now need to create a linked resource to bring in the src/test/java folder. It is best to create it using a variable so that your projects can retain some platform independence.
To create a new linked folder select New->Folder, input src in the folder name: field then click Advanced>>
Click Link to folder in the file system
Click on Variables... to bring up the Select Path Variable dialogue.
If this is your first time, or you are linking to a new location select New... and give the variable a sensible name and path. If all your projects are located in c:\workspaces\foo** it makes sense to call the variable **WORKSPACE_ROOT and give it that path. If you have some other convention that is fine, but it makes sense to put a comment in the .project file so someone has a chance of figuring out what the correct value should be.
Assuming the values above you can now set a value of WORKSPACE_ROOT/[subject project name]/src on the input field
Once you confirm that you should see the src folder with a little arrow, and if you look in the .project file see something like this:
<linkedResources>
<link>
<name>src</name>
<type>2</type>
<locationURI>WORKSPACE_ROOT/esf-ns-core-rp/src</locationURI>
</link><!--NOTE the WORKSPACE_ROOT variable points to the folder containing the subject project's sandbox-->
</linkedResources>
You can now add the src/test/java folder as a source location as normal.
Note you can also share just the src/test/java folder by changing the config to something like this:
<linkedResources>
<link>
<name>src/test/java</name>
<type>2</type>
<locationURI>WORKSPACE_ROOT/my-project/src/test/java</locationURI>
</link>
</linkedResources>
This gives more control over the config, but you would have to repeat for src/test/resources, src/it/java etc.
You then set all the test dependencies only in the test project.
Very not pretty, but it does work (I've also used this where my test compliance level is different to the main compliance level, e.g. 1.5 for tests, but 1.4 for the target environment).

I'm afraid the answer is that you can't. There are 2 open issues which were postponed from 3.5 related to your problem:
Ability to mark source folder as test sources
[buildpath] Should be able to ignore warnings from certain source folders

Since you use both Eclipse and Maven you can workaround it.
Create a new "Maven Build" run configuration with goal "exec:java" and parameters "exec.mainClass=com.example.Starter". This way the classpath will be calculated by Maven.

Actually if you look in eclipse as to how Maven integrates dependencies it will not make the difference in test or runtime dependencies your test libraries are always accessible.
Maven will keep the difference when packaging the application and when it generates the runtime classpath if maven has control over the execution of that part. When eclipse is concerned Maven simply adds them all without question to the eclipse build path.
Why is it you need to have this separated like so ? What will this help you acheive ?

Eclipse Photon finally added this feature, with m2e support for it.