Following is a question that is posted on http://dev.eclipse.org in April 2003. The original question is:
Hi all,
in eclipse i have created several java
projects representing different
modules for one web application. i'd
like to configure one output folder
for all of these projects. Any time i
build a subproject the content of the
output folder is deleted, so i loose
the classes of all other subprojects.
I think there must be a switch or
something like that to tell eclipse
not to clear the content of the output
folder when it builds a project - but
i just can't find it.
Thanks for your help!
Alex
I am trying to see if I could get a definitve answer for this question. I have tried to find out to see if this question has already been addressed and I was not able to find any except for the following answer:
Window-->Preferences-->Java-->Compiler-->Build Path
The above answer did not help me much.
Hmm... I think this approach will bring more trouble than it's worth. Sure it's a priori a quick and dirty fix to integrating your projects together but you are only pushing the problem forward. It is good practice to keep your modules as isolated as possible from each-other, trying to merge the compiled code in a single location is working against the way the IDE was designed and will only bring trouble.
I would recommend that you look into maven to build and package your modules. Then referencing them is just a matter of adding a declaration in the project that requires it and you are integrated. Of course you will need to learn it but it provides a good base of conventions that when followed yield almost effortless integration. Plus reusing some modules in another project becomes trivial so you gain in all fronts.
To answer the other question in the thread when they wish to make a tree of related projects it is possible though somewhat clumsy. Eclipse will always present projects as a flat list, however the folders can be arranged in a tree nonetheless. Just specify a custom location when creating a project or import the project from the sub-folder. Again here Maven can help a lot with it's concept of modules.
As eugener mentioned in his comment, there are plugins for maven that will make most of these tasks trivial. You may find all you are looking for just by exploring the gui, this said, reading the maven literature will give you good insight on how it works and what it can do for you.
Related
first off thanks for any help! I am relatively proficient at programming in languages like python, but that's not going to stop me from asking a dumb, and probably very basic question about JAVA
I am working on some satellite orbit research for graduate school, and I am using the maven compiled java project OREKIT. Information on OREKIT can be found here;https://www.orekit.org/site-orekit-9.2
I believe I have built the project correctly using the steps to import a maven project into eclipse, but I am having issues getting any of the included tutorial programs included to run. The first errors I get are "Error: Could not find or load main class" and then followed by the name of whichever tutorial script I'm attempting to run.
MY attempt at solutions, which have not worked are as follows: First I attempted to create an entirely different java project with a main class and import the scripts I wanted to run, but I think this created more problems than it solved. Secondly, in the OREKIT project folder which was created with the maven building, there is a src folder. I right clicked and set it as the source. It contains a "main" folder with various contents but still the errors persist.
I probably am asking something extremely simple, and googlable but I haven't figured out what to google or what to do to fix my problem. If anyone has some suggestions I would be extremely grateful!
Thanks a ton!
I'm developing a struts2 webapp for months now using maven to manage my dependencies and I've just discovered LESS. I have installed and configured the LESS plug-in for Eclipse but it's really annoying to right click > run as > LESS compiler every time I save the .less file due to a modification of its content or something...
The thing is that I've been researching on how to plug in grunt.js (recently discovered task runners too) into maven (as explained here) but I think it's quite hard and I wondered if somebody knew an alternative to this.
In my struts2 project I have both the front and back-end of my webapp.I know it's not the right approach and if I could start all over again I would separate them into two different projects, but now it's too late (disadvantages of the learning proccess, we're not born knowing it all).
Having said all this, how can I set up a kind of task for watching my .less files and automatically compile them into .css when saved/changed?
I also found this ant task here, but I dont really know if it's what I'm looking for.
There are a lot of Java Less compiler (see Java Compiler for Less CSS?), so you can execute one of them by your build tool (e.g. Ant - maybe you need to write a simple Java application, which use the chosen compiler).
If you use Maven (or can switch to it) to project management, then you can use one of lesscss-maven-plugin:
biz.gabrys.maven.plugins:lesscss-maven-plugin
org.lesscss:lesscss-maven-plugin
see more...
It is possible to create an ant task to compile certain .less files into CSS whenever they are modified, and more or less is what I was looking for, but grunt seems to be more flexible as you can tell it to watch all your files with .less extension and in this solution I've found you have to declare in an .xml file the .less files you want ant to watch.
This is not explicitly what I was looking for so I'll leave this question open for now as I'll keep researching on how to make this solution more dynamic and see if it is possible to avoid the fact of defining every .less source and .css target you want.
Link to solution here
I have seen, read and thought of different ways of using Workspaces (per project, per application (multi-asseted or not), per program language, per target (web-development, plugins,..), and so on) and I am still doubting what the best approach is.
Can anyone give a detailed, but not a page long insight into this?
This involves a lot of sub-questions, so to speak, and I don't know all the specific sub-questions I should ask, as I am sure I don't know all aspects of Eclipse (and Workspaces), but I'll try to give an example of what I am looking for:
What for?
What did the Eclipse development team expect it to be used for?
What do other/most people think?
What do you think?
... ?
Why?
Are there configuration conflicts vs. sharing merits?
Any filespace reasons?
Performance?
... ?
I am speaking of the minimum use-case for a developer that uses different languages and protocols, not necessarily all of them in one project (E.g. Php, Javascript and XML for some projects, C# for others, Java and SQL for still others, etc..)
Edit 2012-11-27: Don't get me wrong. I don't doubt the use of
Workspaces, I just want to use it as it is meant to be or otherwise if
anyone would think it better. So "what for?" means: What's the best use? And
"why?" actually targets on the "what for?", in other words: tell me the reasons
for your answer.
I'll provide you with my vision of somebody who feels very uncomfortable in the Java world, which I assume is also your case.
What it is
A workspace is a concept of grouping together:
a set of (somehow) related projects
some configuration pertaining to all these projects
some settings for Eclipse itself
This happens by creating a directory and putting inside it (you don't have to do it, it's done for you) files that manage to tell Eclipse these information. All you have to do explicitly is to select the folder where these files will be placed. And this folder doesn't need to be the same where you put your source code - preferentially it won't be.
Exploring each item above:
a set of (somehow) related projects
Eclipse seems to always be opened in association with a particular workspace, i.e., if you are in a workspace A and decide to switch to workspace B (File > Switch Workspaces), Eclipse will close itself and reopen. All projects that were associated with workspace A (and were appearing in the Project Explorer) won't appear anymore and projects associated with workspace B will now appear. So it seems that a project, to be open in Eclipse, MUST be associated to a workspace.
Notice that this doesn't mean that the project source code must be inside the workspace. The workspace will, somehow, have a relation to the physical path of your projects in your disk (anybody knows how? I've looked inside the workspace searching for some file pointing to the projects paths, without success).
This way, a project can be inside more than 1 workspace at a time. So it seems good to keep your workspace and your source code separated.
some configuration pertaining to all these projects
I heard that something, like the Java compiler version (like 1.7, e.g - I don't know if 'version' is the word here), is a workspace-level configuration. If you have several projects inside your workspace, and compile them inside of Eclipse, all of them will be compiled with the same Java compiler.
some settings for Eclipse itself
Some things like your key bindings are stored at a workspace-level, also. So, if you define that ctrl+tab will switch tabs in a smart way (not stacking them), this will only be bound to your current workspace. If you want to use the same key binding in another workspace (and I think you want!), it seems that you have to export/import them between workspaces (if that's true, this IDE was built over some really strange premises). Here is a link on this.
It also seems that workspaces are not necessarily compatible between different Eclipse versions. This article suggests that you name your workspaces containing the name of the Eclipse version.
And, more important, once you pick a folder to be your workspace, don't touch any file inside there or you are in for some trouble.
How I think is a good way to use it
(actually, as I'm writing this, I don't know how to use this in a good way, that's why I was looking for an answer – that I'm trying to assemble here)
Create a folder for your projects:
/projects
Create a folder for each project and group the projects' sub-projects inside of it:
/projects/proj1/subproj1_1
/projects/proj1/subproj1_2
/projects/proj2/subproj2_1
Create a separate folder for your workspaces:
/eclipse-workspaces
Create workspaces for your projects:
/eclipse-workspaces/proj1
/eclipse-workspaces/proj2
The whole point of a workspace is to group a set of related projects together that usually make up an application. The workspace framework comes down to the eclipse.core.resources plugin and it naturally by design makes sense.
Projects have natures, builders are attached to specific projects and as you change resources in one project you can see in real time compile or other issues in projects that are in the same workspace. So the strategy I suggest is have different workspaces for different projects you work on but without a workspace in eclipse there would be no concept of a collection of projects and configurations and after all it's an IDE tool.
If that does not make sense ask how Net Beans or Visual Studio addresses this? It's the same theme. Maven is a good example, checking out a group of related maven projects into a workspace lets you develop and see errors in real time. If not a workspace what else would you suggest? An RCP application can be a different beast depending on what its used for but in the true IDE sense I don't know what would be a better solution than a workspace or context of projects. Just my thoughts. - Duncan
Basically the scope of workspace(s) is divided in two points.
First point (and primary) is the eclipse it self and is related with the settings and metadata configurations (plugin ctr). Each time you create a project, eclipse collects all the configurations and stores them on that workspace and if somehow in the same workspace a conflicting project is present you might loose some functionality or even stability of eclipse it self.
And second (secondary) the point of development strategy one can adopt.
Once the primary scope is met (and mastered) and there's need for further adjustments regarding project relations (as libraries, perspectives ctr) then initiate separate workspace(s) could be appropriate based on development habits or possible language/frameworks "behaviors".
DLTK for examples is a beast that should be contained in a separate cage.
Lots of complains at forums for it stopped working (properly or not at all) and suggested solution was to clean the settings of the equivalent plugin from the current workspace.
Personally, I found myself lean more to language distinction when it comes to separate workspaces which is relevant to known issues that comes with the current state of the plugins are used. Preferably I keep them in the minimum numbers as this is leads to less frustration when the projects are become... plenty and version control is not the only version you keep your projects.
Finally, loading speed and performance is an issue that might come up if lots of (unnecessary) plugins are loaded due to presents of irrelevant projects.
Bottom line; there is no one solution to every one, no master blue print that solves the issue. It's something that grows with experience,
Less is more though!
Although I've used Eclipse for years, this "answer" is only conjecture (which I'm going to try tonight). If it gets down-voted out of existence, then obviously I'm wrong.
Oracle relies on CMake to generate a Visual Studio "Solution" for their MySQL Connector C source code. Within the Solution are "Projects" that can be compiled individually or collectively (by the Solution). Each Project has its own makefile, compiling its portion of the Solution with settings that are different than the other Projects.
Similarly, I'm hoping an Eclipse Workspace can hold my related makefile Projects (Eclipse), with a master Project whose dependencies compile the various unique-makefile Projects as pre-requesites to building its "Solution". (My folder structure would be as #Rafael describes).
So I'm hoping a good way to use Workspaces is to emulate Visual Studio's ability to combine dissimilar Projects into a Solution.
It's just a feature for structuring projects.
Obviously Eclipse designers tried to avoid having global settings for Eclipse and decided to put them into workspace.
Each Eclipse app depends on each workspace settings.
Is it a good decision? I think it's not so.
It lacks flexibility. It was naive to expect that global settings can be avoided.
It doesn't allow you to have single projects (it can be a surprise for Eclipse designers but it happens quite often).
But it still works.
Many people use it. Sometimes they suffer but more frequently everything is ok.
Situation:
I need several swf/exe output files compiled in FlashDevelop from several projects. More than 60% of ActionScript 3.0 source is common for all project, rest are project-specific. How can I organize that in FlashDevelop? I want to have "one-click-to-build all" setting without duplicating common codebase (so when I need to fix something I do not need to copy-paste solution into several files).
All sources are under develeopment and will change very often.
A straightforward solution is to make an external classpath, for instance:
c:\dev\shared_src\
c:\dev\project1\
c:\dev\project2\
Then configure each project:
Project Properties > Classpath
Add Classpath > select '../shared_src'
PS: of course you should keep everything under source control.
Using svn:externals you could structure your repository in such a way that the commom parts are stored just once in the source control system, so changes made can be synchronised with just a single commit and update cycle.
For example, imagine that you have ^/ProjectA and ^/ProjectB, each of with require ^/Common as a sub directory.
Using svn:externals, pull ^/Common into both projects.
The exact nature of doing this will depend on the version of svn you use, and any client you use (such as TortoiseSvn). Refer to the relevant edition of the svn book for specifics.
The ease of implementing this will depend quite a lot on how separate the common code currently is in your application; and pulling in directories as directories is much more practical than trying to pull them into an existing directory; and unfortunately wildcards for filepaths are not supported.
However, based on your description of your aim; this is the most straight-forward solution I can imagine.
Hope this helps.
I'm evaluating the possibility of developing an Eclipse plugin to modify the source code of some Java files.
The Eclipse plugin should:
add one menu option or context menu option to launch the modification process.
add a key binding
only alter the UI in that way when an editor has been open on a Java file.
the modification process would not open a dialog, or maybe, a very simple one.
the modification process would traverse the AST of the Java file and would modify it.
Considering that we have no experience with Eclipse plugins and we need spend time in reading docs, how much time do you estimate in developing that plugin?
Thanks in advance.
It's really not that difficult at all... I had students in my design patterns class doing it for an assignment (adding/removing javabean getters and setters)
See http://help.eclipse.org/ganymede/topic/org.eclipse.jdt.doc.isv/guide/jdt_api_manip.htm
[EDIT: added the following article reference]
And a great article on it at http://www.eclipse.org/articles/article.php?file=Article-JavaCodeManipulation_AST/index.html (from 2006 -- there may be a few API changes since)
Yes, writing plugins takes a little getting used to, but so does any API.
And you can modify the AST -- see the page I reference above.
(I should note that the above link is from the eclipse help, which can also be accessed via Help->Help Contents inside Eclipse -- there's a lot of good info in there, but it's just a starting point)
You'll probably spend quite some time cursing the complexity of the eclipse plugin system. There are some example plugin development projects that can be very helpful if they cover the area you're working in.
I'd say you're looking at 2-4 days of work, spent mainly getting familiar with the platform - someone with a lot of experience writing eclipse plugins would probably take no more than an hour.
However, your step 5 could be tricky. I don't know how easy it is to access and change the Java AST; my experience is based on developing an editor plugin for an exotic file format rather than Java code.
Well, the four first points are easy to achieve, even by monkey coders that look at the eclipse PDE documentation shipped with Eclipse. These can be achieve in 1 day of work, maybe 2.
The hardest point is really the fifth one and the kind of modification you expect to do. Acting directly on the editor content is simple, accessing the editor internal AST and modifying it is really a bigger challenge and I doubt that it could be achieve in less than a week by unexperimented people (it can take longer, depending of what kind of modification you want to apply).