We are trying to migrate our builds from ant to maven. Project I am working for is using ant since ages. Scripts are real complex where build artifact is a zip file having a definite directory structure. Build creates about 108 unique jars and packages them to this zip file along with many config files and other 3rd party jars.
We need this zip file to be same as now even after migration to Maven. I am just a learner on Maven as of now. My question to you guys is that if there is a way using which I can use one pom.xml to produce more that one jar file, providing list of jars and includes, excludes packages for each.
I googled and found that in case we need multiple jars from one project but different packages, we can do so by placing one pom.xml at each package (jar will be created from this package) and bonding all using dependency management.
But this does not solves my problem, as having 100+ pom.xmls does not seems to be a good idea.
Hope I have made my question clear. Please suggest if there is a way out.
Adding to Udo's answer here's another Sonatype blog posting with a diagram explaining the Maven anti-pattern of generating multiple jars from a single Maven project.
Both articles recommend adopting a modular structure to your code rather than fighting Maven's approach of decoupling large projects into a set of interrelated sub-modules.
Incremental publish approach
Start with looking at the arifacts you actually plan to share. Your mail suggests that the only file you're actually publishing is a large zip file containing 100+ jars and other files?
You could invoke the Maven command-line tool to publish this zip to the Maven repository:
mvn deploy:deploy-file \
-Durl=$REPO_URL \
-DrepositoryId=$REPO_ID \
-DgroupId=org.myorg \
-DartifactId=myproj \
-Dversion=1.2.3 \
-Dpackaging=zip \
-Dfile=myproj.zip
This approach can also be used to publish jars and POMs (containing dependencies). Eventually you'll be overwhelmed with the number of POMs to maintain.... AT which time it would be simpler to restructure the building of that jar into a sub-module.
Alternative to switching build technology
It's very difficult to walk away from a legacy ANT build. These often contain complex, custom and difficult to reproduce build logic. For such projects I recommend using Apache ivy to externalise 3rd party dependencies and share artifacts with other projects (who might be using Maven).
To that end I wrote an ant2ivy script for generating an initial ivy setup, based on the jars that already exist in the ANT project's directory (normally committed alongside the source).
Using ivy doesn't get you away from the fact that it's a good idea to create project sub-modules. However it does enable you to modernise your ANT build.
Update
Yes, there are Maven ANT tasks available. I don't use them because they based on Maven 2. I'm disappointed that we're still waiting for their Maven 3 replacement aether-ant-tasks (Only available from GitHub). Ivy is still the no1 choice for integrating non-Maven clients with a Maven repository
Well you can generate multiple jars out of one project.
Its not really considered best practice. Look at the supplied article and decide it yourself.
In the includes your are not limited to packages, however this surely makes it easier. :)
Related
I'm a bit confused between maven assembly plugin and build-helper-maven plugin.
I've also read in the maven documentation that The assemblies/archive created by the Assembly Plugin gets deployed during the deployed phase.Hence, they can be deployed to the remote nexus repositories.
The purpose of maven assembly plugin is to archive many things into one(say in tar.gz format).
However, the attach-artifact goal present within build-helper-maven plugin has the same role i.e.archiving,installing and deploying the artifact.
With that being said,why would anyone use both of them together? I've seen people using both of them together. Isn't one of the plugins an alternative choice of the other?
Kindly advise.
If you use maven-assembly-plugin you can create as you already mentioned any kind of archives (range from very simple to very complex structures) they will be by default be attached to your project which means they will be deployed into remote repositories in one go if you do mvn deploy with no supplemental configuration.
The build-helper-maven-plugin is intended to add an artifact (one goal of this plugin) which is usually not generated by Maven itself which most of the cases is a smell. If people using them together (in the use case to create an archive and attach it) this makes no sense.
Apart from that the build-helper-maven-plugin can also be used to add other source directories for example for scala, kotlin projects (other goals for example add-source etc.)
So those plugins are not alternatives they have different intentions/use cases.
I have a ant build.xml file , how can i directly create a maven pom.xml which is exactly equivalent of build.xml file ? I know that I can create a maven project and move the folder of build.xml to appropriate folder of maven directories, But is there any automated way of doing this ?
ANT and MAVEN are different so there is probably no such complete automation really.
Still there are some attempts to automate it (see: https://github.com/ewhauser/ant2maven/blob/master/ant2maven.groovy and its forked repositories).
Another approach may be to create a pom.xml file and use https://maven.apache.org/plugins/maven-antrun-plugin/ to include the ANT script in it.
The simple answer is no. There is no easy way to generate a POM.
In my opinion switching to Maven is best left to new projects with little or no legacy to defend. In short Maven is a highly opinionated build tool that follows a standardized build workflow. ANT, on the other, ANT is gloriously configurable... resulting in no two builds working the same way :-)
A secondary problem is that few ANT builds properly record the origin and version of their 3rd party dependencies...
In most cases you are better off keeping the existing ANT build logic and introduce dependency managment using a plugin like Apache ivy. This allows an ANT project to properly integrate with a Maven repository infrastructure. This further enables collaboration with other teams using alternative build tools like Maven, Gradle or SBT.
Related answers:
Migrating complex project from Ant to Maven - How to handle unusual folder structures?
Maven or Ivy? Which one is better with a system already in production? And the other differences?
I've inherited a few maven projects which have added a /dependencies directory to capture Java jar libraries that aren't part of the project war and must be installed by a DevOps into a Tomcat installation.
The libraries in this directory seem to fall into four categories:
"provided" scope libraries,
downstream dependencies of those provided libraries, and
discoverable implementations of api jars
"mystery" libraries, i.e., not available in an external repository, and maybe unsure where they ever came from.
Is there a strategy to get Maven to help manage these dependencies and perhaps fetch them for external install?
There are probably several strategies to choose from.
Number one: leave it as it is. If it works and the build is reproducible (on different environments) that seems one valid solution.
The "mystery" part of the build might not be more of an issue for new people working with it.
I think it is valid to create an own maven module to be delivered to the infrastructure team. This module can contain the jars in the /dependencies folder.
What you would need to do is create a pom.xml and add all dependencies currently in that directory (of course not the transitive ones). The magic ones would need to go in a repository proxy (nexus, artifactory, ...). If you don't have a maven repository yet: you want one! (its easy to setup and it does help a lot!)
I would then use the assembly plugin or some ant task to build the zip do be delivered. So the infrastructure team is able to just unzip / copy the files where they need to be. This step can then even be scripted (so the upload / unzip is done through SSH or something like that).
This is probably only one way to do it. I would assume to resolve the jar's in the /dependencies directory may be a bit of a pain.
The advantage is obviously that you document and simplify the management of those libraries. I would also assume if you update some of them it is easier across branches to merge since there are no binary files around. So it may be worth the effort.
I'm working on a project that has a reliance on a significant number of 3rd party jars; these jars contain both proprietary classes and custom/patched versions of existing libraries. I'm trying to figure out how to tie these jars into the maven architecture so as to be CI friendly.
My initial idea was to create an uberjar of all these libraries, and add that one uberjar to the maven repository, however I have not been able to figure out how to take this set of standalone jar files (that are not dependencies) to merge like that. There exists lots of documentation on how to uberjar a project and its dependencies, but not standalone jars.
I feel like i'm missing something basic, or maybe there is a better way. Any recommendations are welcome.
You would be better off to proceed as follows:
Set up a repository manager.
Write a shell script that runs mvn deploy:deploy-file for each of your jars, generating the GAV with a simple algorithm.
treat them like anything else.
To elaborate on Step 2:
G:A:V - my-company-name:name-of-jar:version-based-on-todays-date.
I want to create a maven project, which has to depend on a non maven project which in turn depends on 2 other non maven projects. I do not have ownership of any of the other projects and it would not be possible for me to change anything in those projects let alone the structure to conform to the maven structure.
I asked if I could just get jars -- but was told that because of multiple levels of dependency, it would be "difficult" -- although I haven't understood why.
Is this possible or should I just abandon the use of maven to create my project and go with a regular project with jars in the lib folder?
Inxsible
If you can go with a regular project build that means you must have access to the other project's jar files?
It doesn't really matter how the other project builds them, you can still gain more control over your own build process by loading the jars you depend on into a Maven repository.
I'd suggest using one of the following repository managers:
Nexus
Artifactory
Archiva
They'll give you management screens to uploading 3rd party jars, they'll also a more efficient way to use other Maven repositories like Maven Central.
Once you've got your Maven build process working, you could encourage the other projects to automatically publish their versions into your Maven repo.
They could use the ANT tasks provided by the Maven or Apache ivy projects. Worst case you just continue to load their libraries until they see the light :-)