The problem: we have dozens of Maven sub-projects (managed by m2eclipse) in our 3-level POM tree and people keep adding and removing some of them on a bi-weekly basis. The problem is further complicated by a fact that not all newly added projects result in compile-time error when they are missing. The could end up not being dropped into OSGi container since people forget to import them properly and Eclipse for some reason doesn't know about their existence automatically.
Currently, people have to watch some mailing list and whenever there is such an event, they have to go and either manually invoke import wizard for the very root POM and add missing projects or manually remove some of the not needed ones. Moving/renaming is a combination of removing/adding.
That all is very error prone and we would like to automate/simplify the process somehow.
Ideally, we would like to have the following workflow:
1) sync
2) fire Eclipse
3) Some hook to trigger which would analyze developer's workspace against latest POM tree (the very root POM is fixed and known)
4) There should be some button somewhere which would be:
- green, if everything is all-right
- red, if not
Clicking it should automatically remove not needed projects (and update Eclipse internals) and add the new ones (some sort of invoking import wizard in a silent mode).
Is it possible with the existing functionality? Or would we have to somehow extend m2e? Any other solutions???
Any help would be very appreciated!
P.S.
We're aware that this type of problem we have is probably due to badly designed project structure. However, it's not easy to get that fixed while running on tight release cycles. So, we need an interim solution.
This smells to me that you're fixing a wrong problem. I doubt something like this would be supported out-of-the-box in m2e - unless one day it becomes best practice to put each type in it's own module. After some time project modules should stabilize, and reflect architecture which can change but not frequently (major versions only). If it changes too frequently then not enough thought has been put into design decisions. Consider splitting projects into multiple sub-projects which one can checkout/clone and work independently on.
When syncing changes just check if there were modules added/deleted - and if so, after sync just logically remove and then import back existing maven projects.
Related
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.
I have 3 different packages, let's say :
com.pack.*
com.package.commons.*
com.package.app.*
The thing is, these 3 packages are in the same source folder and I can't move them.
My com.pack is completely independant, let's say it's my framework.
My com.package.commons can import classes from com.pack ONLY.
My last package can import whichever classes it needs.
In my eclipse project everything is thing as long as I'm the only one to develop, I know I can't import anything without checking first where it comes from.
But I work in a team and errors happen frequently, I've tried to make an Ant Build that will first build my framework then my commons (with the framework in it's CP during build time) and lastly my app. But I can't get any error from it.
Do you have any idea how I can perform these checks during build time or any other solution?
thanks
EDIT: I can't split in 3 projects even if it would be lot easier I know that!
Why don't you separate the project into three eclipse projects? If one package is completely independant, then (in my view) it doesn't belong into that project. And that goes to your package.common package as well. When it's a library project, then it could be separated thus implicitly solving your "separate build" problem.
As for the errors, I didn't could understand you well. What kind of errors do you mean? Import errors (e.g. visibility between packages) would be also generated when the project is divided into several projects with dependencies.
I am working with eclipse on a mavenized project which has a significant number of modules/subfolders/maven subprojects.
Whenever I look for a resource, or make any kind of research, it shows me every occurrences in every project times two because of the target folder...
example:
projectA/projectB/src/main/resource/.../Foo.xml
if I look for a string that is in foo.xml, it will show:
projectA/projectB/src/main/resource/.../Foo.xml
projectB/src/main/resource/.../Foo.xml
projectA/projectB/target/main/resource/.../Foo.xml
projectA/projectB/target/main/resource/.../Foo.xml
That is a lot for one file. Besides, let say that the prohectA is intended to create a pom, not a war, a jar, or a ear... The problem is now, that if I select this entry, I won't be able to use the auto completion, or the inspect element functionality (that I can't work without!!!!). Even worse: if i select a target directory, my changes will be overwritten on the next maven build...
What can I do? At the moment, I am just paying attention, but it is kind of painful... And I do not have time to go through all the project to mark them one by one as derived (basically around 1000 clicks), so they do not come up in the searches... Besides, the target folder would just appear again after the next maven build.
Any ideas?
The perfect way would be to have eclipse recognize the subproject nature of these, and not show the different occurrences... and maybe setup a filter for the target resources... I do not know if it is possible.
I am also willing to write a tiny script, if people are kind enough to explain to me what eclipse files it should modify in order to accomplish this.
Import the sub projects as separate Eclipse projects (this should happen automatically if you point the Maven import wizard at the master project directory). Keep the master project closed if you're not editing it. You'll still get the target folder version of resources, but at least only once.
You could use that AutoDeriv Eclipse plugin here AutoDeriv to list the paths you'd like to mark as derived, and discard from research etc. as you would do in a .gitignore file.
Once it's done, resources are always correctly marked as derived, even after a maven clean/install.
[edit]
You can write rules at workspace level, to handle several projects at once.
Exclusion rules allows you to mark everything as derived, except for a peculiar folder or file.
Since the 1.3.0 version, Eclipse decoration helps you to quickly see the effects of the plugin.
Disclamer, I wrote it =)
For my current project, every time I set up a new workspace, I need to import hundreds of existing projects scattered in 20+ different directories. Is there a way to automate this step in Eclipse?
These projects are all checked into ClearCase.
This answer shows how to import an arbitrary set of projects into Eclipse using a custom plugin.
If I understand your question correctly, you would simply need to specify the paths of all the projects to import in the newprojects.txt file in the workspace root. You may want to remove the part that deletes existing projects though.
Could you import them all into a SCCS and then check them out all at once? You might try this as an experiment using cvs, not because you want to start using cvs in 2009, but because it has the best Eclipse support. If cvs can't do it, the others probably can't either.
For snapshot views, we have a "template" workspace which reference the .project and .classpath files in a "standard" way:
c:\ccviews\projectA\vob1\path\...
c:\ccviews\projectB\vob1\path\...
c:\ccviews\projectC\vob2\path\...
So by copying that workspace, we are able to quickly setup the projects for a new member of the team.
Each colleague will define their own snapshot views with:
a unique name (
colleague1_projectA_snap,
colleague1_projectB_snap,
...)
the same root directory for each view referring to a given project
(c:\ccviews\projectA for:
colleague1_projectA_snap or
colleague2_projectA_snap or
colleague3_projectA_snap...)
Since a snapshot view can be located anywhere you like on your disk, you can:
define a standard path
scale that to a large number of snapshot views.
Of course, that would not be possible with dynamic views, since their paths would by:
m:\aUniqueName\vob1\path
You could ask for each user to associate a view to a drive letter, but that do not scale for a large number of views.
Anyway, dynamic views are great for accessing and consulting data, not for compilation (the time needed to access any large jar or dll through the network is just too important)
Eclipse as the concept of project sets, but I'm pretty sure that's tied to using CVS. My team used this feature and it's how we shared the set of projects between us.
Another 2 alternatives I know of:
Buckminster
It's an Eclipse project which does component assembly, and one part of that is projects. Documentation was a bit crappy last time I played with it, but it does work. No idea if they have support for ClearCase, though it is extensible.
Jazz
Costs money and is also built on Eclipse. Covers similar ground to Buckminster but goes a whole lot further in team-orientated stuff.
I have created some scripts to do this for SVN. Currently, the scripts are run from Vagrant, but you could run them standalone. The process for clearcase should be similar.
See the answer here, which provides links to the source code: https://stackoverflow.com/a/21229397/1033422
I am using Eclipse 3.5 for several different Java/JSP projects. All of our project code is stored in Subversion. I use the Subclipse plugin to update / commit code. This works great for all projects except one. There is one project where almost every time I do a SVN update, the entire project becomes riddled with Java compile errors. Most of the errors are complaints that it can't find other class files within the same project. To resolve this, I have to go to Project > Clean and manually clean out the project, which takes a little while to run. Everything compiles just fine after this, but it is a bit of a pain to have to manually clean the project every time I do a SVN update. And this only happens for this one single project.
Anyone experience something like this? I am not even sure where to look to figure out why the project needs to constantly be manually cleaned. Is it possible that someone else is checking in a file that breaks my project build in Eclipse? If so, what file(s) should I look for?
First, excuse me if I say something obvious, but you didn't give any details of your project configuration, nor described your previous attempts at solving this issue. So, maybe you've already tried everything I'm going to suggest... ;-)
Off the top of my mind, I'd check whether someone else is committing compiled classes, instead of sources only.
Other than that, it depends on your configuration: I'm assuming that you've got the "Build automatically" flag checked, that you're building through Eclipse only (and not, for example, through Ant, letting maybe the Ant build put its output somewhere in your classpath), and that you're not versioning jars nor your .classpath file.
I suggest (if you're not doing so) to perform your SVN updates going through the Synchronize view (Team -> Synchronize with Repository), in order to see at a glance what kind of incoming changes you've got, to better distinguish cases when your project gets messed up from cases when it doesn't.
Some one already explained that, may be someone else also committing the compiled classes , and the class paths are getting conflicts. Fist know this info from your collegues and proceed. I didn't come across this situation. sorry.
How are you storing the project on SVN? Are you storing the entire Eclipse project or just source code, structure, etc? If you're not storing the entire project I'd suggest doing that as it makes it easier to work with (unless you've got somebody using a different IDE). Without some more information it makes it hard to diagnose, but it certainly sounds like somebody is committing compiled class paths. You should check the SVN history to confirm.