I have a project that some ant files target to extract different packages (I'm the guy who comes and see this ugliness, not the one who did it).
So, one package, one ant, one jar.
And different OTHERS projects use one or more of this jars.
I can't touch the folder structure.
I have to migrate this (and the other projects) to maven, but other than make several poms that exclude all others packages and compile it's own, I don't know how to solve this problem.
I'm not very good with ant, but I read here that ant-task can install into the local repository, so it can make easy for the dependent projects to use those jars.
Can anyone can help me with an example of how to use the ant-task-plugin to achive this, or a better approach?
What I do and work for me was to add a new maven-jar project and change the source folder so it points to the mentioned folder.
Then I exclude the packages so it can generate the required jar.
Repeat for every jar I have to make this way.
Add this projects to the parent pom, so the can be created at once with the dependent projects.
Hope this help someone.
Related
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.
We are using maven for building the project. It's legacy and huge one.
We newly added few .keystore files to it's resources folder.
The problem is, once the build is done, the .keystore files are getting tampered [may be maven is trying to replace/search for some placeholders]. Since it's legacy one, the project structure is so much messed up and we don't have separate distributions or no other choice but to go with plain build.
What I want is, tell maven to copy these sort of files without touching them and keeping the build as usual like before.
Between, there's no explicit is mentioned in pom.xml, tried to doing with that as per this http://maven.apache.org/plugins/maven-resources-plugin/examples/include-exclude.html but it's messing up the project build.
I don't want to tamper the build, since it's legacy and huge one. We are using Ant plugin
Just switch off filtering for the respective <resource/> or add an <exclude/> for it.
After going through lot of sources, Found the solution http://maven.apache.org/plugins/maven-resources-plugin/examples/binaries-filtering.html
Thanks :)
I am completely new to Maven and come from an ant world. I am having lots of trouble something that might be really trivial.
I want to have a maven project that is made out of non-code items that I want to ship along my jars. These items are DDL scripts, installer scripts a couple of utility scripts, readmes etc.
I do not want to use "resources" in the corresponding java projects since I do not want them living in the actual product jars. I want them shipped as separate artifacts that just like any other jar.
It is acceptable to bundle them up in a jar or zip, etc.
Is there a way to do this?
Thanks!
Use the build helper plug-in to add additional artifacts to the Maven module.
Check out the answer to the following question
Ok, I found it and it was pretty simple. Just created a project added a simple pom with no plugin pacakging jar and I create the proper dir structure
src/main/resources/...
This builds it into a jar
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. :)