I have setup a gradle java multi-project in Eclipse Kepler. I have the build working great. The problem is, when I try to re-factor rename a class in one of the projects, the re-factor only occurs in that one project, and does not properly cascade to the other projects. My other projects become filled with compile errors due to the previously named class references.
Is there a way to make this re-factoring work across gradle projects?
Figured it out. The solution was to enable dependency management on each of the related projects.
To do this, right-click on the project in the package explorer:
gradle -> enable dependency management
You will need to do this to all the projects which depend on the project containing the class you want to re-factor.
Related
I installed hybris plugin.
Imported project with it.
Have done ant clean all.
Then, if I try to build->recompile class it's not working. Seems like idea doesn't see classes generated by ant.
If I do build->rebuild project and then build->recompile class it's working fine, but it's not convenient at all. I believe there is fix to this, but I couldn't find it.
This is usual error I've got(packages are different for different cases):
this is essentially the expected behaviour. You can't mix "ant" build
and "native IDEA" build. Those are two separate build systems.
This is an explanation of hybris plugin developer (hybris-integration.atlassian.net/browse/IIPS-120)
And he suggests a solution for that:
before you try to import the project you need to do ant clean all (you will not need to use ant afterwards)
import the project using hybris plugin.
Press Build->Recompile project
Then you can create or modify your test run configuration if needed.
Recompile your classes and so on directly in Idea.
Also, he mentioned deal with JRebel here (hybris-integration.atlassian.net/browse/IIPS-47)
we support both compilation modes. Ant targets and idea internal. They
shouldn't be mixed as idea has it's own compilation model/cache. If
you use idea compilation then you can use JRebel or hotswap.
You cant hotswap classes in hybris without the help of a hotswap agent.There is a tool available in the market called JRebel. It is a good commercial tool if one can afford. However, if you are an open-sourcist, there is a promising alternative to JRebel, which is DCEVM (Dynamic Code Evolution Virtual Machine) along with HotswapAgent.
I don't know if this help,
you can start another cmd console, and run
setantenv and ant build to hotswap class in runtime.
I am working on two Gradle projects. One of these projects is a supporting library that will be used by other projects in the future so project A depends on project B but not as a 'multi module project'. The dependency is to be resolved through the artifact repo so project a declares it as a compile dependency using it's maven coordinates.
My problem is when working on these two projects in IntelliJ changes to project B aren't made available to project A until I install it (using the Gradle Maven plugin) in my local repo. This is kind of annoying and slows down my workflow. Is there a way to get IntelliJ to automatically update the dependency internally?
This is supported in the latest versions of Gradle and IntelliJ. It is known as a Composite Build.
Composite builds can be declared in the project's settings.gradle file as follows:
includeBuild '../my-app'
or by using the --include-build command line argument:
$ gradle --include-build ../my-utils run
Take a look at the Composite Builds with Gradle and IntelliJ IDEA Webinar for instructions on how to configure the integration.
In IDEA 2017 you can right-click on the gradle module and use Composite Build Configuration to link the current module to one or more gradle module already opened in the current workspace.
I was doing some experimenting with Gradle and created a multi-project build, with multiproject_test dependent on two projects ChildA and ChildB. I put this simple test project on GitHub.
https://github.com/thomasnield/gradle_multiproject_test
Everything seems to be working great on the command line and Eclipse. Everything was compiling and the dependencies were being recognized and used. But when I imported the project into IDEA it did not create the dependencies. It seems like I had to manually create the modules although it did import the source code from the child projects.
My question is do I have to specify these module declarations separately in the build.gradle script for IDEA? Why would it not even compile the dependencies?
UPDATE
Solution proposed below worked great. IDEA handled the build.gradlescript much more gracefully than the idea plugin.
Loading a Gradle project to build an IDEA project by using the idea plugin does not always work well. The recommended way to load a Gradle project in IDEA is to import the build.gradle file from the root project.
More detailed instructions can be found in IDEA documentation here.
I have 2 completely separate projects where one depends on the other. I've very recently mavenized the main project but can mavenise the dependency if absolutely necessary.
Originally these were Netbeans projects, with the main project having several modules. What I liked is that I could declare the dependency as a dependent project. This allowed me to use the most recent code as it changes a lot (the project is in its infancy). NetBeans would put the dependent project on the classpath when running, and build a jar in the /dist directory when doing a clean and build.
Now that the main project is in maven, I can't do this anymore. The only alternative I've found was to manually copy it into the project repository, but that removes a lot of automation and ease of use. Every time I wanted to test a change I would have to rebuild the dependency, move it to the buried project repository folder, rename it appropiatly, switch back to NetBeans, then run. This is vs clicking run and everything being done automatically.
Maybe I'm just lazy, but is there an easy way to do this?
I have 2 completely separate projects where one depends on the other. I've very recently mavenized the main project but can mavenize the dependency if absolutely necessary.
Mavenizing the dependent project would help a lot. Like Eclipse or IntelliJ, NetBeans supports something Eclipse calls Workspace dependency resolution: if a project A depends on a project B and you open both of them in your IDE, A can be configured to depend on B sources instead of B jar (and any change would become immediately visible).
mavenizing the depedency project is the best option.
Alternatively you might get away with using a system scope dependency which points to the dependency project's dist/ folder jar artifact.
Can I make a single maven project that can be included as a dependency (to reference Java classes inside) and executed as a plugin?
I'm working on a library to help with hosting GWT on a LAMP stack. For someone to use this, they need to extend some Java classes (so it must be a dependency) and they need to invoke a maven plugin (so it needs to be a plugin). The plugin code references the same Java classes, so if they are seperate projects, the plugin one must depend on the library one.
As is, I have the library as a normal maven project, and the plugin as a maven plugin that depends on the library. This means that to do a release, I have to release two different artifacts, and the dependent project must update both version numbers for both artifacts. It'd be nice to have a single project.
You'd be better of by doing the following
project for the jar, Foo:Foo.jar
project that uses Foo:Foo.jar as a
dependency that builds the plugin
Maven parent project that
builds 1&2
The directory structure would look like this
\project\pom.xml
\project\foo\pom.xml
\project\foo\src\main\java\foo.java
\project\plugin\pom.xml
\project\plugin\src\main\resources
\project\plugin\src\main\java
From \project you can do a mvn clean package to build \project\foo\target\foo.jar and \project\plugin\target\plugin.jar
Hope this helps.
If you create a maven plugin it still has a artifactId/groupId/version. There's no reason it can't be references both in your section and in your section. On the other hand, if thats ugly, why not just make a library with the common code that both your main project and your maven plugin project depend on?
EDIT:
Sorry, wasn't clear on the second part. Look into composite maven projects, where there is a top level pom that defines a number of child modules. In this case, the maven plugin and the common library code could be separate children producing separate artifacts, but you only need one version number and one release command executed from the top level. I haven't done this but there are any number of open source projects that do. its often used as an idiom to put testing code into a single module that can be referenced by all the others, without having it go out in any distributable jar.
The best practice is to not do what you're suggesting. Examples of this include PMD, BND, JUnit/TestNG, and so on - no serious projects seem to package the maven plugin with the library proper.
One way to get both alternatives is to use maven assemblies to have two seperate maven projects for each the library proper and the plugin and then a separate packaging as a jar containing the classes from both.