I am trying to create a script that would list all the linked libraries in an FDT project and their corresponding svn repositories.
My problem : I was not able to find the file on my system where Eclipse (or FDT, I'm not even sure) writes all of the path variables.
I have tried capturing changes on my system and have had no luck.
If anyone knows where to find this file (Mac OS X) or knows a technique I could use to find it, it would be very appreciated.
Thanks.
In FDT, you can find the list linked libraries in the .as3_classpath file if those libraries are in your project folder (or below). They reflect the content you add in the 'Library' tab of 'FDT Build Path' in your project's properties. There's also an entry in the .project file that reflect the linked libraries you add with the 'Source' tab. Those libraries can be located anywhere on your hard drive, and that's why you define 'path variables' for them.
Personally, I create a 'lib' folder in my project where I copy the libraries I need and add them with the 'Library' tab. I find it much easier to share the project (since everything is relative to the project) and you don't need to worry about having two projects modifying the same library file.
For the location of those 'Path' variables, as far as I know, could only be located in your eclipse installation folder or in your eclipse 'settings' folder, usually in your 'user' directory.
Related
I have imported a very large project for an STM32F4 that I have found online. I was going through including all the .h files in folders when I realised the program structure had them everywhere and outside of neat Inc/Include folder.
The method I normally use is go to Project Properties>C/C++ Build>Settings>Tool Setting Tab> then include the folders in the Includes boxes provided, the "-I" box.
This is very tedious; is there a better way?
I hope it's OK to ask this here. Netbeans forums isn't responding. If not, I'll delete this or ask for it to be deleted. I'm desperate so I'll face the wrath, if any.
I moved my Netbeans projects folder from one directory node to another to make backing up all my stuff easier. BAD MOVE.
Now when I open a project using Files | Open project (ctrl-shift-O) NO source files appear because there is no "+Source Packages" node to expand.
It looks like this for all projects, e.g. one named GBL:
Projects
-GBL
+Libraries
It doesn't look like this anymore:
Projects
-GBL
+Source Packages (How do I get this back?)
+Libraries
The Netbeans Properties for each project shows me the path it's using. Windows 7 Explorer shows me that the src, build, and nbproject folders contain files and ALL the source files are in the src folder for that path.
What have I done and more importantly what should I do to get back to being able to open a project normally?
(I've tried recreating the original Netbeans folder and using Windows Explorer to copy an entire project folder into it but: same result--all I see is the Libraries node under the project's name node.)
I just tried to Clean (and also Build) to see what would happen. Error:
ant -f C:\\Users\\Dov\\Documents\\NetBeansProjects\\BasicShirt -Dnb.internal.action.name=build jar
C:\Users\Dov\Documents\NetBeansProjects\BasicShirt\nbproject\build-impl.xml:[u]231[/u]:
Must set src.dir
I just Set Configuration by right-clicking the project's name and provided a path to the src folder.
NOW I SEE MY SOURCE FILES BUT NOW THIS line in the .xml file is flagged with similar message:
<fail unless="[u][b]test[/b][/u].src.dir">Must set test.src.dir</fail>
NOW what do I do? (Netbeans 7.4.)
If I could get rid of the 7.4 automatic creation of +Test Packages, I might be OK.
If you can help, I'd be very happy.
(I'm considering re-installing 7.3 if available or removing and reinstalling 7.4 and try to avoid the "testing" requirement, but there goes all my many tweaks of 7.4.)
Well, after considerable frustration with the problem, I solved it, essentially.
It's here, in total. My synopsis plus how it helped me follows. In short, I had to set up a new java project based on existing sources using the New Project Wiz and simply direct Netbeans to the sources.
File > New Project
Choose Java Project with Existing Sources.
Type a (new) project name and ...
... make the Project Folder contains the path to where you want the new project to be stored. (For me, this is the folder where Netbeans has been able to find my sources.)
Click Next for the Existing Sources page of the wizard and ...
5a. ... in the Source Packages Folder pane, click Add Folder and ...
5b. ... navigate to your sources and select the source root folder.
Clicking Next goes to the Includes/Excludes pane, which I didn't need to use.
In my project there is a symlink to a folder from another project.
The name of this folder is in .cvsignore
But this folder (symlink) contains cvs metadata (CVS folders) from the other project.
The cvs command has no problem with this and ignores the folder.
But eclipse wants to synchronize it.
The question is, can ecplise ignore a folder at synchronize time, or how to make eclipse respect .cvsignore files?
the folder (symlink) name is shared and in my .cvsignore contains a line with it's name
We use the symlink trick to share sources between our software and its plugins which are built separately (separate autotools projects).
The issue here is an explicitly shared folder overriding the .cvsignore entry.
You can find the exact details as explained by the previous Eclipse CVS component lead within bug 169710. This bug is marked as a duplicate of another defect which is still open, meaning this is a known issue.
As Michael pointed out, your choice is to use an Eclipse link for development:
Add new folder to Eclipse project
Select Advanced > Link to alternate location (Linked Folder)
Select the workspace variable (i.e. WORKSPACE_LOC) and point to the other project on your workspace (i.e. WORKSPACE_LOC/other_project/foo)
This will get you a linked resource that developers don't have to worry about mistakenly checking-in. For your automated builds you'll need an extra post-checkout step where you create the symlink.
This is not ideal but it's a sensible alternative, short of fixing the Eclipse issue.
I imported external libraries using absolute path. But I have two work environments, switching between Linux and Windows. Projects are downloaded from SVN. So I was wondering whether I can import these libraries by relative path.
You should declare a variable (Java Build Path -> Add Variable... -> Configure Variable ... -> New) to set the changing path on each system (e.g. FOO_BAR_HOME).
Than you can add the Variable to the Libraries and edit it to point to your library, like
%FOO_BAR_HOME%/lib/foobar.jar
Take a look at the existing variables for usage.
Alternative you can place the library inside the project (e.g. subfolder 'lib'). If you add the library from this location ('Add Jars...' NOT 'Add External Jars...') it will be added by relative path.
Hey I was having this issue as well, but I can offer an alternate solution for those who want to keep the required library locally but outside the directory of the Java Project.
First, add the library you want using the usual "Add External Library/Jar" method.
If you go into the home directory of your Java Project, you should see a .classpath file. Edit this with any text editor you wish, and look for the line that references the library you added. Then, say your library is called lib.jar and you have it one level outside of your project.
Lets say the line says:
<classpathentry kind="lib" path="C:/Users/Public/workspace/lib.jar"/>
Rather than moving lib.jar to your Project's directory, you can just change this line to say:
<classpathentry kind="lib" path="./../lib.jar"/>
and your Java Build path will be updated to look for it in the directory one level above the current project.
Also, to my knowledge if you're running a Mac or any Unix based OS, then the .classpath file will be hidden. In order to access it, you can try opening it from Terminal, by navigating to the directory that your Java Project uses (the actual project folder itself, not the workspace), then either vi or vim ".classpath". Keep in mind that using ls or even ls -a might not work, but trust that it will be there.
Once you've changed it to the specified location, save the file and when you go back into eclipse, the reference should still be working. Keep in mind that the "./" at the beginning is necessary. Just having "../" will not work, or at least it didn't for me.
I did it very simple. I had a lib with an absolute path in my classpath:
/home/glauco/workspace/ltClubs/lib/swingx-core-1.6.2.jar
So i just removed the absolute path from it and it works. Now it's relative xD:
lib/swingx-core-1.6.2.jar
This should be a comment on the previous answer, but the strange reputation system from this site forces me to post a new answer instead... (no comments)
You can use a relative path, but you're missing the './' in it.
Instead of
lib/swingx-core-1.6.2.jar
you should use
./lib/swingx-core-1.6.2.jar
Add the folder containing the dependencies into the JAVA project. Select and right-click the dependencies, "Add to Build Path" pops up as a context menu. This adds the dependencies using relative path instead of the absolute path.
What do you guys do, when you have huge project built with ant for instance, where the source folders are right bellow the root project folder, for building classpath from source files ?
Putting entire project as a source folder is nonsense.
Putting separate folders as source folders can't be done if they are part of the package hierarchy and the only thing I could think of, is to copy the source folders into a separate folder and add it then as source folder which is weird but I don't know how else to do it.
Having to duplicate sources just because of the eclipse way of making classpath and also because of somebody doing stupid project structure
It's really pain in the ass...because the ant scripts are written for this structure.
Even if it was just one folder, it's a problem anyway. There must be included the upper folder to the source classpath which means it is included with all the crap around and also it means that package explorer is flooded with the packages.
example:
Instead of /project/src/java/utils where we can put src folder into source classpath...
there is project/java/utils + lot of crap like /project/docs is in the project as well.
The trick is:
An Eclipse project root directory is defined by where the .project and .classpath are.
Two options here:
Those Eclipse project files are located in the workspace (and the 'project', the one with 'java/utils' inside, is not)
Then you can make a linked folder within the Eclipse project to reference 'project', calling that linked folder as 'src', using it as your source folder.
The ant script remains right where it originally is (in the 'project' directory, along with all the other sub-directories)
Those Eclipse project files are located directly within the 'project' directory (along with 'java' and 'docs': don't.
Delete that Eclipse project (not its content, only its definition, that will only remove the .eclipse and the .classpath), and recreate anywhere else.
Then go back to 1.
For each source folder in eclipse you can choose which subfolders of it you want to include or exclude as a source folder (you can also use patterns). If I understand correctly, in your situation you can add the project root folder as a source folder and include only those folders that contain source. So in your example only "java" would be included.