Is there a way to get the directory of a project in Eclipse? We are writing a plugin that will allow the user to select files, and then run some processes on those files. I would ideally like to be able to get all the files with a certain extension, but that is not necessary.
sure:
ResourcesPlugin.getWorkspace().getRoot().getProjects()
will get you a list of all the projects in the workspace. you can easily iterate to find the one you want. At that point, you can look for certain files by extensions, etc.
If you want to enable your users to select files inside eclipse workspace with a certain extension, you can look at the class org.eclipse.ui.dialogs.ElementTreeSelectionDialog (org.eclipse.ui.dialogs plugin)as a start.
Then, to have an example on how to make it filter extensions, you can look at the class org.eclipse.jdt.internal.ui.viewsupport.FilteredElementTreeSelectionDialog (org.eclipse.jdt.ui plugin) to see how they do it and then reimplement the stuff.
This should give you a higher level of action than going threw files inside projects by hand and reimplement dialogs.
Related
After developing a java app in Eclipse, I would like to deploy it by packaging it into a runnable .jar with only the minimum necessary by the main method and its dependencies.
I have several packages in my workspace I work with too, but do not need to be in the resulting .jar file.
When I try to export, it clearly says that the required libs will be there, but also the other independent packages are inside too. (With the Export option happen exactly the same)
I choose to export only the Main class of the com.project... package, but also the test.project... has been packaged.
In the project I have both com... and test... packages obviously.
How could I force it to truly package only the required ones?
Thanks in advance.
TEMPORARY ANSWER (2019-07-03):
Seems that, for now, there is no way to achieve this automatically, thus the answer from #arnonuem seems a good workaround.
If better news, please feel free to improve this thread.
Thank you all.
I would create an ANT file for this specific task. There you can freely customize which packages should be compiled into the jar and which not.
Please inspire yourself reading this example.
For a general overview what i am talking about you could take a quick look into this.
https://howtodoinjava.com/ant/ant-build-jar-file-example/
Please focus on
<javac srcdir="${src.dir}" destdir="${build.dir}" classpathref="classpath"
includes="src/path/to/TheClassToBeIncluded.java" />
For more detailed information on how to include or exclude files or packages you should refer to the documentation over here:
https://ant.apache.org/manual/Tasks/javac.html
At the bottom of this page there is a list with valid build parameters.
First of all, we have to distinguish build and export.
Build transfers .java source code into .class byte code and mostly copies other resources. While doing that it usually merges all source folders into a single bin folder.
Export runs a build (or relies on Build Automatically) and then modifies the resulting .class files and other resources. Usually it packages them into one or more .jar files.
Therefore, our solution includes two steps:
build everything that is unwanted for export into a separate folder (or more)
export from a specific folder (or more)
For step 1, refer to this answer on Stack Overflow.
In a nutshell: Go to Project Properties > Java Build Path > Source tab > Allow output folder for source folders. This enables you to configure a specific output folder for each source folder in the centered viewer.
For step 2, we need to understand that eclipse's Runnable Jar File Export relies on a Launch Configuration.
So before exporting, go to Run > Run Configurations..., select the Classpath tab, remove the default User Entries and hit Advanced.... Now you can Add Folders containing your built classes.
You might want to use separate Run Configurations for internal testing and exporting.
I have struggled with this problem on and off for years, supposing it was just me who was failing to find the right solution. Possible solutions always seem to involve detailed manual configuration e.g. configuration of the build path, or selection of the folders from which classes are exported into a jar, or learning ant, but which still requires manual configuration. The problem is that the inter-dependencies between classes (and packages) are complex - imagine drawing a network diagram from import statements. Manual configuration is time-consuming, error-prone and, I think, infeasible except in simple cases. I am a bit stunned. If there is no automatic solution for selecting necessary classes, I suppose people are regularly exporting their entire code base and that the world is full of bloated jars ... (and, incidentally, without obfuscation, the entire source code base is thereby made available through reverse engineering).
I have build a set of Java classes that act as kind of plugins in a third party application.
When ever new request come on my table I create new classes (plugins) or modify existing one.
To make the changes available to the third party application I can put a Jar into an so called extlib directory or put single class files into an so called ext directory.
I am looking for a proper way to handle different versions of my files.
When changing only one single class it a bad idea to replace all class files in ext dir. Same problem when compiling as JAR. After changing one single class, I would have to compile q whole new JAR with all files inside.
Replacing all files inherits the chance of accidentely replacing a untested change.
Do you have any hints / best practices of how I could manage the different file versions?
My Ideas:
Some kind of patch would be great. When changing some files, I just push a button to compile a zip archive with all changed files inside. In optimal case with a version mark in all the files.
Would something like this be possible with eclipse plugins pxe.?
There exist a number of workflows for this.
The terminology varies a bit depending on the version control system that you are using; I am going to use git terminology.
One workflow is to always work on a branch, and to never merge a branch that has not been thoroughly tested into master. So, then, a release is only made from master.
Another workflow is to work on whatever branch you want, merge into master whenever you want, then every once in a while pull from master into a designated "release" workspace, do your testing there, and then release from that.
As for binary patching, I am sure there exist tools out there, but I do not know of one, I asked a few people and they don't know either, so I have no answer for you here. I suppose if you have .class files you can use some folder synchronization tool, but if you have .jar files then you are going to be replacing them in their entirety.
I am building a desktop application with NetBeans 8.0.2. For my application, I have to manage 3 differents projects : The main project, and two "tool" projects that are linked to the main.
When I run the main project, it will check the JARs present in his classpath in order to retrieve the Manifest files and do some work with.
In order to have my application run correctly, it has to see the two linked projects' JARs but it doesn't, because NetBeans deals with the compiled classes of the project instead of the JAR (for debugging purposes I presume).
I found nothing about it on the Oracle documentation, and the only thing looking a bit like what I search is to create a big-fat-JAR by using another component.
Is there a way to tell NetBeans to "compile the linked projects and use the JARs instead of the .class" files ? Thanks in advance
EDIT : Here is an example when I add the project with "Add Project .." option
/C:/Users/xxxxx/Documents/GuiceProjectsRD/xxxReaderRef/build/classes/
And here is an example when I add the JAR
/C:/Users/xxxxx/Documents/JavaLib/xxxReaderRef.jar
When I add the JAR, I have the ".jar" extension which helps me identify a JAR and then look into it for a Manifest. When I add the Project, there is no path to the JAR but only to the compiled classes, and I can't work with that.
I would not depend on the Manifests in Jars since you then get this kind of issues.
Have a look at the Typesafe Config library. It's a small 100% pure Java library to work with Json/Hokon configuration.
Instead of relying on a Manifest, create a 'reference.conf' in each tool project. In your application, create an 'application.conf' (if needed). Load the config via 'ConfigFactory.load()'. It will automatically search all available reference.conf's, and application.conf, on the classpath, whether in a jar or not, and merge those configs into a single configuration.
I use this approach in project to be able to plugin extension. Have for example in tool A a configuration like
tool.A.class = 'my-tool-A.class'
or used nested structures like
tool {
A {
class = 'my-tool-A.class'
}
}
Do something similar voor tool B.
Then in your application, from the Config, you can get a list of 'tool' configs and detect the available tools like that.
I have a java source file in my project, that I want to move to an entirely different location than the rest of the files (my unix home dir), but I still want to be able to properly use it in my project. Is there a way to do this?
EDIT - I see there is a vote to close this for being unclear, so - let's say you have a pJava project in Eclispe. All the source files are neatly saved in their relevant packages, under the same directory. Now, I want to move one of the files to somewhere completely different, but still have it used in my project. I hope this clarifies
Thanks!
I suggest that it depends on what your reason is for moving the source file.
The Java file is still conceptually part of this project, but you're moving it for general organisational purposes. In which case, the new "completely different" directory is another place where sources should be read from, which most IDEs will call a "source root". You should configure your project to read sources from there as appropriate for your IDE.
You're moving the file because it's distinct from this project. In which case I would suggest it ought to be a separate project in its own right. In order to still use the logic in your original project, you'd build the new project into a JAR, and then bring in the JAR as a library dependency (either directly, or using some dependency management system such as Ivy/Maven/etc.). Again, the details will depend on what your current setup is.
Right click on your Eclipse's project -> properties -> java build path , and under the source tab click Link source then choose the parent folder of your java file .
I'm currently developing a 2 project system, mainProj and sideProj.
The idea would be to have the output .class files from sideProj be put as mainProj's resource files, so I'd like to find a way to automatically put the output os sideProj as resources of mainProj.
The "default output folder" option only seems to allow me to output to any directory inside a given project, not to other projects.
What would be the best way to accomplish this (preferably without having to resort to ant)?
Isn't it easier the other way around by simply adding sideProj to the build path of mainProj? Like for every normal library project and main project? Or is there a more specific reason for moving those class files?
If you really want to process as described initially, an Ant based builder is probably your only choice (select sideProj, context menu, properties, builders, add, Ant, ...). While you have to write that short script yourself, it takes part in the automatic build process afterwards without you needing to invoke it.