This worked fine using Maven. Project A would depend on Project B and when I loaded up both Project A and Project B then Project A would use the locally built jar for Project B instead of depending on the jar pulled from Nexus.
All my projects use Gradle now and I can't figure out how to get them to see each other.
If it is just a simple Eclipse Project A depends on Project B, then this simple solution is what worked for me (I had to read for so long to figure this out! Why wasn't it obvious?)
Project B is its own Gradle project and is not necessarily aware of other projects - you don't have to do anything special for Project B
Project A:
settings.gradle
include 'Project B'
project (':Project B').projectDir = new File(settingsDir, "../Project B")
build.gradle
dependencies {
compile project (':Project B')
}
Save the two, and do an Eclipse -> Gradle -> Refresh Dependencies, and you will now see Project B as an actual Project Dependency in the Gradle Dependencies of Project A (I had to use dashes instead of spaces since Eclipse wouldn't let me have spaces in my Gradle projects' names).
Note: if building these projects on a remote server, make sure that you are either checking these two projects into the same source control repository or make sure that they end up in the same place relative to each other the way they are in Eclipse.
Look in the Gradle User Guide, at Chapter 51, "Dependency Management". See if section 51.4.3, "Project dependencies" does what you need.
Related
I have three eclipse projects (Project A, Project B, and Project C) in my workspace. Project B and C depend on Project A.
In my build.gradle file, I've set up the dependencies in B and C to refer to A:
repositories {
mavenCentral()
mavenLocal()
}
dependencies {
compile('com.example:projectA:1.0')
}
However, when I right click and select Gradle->Refresh Gradle Project on Project B or C, it states that it is unable to resolve the projectA dependency.
I'm using Mars 4.5.2 and Buildship version 1.0.20. I understand that Buildship 2.0 once released will provide support such that it can refer to other eclipse projects as dependencies. In the interim though, how do I install project A into the repo and refer to it in project B and C? I do not see an install option for project A in the Buildship Gradle Tasks.
You've added a dependency using a GAV (group-artifact-version): com.example:projectA:1.0.
When you declare a dependency in gradle using a GAV, gradle assumes that it should go look for that dependency in all the available Maven or Ivy repositories that it knows about. I presume that the reason it can't resolve the GAV, is that you never published project A to any repository where your build is searching.
You have two ways out:
Publish project A's output (jar files) to a Maven repo. You would need to apply the Maven publishing plugin. For example, you could publish to your local repo using "gradle publishToMavenLocal".
Declare the dependency as a Project dependency, and keep your projects as sub-project of the same parent project.
You'd declare the dependency as compile project(':projectA')
The latter is probably a lot easier to work with.
BTW, Buildship itself probably has little to do with this issue, rather it's a general problem of using dependency tracking build systems like Gradle or Maven. I remember seeing some reference to how Gradle would solve this problem better in 3.0 and up, but I can't seem to find the link at the moment.
Two Gradle Git projects need to be created, within the same repository, using the Eclipse IDE. Project A depends upon a third-party library (a JAR, source code, Javadoc and natives) and project B depends upon project A.
Without Gradle, both projects would be created and Git would be enabled with Project Explorer > [Project Name] > Team > Share Project. Then, dependencies would be added via Project Explorer > [Project Name] > Build Path > Configure Build Path, followed by Projects > Add and Libraries > Add External JARs (which would also allow the specification of the locations of related source code, Javadoc and natives). This would enable automatic code completion of Project A from Project B as well as source code and Javadoc integration, within Eclipse.
With Gradle, should the settings.gradle or build.gradle files be manually edited, without adding dependencies through the Eclipse GUI, or must both be used simultaneously? Additionally,how does this effect which hidden files should be indexed by Git (.project, .classpath, .settings, .gradle)?
How is this setup through Eclipse and Gradle?
When you use a build-tool like Gradle (or maven), it is kind of assumed that the build-tool is in charge of configuring stuff like project dependencies and classpaths.
This kind of conflicts with the Eclipse UI which is kind of built to allow you to manage classpath / dependencies via its own ui.
But the Eclipse UI only controls what eclipse uses as the classpath when the Eclipse JDT compiler compiles your code... inside Eclipse.
So if you change things that way, then Gradle will not know about these dependencies and the build won't work.
Yep, this is definitely confusing :-)
The proper thing to do is manage your dependencies and project configuration entirely through gradle. So that means editing the build.gradle and settings.gradle.
The tools (BuildShip or STS Gradle Tools) provide a 'bridge' to try and configure Eclipse projects in conformance with your build.
E.g they may offer a 'Update Project' or 'Refresh Dependencies' command in project context menu.
Even if you don't use Gradle tooling, this kind of holds true. You then would use Gradle's 'ecplise' plugin and run a command like
gradle cleanEclipse eclipse
To generate the eclipse project config from the build config. Then import the project into Eclipse as configured by gradle. Also in this case, it would be a bad idea to use Eclipse UI to make changes to the buildpath since ultimately it has the same issue, changes you make to those generated files may make things compile inside Eclipse, but Gradle doesn't know you changed anything. And the next time you run gradle cleanEclipse eclipse your changes are also blown away.
As to your specific questions:
should the settings.gradle or build.gradle files be manually edited ...
Yes.
... without adding dependencies through the Eclipse GUI ...
Yes.
... or must both be used simultaneously?
No, only configure things in gradle. Then 'synch it up' to eclipse with some tool (BuildShip / STS Gradle / gradle cleanEclipse eclipse)
How does this effect which hidden files should be indexed by Git (.project, .classpath, .settings, .gradle)?
General rule of thumb. Only index the stuff that defines gradle's behaviour (there may be some exceptions, but in general try to minimize them only violate this rule if you have a good reason).
So specifically don't put in git these 'eclipse metadata'
.settings
.project
.classpath
Do put in git: the gradle wrapper and its properties file.
Gradle also has a .gradle folder. It belongs to gradle, not eclipse, buts is caches and things which are 'transient'. You don't want those in git either.
I have a large application with many eclipse (actually using Spring Source Toolsuite) projects with ivy managed dependencies for each project. We currently have it setup and working where you can have project A (a dynamic web project that generates a war) and project B (generates a jar) setup such that project A depends on project B and if you only have project A in your workspace, it will go pull the jar file generated by project B from the ivy repository. We setup the deployment assembly to take the eclipse library generated from the ivy resolve and put it in the WEB-INF/lib directory so we can easily deploy to tomcat.
With the manual process, all of this works. I can make a change to project B, publish it to my local ivy repository, and re-resolve the dependencies on project A, and I get the new project B jar file and everything compiles and updates on tomcat as expected.
The problem I'm having comes when I change the ivy resolve settings of project A to "Resolve dependencies in workspace". When I make changes in project B, project A successfully notices the change and compiles correctly, but the deployment assembly breaks. When I go look in tomcat, it has a folder for project A's context root, but it is empty. If I uncheck the "Resolve dependencies in workspace" checkbox, the context root folder gets populated and everything returns to a working state.
I can continue doing the manual process, but it is a huge timesavings if I can get ivy to use my workspace first, then get the jar from the repository if the project does not exist in my workspace. Any suggestions would be greatly appreciated!
The solution was to add the Utility Module facet to project B (Project Properties->Project Facets->Utility Module) so that eclipse would know the structure of the jar file that is supposed to be generated.
In a Java project in Eclipse, I am trying to debug project A.
Project A has a dependency on B.jar, normally B.jar comes from my .m2/repository.
but now I want to make some temp changes to B's code, and have it reflected in A,
so I directly edit the source code in B project in eclipse, and set B as a dependency project in A's build path. Additionally, both A and B refer to C.jar as their dependencies.
This builds A fine, but when it is run, A's classpath contains 2 copies of all the classes and resources in C.jar. this creates a problem for those hibernate hbm.xml mapping files in C.jar and I got errors saying duplicate mapping for...
This looks to be a defect in eclipse, in that it lacks the resolution ability as maven posseses. is there a way to work around this? (apart from building B and installing to .m2 instead of having it as a dependency project)
Thanks
You mentioned "[setting] B as a dependency project in A's build path" - do you mean editing eclipse's build path or editing the project's POM? I'm guessing the former, in which case make sure that you have the latest version of the m2eclipse plugin installed and that both projects A & B are Maven eclipse projects. If it is set up correctly then your projects should look have an 'M' on their project icons, and the icons of any workspace dependencies should look like folders.
Sorry for being verbose...
I have some existing maven projects. I imported them into Eclipse using Maven -> Import existing Maven projects.
This gave me 6 individual projects and one project which lists all 6 under it. (The umbrella project has 6 modules defined in it which translated to 6 eclipse project - as I understand how maven works)
One of the project A requires two other project B and C (at compile time and run-time).
Build path -
On the build path of A I have one of the libraries as Maven dependencies. And it builds fine.
Deployment assembly -
On the deployment assembly of A however there is no entry for deploy to web-inf/lib. Because of that when tomcat starts it doesn't find any required jars or the project B and C.
So I added an entry to deployment assembly as : source - maven And dependencies deploy - web-inf/lib.
Tomcat comes up and my webapp for project A comes up.
This however breaks the eclipse build - upon build eclipse complains:
"Invalid classpath publish export Project entries not supported"
This I see is because, under build path, there is new entry added to web-inf/lib to publish/export under maven-dependencies. Removing that removes maven entry from the deployment assembly as well.
The only workaround is that in the deployment assembly I specify the web-inf/lib under target generated by maven but that causes stale copies of project B and C to be picked up.
Why I need this setting is because when I make changes to project B and C in Eclipse and build them in Eclipse I want to see the changes when I am debugging project A. I don't want to run maven builds on B and C again since its time consuming.
Any help is much appreciated.
I did try including the MAVEN2_CLASSPATH_CONTAINER but that is always empty and when tomcat runs it cannot find the necessary libraries. (BTW what vale is the MAVEN2_CLASSPATH_CONTATINER set to?)
This is on Eclipse Indigo Mac OSX.
You need to add the relevant project/s to your Deployment Assembly.
Right Click Project -> Properties -> Deployment Assembly -> Add
I solved just doing this:
right click on my eclipse project-> Maven -> Update Project Configuration...
Figured it out ..but not completely...
So I added maven dependency in the deployment assembly as I mentioned earlier.
Maven dependency -> WEB-INF/lib
AND additionally added project B and C as well :
B -> WEB-INF/lib and C->WEB-INF/lib
Somehow this way B and C are not added to the publish/export in the java build path. I don't know how eclipse knows to not export B and C from maven repo but to export it from project B and C itself.
Anyways thats for some other day..
for now i m happy :)
For anyone else that searches for this, it seems that you can also manually add the following to the .classpath file
<classpathentry combineaccessrules="false" kind="src" path="/B"/>
By including Maven Dependencies, you are including dependencies for project B and project C. It turns out, you also have to include project B and C manually.
The exact fix which works is.
project A -> properties -> Deployment Assembly
Click Add and then Project. Select B and C. Problem will get fixed after rebuilding.
I had this problem, but I believe none of these answers correctly fix the problem. Instead they workaround m2eclipse (which should manage classpaths and deployment assembly for you). For me, the problem that I was using m2eclipse without m2eclipse-wtp (a separate plugin).
See this SO answer for the plug-in details.
You can add the relevant projects / or maven java build path entry if using maven to your Deployment assembly (project -> properties -> deployment Assembly)
Then checks if theses relevant project are Facets compatible. (project -> Project Facets)
This error can occur if you have multiple entries of same jar in you class path. So you need to check your classpath and remove duplicate entries.