Right click an arbitrary existing project in Package Explore, choose "export..." - "Java" - "Runnable JAR file", I find all the old projects in the "launch configuration" list. Those projects have already been removed from the disk, and are not visible in the Package Explore. How can I remove them from that list? I'm using eclipse indigo.
This question seems to be well answered here, however, to make changes I have simply deleted every undesirable launch configuration from the below path.
${WORKSPACE}/.metadata/.plugins/org.eclipse.debug.core/.launches/Delete all the .class LAUNCH Files
After deleting the files, it is necessary to restart Eclipse for the changes to take effect.
Under Window...Preferences...Run/Debug...Launching...Launch Configurations, you can activate and deactivate some filters that restrict what is shown in Run...Run Configurations. I think it is what you are looking for.
Eclipse menu -> Run -> Run Configurations... pops up the list of all viable run configurations, grouped by type. You are looking for those under Java Application. Any of these are deletable. Delete them and they will no longer show up in Run/Launch configuration lists.
Go to Run->Run configuration. Delete the existing saved projects under the Java Application.
Run the class, having main method from eclipse. It will be automatically set.
create runnable Jar.
Go to Run->Run configuration. Delete the existing saved projects under the Java Application.
Then run the class, having main method from eclipse. It will be automatically set.
Now create runnable Jar.
Related
I have tried to find these out, but could not.
Can eclipse open all dependent projects? I have a maven project with dependencies. Can eclipse open dependent projects also? (or at least try to, as some of the dependencies are external and would have no sources/project)
As a workaround to the above possible limitation in eclipse, i have created working sets and added projects to them. But could not see an option to open all projects in a working set one one shot. Is there such an option?
(Using eclipse Kepler)
Selecting this option should do it for you.
mark all project, right click and select open project
In Eclipse I have two maven projects A and B, where A is a parent for B. The directory structure is the following:
A/pom.xml
A/B/pom.xml
A/B/...
Then I use File search (Ctrl+H) to find any file in the project B. The search result window shows the file two times with different relative paths:
A/B/<my_file>
B/<my_file>
So, the same file is shown twice. Obviously, the first search result is reduntant. Is there a way to exclude these duplicate search results?
What I personally do to avoid this is marking each module in the parent project as derived (right-click on the folder > properties > Attributes: Derived).
Then when you perform a file search, uncheck "Consider derived resources" (I don't think it is checked by default) and you won't get the A/B/<my_file>.
The only inconvenience is that you must do this for each module, and each time a new module is added.
In an open resource window (cntrl+shift+R), click on the arrow on top-right and check "Filter Duplicated Resources". This worked for me.
Checking Window -> Preferences -> Maven -> Hide folders of physically nested modules (experimental) worked for me in Mars.1 Release (4.5.1).
After checking it I closed all projects within eclipse, deleted eclipse project files (.project, .classpath and .settings) and reimported my maven projects.
I had similar problem.
My solution for this problem was
Create eclipse "working set" of projects to search
Set this working set as option into search dialog
Search in it
Windows - Preferences - Maven - Hide folders of physically nested modules
I agree with Damon Horrell.
Go to Windows - Preferences - Maven - Hide folders of physically nested modules (make sure the checkbox is checked).
Note: Make sure to re-import the maven project into eclipse to see the changes.
Within the parent project, child ones were already visually hidden in my case, but still found through search and Ctrl-click links.
I solved this by using Resource filters:
Right-click (parent) project > Properties > Resource > Resource Filters
Click Add Filter..., select Applies to -> Folders and enter one child project's folder name, click OK
Repeat 2. for all child project folders
By the end, you should have something like this:
There is an ancient bug which requests Eclipse to support nested projects. Opened 2008, won't happen soon, I guess.
Since Eclipse doesn't support Maven's default nested module layout, you have to import each module individually which doesn't confuse Eclipse but it can confuse you as you can see in the search results. Similar things happen when you start to save launch configs in a module.
There are several possible solutions:
Get used to ignoring half the search results. Takes some discipline but no magic.
Make sure your root project doesn't contain anything important that you might want to open from Eclipse (i.e. move the parent POM to a new module which must be a child of the root project). Now you can close the root project.
Takes some discipline where to put things in your project and it's clumsy when you have to add new modules.
Use the flat multi-module approach. This is an extension to #2, it looks odd and there might be plugins that are offended by that. So if you use a lot of nonstandard plugins, you should check whether they like the new layout.
As a new joiner, still couldn't comment but I'd really like to add something to the best answer. It works! It not only removed the duplicate files for me (one from child module and one from parent module), it also removed the class files from parent module).
But it added the folder to my .gitignore which will cause problem for new files/directories added later. I just reverted the change to .gitignore and it still works in eclipse.
Find this answer to disable auto change of .gitignore
EGit and Eclipse modifies .gitignore file but it should not
You can solve this problem using a flat multi-module approach.
Caveats may apply if you're using the maven-release-plugin with a version control system other than Subversion.
In addition to "Hide folders of physically nested modules" mentioned, you could uncheck parent modules when importing Maven project:
I set my java runtime options in Eclipse's Window > Prefs > Java > Installed JREs > Default VM Arguments. Since this setting is sufficient for all my main() entry points, I do not bother with customizing the "run configurations". It looks like nice flexibility but I probably will never need it. I was worried that I would have to repeat my VM arguments in the run configurations and so I started to copy my VM arguments but after an experiment it seems that I do not have to. Now I will have the opposite worry that I have some unintended customizations.
To eliminate the second worry, is there a way to eliminate the clutter visible in the Run drop down menu? What about the "Launch configurations" visible in the JAR export dialog? Is a run configuration the same thing as a launch configuration? How do I eliminate the multiple launch configurations?
I am on Eclipse Indigo on Ubuntu.
Edit After I manually delete all the run configurations, and proceed to do an export, buttons are greyed-out so I can't proceed. When I select the launch configuration drop-down, I end up with only one choice, from an unrelated project. I then created a run configuration for the real main entry point for the current project. I expect the clutter will return as I continue to use Eclipse.
One simple way would be to organize your projects by Eclipse workspace, which would limit the "run configurations" list only to the project referenced in a given workspace.
Switching workspaces would reset that list to the ones recorded for the projects of the new workspace.
Note: the OP's answer regarding launches file location isn't the only location possible.
The official one is:
${WORKSPACE}/.metadata/.plugins/org.eclipse.debug.core/.launches
But you can copy them enywhere else you want (as explained in "How do I save Eclipse launch profiles across workspaces?"), either by manually copying those files or by sharing them:
See "Which eclipse files belong under Version Control".
Once you know where they are saved, a simple delete is enough to make them disappear from the launcher menu.
The answer comes from #Francisco Puga
Experimental evidence shows that deleting "launches" seems to make run configurations disappear so it would seem that they might be synonymous.
I'm using eclipse to run the tests in a single junit(4) test class. The tests in the class all run just fine. Then I add an additional test and run the class through the test running in ecplise again. Only the old tests are run. The new test isn't seen by eclipse. There's no error or anything, it's just as if eclipse is looking at an old version of the test.
If I run the tests using maven, everything works fine. Additionally, after I run the tests in maven, ecplipse can see and run the new test correctly.
Any ideas what's going on? Any ideas how to get ecplipse's test runner to see my new test cases?
I had the same issue. I solved it by doing the following:
Going to Project -> Properties -> Java Build Path
For the source folder src/test/java, the output folder was set to
"Default output folder"
Setting this to the typical Maven target/test-classes directory in your Maven structure
After this, Maven and Eclipse were in sync (as opposed to Eclipse happily running an older version of the tests, from whenever the last Maven compile was).
Maybe you "just" need to create a new Run configuration. Eclipse "remembers" the latest used Run configuration and just repeats it if not told otherwise. To make sure you have a new Run Configuration you can rightclick the test case in the package explorer and choose Run As | Junit Test. Next time you hit play this will be the "remembered" Run configuration etc.
Possibly src/test is not in the Java Build Path.
Solution on Kepler:
Project -> Build Path -> Configure Build Path -> Source -> Add Folder
Then check the box corresponding to test under src
You might find this is likely caused by using Maven to build (Maven usually builds into the 'target' folder), but Eclipse is using a different build folder for its own build process. Simplest way is to go into the target folder under your Eclipse Project (or Bundle if using OSGi) and delete the conflicting subfolders/class-files from under that directory; for me this is my "target" folder. Then get Eclipse to rebuild, and everything should be fine.
Technically, and alternatively, you could just blow away the entire build/target folder if you wanted to, and let Eclipse rebuild everything.
In response to the answer provided by Ryan Dawe, I have found out that Default output folder can be set to only one folder, for all the source folders on build path. So if i changed the output folder to target/test-classes, my src/main/java was also outputting classes there.
You might have written this response for a different older version of eclipse, but as of Mars.2 release, we can only have one default output folder for all source folders.
The best solution i have found so far for this problem is to just include the target/test-classes as a class folder, by going to Project -> Properties -> Java Build Path -> Libraries -> Add Class folder.
It seems that your project wasn't recompiled. Either check Menu:Project/Build Automatically or do it manually as Boris Pavlocic commented.
This seems to be the same issue as junit not using the newest file
The problem seems to be that Eclipse puts the compiled tests in the wrong folder which can be solved by manually specifying where they should end up.
Add "test" in front of your test classes if not there already the #Test annotation isn't always picked up from Eclipse's Junit Test framework.
Here is how i fixed my problem...
right click project and go to Run As -> Run Configurations...
select JUnit -> [project-name] on the the popup that came up
(this configuration of [project-name] was created for me by eclipse
but if not there you can right click JUnit -> New and create it)
goto Classpath tab
highlight User Entries and click Advanced... button
on the Advanced Options popup that came up select Add Folders and click OK
on the Folder Selection popup that came up scroll to your project open up target and select test-classes and click OK
repeat steps 4-6 for the [project-name]/target/classes directory and any other directory needed in your classpath (like properties files used in your tests etc.)
Note: this assumes your project's default output folder for tests is target/test-classes, if it is not then adjust accordingly. Also, make sure you have the right JUnit version selected under the JUnit Run Configuration as well and your src/test/java directory is a source folder to your project, etc. as mentioned by others.
It means that you have created a Test class that you haven´t build yet.
After a build, for example with "gradle build" the Test class will be found by Eclipse too.
In my case I had to make a cleanup before as well.
I'd like to use the source code of maven-managed dependencies when debugging our webapp in myEclipse 8.
I have managed to attach the sources to the libraries in the "Maven Managed Dependencies" classpath container, i.e. when I open a class file from a dependency (e.g. using Ctrl-Shift-T), I see the source code.
However, when I define a server connector for my tomcat, deploy the wepapp to it, and launch it in debug mode and execution halts on a breakpoint in that same class, the editor pane only displays the text "source not found", and a button to edit the "source lookup path". I have attempted to manually add the "Maven Managed Dependencies" classpath container, only to be told "Use maven project settings to configure depedency resolution". However, I see no useful setting in that property pane ...
How can I attach those sources? I am aware that this works with the m2e plugin and wtp, but I'd rather avoid convincing the rest of my team to switch plugins ...
Looks like issue MNGECLIPSE-983
I have confirmed that if I manually pick the External Archive option and find the relevant -sources jar (navigating that big .m2/repository tree to find it) and then add the jar as a sources it does work, and surprisingly it does remember the next time which isn't too bad.
That's at least doable I think for me because we don't often need to step debug through external dependencies, but when we do, it's often frequent, so adding it once while a bit of a pain, can be done on a case by case basis.
I have since discovered that this problem only occurs if the server is launched using a launch configuration.
The problem does not occur if the server is started by:
click the server icon in the toolbar -> context menu appears
mouse over the intended server -> submenu appears
click on "Start"
While this precludes sharing the server configuration by checking the launch configuration into version control, it at least allows seamless debugging.
Please do the following steps in Eclipse IDE(Tested with Version: 3.5.2),
In Package Explorer, Right Click on the Project which integrated with Maven container.
Select Maven 2 and then select "Fetch Source JARs".
The above action wil fetch sources of all the 3rd party jars present in the Maven Classpath.
Regards,
Rajesh.
Just put the .m2/repository/ folder itself with the search subfolders option.