We're using Maven for a large project that is broken up into eight or so modules. The structure of Maven projects in Eclipse makes it difficult to understand class usage between modules - if module 1 defines class Widget, and module 2 uses it, then you can't just look for references to class Widget, because from the Eclipse perspective the Widget in module 1 is different than the Widget used by module 2.
Is there a good solution to this, other than "don't use Maven" or "use the global Java search"?
m2eclipse has an option in the Maven project context menu called "Enable Workspace Resolution" which controls whether the Maven artifacts or the workspace projects are used to resolve intra-project dependencies. Turning this on set Eclipse to look for the workspace version of the class and solved my problem.
I daily work in Eclipse on a large project split into several maven artifacts using Eclipse. I use the m2eclipse and I have no issue to navigate from a module to another. Eclipse is even able to use a opened projects as an artifact rather than fetching it from the repository.
The only restriction I saw is that you should have a one artifact to one Eclipse project mapping and it works flawlessly.
Related
I'm having some trouble configuring Buildship for Eclipse the way I want. I currently have > 50 projects always open in Eclipse, but I want to move to having only the projects I am actively working on in Eclipse, and the other projects would use a Maven repository to resolve their dependency.
Lets say ProjectA (which contains a main) depends on ProjectB (a library project). If ProjectB is opened in Eclipse, I would like ProjectA to use ProjectB directly. A change in the code in ProjectB would be noticeable when running ProjectA. However, if ProjectB is closed, I would like ProjectA to use the ProjectB's JAR located in the Maven repository mentioned in the build.gradle file.
The behavior that I am talking about is detailed here.
Is there a way to do that using Buildship? Or should I use another Gradle Eclipse plugin?
There's a new composite build support feature added in Gradle 3.1. This feature is a game changer and makes it simple to work on more than one project at once.
You can use dependency substitution rules to swap out repository dependencies with local project dependencies.
If each project is within it's own separate git/subversion repository you can use prezi pride to manage the 'pride' of projects. You could import the (dynamically generated) multi module build into buildship.
If you wanted to use the eclipse plugin instead of buildship you use the whenMerged or withXml hooks to tweak the generated .classpath files to point to the projects within your workspace (note eclipse will now build differently to gradle command line).
For the sake of completion, I ended up going with the dependency substitution as suggested by Lance Java. This approach has the following advantages:
Does not require a third party software.
Is IDE independent. We're not tinkering with the .classpath file directly, we let the Eclipse plugin (or any other IDE plugin) handle this.
Other plugins can access the actual dependency we want to use.
However, there are some gotchas with that approach:
Dependency substitution cannot be done inside a task. It needs to be done either in the build.gradle file or in a method that is called from the build.gradle file.
You need to refresh the workspace.
I've been asking myself this question for a couple of years but never really found the solution.
I used to work with eclipse (on maven java projects). I could import a project -let's call it 'proj-A'- and if one of proj-A's dependencies was found in the workspace with the same exact version, eclipse would use that project's source instead of the jar from the repository. This way I could edit a library and see the changes in the project that used it right away.
For example, in Eclipse, if proj-A depended on dep-B-1.2.3-SNAPSHOT, I could import proj-A and dep-B in the same workspace, and if dep-B version was 1.2.3-SNAPSHOT I could see the live changes in dep-B sources from proj-A classes.
I'm now working in scala in IntelliJ. I don't seem to be able to do that. what's the best workflow if you want to avoid publishing the library and then reloading the whole project that uses it along with all its dependencies every time?
If I import proj-A as sbt project I can find dep-B snapshot jar in the libraries (loaded from some repo, be it local or remote), and I can't see the code changes to the dep-B module imported in the same intellij project (i.e. the equivalent of eclispe workspace).
If I manually remove the dep-B jar and add the dep-B module as a dependency for proj-A I'm forced to do it everytime I reimport proj-A for some reason.
I'm not sure there's a way of doing this as straightforward as the eclipse way (automatic), but maybe you know something I don't ...
thanks
It should work out of box for dependencies, which are imported to the project as modules, no additional settings needed. At least for Java.
Just do not run a Maven goal, that would use dependencies from the repository.
I thought I understood Maven as I've worked on a few projects using it, but I seem to be having trouble creating my own project with it, so can someone correct me wherever I may be wrong?
Assuming I create a new Maven project (we'll say I did it through Eclipse or IntelliJ):
If I add a dependency to my POM file, assuming I add a public repository where that dependency can be found, shouldn't the IDE download the specified JAR and make it so that it is recognized when I use it in my code? Currently, my projects do not recognize any classes that should be found in JARs via my POM dependencies.
Assuming #1 does work, how can I determine via maven which transient dependencies I have? For example, I'm using classes from Pentaho Data Integration, and some of the plugins for it reference things like org.mozilla.javascript.*. Could maven automatically tell me that without me having to run the code, see it fail, and manually fix the dependency? There will be hundreds of those instances here, so manual fixing really isn't viable.
Here are my IntelliJ two cents:
1 - Adding a dependency in pom.xml of your project
Should indeed download the depended jar(s). You may need to approve "Import Changes" dialog if it pops in, or enable auto import.
2 - Seeing transitive dependencies
It can be achieved via Maven Dependencies Diagram - unfortunately only in IntelliJ Ultimate edition. You can use Maven Dependencies Plugin to see the dependencies tree in your favorite CLI.
Question 1: Adding a dependency
In Eclipse, depending on how you created the project, you should be able to add dependencies that are automatically recognized using the maven context menu.
Note that you should have created the project using the eclipse maven plugin so that it has maven nature.
To add dependencies/plugins from a remote repository, you can search in the resulting UI for a dependency if you know the artifactId or groupId. The plugin will pull up the deps whether the repo url is specified in the pom.xml or not.
After adding a dependency to the POM, the IDE will start downloading it and all transient dependencies as soon as you save the file.
If something goes wrong, you can try to "Update Project" from the context menu.
Question 2: Determining transitive dependencies
Transient dependencies are visible in the "Dependency Hierarchy" tab of the POM editor.
I usually default to the command line because it allows much more flexibility and functionality when tracking the dependency graph.
I am sorry but I have not worked with IntelliJ
We've got a multi-module project using Eclipse and Maven. The only way I could get it to work in the past was to use a flat layout for the projects, where the parent module was a peer to the other modules. This worked fine with m2eclipse and Subversion.
Now we'd like to move to Git and GitHub. I'd like to expose the entire project, along with all the modules, as a single project on GitHub. The problem is that EGit, the Eclipse/Git plugin, wants to manage projects one at a time, not groups of projects, and so if you've got a flat layout, you can't do it.
The right answer is to use a standard Maven hierarchical layout and manage the parent and all the modules as a unit. But Eclipse doesn't like that, and no amount of fiddling will get Eclipse to accept nested projects. m2Eclipse does not support hierarchies: https://issues.sonatype.org/browse/MNGECLIPSE-2291
So what do you do? Do Git from the command line and abandon the ability to see what files have changed in Eclipse? Or abandon Eclipse?
A standard Maven multi-module structure as a single git repo works perfectly fine for me in Eclipse Indigo with M2e and the git plugin that shows up in that environment. You can't ask Eclipse to do your fetching for you, but once you've pulled from command line, you use Team/Share, say 'Git!' and all is well.
I think I see what's the source: hierarchy is a problem for projects inside the workspace, not 'existing projects' that you import.
Here's a typical workflow:
use git svn clone to get a tree. it's a stock, hierarchical mvn multi-module tree
in eclipse, use import/maven/existing maven project. Point at the whole tree
select all
OK
it works fine. The nesting does not disturb eclipse one bit. I don't know what problem that bz is pointing at.
Before I used m2e I used the maven-eclipse-plugin. And it also worked in these cases, because it does not generate a .project/.classpath for <packaging>pom</packaging> aggregating projects, so Eclipse is never called upon to actually nest anything.
I'm not alone -- see the developer setup instructions as cxf.apache.org for an open source example that you can try for yourself.
Is it possible that you are working with old versions of the tool?
I have a Maven multi-module project that I work with using Eclipse 3.7 (Indigo), M2Eclipse (1.0) and EGit (1.0).
On the file system the multi-module project has a single parent directory.
In Eclipse I have separate projects for each module.
M2Eclipse does the dependency management perfectly.
There is single git repository (.git directory) at the top-level and EGit works perfectly.
You can put your modules in Git with hierarchical layout. And build those modules by Maven. If those modules are projects(whatever java, c++ or php project) recognized by Eclipse, they can be imported into workspace as flat layout in workspace.
-- the root of Git working directory
-- moudule1
-- project1(a java project)
-- .project(a project file recognized by eclipse JDT)
-- pom.xml
-- project2(a java project)
-- .project
-- pom.xml
-- module2
-- projectA(a java project)
-- .project(a project file recognized by eclipse JDT)
-- pom.xml
-- projectB(a c++ project)
-- .project(a project file recognized by CDT)
-- pom.xml
For Maven projects, multiple imports at once can be achieved via the Maven import wizard (that is accessible from Git).
In case you don't know what kind of projects you're about to import, you can use the new Easymport that will import project "as best", by deducing configurations from various files. See https://github.com/jbosstools/jbosstools-playground#easymport-easy-and-smart-openimport-of-a-project
Once you get all those projects, you can use the Nestor plugin, which will show project in a nested/hierarchical layout, mapping more correctly your Maven project: https://github.com/jbosstools/jbosstools-playground#nestor-view-nested-projects
I'm a beginner at Maven and I've played with it from a command line point of view a little, so now I was trying to use it in Eclipse; I installed the m2eclipse plugin to do so.
But I'm stumped from the very beginning! Apparently I've missed a bit of terminology somewhere along the line. I can't keep track of all these new Maven terms... What is a Maven Project, and what is a Maven Module? These are my options when creating a new project in the Maven category in Eclipse.
They are basically the same thing, but with one difference.
When you create a module, you must specify a parent project.
When you specify the parent project, it adds a <modules> section to the parent projects pom.xml.
That section basically says to the parent project:
run every command I get against all of my modules first
So for example, if you run, mvn package on the top-level project, it will run mvn package against all its module projects first.
Hint:
Make sure all modules have high cohesion and related to each other, otherwise you will have a huge messy project without applying SRP (Single Responsibility Principle)
Found it! My searches were returning tons of hits for creating a "multi-module project", but once I added "-multi" to my query, the answer was on the first page.
According to Creating and Importing Projects:
m2eclipse provides the ability to create a Maven module. Creating a Maven module is almost identical to creating a Maven project as it also creates a new Maven project using a Maven archetype. However, a Maven module is a subproject of another Maven project typically known as a parent project.