I'd like to work on two different versions of the same multi-modules maven project under eclipse.
Unfortunately, when you import a multi-module maven project under eclipse, you can change the parent module project name yourself, to prevent conflicts, but not the child modules projects names. Child modules are imported as root projects, named after the module name. Apparently there is no way to rename them during import.
In an ideal scenario, I'd like to keep the pom as it is. Obviously I'd like to keep the same eclipse workspace...
Yes, you can. You have to change the name pattern in the m2eclipse importer. All modules will have this pattern and you have a conflict-free env.
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 am new with the Maven. I have two projects. I want this kind of tree:
project1
--pom.xml
project2
--pom.xml
pom.xml
which means I performed aggregation and inheritance. By doing like this and importing two projects in eclipse, the second project can't see junit dependency which is specified in the outer - common pom.xml.
The problem with the first project is that instead of having packages i see only folders.
Try using Package Explorer in Eclipse in order to see packages instead folders.
Also for this kind of inheritance try to add both projects in one parent project and import this one into Eclipse. In both .pom files of projects you must specify their parent project
As MykoB has said, ensure the common pom.xml has project1 and project2 defined as modules. In each of the child project, specify the common pom.xml as parent.
Choose the folder containing the parent pom.xml when importing the project in Eclipse and you should have the parent and both the child modules imported correctly.
This assumes you have the latest Eclipse Indigo with m2e plugin.
What you've built is the correct default Maven module structure, but Eclipse likes to have all its projects at the same level. That is, your root pom.xml which contains the module entries should be in a folder of its own, like so:
WorkspaceFolder
\_project1
\_pom.xml
\_project2
\_pom.xml
\_Builder
\_pom.xml
\_Parent
\_pom.xml
The Builder pom.xml has module entries that look like <module>../project1</module>. That's your aggregation part. Additionally, if you want to have a parent pom for inheritance (which is not necessarily related to having a pom with modules), you'll have to add the Parent entry to project1, project2 and Builder's pom.xml, and you'll need to have a <relativePath>../Parent</relativePath>.
Note that all relative paths come from the problem that you're adapting your subfolder structure to what eclipse likes.
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
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.
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.