multi project java build with gradle - java

I've decided to use gradle instead of ant in some of my applications.
the folder structure for my apps is:
<appname>
---java
------build.gradle
------settings.gradle
------sourcefolder1
------sourcefolder2
------sourcefolder3
---------------subsourcefolder1
---------------subsourcefolder2
I take the compilation files for every application and create a single jar that contains them all.
My issue is as follows:
There is no code to compile under the java folder, only under its subdirectories which are sub-projects in gradle. So, I apply the java plugin only for the sub-projects. In this case everything compiles fine but the final jar to contain everything doesn't get created. On the other hand, if I apply the java plugin to the rootProject it starts compiling the source folders although they have a uniqe project of their own.
I tried applying the java plugin to the root project and overriding compileJava task to do nothing - but it created an empty jar, probably this task also generates the products to jar.
Is there an elegant solution for this?
Thanks.

Related

IntelliJ IDEA Gradle + Groovy

I am new to IDEA.
What I would like to do is have a project (or module?) that has maven folder structure (aka src/main/java, src/main/groovy, src/test/groovy, etc), be managed by Gradle and support creation of Groovy classes, their compilation and execution.
What I tried:
Create a "Groovy" Project.
I can add "Maven" support, but not Gradle.
Create a "Gradle" project and add "Groovy" module to it
I can manage dependencies and plugins, but the file structure is screwed up.
The code goes into a sub-folder of the project (aka the name of the module)
I cannot directly add folders to the "src" of the module. When I copy them into the src folder they are considered package names.
What I am looking for:
Solution to the particular problem
General workflow for creating multi-facet (aka Gradle+Groovy or Java+Maven or Web+YouNameIt) project/modules.
Explanation of what is the reason for this paradigm/structure shift in IDEA?
I would suggest not creating the project from inside Intellij.
Since Intellij imports Gradle projects quite nicely you can just import one of the pre-made Groovy Gradle Quick Starts you can find at the root of your Gradle installation.
For example $GRADLE_HOME/samples/groovy/mixedJavaAndGroovy has the exact Java/Groovy layout you describe with the HelloWorld Classes and Tests in place. Just copy it, rename the root folder, import it into Intellij and code!
Solution to the particular problem
0) Turn on Gradle plugin in Preferences -> Plugins
1) Create any Java project (Groovy, Maven, plain Java)
2) Create build.gradle file in base directory
3) Open JetGradle view and click Add. Then select your build file
4) When you do this first time, IDEA will prompt you to locate your local Gradle distribution (you may also change it later in Preferences -> Gradle settings)
As for project structure, Gradle follows Maven conventions, so in the build file you just write:
apply plugin: 'java'
and everything just works.
Create a "Gradle" project and add "Groovy" module to it
I can manage dependencies and plugins, but the file structure is screwed up.
The code goes into a sub-folder of the project (aka the name of the module)
I cannot directly add folders to the "src" of the module. When I copy them into the src folder they are considered package names.
Explanation of what is the reason for this paradigm/structure shift in IDEA?
The main reason is to provide possibility of logical decomposition of your application into separate modules, e.g. app-core, app-web, app-ear etc. Each of this modules produces an artifact: jar, war, ear.
Compare this with other IDEs, say Eclipse, where you would have several different projects (perhaps dependent on each other) to accomplish the same thing. So basically, you may think of IDEA module as of Eclipse project (roughly). Also this greatly simplifies usage of Maven multi-module projects.
As for the src folder: IDEA lets you mark directories inside the module "content root" (base directory of the module) as Source, Test Source or Excluded. If src is marked as Source directory, then obviously everything inside is treated as packages and sources.
I followed the steps in this video:
Create "Gradle" project, with Gradle plugin enabled and Gradle API plugin disabled. Select "Create empty folders" option.
Add "apply plugin: 'groovy'". This will create groovy folders.
Add "" to IML project file in order to be able to create Groovy classes.

How can I organize source-generation in Maven?

I have a Maven plugin which generates sources for my java project and places them into 'target/generated-sources' folder. I need these sources at compile-time. I want to have them in my project while modifying it, already generated. And of course, I want to put them into the correct folder under 'src' folder, and not into 'target/generated-sources'. How can I organize this using Maven?
In other words, I want to be able:
generate sources I need by running some goal of my special source-generating plugin (already done, the sources have the package I specified)
move these generated sources to 'src/main/java/...' folder of standart Maven layout.
remove them from 'target/generated-sources' folder, because otherwise mvn clean install command raises error which says that I have "duplicate class". Indeed, if I just copy generated sources from target to src - I have to classes with the same name and package, though one of them is located in target folder.
Which Maven plugins can hlp with this? I suppose this is a typical task.
The standard solution in maven is to generate all source into target/generated-sources, all source code from target/generated-sources and from src is compiled into target/classes and merged into target jar.
Plugin should never touch files under src directory, because these files are managed by version control system (ex. git).
If plugin is badly written and source files from target/generated-sources is not automatically compilled into target, then use goal build-helper:add-source from Build Helper Maven Plugin as #James Kingsbery said.
In maven-com4j-plugin source code there are comments:
/**
* Directory in which to create the Java COM wrapper files. This directory
* will be added to the Maven project's compile source directory list and
* will therfore be auto-compiled when the Maven compile phase is run.
*
* #parameter expression="${outputDirectory}"
* default-value="${project.build.directory}/generated-sources/com4j/java"
*/
The more important part and solution to your problem is:
This directory
will be added to the Maven project's compile source directory list and
will therfore be auto-compiled when the Maven compile phase is run
So, generated source code should be automatically compiled and archived into builded jar.
You should have a look at the build helper plugin. It allows you to specify additional source directories (such as target/generated-sources). See also Usage of maven Build Helper Maven Plugin.
If your plugin works correctly it will add the generated sources to the internal project and other plugins like the maven-compiler-plugin will pick it up and compile the generatd code.
Within your plugin code you can accomplish this by using something similar:
mavenProject.addCompileSourceRoot( getOutputDirectory().getAbsolutePath() );

Create compile script for Java

I have downloaded an Eclipse project and I want to be able to have other people compile it without using Eclipse. It is a fairly large Java project that is still being worked on. How would I make a compile script that compiles like eclipse?
I highly recommend you look into Maven. Basically you'll define a Maven pom file in the root of your Eclipse project directory which will contain your dependencies (jars) as well as compile and assembly configuration. With this in place you can simply checkout a project and run a maven build command against the local directory you checked out to and an executable/deployable package will be created.

Adding plain Java project as a classpath to an eclipse plugin

I have a plain Java project (not a plugin project) which I want to add to a classpath of a eclipse plugin which I am developing. But in web projects I can add that project as a build path and it works fine. But I tried same thing in eclipse plugin, I am able to compile successfully, but at run time I am getting java.lang.ClassNotFoundException.
I know OSGi quite well and I know how to add OSGi into an classpath (using export-packages) but what I want is to add Standard, non-osgi project into an classpath, so that I wont' get runtime errors. Is there anyway I can achieve this?
I can export project as a jar file or make it as a plugin project and it would work fine. But that's not my option currently because, still that API is in pre-alpha stage, and there would be lot of changes going on. So I am trying to avoid pain of exporting it as jar file everytime. Is there any option for me other than this?
I have a similar situation: I want non-OSGi Maven dependencies integrated into the classpath of my plugin. I succeeded with a roundabout solution, which I think is the best I could get.
I have a build step outside of Eclipse where I copy the class files of the dependency into the plugin's lib folder. The lib folder is specified in MANIFEST.MF as an entry in Bundle-ClassPath and (here comes the hack) as a source folder in build.properties. That was the only way to make the plugin work both when launched from within Eclipse and when exported.

Java Maven project minify the build

I am working on a multi module Maven project. We have created a project which builds an uber jar. The unpacked jar is about 60mb which is a problem for our client.
Are there any tools we can use to remove unused .class files within the dependencies when the build is completed?
Another option would be if we could analyse what .class files are loaded when running and produce a list of these and thus remove others from the build manually.
cheers,
I'm not sure if it could remove classes as such, but proguard has some awesome results in terms of minifying class sizes. You can see from the link it reduces the Ant module by 90%

Categories

Resources