I'm migrating existing build system from Ant to Maven, and so far I've solved (or redesigned) many issues, except for this one.
Target of each our system-specific project is a simple JAR, but it additionally contains some project configuration and customizaton information which is copied to a (let's say) /product folder of a WAR. This way modularity and extensibility of our web-application is achieved
Consider example:
project:
MyProject
/product
product.info
some.data
WAR:
./product
/MyProject
product.info
some.data
..
..
./WEB-INF/
/lib
MyProject.jar
..
My question is: how do I achieve this result for our product-specific projects? The first thing that comes up my mind is: two artifacts as a result of such project build (JAR and ZIP), where ZIP is created by a POM in /product folder (and the best layout would probably be splitting each project into two sub-projects so that I can aggregate POM and ZIP with one multi-module project). I will appreciate all solutions proposed (incl. project folders' restructuring options).
The first and obvious answer is splitting up each such 'product' project (consider it as a 'module' if it's easier to perceive this way) into two sub-projects -- one for JAR, and one for configuration data. Then, using an assembly, all declared 'product-ZIPs' will go to ./product folder of a WAR.
EDIT Classifiers could also be applied to configuration-plugins in order to make assemblies more structured and easier to implement.
Related
We have a EAR project which has a WAR project. Maven is used, so pom.xml. As typical of any project, this project also contains a big feature (say Job Scheduling "JBS") among many other features. As it is planned to retire this whole project in the near future, it is discouraged heavily to spend much on working on this project (whether bugs or enhancements).
Therefore, for the sake of running the (JBS) feature as a separate application, the whole EAR project was duplicated (also to save time/cost). As a result, all the Java packages and classes (necessary for JBS project) were duplicated. In this situation, if we update one or more classes in the main project, this (JBS) feature project/application gets outdated (and needs update).
The fact is that this JBS feature project ONLY requires many packages of Java classes (from the main EAR-WAR project), and do not require 99% of the web modules and others. I am removing all the unnecessary things from JBS project. Then I would like to create a JAR library with all the java classes, so JBS project can have a dependency on this JAR.
I do not know if it is a good idea to separate these classes out of the main project (to create another Java project). I would like to continue to have these classes as part of the main project. Then, it will be good, as and when one or more of these classes are changed, a new version of the JAR will be generated (right away). And the JBS project would then make use of this updated JAR.
How can we accomplish this? I understand, through maven, we can do a build/package jar/war/ear on a project of that nature. I am not an expert with maven (and did not learn it systematically).
But, is there a way to create one or more JARs additionally from inside WAR pom.xml? In other words: I mean pom.xml of WAR will create a WAR. In addition to creating a WAR, can maven help create additional JAR? Or can maven create two packages out of one pom.xml?
Or should I create a separate module in the main project with all these packages/classes, and have its own pom.xml to generate the necessary JAR? For this, most probably I need to modify the structure of the main project. I would like to avoid this unless there is no way out.
Can you advice?
It seems like the best thing for you would be to create a multi-module project that both contains the JAR and the other project. This way, you can easily change/build them together, but you create separate artifacts.
I am using gradle and its local repository is at \.gradle\caches\modules-2\files-2.1 which has all the downloaded jar but not my modules.Is there any specific place I should be searching it for ?
I need it as is in settings.gradle I am having a dependency path specified like :
include ':model'
project (':model').projectDir = new File(settingsDir, './model')
in a new project. Also I don't want to give path in that way because if I have a dependency from multiple projects on this project then mentioning path will be difficult and weird.
How can I make gradle search it from local maven or gradle repositories.
I'm still not sure what is being asked here, and I suspect there is some confusion over how multi-project builds work. So I'm going to attempt to provide a general-purpose answer.
The first question you need to answer is whether you're interested in dependencies between projects that are part of the same build — as in part of a multi-project build — or in separate builds.
Project dependencies (multi-project builds)
Project dependencies are covered in the user manual and only apply to multi-project builds. They use a logical path, using colons as 'path' separators, to specify the location of the target module, like so:
dependencies {
implementation project(":model")
}
At this point, Gradle needs to know where ":model" exists on the file system. There's no getting around that. You have a few options:
Follow the convention of directory structure matching the logical path structure, i.e. have a MyBigProject/model directory containing the ":model" child project
Specify the file path of ":model" in settings.gradle, e.g. with project(":model").projectDir = new File(rootDir, "unusual/path/to/model")
Automate the discovery of projects
The most common approach is the first one. The second is not unusual, particularly if you want to put child projects into a separate directory, like subprojects — something the build of Gradle itself does. I haven't seen the last option done, and I don't know whether it runs into problems.
For the sake of completeness, and at your own risk if you use something like it, here's an example of automatic discovery of projects in the settings.gradle file:
rootDir.eachDir { File dir ->
if ("build.gradle" in dir.listFiles()*.name) {
include dir.name
}
}
This fragment basically looks for directories within the root project folder that have a build.gradle file in them and adds them as child projects. The child projects' directory names become the projects' names.
It's not particularly clever, and you should really use different names for the build files, but it may give you some ideas to work with.
Non-project dependencies
As with project dependencies, Gradle needs to know where to get the corresponding JAR or other form of artifact for a specified module. You normally specify Maven Central or something similar for this, but there are other useful, but less common, options:
Copy a project's artifacts into the local Maven repository — both the Maven Plugin and Maven Publish Plugin support this
Publish to a Maven-compatible repository using a file:// URL rather than an HTTP/HTTPS one, which protects your projects from corruption of Maven Local
Worth noting is that Gradle supports composite builds that allow you to substitute a normal dependency with (effectively) a project dependency from another build. So if model were part of a separate build but you had the source code and build locally, you could make changes and immediately test them in another build's project without going through the whole "install" intermediate step that's common in the Maven world (and Gradle pre-composite-builds).
Hope all this makes sense.
I have a situation at the moment where I have:
Project A which is built into a fat jar using Maven assembly plugin.
Project B which uses the jar built in Project A. It is added to the project as a resource and launched in a separate process using a process builder.
I wonder if it's possible to achieve similar behaviour using just one Maven project. I.e build the jar containing only the classes and dependencies required for project A, and then build the rest of the project with the prebuilt jar.
Sorry if I'm not being very clear here.
This is against a few of Maven's core concepts:
One project, one model (POM). Two projects (A, B), two models (POMs).
There's one artifactId in a POM. What is a second artifact (jar) supposed to be named?
One project leads to one artifact. There is no additional "prebuilt jar" built within the very same project.
Dependencies are for the whole project (and possible sub-module projects). I'm not aware of how to "containing only the classes and dependencies required for project A".
Artifacts are stored:
in <project>/target temporarily
in the local Maven repository (default: ~/.m2/repository)
possibly in a remote Maven repository
... while resources are taken from <project>/src/main/resources during the build.
There might be some tricky solutions (which have possibly pitfalls, too) to achieve this if one thinks about it thoroughly. But I'd never ever recommend such.
I am using alfresco 4.1.3 having following project structure.
I am using the ant script to build project.
Now I want to convert this project into maven based alfresco5.
I have configured alfresco5 using all-in-one archetype and I am able to run it successfully. My questions are:
How can I convert my alfresco ant based project in alfresco5 maven based?
Do I need to add src files in repo or repo-amp?
Do I need to copy all share related files in share or share-amp?
Any help would be greatly appreciated!!!
Thanks in Advance.!!
That totally depends on the ant build setup. But one good guess is that you will have to put the files residing in the "Alfresco" folder of your old project into different subfolders of the repo-amp, and the same way around with the "Share" folder. Most files will go into those folders, you have to study the SDK-docs carefully to know into which folders the files will go. Depending of the nature of your extensions some files could go into the Share and Alfresco war-structure as well (additions to web.xml for example).
There are no "Swiss army knife" for that works for all cases here.
Good luck
Do the following things:
Create new project as maven project and provide group id (it's yours) artifact id as alfresco5 and version (ex:43.0.1-SNAPSHOT)
With this it creates maven based folder structure
src/main/java -> replace it with your src folder
3.src/main/resources ->add your Share, reference and Alfresco folders.
look at you lib directory..what ever .jar will be there you need to define it in dependencies under pom.xml
compile the whole project..if there are compilation errors then add required dependencies in pom.xml
We have one project that reuses 3rd party war (it's shindig-server-2.0.2.war if anyone asks:). This war currently sits in project root and the current ant tasks unzips it into some temp folder, performs several changes (like applying fixes, modifies the web.xml etc.) and finally build the war from our sources and the war content. This 3rd party is checked into the source repo.
We are migrating to gradle. Where should we put this file in Maven directory structure?
It does not look it belongs to /src/main/resources as it is not packed withing the artifcat; also, imho it does not belong to /src, too. Should we have a /lib/resources folder in root where we could store such files?
I don't think the Maven directory structure defines a place for local dependencies, and since this is a Gradle build, it doesn't really matter either. I wouldn't put it under src, but lib sounds fine.