I'm looking into migrating some of our ancient maven projects over to gradle (so shiny). Things are looking pretty good however I'm unable to get Eclipse/Gradle to adjust the project dependencies appropriately when I have 2 projects checked out. I'm hoping to use a repo for standard jar dependencies but be able to depend directly on a project if it is checked out.
Let's say ProjectB depends on ProjectA. As far as I understand the Eclipse/Maven plugin, it is able to a:
Interrogate the maven dependency for ProjectA and understand its group/artifact/version tuple.
Look through ProjectA eclipse project (if imported) to see if has the same group/artifact/version.
Replace the jar dependency with a project dependency.
This is a powerful feature because it means that a developer does not need to import ProjectA when they are working on ProjectB -- they just get it from the repo. But if they do have it imported, they can make a refactor to ProjectA in Eclipse and it will automagically refactor the dependent code in ProjectB.
How can I get eclipse/gradle to adjust the build-path so that there is a project dependency when available otherwise use the jar?
Things I've looked into:
Gradle "multi-projects" but our code isn't in a hierarchy like that.
Gradle includeFlat but this isn't some simple single directory structure.
resolutionStrategy.dependencySubstitution but I couldn't seem to get it to work. I doubt that findProject(...) is able to find a project that is loaded into Eclipse to it can link the 2 projects together in the classpath.
composite builds seem to use some of the language I'm looking for but it is about importing a build into another build.
Anyone else figured this out? Thanks much in advance.
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.
(This may be a dumb question but I am not quite familiar with the interesting eclipse importing logic)
I am trying to read the source code of Netty, so I checkout the tag folder for Netty-4.0.24.Final from the Netty SVN (https://github.com/netty/netty).
The files are shown as below:
Since there's a pom.xml files there, I use the "import existing maven project" to import it into Eclipse.
But the imported result looks like this:
I am expecting some well-formatted package layout. What's wrong?
ADD 1
I found this thread: "Source folder is not a Java project" error in eclipse
It seems I need to manually turn on the Java Project Facet for each project in order to see source code organized in packages. But I am wondering does it have to be this tedious? Is there any simpler way to import a maven project and display it in packages?
It doesn't matter if you are using tag or latest branch, Netty project composed from a sub-projects you see in the worskpace
Yes each one is full Maven project on it's own and gets deployed as separate artifact into Maven repo. When you open any of them, there will be your familiar Maven folder structure.
Your highlighted pom.xml is multi-module project for all the sub-projects.
It's used to build all sub-projects in one go.
If want to get familiar with this concept: I would suggest this tutorial:
http://books.sonatype.com/mvnex-book/reference/multimodule.html
BTW, when you import sub-projects into Eclipse M2E plugin names projects according their artifact names, not according folder structure.
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 have a multiple modules in our Java project and each module publishes SNAPSHOT jar files to Nexus repository. All the sub-modules are directly dependent on the SNAPSHOT jar files.
During development, we want to depend on the Eclipse project rather than SNAPSHOT jars. So we introduced a flag which switches between the dependencies as shown below.
if(System.properties.'setupProject'){
compile project(':Core')
compile project(':Module1')
compile project(':Module2')
}else{
compile 'com.test:core:0.1-SNAPSHOT'
compile 'com.test:module1:0.1-SNAPSHOT'
compile 'com.test:module2:0.1-SNAPSHOT'
}
Executing the following command generates the .classpath file as expected.
gradle eclipse -DsetupProject=true
Is there a better way to do this? Can we use Gradle configurations to achieve the same?
I could not find good examples for the same.
At the moment this is the way to go. You might tweak this even more and instead of using a System property to mark a project as available you can check if the project folder is available (project is checked out)
cheers,
René