I intend to extract several classes and packages from one Java project and place them into another (which will have a distributable jar). That much isn't too difficult, but of course with such a large refactoring there are consequences. Namely there are many classes in the original project that are subclasses of the classes I want to extract. What's the best method for approaching this sort of refactoring?
You can create separate projects and the main project will have dependencies for all these projects. So in your IDE you can navigate through source code easily.
When building your application, each dependency could be built into a jar and the main application will be bundled with all the dependents jars in its classpath.
Let take as example a web app using plugins, and plugins using common classes, utilities and so on stored in a project named common-plugins.
project/webapp: having dependency on plugin1, plugin2 and common-plugin
project/plugin1: having dependency on common-plugins
project/plugin2: having dependency on common-plugins
project/common-plugins: having no dependencies
When building your project, you could build the plugins and the common-plugins into jars, bundled with your web app
project/webapp.war/WEB-INF/lib/plugin1.jar
project/webapp.war/WEB-INF/lib/plugin2.jar
project/webapp.war/WEB-INF/lib/common-plugins.jar
This way in your IDE, I will take eclipse for instance, you will have a workspace having 4 projects with dependencies as described above. At build using maven, ant, ivy, or what you want, you will build the 3 projects that the webapp project depends on, then bundle the whole stuff.
So basically this is what I did:
Create a new project
Copy over the appropriate classes from the old project to a new package in the new project, reconfigure until everything builds
Test that project separately and build it in to a jar
add jar as a dependency
Delete the classes from the original project
Manually change all the imports from the old packages to the new packages
What I was really looking for was some way to automate or streamline step 6 to make sure I didn't break anything, but I'm not sure it exists beyond mass find/replace.
Related
I'm writing a lot of plugins for minecraft bukkit server's and I've grown tired of copy+pasting the same utility classes in my projects all over again. I decided to just put them all in a separate project and add them to my plugins via maven. I'm using IntelliJ Ultimate.
I want to have a maven project that contains all my utitily classes called e.g. UtilityAPI. Then I want to be able to create another project, which will be my bukkit plugin. In this second project I want to be able to use all the code from the first one. Also, I'd like it very much, that if I choose to build a plugin jar, maven automatically takes into account the most recent code from my API-Project.
I started working on this and started reading about maven modules and how you can use them to forge different projects together. I initially thought, that this was just what I needed, and tried to just add
<modules>
<module>UtilityAPI</module>
</modules>
However this results in my bukkit plugin project being considered a parent project, and refuses to build in a jar, but just in a (at least for me) rather useless .pom file. I'm not sure how to proceed. Do I have to create a "parent" project for my bukkit plugin project which contains the api and the plugin project as modules? And if yes, how do I generate a .jar, and not a .pom?
The dream solution would be to have the UtilityAPI project, and being able to include it in any new plugins that I might write in the future. I'd also be a fan of having a simple way to create a jar with the newest sources of my plugin in it. Is this possible, and if yes, how?
In your Maven multi-module project your plugin would have to be another module (and not the parent, which has packaging type pom). This module would then have a dependency on the API module (dependencies between modules are possible).
However, multi-module projects are usually intended for projects which are tightly coupled. That does not appear to be the case for your scenario. It sounds like the plugins have (potentially) nothing in common except for the dependency on the API project. Maybe it would be better to have the API project as separate standalone Maven project and then deploy snapshot versions of it (or install them only to your local Maven repository) and use these in your plugin projects.
I have a project with a library JAR and a set of applications. Right now the applications (all 5 of them) are in a single project. These tools each have one or two classes, they run from the command line with one exception. Even the GUI tool has only about 8 classes. I am struggling with how best to structure this in Eclipse.
I have seen that I can use maven-shade to create multiple executable JARs from one project. I would need to convert the project to Maven, but I assume that is not a big problem.
I can create a separate project for each tool. This seems like overkill to have several projects with one or two classes in each.
Additionally, both of these solutions will leave me with either a bare class file or a JAR plus the dependent library JAR. Not ideal for deployment.
Before I pick one of these, I thought I would ask here if there is a different approach that I am missing for packaging these tools.
In eclipse, Export --> Archive file, You can select/deselect what classes you want to export into your Jar File
Yes, but You could/need to create using Maven, and for each build building jar you need to set the main Class.
Checkout the documentation of Maven.
I think You could to the same with Gradle, but not sure.
https://maven.apache.org/plugins/maven-jar-plugin/examples/attached-jar.html
I have a case where there are multiple projects and each are interdependent and I could not create a maven script with such a dependency because jars wont be ready to use as both are interdependent. Do we have a solution for such cases in maven? The solution what i see here are below:
Remove the dependency between the projects means change the code to remove such interdependent.
Merge two projects into one in the build - means create single jar by picking up source from 2 projects.
I dont want to do either of do as it needs additional efforts to do so.
Is there a way source of one project can be used in another project and not being part of JAR?
In Maven you cannot build interdependent jars. This problem also arose in our company when we moved legacy projects to Maven. In my opinion one should really put effort into solving this situation, so use your proposals (1) or (2) or generate a third project which contained the shared classes on which both jars depend. Any "trick" to avoid this would be as complicated and lead to a bad project structure.
currently we are using ANT script to build the project and running jUnit tests. Now, we decided to move to Maven.
We have two web projects, Core-Project and Sub-Project. Now here it gets complicate. Their project is as follow.
Now, If I want to add this Sub-Project to Core-Project then I will create a jar of Sub-Project with WebContent folder and put it into Core-Project. Now whenever I run Core-Project, we have one utility class which extract content of Sub-Project into Core-Project.
Final(expected) project structure should look like this.
How can I achieve this in Maven? I mean how do I create a jar which contain some files located in src->main->webapp.
It seems that you need to rethink your architecture a bit. This answer may go beyond the scope of your question, but it's important to treat Maven as 'convention over configuration'. It is possible to achieve your layout using a combination of maven packaging tools, but if you restructure and follow Maven conventions, it will make more sense to people outside your project and be less work to maintain.
Suggested:
config-project
sub-project
core-project
config-project can hold the configuration for all parts of your application. sub-project and core-project can depend on this project and use it at runtime. You should package this project as 'jar' or 'zip' depending on the resources you need to make available to other projects.
sub-project should only contain the binary code common to the non-web based part of your application. It should be packaged as a 'jar' project and not be packaged with the config-project dependencies.
core-project should be packaged as a 'war' project. and follow the directory structure as suggested here: Maven War Plugin
Keeping the separation between your configuration, your non-web code and your web code will take a little bit to get used to. There is an excellent archetype by Tomcat which generates a maven project structure composed of these parts. It is easy to generate and inspect: Maven Tomcat Archetype
I am developing a Java application using IntelliJ Idea 14.1.4.
If it would have been solely Java application, I would have known exactly how to structure the project in Idea:
A single Java project, containing several modules: One for each part of the application (JAR).There will be at most 4-5 JARs.
The dependencies between the modules are also known: Protocol does not depend on anything, everything else depends on Infrastructure, and so on.
Next, I would like to use Gradle scripting for managing the project. So my question is what is the best practice to structure the code in Idea?
Should I create a single Gradle Project and a Gradle module for each of the JARs?
Should I create a single Java project (or maybe empty project) and Gradle modules for each of the JARs?
Should I create a single Gradle project and each of the modules will be a Gradle's sub-project? Maybe it will be better to have an empty project and several Gradle modules because not all of the JARs are closely coupled?
Since I have never used Gradle before, I would appreciate any guidance for the best practices when combining both Gradle and Idea.
Thanks,
Guy
As long as possible, I would keep the code in one source repository. On the root, I would have an "empty" project not outputting anything. All your jar projects would be sub-projects (in Gradle terms). You include them via the settings.xml file located in the root project.
Each sub-project has its own build.gradle file. In those files, you can easily define the dependencies between your sub-projects, e.g.:
dependencies {
compile project(':subProject3')
}
For convenience, I often create a special export task to put all artefacts in one export/ folder on the root level so that you don't need to go through all those sub-folders to get your stuff.
task export(type: Copy) {
from project(':subProject1').jar
from project(':subProject2').jar
from project(':subProject3').war
into 'export/'
}
IntelliJ Ultimate 14 works fine with this approach. You can simply hit Make to compile everything. You might also want to configure your project settings to run gradle jar or gradle export during a make if you prefer.