I have a few java classes, holding my application's logic. Now I want to create two applications, one will be a SpringBoot web application and another one will be a desktop application. Both of them will use logic, that I already wrote.
I see only one way to do it: compiling logic classes into a .jar file and then putting it as a library into two Idea projects. But if I update any of this code, I will have to recompile it into jar and then replace an old jar with a new one in both projects.
Is there another, more simple way two divide my code into two projects?
What should I do with Git/GitHub?
P.S.
My project is in java, I use Intellij IDEA, GitHub.
Multi-module project
As commented, you need a multi-module project. The content for each module is compiled separately, producing separate JAR files.
IntelliJ supports multi-module projects.
I recommend using a Java build management tool to assist. Apache Maven is one such tool that supports multiple modules.
The word “module” used here in this context should not be confused for the Java Platform Module System. You may or may not choose to use Java modules in your project modules’ code.
I suggest rest web service interface to export the logic data..
SpringBoot web application can consume the rest services
and the other a desktop application can consume the rest services
ONE REST SERVICE LAYER
--------------------------------------
| |
Desktop app, SpringBoot web application
this way to don't duplicate your code and bugs twice.
Related
I have a Spring Boot Project called SuperProject and I want to use this project with differents contexts paths.
For example: paths 'baseUrl/client1', and 'baseUrl/client2', and 'baseUrl/clientX' will use the same logic and use cases defined on SuperProject.
All of this clients will use different database url connections, but the tables will be equals, so the client project will work.
So basically I should to only change the .properties/.yml file for each client.
However I can't have repeated code, because if I have to change any logic/use case, all of this clients will need to change too.
I think that i have to develop a .war library and share it by maven into all "client projects". But I don't know if the webservices url's, defined on SuperProject, will be mapped when i compile the projects.
How can I do that? Is this idea the best approach?
For example, you can use "assembly" plugin for maven with different environments. Eventually, maven will create packages for each client.
We're building an application that consists of several subprograms. Each of these subprograms are written in Java and share some common code. They are meant to be run as separate command-line utilities in a Linux environment.
What is the logical way to structure this kind of application in Eclipse? For now I'm thinking of: a) single Eclipse project with multiple classes and b) one Eclipse project for each of the subprograms and a project for common code.
Additional information:
Some of these subprograms would do primarily number-crunching, while other programs would use some graphics library to display information, while others would be simply manipulating files.
Evidently, the application covers a very wide area of functionality, therefore I am more inclined to the idea of packaging it into separate projects - but I'm not sure how well would that work with Eclipse.
Use a maven multi-module project. Eclipse works fine with maven projects.
You can use separate modules for subprograms. You can even make your subprograms component-based. That will allow you to have utility modules shared among your subprograms.
For example, if you encapsulate graphic processing code in a module, you can add it as a dependency to all subprograms that need graphic processing capability.
For all those who are having problems with getting Egit to cooperate with multi-module Maven projects, please see this answer.
I want to setup GWT in a special mode. I only use GWT for the client side as a replacement for having to deal with JavaScript directly.
The idea is to produce a single JS file.
Since this is also part of a bigger project with multiple project pages I got a problem where to put the output of the compiler and how to setup.
The ideal setup would be placing the GWT stuff into a single project and incooperate the ouput in a different project. The question is how to do it?
Update:
The current plan is to compile the JavaScript out of GWT using a simple Java application just issuing the GWT compile command and taking the Eclipse auto-build classes as necessary input. After the sources are compiled to java script the application copies the js files (one for every supported browser) to the related destination. This way the once created js files stay static and other developers do not have to deal with GWT related build tasks and we just avoid a necessary maven fight to get things working on build.
Also the GWT project can now depend on the web project making it possible to start the web application and alter its behaviour by adding support to host mode debugging.
Does anyone know a working example?
The easiest way, if you build a WAR in the end, is to put the output of GWT in a WAR too that you can use an an overlay in the final WAR module.
Other Maven plugins could do the trick too (dependency:unpack, maven-shade-plugin, etc.)
See https://github.com/tbroyer/gwt-maven-archetypes for examples.
We are building a small application using different architectural layers such as domain, interface, infrastructure and application. This follows the Onion DDD model. Now I am wondering if there is any benefit in splitting the application into a multimodule maven project. As far as I can see now it seems to make things more difficult than needed. The entire application will be deployed as a single WAR file into a Tomcat container.
Splitting your application makes sense for the following:
When a certain part of the project needs to have new functionality or bug fixes, you can simply focus on that module and run just the tests for it. Compiling a fraction of all the code and running just the related tests speeds up your work.
You can re-use the code from the modules across different projects. Let's assume your project contains some well-written generic-enough code for mail sending. If you later have another project that need mail sending functionality, you can simply re-use your existing module or build upon it (in another module by adding it as a dependency).
Easier maintainability on the long run. Maybe now it seems like a small project. In a few months things might look different and then you'll need to do more refactoring to split things into logical units (modules).
Conceptual clarity (as added by Adriaan Koster).
Concerning the WAR: You can have an assembly module which puts things together and produces a final WAR file from all the related modules.
Initially, this may seem as more work, but in the long-run, modularized projects are easier to work with and to maintain. Most sane developers would prefer this approach.
Using multiple modules forces you to have a hierarchy of dependencies. You have one module which is standalone and doesn't depend on any other of your modules. You have another which only depends on that. It might appear harder than allowing anything to depend on anything else but this approach results in a mess of dependencies which is hard to fix later.
If you are trying to follow a layered model I suggest you place each layer in a different module. This will ensure you are not tempted to break the model.
Short answer: today it is small, tomorrow it will bigger and more complicated to maintain, reuse, extend, integrate with other system and so on
As far as I know, Maven do little help for WAR dependencies. As you are talking about single WAR, this should never be a problem.
You can separate java classes into several "jar" submodules, but if you split the WAR project into several smaller WARs, using some kind of "overlapped" packaging things get complicated.
Just information, one of our projects, it contains too many web pages, so we decided to split it into several WAR submodules, however, the session is not shared between different WARs deployed, and we are not going to use Kerberos stuff. At last, we modified a lot sources of Glassfish, Jetty, MyFaces, etc. To make them resolve web.xml stuff inside JARs. And converted the whole project to Facelets 2.0 (to avoid the dependency of JDK tools.jar and custom resource handler), the only reason is to change the WAR submodules to JAR submodules, and move all webapp/pages into class resources. So the conclusion, Maven does great job for JAR dependencies, but no WAR or single WAR.
EDIT You can put applicationContext.xml in one of the base submodule, and import it by classpath:com/example/applicationContext.xml. Also Spring 3.0 do have annotation supports, you can make spring auto scan them instead of declaring them all in the xml.
Spliting your project into multiple maven projects is useful if you want to reuse your classes in another project or if your projects are deployed in different configurations.
Maybe think of a webservice - if you are hosting the server, you could build a project for your domain classes (models) and your endpoint interfaces that could be used by server and client. The server would be another project that is build to a WAR.
To develop further clients the first project could be used, too.
Use a parent project for dependency management on common projects (like logging) and different profiles and build configurations.
I have recently joined a project that is using multiple different projects. A lot of these projects are depending on each other, using JAR files of the other project included in a library, so anytime you change one project, you have to then know which other projest use it and update them too. I would like to make this much easier, and was thinking about merging all this java code into one project in seperate packages. Is it possible to do this and then deploy only some of the packages in a jar. I would like to not deploy only part of it but have been sassked if this is possible.
Is there a better way to handle this?
Approach 1: Using Hudson
If you use a continuous integration server like Hudson, then you can configure upstream/downstream projects (see Terminology).
A project can have one or several downstream projcets. The downstream projects are added to the build queue if the current project is built successfully. It is possible to setup that it should add the downstream project to the call queue even if the current project is unstable (default is off).
What this means is, if someone checks in some code into one project, at least you would get early warning if it broke other builds.
Approach 2: Using Maven
If the projects are not too complex, then perhaps you could create a main project, and make these sub-projects child modules of this project. However, mangling a project into a form that Maven likes can be quite tricky.
If you use Eclipse (or any decent IDE) you can just make one project depend on another, and supply that configuration aspect in your SVN, and assume checkouts in your build scripts.
Note that if one project depends on a certain version of another project, the Jar file is a far simpler way to manage this. A major refactoring could immediately means lots of work in all the other projects to fix things, whereas you could just drop the new jar in to each project as required and do the migration work then.
I guess it probably all depends on the specific project, but I think I would keep all the projects separate. This help keep the whole system loosely coupled. You can use a tool such as maven to help manage all the dependencies between the projects. Managing dependencies like this is one of maven's main strengths.
Using Ant as your build tool, you can package your project any way that you want. However, leaving parts of your code out of the distribution seems like it would be error prone; you might accidentally leave out necessary classes (presumably, all of your classes are necessary).
In relation to keeping your code in different projects, I have a loose guideline. Keep the code that changes together in the same project and package it in its own jar file. This works best when some of your code can be broken out into utility libraries that change less frequently than your main application.
For example, you might have an application where you've generated web service client classes from a web service WSDL (using something like the Axis library). The web service interface will likely change infrequently, so you don't want to have the regeneration step reoccurring all the time in your main application build. Create a separate project for this piece so that you only have to recreate the web service client classes when the WSDL changes. Create a separate jar and use it in your main application. This style also allows other projects to reuse these utility modules.
When following this style, you should place a version number in the jar manifest so that you can keep track of which applications are using which versions of your module. Depending on how far you want to take this, you could also keep a text file in the jar that details the changes that have occurred for each revision (much like an open source library).
It's all possible (we had the same situation some years ago). How hard or easy it'll be depends on your IDE (refactoring, merging, organizing new project) and you build tool (deploying). We used IDEA as IDE and Ant as build tool and it wasn't too hard. One sunday (nobody working+committing), 2 people on one computer.
I'm not sure what you mean by
"deploy only some of the packages in a jar"
I think you will need all of them at runtime, won't you? As I understood they depend on each other.