I have a project in which there are few components like A, B and C. All the components are exposing rest interfaces that other components are consuming. So, I am using ant to product A.war, A-services.jar, B.war, B-services.jar, C.war, C-services.jar.
A-services.jar contain the interface declarations for B and C.
B-services.jar contain the interface declarations for A and C.
C-services.jar contain the interface declarations for A and B.
I want to migrate it to Maven. But I have read at some places, it is not a good idea to have a single pom produce multiple packages like A-services.jar and A.war. What should be the best way to go for that.
I would assume the reason you have A-services is because of shared data models and such. With that being the case you end up with multiple projects. A POM for the A services. Then another A WAR project that has a dependency on A-services. And your B project also has a dependency on A-services.
With that being said it seems you really just need to separate your projects into data model projects and implementation projects.
You will have six projects. Do not try to make Maven produce a WAR and JAR from the same project.
You may find the maven-assembly-plugin to be helpful for you, but as Andrew stated, you really need to separate out your project into proper modules. This is what Maven is really for.
Related
This might be a silly question, but I need to know. I'll delete it if it's too silly to answer.
In a maven project in IntelliJ, I have the following structure:
procedure
e2e
cucumber (same level as common)
src
test
java
e2e
support
File: ScenarioState.java
package e2e.support
common (same level as cucumber)
src
main
java
common
testdata
File: Case.java
package common.testdata
Is there any way to import the package e2e.support (where ScenarioState.java resides) into the file Case.java in the common.testdata package?
I've been playing around with maven imports, dependencies etc., but I haven't found a way to do it. I might have to redesign some classes to get around it, but that would impact other parts of the project and I'd like to avoid it if possible.
If you really want to do that (and I would strongly recommend to either leave the project alone or restructure it first), define an additional source directory as in
How to add an extra source directory for maven to compile and include in the build jar?
But beware that a project like this will haunt you till the end of time.
One could have in the common's pom.xml a dependency to cucumber with <type>test-jar</type>.
However this violates the concept of src/main for the final product, and src/test for the unit-tests (not incorporated in the product, separate test classes).
(In src/test there can be other classes, so maybe easiest would be for common to have a src/test instead.)
If ScenarioState has nothing to do in src/main, one could place it in a more low-level library cucumberbase in src/main. And make a dependency in cucumber to cucumberbase with <scope>test</scope>. In <common> a normal dependency to cucumberbase.
Keep this main-test separation as otherwise other developers risk insanity.
I think I already know the answer, but would appreciate if someone can confirm it for me.
A) We are including a library in a build using maven-shade-plugin;
B) This library implements singleton(s);
C) Our resulting jar (uber-jar) is, in turn, used in a build of a megaproject;
D) Other jars in a megaproject also using the same library (A);
Would the library (A) be not acting as a singleton across the entire megaproject?
Would we end up with a separate set of static variables for each shaded copy of an artifact?
Would using maven-assembly-plugin instead of maven-shade plugin help?
You described a scenario in which the same class could end up in the classpath more than once.
In such an application the class loader will pick up the first one found when looking for that class. Once it has found it, this class is loaded and initialized by this class loader, and he will not look it up again. Usually that does not lead to problems, and you will still have the singleton as you want: one instance only.
If - for some reason - you have multiple class loaders at hand, they each could load this class from another location. So you could end with several singleton instances.
The shade plugin seems not to be the best tool for that. I would suggest to use it only for standalone applications that you package in a single shaded JAR - the end product.
We always use the assembly plugin because it gives a more fine-grained control over the packaged assembly. But you should not use shaded JARs as dependencies, instead simply use the core libraries. Even if you have the same dependency in various dependency paths in your project, the assembly plugin will package it only once.
I'm coding in Java with Eclipse. I have two projects: ProjectOne and ProjectTwo.
I have some packages in ProjectOne that I want to include in ProjectTwo without including anything else from 'ProjectOne'. How can I do that?
You can create one more project projectThree with your needed classes from ProjectOne in it. Then ProjectOne and ProjectTwo depend on projectThree. I think this is best case scenarios now..
Project Jigsaw which is planned to released in Java 9 should solve your problem.
it adds modules to Java..
" modules provide a list of all the packages of this particular module that are considered public API and thus usable by other modules. If a class is not in an exported package, no one outside of your module can access it – even if it is public."
More can be found here...(above comment is taken from Below link)
https://blog.codecentric.de/en/2015/11/first-steps-with-java9-jigsaw-part-1/
I'm looking for a possibility to parameterise a multi-module build in a way that I can replace/specify some files (e.g. UML files) that are used during the build in order to produce different output.
The procedure of the build stays the same but I want to be able to produce different output depending on the input UML model.
I have a multi-module project that builds several jars based upon an UML model. The pom structure looks as follows:
+ generation
- mod1
- mod2
- mod3
The root pom (generation) generates java sourcecode (.java) based upon an UML model stored in the directory /uml. Afterwards the modules (mod1...3) compile distinct subsets of this sourcecode and package the output as jar.
I want to reuse this build procedure and apply it to different UML models.
How can I reuse the entire generation, compilation and packaging procedure defined in the multimodule project in other maven projects?
# Generate jars based upon the foo UML model
+ generation-foo
/uml/foo.uml
# Generate jars based upon the bar UML model
+ generation-bar
/uml/bar.uml
Update
I could use profiles in the generation project in order to define the different input uml models and then just activate the relevant one. But I would lose traceability that way.
Perhaps a completely new approach would be a better idea ... any suggestions?
Conceptually, I would say, Maven is designed around the POM file which is a model of the project that is being built. It is not so much a process description that applies a function to an input and results in an output on basis of that.
That being said, there is a lot possible with properties in the POM, which then can be passed along on the command-line: -Dproperty=value. It looks as if you would be able to pass the property to whatever process is generating the source code.
I may express some caution, though. I'm seeing some possible red flags in the overall design that you describe. If modules (regardless of their inheritance relationship) pass along files/folders, that should preferably go through installation.
So, if you were to do that, you end up with a version of the parent project in your local repository of which you don't really know what it is. Which parameters were used? And how will a user of that artifact then deal with that?
I'm not saying this won't work, but it may get hairy and not play entirely well within more traditional Maven implementations.
I'm not entirely sure I understand your use cases but you might want to look at:
POM Inheritance : Defining as much as you can in the parent module (different groups of modules can have the same parent)
Maven profiles : you can activate based on all sort of potential conventions like even the project name.
Maven Archetypes : And finally I think based on what your saying this maybe the only solution of a reusable project template
I have a Java project in eclipse - within the project I want to configure two source directories:
src-api
src-core
This is simple.
The problem is that I want src-core to be able to access src-api, but I don't want src-api to access src-core, I want eclipse to not let me compile and be able to find classes configured in src-core only from the src-api.
Is it possible to do so?
I would very much appreciate your help.
No, it is not possible.
Just create two different project api & core. Then make core project dependent to api project.
I would use two different projects, one for src-api and one for .
The src-core should have src-api as a dependency, but not vice versa.