I am currently working on an effort which makes use of Windriver's Workbench tool, which I understand is built on top of Eclipse.
Our source control tool is ClearCase and we are working primarily out of snapshot views located on the workstations of individual developers. As a result the absolute path for each developer's view is different. As deeply nested relative paths can be somewhat cumbersome (e.g. ../../../../../Some_Package/src/) we are using a Linked Resource PROGRAM_ROOT_PATH which identifies the particular view directory for a given developer.
This is working relatively well for for referencing header and library directories in the build properties, but we are trying to reference that Linked Resource from our build scripts in order to do build post processing such as copying the compiled program to a release area.
Accessing the Linked Resource as though it were an environmental variable appears to be the wrong thing to do as $(SOURCE_ROOT_PATH) provides an empty string. Is there a way to access this information from Eclipse / Workbench from a makefile?
Look inside the .classpath and .project files in the root of your workspace project - I believe the linked resource should be defined in one or the other of those (probably .classpath). From your script (you don't mention if it is Ant, Maven, Gradle, etc.) you should be able to find a way to get that value out of the .classpath (through some plugin or custom code).
We use Eclipse, ClearCase, and Ant. The easiest way I have found to share projects is to include the .project, .classpath, and build.xml files in the top level of the project in ClearCase. Then when you create your view, mount it in your Eclipse workspace, and do a File -> Import, then choose Existing Project from the popup. Browse to the top-level of the project in the view and import it.
The paths in the build.xml and .classpath are relative from that point down, so it doesn't matter what the absolute path is up to the project. For example, your build will define your source directory as something like ./src/java, test directory as ./test/java, etc. Whether your absolute path is c:\workspace\project or /home/someuser/project or whatever doesn't matter to your build script.
Related
Every projects in eclipse has 4 .files(.settings,.classpath,.cprojects and .projects).
Can anyone explain me why are these files generated and what happens if I delete these 4 files. I have deleted these files from one app which resulted in changing the name of app.
Eclipse is a runtime environment for plugins. Virtually everything you see in Eclipse is the result of plugins installed on Eclipse, rather than Eclipse itself.
The .project file is maintained by the core Eclipse platform, and its goal is to describe the project from a generic, plugin-independent Eclipse view. What's the project's name? what other projects in the workspace does it refer to? What are the builders that are used in order to build the project? (remember, the concept of "build" doesn't pertain specifically to Java projects, but also to other types of projects)
The .classpath file is maintained by Eclipse's JDT feature (feature = set of plugins). JDT holds multiple such "meta" files in the project (see the .settings directory inside the project); the .classpath file is just one of them. Specifically, the .classpath file contains information that the JDT feature needs in order to properly compile the project: the project's source folders (that is, what to compile); the output folders (where to compile to); and classpath entries (such as other projects in the workspace, arbitrary JAR files on the file system, and so forth).
Blindly copying such files from one machine to another may be risky. For example, if arbitrary JAR files are placed on the classpath (that is, JAR files that are located outside the workspace and are referred-to by absolute path naming), the .classpath file is rendered non-portable and must be modified in order to be portable. There are certain best practices that can be followed to guarantee .classpath file portability.
The .settings folder is used by various plugins to set persistent 'Properties' as opposed to 'Prefereneces' to specify project specific settings that should be preserved.
.settings is usually a directory you most definitely want checked into svn/cvs/git etc as it will ensure that all users who check that project out into eclipse use the right project specific settings.
In our case we use it to supply a minimum compiler version of java but we want things compiled to 5 for our servers. We also use it to enforce some coding standards and auto-formaters which makes version diffs much easier to read.
In your specific case you selected 'Enable Project Specific Settings' under "Properties->Java Compiler" by right clicking on the project and choosing properties.
I'm working on eclipse-kepler.
when I try to add external jars, they are added under the project and not under any folder (that is under the project),
Is there a way I can abbreviate (shorten/shrink) them so it wouldn't be so annoying?
Well, it depends on what is your issue.
If you would like to filter out libraries, there is a magical button, a white triangle on the top bar of the Package Explorer. There you can filter out all the libraries with a click so they won't be enumerated (see this screenshot).
If the issue is that they are included as external Jars (which I'd discourage, since it becomes harder to set up the project in a different environment both for you and others), simply create a lib folder, copy the Jar there and include it as simple Jar files (that way the .classpath file won't have any absolute paths).
Actually this feature is quite handy, it saved me a dozens of times. When there is a problem with a class you are using you can easily locate it by opening the type with Ctrl+Shift+T and linking it with the editor. It can go into the Jar files and show you where is it. When there is a Claspath conflict it can be a life saviour.
I created an Eclipse project and now I want to put it on my SVN repository. Which files should I put on ignore list? There are many files that I don't know what they are used for. There are folders like .history, .root, .safetable, .log, .settings ... and many .index files, also some .running files. Can I put all that to ignore list? Do you know which extensions/folders can always be on ignore?
Thanks.
The answer is very dependent on your project. Committing the source is a good thing however it'll force new developer to recreate the project environment which can be painful. If you are using Maven with the m2eclipse plugin committing only src and pom.xml is a good approach as it only takes a few minutes to recreate the Eclipse environment from src and pom.xml.
On the other hand it is ok to commit .classpath and .project but that also means extra work such as never using external jar directly but through variables or user library, etc.
If you have time to experiment, why not check in everything, have a colleague check out the project, and see what throws up errors? Anything that references paths outside the project is likely to fail if your colleague doesn't organize her harddrive the same as yours. Those things should be changed to reference variables, or not placed under version control.
Let your colleague build the project, run the IDE through its paces, and then sync up to the repository to see what changed. Files that are volatile, run time logs, and temp files should be omitted. Anything that makes it easier for another developer to setup the project and get running should be included. Taking time to experiment will help you gain a better understanding how your project is setup.
Basically, you want to avoid checking in anything derived from source (like .class files in a Java project) or anything that every developer would have to change for their local environment, like a file with absolute references outside the project directory. One approach I have used in the past for handling configuration files that require customization by developers is to include a copy of the file, usually with extra comments, with a .example extension. Make it clear in a README or other documentation which example files need to be customized and what the "real" name for the file should be. Also include he "real" file name in the svnignore list so it doesn't get checked in and overwrite everyone's local customizations.
To address your specific examples:
.history, .root, .safetable, .log,
.settings ... and many .index files,
also some .running
.settings is one you'll have to experiment with. If you have settings, such as code style or formatting guidelines, that all developers need to follow, then it can be handy to have those under version control, but some other settings may not be appropriate for all developers. The other examples are not familiar to me, possibly because they are associated with a type of Eclipse project I don't work with.
My first guess would be that any file whose name is starting with a dot should not be versioned. Most commonly such files refer to Eclipse settings which are not project-relevant.
Now, the .project and the .classpath files, in a Java project, are quite "project dependant" and I usually include them.
To get a more precise answer you should specify which project type you are working on.
in my Java Eclipse project that contains JUnit tests, I also have a package "resource" that contains all input data used for the tests. But when compiling JUnit tests, the Java compile also data available in resources, so I find the same data in the "bin" folder. Is there a way to avoid this?
thanks.
If you have a particular package within the source path you want to exclude (your resources folder for example), you can right click on the package and select: Build Path > Exclude.
This will tell Eclipse that you don't want to include that package as part of the build.
This is making a couple of assumptions: that you're using Eclipse Helios (because the option might be different in older versions), and that the resources are stored in the same folder as your regular java source files (because if resources is in a folder by itself, you can remove that entire folder from the build by using Build Path > Configure Build Path -> Source tab.
Update:
After the discussion in the comments regarding why you would or would not want to copy resources into the bin directory:
The contents of your bin directory should be ignored and not checked into to a version control system (when using CVS, bin should be an entry in the .cvsignore file)
The resources are only duplicated on your local machine, which is fast and hard discs are big. I'm not sure you should be worrying about this
If you're using Class.getResource to access those resources, they need to be on the classpath somewhere. The bin directory is as good a place as any
So, realistically (barring some unknown, like the files are hundreds of gigabytes or something), I don't think you need to be concerned about excluding these files from the build.
We are using Eclipse+CDT+SVN(Linux). How can we have some common header files in a separate include directory, which is also in the SVN, but not in the project specific subdirectory.
The main goal would be to create some common, reusable code for multiple projects and to be able to easily edit/commit that code within eclipse.
We have different directoy structures on the machines, so "simple" links would not work out.
You could use:
an external project (as suggested by Rahul in the comments of your question) with those header files in it: your first project would "depend on" your second one.
The problem is the path of the common project which can be different from machine to machine, while still being stored in full in the .classpath or .project of your CDT project.
a linked directory, which at least use a path variable for linked resources, and would only require to set that variable to the proper path (to the common project) depending on the current machine.