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.
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 have a netbeans project that is under mercurial. What I would like to do is to strip down everything that makes this project netbeans project to only to leave code in there so that I can easily import it in say eclipse.
Is there some automated way to do this or do I have to remove manually this?
What approach would you recommend.
Cheers
You only have to add the nbproject folder to ignore (= don't check in). All NetBean-settings are placed in this folder. Dont check in the build and dist folder as well, because these contain the compiled code (but they are ignored per default).
The best way to do "IDE neutral projects" is to use Maven !
In NetBeans when the project is Maven-based (as opposed to Ant-based) you'll see that all those NetBeans-specific files that you normally see in nbproject folder are just not there. The nbproject folder doesn't even exist. The reason is that for a Maven-based project NetBeans essentially uses the pom.xml as the definition of the project and that's a good thing because the POM is portable and directly understood by other IDEs.
Even for a Maven-based project NetBeans will still store some IDE-specific stuff in a file called nb-configuration.xml but you can include all of the contents of this file as properties inside the pom.xml. These properties will then be ignored by other IDEs when they load the POM. This way you can pretty much avoid altogether to check any IDE-specific files into the VCS. Also it is worth mentioning that the stuff in nb-configuration.xml is never needed for someone else (using NetBeans or another IDE) to be able to build your project. Another way to put it is that it contains non-essential data. The POM - by virtue - is always guaranteed to be a complete description of how to build the project.
Contrary if your NetBeans project is Ant-based then at least in my experience you cannot avoid checking NetBeans specific files into the VCS ... because otherwise even those using NetBeans won't be able to correctly open your project.
However even with Maven there's one area where you'll be forced to have NetBeans-specific files in the VCS and that is if you use the Matisse GUI builder in NetBeans. The Matisse GUI builder produces some proprietary files with .form extension and you really need to have those in your VCS. But this is the only example I can come up with where NetBeans-specific files will need to go into the VCS assuming your project is Maven-based.
If the project indeed is Maven-based and you still feel that there are NetBeans-specific files that you need to have in the VCS then let us know exactly which files you're thinking of. Then we can take it from there. :-)
We have an application developed in NetBeans, based on the NetBeans platform. There's a 3'rd party program that we have a runtime dependency on, more specifically a jar in the other progams lib folder.
How should we include the other progam's jar in our classpath?
The recommendation from the other progam's manufacturer is to set environment variable CLASSPATH to include
C:\Progam Files\Other Program\lib\theJAR.jar
And if that's not possible, we should copy theJAR.jar to JRE-HOME\lib\ext
We must not copy theJAR.jar anywhere else, that might cause it to stop working...
Now NetBeans takes no notice of what's on environment variable CLASSPATH. Their recommended way seems to be to make a wrapper, but that would lead to copying the jar, unless there's some way to make a wrapper module that points to CLASSPATH?
At the moment we are copying the jar into JRE-HOME\lib\ext. But then there's unnecessary hassle when we install some java update.
Do you have any solution to this problem? It seems like something that might be simple, but I haven't found the right place to look yet...
Edit: The application is ant-based.
From the documentation for the Module System API's overview of the runtime infrastructure (bottom of the page under the section "Common Problems and Solutions"):
Q: Can my module add a library JAR to the classpath from outside the
IDE [read: platform] installation?...
A: Not easily. You have a few options:
Add an entry to ide.cfg [your app's .config file]. For example:
-cp:a c:\eak\lib\eak.jar This startup file provides the ability to add classpath entries to the IDE's Java invocation.
...
It goes on to list two more options. The second option is the same solution you've come up with. The third is to "partition your module and use a new classloader" which I can't recommend either way since I have no experience doing this (but it's worth a read).
Assuming that this first option is what you are looking for, you will need to add a custom .conf file to your project and point to it in your project.properties file, like so: app.conf=nbproject/my.conf. This will add your custom .conf file to your app's install directory instead of the default config file that is normally added. Of course, you'll need to add the -cp:a c:\eak\lib\eak.jar entry to this custom config file in order to load the .jar.
During development you'll need to add the following entry to the project.properties file: run.args.extra=-cp:a c:\eak\lib\eak.jar. This will pass the command line option to your debug instance.
You can add that .jar file by following the steps below:
In the left side panel named "Projects" open your project and right click on the "Libraries", then select "Add JAR/Folder...".
Then select your .jar file from the location where you have stored it in the next dialog box that opens and then press "Open".
Vola Finished!!! (with the same process you can add other libraries also like JavaCV, JMF,etc)
And Now You Can Use That .Jar File From Your Project Library.
Hope It Helps.
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.
My environment:
Netbean 6.9.1
Glassfish 3.0.1
Windows 7
Goal:
When my coworkers opens the Netbean Project, the library is already referenced without them manually create library, adding jars into it and reference it.
Detail:
I created Netbean project and the project has reference to few jar files in the folder.
Currently whoever opens the project for the first time, they have to manually create library and refer it to the project.
My project location:
C:\Users\masatosan\Desktop\myProject\myApp
My library location:
C:\Users\masatosan\Desktop\myProject\lib\myLib
The myLib folder contains:
some1.jar
some2.jar
some3.jar
I can achieve my goal if I create reference to individual jar file by defining to project.properties file like below: (creating reference to sqljdbc4.jar)
file.reference.sqljdbc4.jar=../lib/sqljdbc4.jar
javac.classpath=\
${libs.restlib_gfv3ee6.classpath}:\
${file.reference.sqljdbc4.jar}:
But my case is different since I have 3 jars in the myLib folder and wanting to reference them all.
Is it possible to reference all jars in myLib folder?
Please let me know if you need more clarification.
I'm sorry, but it doesn't work that way. When you create a project, you have to add the jar files individually.
However, if you put your lib folder under your project, netbeans will refer to them via relative paths. Then when you share the project (lib directory included), netbeans will be able to automatically find the jar files when the next person uses the project. That way you only have to add jar files once.
Short of using a dependency management tool like maven (which Netbeans has good support for), this is really the best solution. It uses a bit more disk space (obviously), but that's never been a huge issue for me.
I figured how so let me share.
Tool --> Library then library window pop up.
Create library called "MyLib" which contains multiple jars.
Add "MyLib" to your project. This change will be written to project.properties file under nbproject folder.
project.properties file indicates the classpath of lib reference you just added.
It should look like something below
javac.classpath=\
${libs.Excella.classpath}:\
${libs.MyLib.classpath}
Now someone else opens the project from different machine and she just needs to do step#1 and #2, which is to create library with same library name i.e. "MyLib"
I think this is what Bill was saying originally but thought it would be helpful to give step by step instructions since I finally figured .... after long time :D