For some reasons, my computer has 3 Eclipse IDE instances on it, Indigo, Juno and Kepler.
Indigo is used in real developing, Juno is for program execising, Kepler is being used in another project. Each of them contains a maven project.
But, there is only 1 maven in my computer, and 3 eclipse instances are now sharing it.
And these are errors keep coming which associate with maven, sometimes I need to clear some directories in maven or modify some maven config files. That makes me worry about whether one change would affect other maven project in other eclipses.
So I decide to isolate different eclipse, give each eclipse its own maven and tomcat and so on.
Could that be possible? if it so, how should config the system path and other relevant configuration??
Thanks a lot!!!
Could that be possible?
Yes its completely possible.
how should config the system path and other relevant configuration?
Goto Window -> Preference -> Maven -> Installations -> Add and add a new installation of maven and you can switch between any installation of maven within the eclipse
And these are errors keep coming which associate with maven, sometimes I need to clear some directories in maven or modify some maven config files. That makes me worry about whether one change would affect other maven project in other eclipses
Firstly this shouldn't happen unless and until you have different settings and profiles set-up in your settings.xml. So, prior to configuring multiple mavens, first debug why the maven settings get distubred in the other projects.
EDIT
If you are working with different maven settings ( and by settings I mean different repositories setup for each project and different server configurations that you want to keep isolated with other projects ) make use of Maven Profiles . Although, the real purpose of profiles is building for different environments ( like for dev/test/production ) you can use these profiles for building your different projects.
Related
All!
In our project team, people use either IntelliJ or Eclipse IDE depending on what they are comfortable with. Eacf of the IDEs have their own settings files. For instance, IntelliJ uses .idea and .iml and Eclipse uses .project, .settings, .classpath! While some other stack overflow thread says it's not needed to check in any of these files from either IDEs if you are using Maven, I'm unsure why that's the case. None of the threads say why using Maven does not warrant (some of) the settings, .project, .classpath be checked in?
Can someone help me understand 2 things
1) Why don't we need these files to be checked in when using Maven?
2) If we must check in (Assuming Maven is not used), how do we ensure that either IDEs work okay when checking out from source control and what to check in to ensure cross compatibility.
Thanks!
1) These files are not needed because bothe IDEs can import maven projects using the pom.xml file. So the pom.xml file is your single source of project description for both IDEs.
https://projects.eclipse.org/projects/technology.m2e
https://www.jetbrains.com/help/idea/maven-support.html#maven_import_project_start
2) You see it right, it's hard to ensure cross-compatibility if you use only the native project files of the IDEs. Among many other things that's why it's encouraged to separate the build chain (Maven, Gradle, etc.) from the IDE. Also continuous integration systems can be configured more easily if a unified build tool is used so it's kind of a best practice to use one and keep it independent from the IDE.
In case you don't want to switch to maven now, check in the Eclipse .project and .classpath files, Intellij is able to understand them.
I’m using Eclipse Mars with Maven (v 3.3). When I update a dependency in my pom (change the version), my Eclipse-Maven project doesn’t pick it up, even when I right click my project, and select “Maven” -> “Update Project.” I know this because I do not see compilation errors in the Eclipse Java editor that I see when I build the project on the command line using
mvn clean install
When I remove the project from the workspace and re-import it, then things get back to normal. However this is a cumbersome process. How do I get my Maven-Eclipse project to automatically detect changes in my pom and update the project libraries appropriately?
And yes, in the “Project” menu, “Build Automatically” is checked.
When you import the project into Eclipse, use Eclipse's own built-in Maven support (aka, m2e). I recommend against using mvn eclipse:eclipse as it doesn't give the best results (as you're seeing). Maven is a build and dependency management tool, not an IDE; expecting it to manage IDE-specific stuff is silly, in my opinion (I realize the Maven team thinks differently, that Maven should be responsible for managing your IDE, but that's nonsense).
So if you have the project available on your system, delete any Eclipse-specific files (typically just .classpath, .project, and folder .settings), they were generated by mvn eclipse:eclipse and you don't want them interfering with the "proper" import process described here. Then inside Eclipse, use File > Import > Maven > Existing Maven Projects to import the project. That should result in better integration between Eclipse and maven, including automatically updating the Eclipse build path when the pom is changed.
As a quick check, after doing the import that way, you should see a group called Maven Dependencies in the Libraries tab of the project's Build Path (in Properties dialog). Like this:
If you want the Eclipse project configuration to be automatically updated every time the pom is changed, there's a (experimental) setting for that under Preferences > Maven. Be aware that doing so might not be desirable, though - as mentioned in this feature request, it's a somewhat lengthy process that touches a bunch of stuff in the Eclipse Project; doing that automatically on every pom.xml change could end up being more trouble than it's worth.
Three Mandatory checks you should do for automatic update in your classpath
Your Repository is not in-sync with your Eclipse IDE, Please check the below settings in your IDE.
Right Click your any POM.xml from your IDE and check for the Maven profile which should be auto-activated. Also offline and Force update check box shouldn't be enabled. Please refer the below image.
Always check for your user settings which should reflect your local maven settings.xml, as shown in the below figure.
After performing all these checks, refresh your Eclipse Work-space to get these changes reflected.
Eclipse should be updating your classpath. If it's not, that implies something is going wrong.
It's hard to say what the problem could be exactly without knowing more about your project's pom.xml. More information might be necessary to solve the issue, but I'll just make a stab in the dark:
Open the .project file in your project's root folder and check the ordering of builders and natures there. It might be possible that some other nature on the project is also causing maven2Nature to fail. Move maven nature up and see if that helps any.
Alternatively you might be thinking that Eclipse does not update your dependencies because it does not add some some error indicators in the project that should be there with new dependencies. If that's the case try cleaning the current project (project>clean...). Maven in Eclipse does not necessarily trigger a full rebuild when dependencies are updated.
If none of this works, closing/opening the project might solve the issue quicker than re-importing.
What you wrote, should work. Did you check this:
does "pure" mvn install from terminal see your changes in POM?
maybe some Maybe plugin is buggy, cached some dependencies in target, and mvn clean install is needed
you can run Eclipse in a new workspace, and import your project there, sometimes it helps in case of such strange problems
instead of importing Maven project to Eclipse via m2eclipse, you can try to create Eclipse files via the old mvn eclipse:eclipse and see what happens then
does it work well when you try to import your Maven project to other IDE, the free IntelliJ Community Edition for example?
As a last resort, you can delete your current Eclipse installation and install a new version. When you add several plugins, they might interfere with one another and create weird behavior. After you do that, do not import your Maven project into your workspace, but rather create a new one and copy and paste the files that you had.
I'm currently working on multiple large webapps(each webapp when being run actually contains 3-7 eclipse projects) in Spring Tool Suite on a Mac. Every imported webapp has several errors after import and project validation complete. The maven builds will fail continually until I right click on every project associated with the given webapp and select Maven -> Disable Workspace Resolution. I can think run a maven clean, maven update, and maven build to clear out all the errors.
If there a way to disable Maven Workspace Revolution in my eclipse settings/preferences so that it's a global one time setting that tells every project in the eclipse workspace not to use Workspace Resolution?
Below are some screenshots I took to hopefully provide all the relevant details such as version numbers.
I just recently switched from using eclipse with add-ons to using the preconfigured Spring Tool Suite, so the install is only a few weeks old. It should be hopefully the most up to date versions of most plugins.
It can be achieved much faster by doing a Search (Ctrl-H) for resolveWorkspaceProjects=true for files of name org.eclipse.m2e.core.prefs, with the scope set to Workspace, and Replace set to resolveWorkspaceProjects=false.
I don't believe there is a global setting to do this automatically.
creating a parent project with only a pom.xml, and lots of sub projects such as:
my-web
my-core
my-backoffice
etc. is easy, and the sonotype eclipse plugin does most of the work.
However, getting one project to know about the source in the other project seems to be hard. E.g. when you are debugging the my-web project, and step into my-core, eclipse doesnt know where to get the source.
Looking in the Java Build Path in eclipse, the maven plugin has added my-core as a folder under "Web App Libraries". I.e. its not using the my-core-0.0.1.SNAPSHOT.jar or similar, its using the raw java files. Great!
But how to tell maven to tell eclipse to look for the source in the same place?
Im not really sure where to start. Im guessing its possible to get maven to put the source in a special jar using the maven-soure-plugin, but this will usually be out of sync with the actual java files which the web project seems to be using directly.
A quick and dirty solution is to manually Edit the Java Build Path for each project, and add my-core and other dependant projects in the "Projects" tab. Is this best practice? Any other suggestions?
A quick and dirty solution is to
manually Edit the Java Build Path for
each project, and add my-core and
other dependant projects in the
"Projects" tab.
If this doesn't happen automatically you have a configuration problem.
My Guess would be that you have a version mismatch between the pom dependencies and the actual project versions. Or your projects have an unusual name template (m2eclipse resolves projects by their artifactId AFAIK)
Either way, what always helps is in your Debug configuration (Run > Debug Configurations ...) select the Source tab and just Add... the selected projects.
I have an application that is composed of about 10 different Eclipse projects. Some projects must be built with Java 5, and others with Java 6. I have both of these JDKs registered with Eclipse's "Installed JREs" list as "jdk5" and "jdk6", respectively.
The appropriate JRE is on each project's build class path, which is reflected in the .classpath files. However, other members on my team are using different symbolic names for these JREs on their machines. Also, the .classpath files are checked into source control. As a result, people need to make local changes to their .classpath file in order to be able to build.
My instinct is to choose a naming convention for the installed JREs list and ask all the team members to stick with it. However, this just complicates the process of setting up a new developer. Really, I just want to say "build this project with Java 5" and "build that project with Java 6". I don't care where they are installed, or what their symbolic name is. Does Eclipse support this kind of configuration?
Execution Environments are what you want (Preferences -> Java -> Installed JREs -> Execution Environments). You can change the classpath of your projects to use a JRE System Library that corresponds to a particular version of Java, like "J2SE-1.5" or "JavaSE-1.6". Then, Eclipse will categorize the installed JREs into those categories, and use the appropriate one when building your projects.
Honestly, I use the maven (maven-compiler-plugin and profiles) for exactly this.
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.5</source>
<target>1.5</target>
</configuration>
</plugin>
Using a system like maven (or ant, etc) helps us tremendously with classpath/environment/os-disparities problems across developers.
You can configure project specific compiler settings in Preferences->Java->Compiler. However, this only allows you to set the compliance level, not choosing a particular JDK. But maybe that's already enough for your purpose?
If you are synchronizing your project files, eclipse maintains a current JDK in the Libraries tab of the projects build path configuration. This will carry over pretty well as long as everyone has the same JDK installed and loaded into eclipse.
Where possible, I'd still recommend the maven solution that Quotidian suggested, but I've had a fair amount of success manually as long as each developer workstation is set up the same. This can hang you up if you have developers running different operating systems though, as it might look for "C:\Program Files\java" on a linux system, or "/user/lib/jvm/" on wndows, neither of which would exist.
If you're stuck with having to check the .classpath fies into source control, then I'd encourage you to go with your idea of having all the devs install their JDKs in the same location (or use a common env variable name pointing to the locations). I think it's much easier for devs on the same team to have very similar environment setups, and if that common env setup is well documented. That way, as new devs come on board, you can point them to your documentation for env setup and have them up and running quickly - there should be no need to waste time debugging issues around where their JDKs are installed.
If that's not an option, though, and you're already using Maven, then you could consider removing the .classpath files from source control. We've recently done this, and we just have all the devs run the Maven eclipse plugin to generate (or update) their own .classpath files based on what's in the pom.xml file. (i.e. mvn eclipse:eclipse to run that plugin).