When you start a new Eclipse IDE and create a new MWE2 workflow you can reference workflows from plugins in the target environment or workspace (within new RCP)
component = #foo.MyWorkflow {}
But this doesn't works for all workflows, some aren't resolvable:
Couldn't resolve reference to Module 'OtherWorkflow'.
Even when copying MyWorkflow, renaming to MyWorkflow2 and restarting the RCP: MyWorkflow2 isn't resolvable.
edit: must be some kind of problem of the xtext referencer, after some time without any changes, also other workflows can be resolved, but after deleting the workspace of the RCP they re-disappear
edit2: appears like a bug in 2.3.1, with latest nightly (pre 2.4) all workflows can be resolved
First: The # notation does not require a second eclipse instance. The editor and tooling also resolves in the same instance.
Second: The mwe2 builder is not very reliable. Have a look at the hidden bin folder within your project space. The builder should copy and update your mwe2 files in this location. It will only reference files that are present and up-to-date here. I found that I often had to touch the source files to force a rebuild, or to delete the target files to get rid of a stale state that was not recognized.
Otherwise mwe2 is a sparsely charted meta-black hole. You have your wits. Good luck.
Related
Introduction
I have spend a lot of time to fix this bug
In our application we have a lot of generated code by cxf and jaxb which produces tons of warnings. We use the maven-build-helper plugin to add this code to our projects automatically.
By adding this enhancement, eclipse JDT enabled the possibility to set the javac -nowarn flag for specific source folders. Unluckily, by updating the maven project the flag gets lost. There are a few threads on SO where users got bugged by bug.
What I have tried so far
So i came up with a clever solution, javac has a nowarn flag. I set it to my maven-compiler-plugin and specified the directory. My maven build was fine, but my eclipse build wasn't. My research told me, that eclipse jdt does only use the maven-compiler-plugin source and target version. So my next step was to try to configure the EclipseCompiler, but this is not possible, because there is no possibility to add custom compiler Arguments in eclipse JDT.
Next Step. Inside of the .classpath file, eclipse JDT adds an ignore_optional_problems attribute for each ignored path. By updating the maven project inside of eclipse, this entry gets lost. So i started to write a maven "ignore-source-folder" plugin which should add the missing attribute. To run the plugin each time eclipse starts a build, i also created a m2e connector to refresh the .classpath file and everything should be fine.
By testing my plugin with my connector i realized, it works, but only 70% of the repetitions.
What happened?
Every time eclipse m2e/Jdt starts a new build, all classpath entries will be removed and populated again. When my maven plugin gets triggered by eclipse, a race condition starts.
So I started to analyze the code of jdt and m2e jdt. The ignore_optional_problems flag gets only once set manually inside of the patch which was provided to JDT and isn't stored somewhere else. By triggering a new build via m2e-jdt this information gets lost.
How to fix this problem
To fix this problem, some element has to be added or extended in jdt which contains all ignored folders. If a new build gets triggered and the classpath file gets newly generated by m2e-jdt this element should be checked for ignored paths. ClasspathEntryDescriptor seems to be a good place for it.
My problem
I checked out jdt and m2e jdt, but i have tons of errors inside of my IDE and i have no idea how to start. And even if I fix the code, I have no idea how to build and test it. I think my effort will be to high and we talk about 20 or 30 simple lines of code.
I am afraid if I add my results to the filed bug at eclipse, no one will care about it.
So, is there any developer able and willing to help me for this tiny job?
You need to "fix" the M2E's JDT project configurator. Probably somewhere in the m2e-core project. So, your change should obtain some kind of configuration flag from the project pom and create corresponding classpath entries for JDT.
I have some data resources that I would like eclipse to not copy every time it builds. I put them as part of the build path so they get copied, but I don't want that to happen every time as it's time consuming.
Any idea on a better strategy?
I don't even want them to be deleted when clean is invoked. In Visual Studio one can mark a resource file as "copy once" is there such a thing in Eclipse.
Thank You
Having eclipse not copy some file that you have modified even after a clean will be a nightmare: you'll have to remember to copy it manually each time it's modified.
And Eclipse only copies files which have been modified when building incrementally.
If it's so slow, it probably means you have too many such files, and they should perhaps be put in a jar in the build path.
As you ask for a strategy, then ...
Eclipse is not a build tool, it's IDE. So you better not try to setup some build logic based on it. Use eclipse for coding and for performing specific tasks during build use build tools like maven or ant.
I created an Eclipse project and now I want to put it on my SVN repository. Which files should I put on ignore list? There are many files that I don't know what they are used for. There are folders like .history, .root, .safetable, .log, .settings ... and many .index files, also some .running files. Can I put all that to ignore list? Do you know which extensions/folders can always be on ignore?
Thanks.
The answer is very dependent on your project. Committing the source is a good thing however it'll force new developer to recreate the project environment which can be painful. If you are using Maven with the m2eclipse plugin committing only src and pom.xml is a good approach as it only takes a few minutes to recreate the Eclipse environment from src and pom.xml.
On the other hand it is ok to commit .classpath and .project but that also means extra work such as never using external jar directly but through variables or user library, etc.
If you have time to experiment, why not check in everything, have a colleague check out the project, and see what throws up errors? Anything that references paths outside the project is likely to fail if your colleague doesn't organize her harddrive the same as yours. Those things should be changed to reference variables, or not placed under version control.
Let your colleague build the project, run the IDE through its paces, and then sync up to the repository to see what changed. Files that are volatile, run time logs, and temp files should be omitted. Anything that makes it easier for another developer to setup the project and get running should be included. Taking time to experiment will help you gain a better understanding how your project is setup.
Basically, you want to avoid checking in anything derived from source (like .class files in a Java project) or anything that every developer would have to change for their local environment, like a file with absolute references outside the project directory. One approach I have used in the past for handling configuration files that require customization by developers is to include a copy of the file, usually with extra comments, with a .example extension. Make it clear in a README or other documentation which example files need to be customized and what the "real" name for the file should be. Also include he "real" file name in the svnignore list so it doesn't get checked in and overwrite everyone's local customizations.
To address your specific examples:
.history, .root, .safetable, .log,
.settings ... and many .index files,
also some .running
.settings is one you'll have to experiment with. If you have settings, such as code style or formatting guidelines, that all developers need to follow, then it can be handy to have those under version control, but some other settings may not be appropriate for all developers. The other examples are not familiar to me, possibly because they are associated with a type of Eclipse project I don't work with.
My first guess would be that any file whose name is starting with a dot should not be versioned. Most commonly such files refer to Eclipse settings which are not project-relevant.
Now, the .project and the .classpath files, in a Java project, are quite "project dependant" and I usually include them.
To get a more precise answer you should specify which project type you are working on.
I have a bit of code for a dll that is needed by two or more projects in eclipse. Currently each project has a copy of the code and builds the DLL separately. I want to separate the dll code into a separate eclipse project so there is a common location. But I want to avoid the situation where we have to build the dll in the one project, then copy the dll back to the other projects and check the dll to each respective project. This will create a dll for each project that isn't traceable to the exact code that it was built with.
Is there a way to somehow symbolically link the dlls to another eclipse project that is using CVS as the version control system so that it is possible to tell which version of the code was used to create the dll? Am I making this too complicated or missing something obvious?
I thought about working sets in the package manager for eclipse, but I have to investigate more on how to use them with CVS to avoid making it a nightmare for the next person who checks it out and can't figure out why their project won't compile.
Thanks.
What about creating a new folder in a separate project. In the advanced section of creating a new folder there is an option to link to another location on the file system.
Or you could also create a container project that makes use of a projectset.psf file. Have the projectset file link to the different projects in your repository. When you want to check out that project, check out the container instead and right click on the projectset file and select Import Project Set...
If you are working with one workspace, you end up with three projects, each mirrored in CVS: One is the dll, the others are the projects using the dll (configured as a project dependency of these projects upon the dll project).
With three projects I wouldn't aim for working sets - they are good for managing a lot of projects within one workspace, for three projects, I'd consider them overkill. I usually tend to aim for several workspaces instead of working sets.
Regarding the next person working with these projects: You need to keep some kind of documentation about how to setup your projects. You might say that your eclipse project files do just that (as they define a project dependency upon another project) but this is for the machine - humans tend to like other communication means.
If you are worried about changes to the dll being incompatible to one project (because the person applying these changes doesn't care about the other project), aim for a build server. This will build all projects and dependent projects whenever something under version control changes, run all tests, provide a build number and package it all ready for use. This way you can be sure that - whatever is in your deliverable - can be reproduced, because the buildserver is not able to make local (uncommitted) changes to the code. Also a buildserver will signal failure (either broken API or broken tests) at the moment of the last commit (well - a few minutes later) and place the burden of repairing the damage on the one causing the damage.
I have created a Dynamic Web Project in my Eclipse workspace. It is also a Maven project, and under SVN control. But in "Open Resource" (Ctrl+Alt+R) no file from this project appears, unless I check from the window's options (top right drop-down) "Show Derived Resources".
I have checked on some of the project's folders and they are not marked as "Derived".
I have two more (plain Java) projects in the workspace, and all the files from them are visible in "Open Resource".
Do you know what might be wrong with either Eclipse, the Maven plugin or Subclipse (the SVN plugin)?
I experienced a similar issue in Eclipse (Ganymede), when using the Maven and Subclipse plugins. I have not determined which plugin caused this problem, but I suspect that it is related to my pom.xml containing nested modules (ie. a <modules><module>main-module</module><module>integration-test</module>). These appear in Eclipse as nested folders with their own pom.xml files (I did not use the Multiple Projects plugin although I have installed it).
I assume that one of the plug-ins has incorrectly set the derived flag on these folders when I checked out the project by SVN and then updated the MVN dependencies and project settings.
When I right click->properties on the top-level nested module directories I can see the Derived flag is checked. By unchecking the derive flag on the module directories (and checking the derive flag on the target directories within each sub-module instead), it fixed the Open Resource functionality.
As the derived flag is inherited from directories, you may need to check all of your directories in the hierarchy to find the 'culprit'.
If it helps the plug-in authors, my top level module directories contain a hyphen '-' in their names. Maybe that is throwing out one of the plugins.
I think it is the maven plugin:
Jira issue
See also the notes for July 31, 2008 at the New and Noteworthy page for m2eclipse.
Several other nice links deleted because of restrictions of stackoverflow.
In fact, I think that somehow this is eclipse in its own right, as I don't have m2eclipse or using maven for this.
By default, eclipse uses /bin as the target directory. My situation is similar to having maven in the project in that the target directory was changed to lib/classes to accommodate an existing project.
I started seeing issues similar to what is reported here, and while searching for the problem, came across this solution. Eclipse somehow didn't "uncheck" the bin directory as no longer derived, so I ran into the same issues. I tried replicating it, but I couldn't.