Websphere offers a set of provided jars, including com.ibm.ws.ejb.thinclient_8.5.0.jar, com.ibm.ws.batch.runtime.jar, com.ibm.ws.orb_8.5.0.jar, etc.
In the ANT build process, some people had these files on the classpath. Now we are moving to Maven, and I am not sure what I should do with these files:
If they should be part of the build process, I need to put them into the repository. But how should I get or generate proper POMs for them?
If they should not be part of the build process, what are proper replacements?
If you are using a company maven repository as a proxy to maven central, the best thing to do is to make these jar files available there:
mvn install:install-file -Dfile=<path to the jarfile> -DgeneratePom=true -Dpackaging=jar -Dversion=<version> -DgroupId=<groupId> -DartifactId=<artifactId>
In such a case the groupId is usualy composed by your company prefix and then the base package of the artifact. The artefactId would be the last part without the version. For example for com.ibm.ws.ejb.thinclient_8.5.0.jar, the version is 8.5.0, the artifactId thinclient and the groupId something like com.example.thirdparty.com.ibm.ws.ejb.
The same approach works as well if you are the sole developer and install these artifacts in your local repository.
See also the official documentation
Another approach would be to have these files as part of the project and reference them through a local path and install it from there either using the maven-install-plugin or by issuing the steps from the first approach as part of the build process. See Maven and adding JARs to system scope and Maven: add a dependency to a jar by relative path.
Disclaimer: I always used the first option, as this seems to be the proper way.
Try the "was_public" JAR and POM shipped along with WebSphere Application Server traditional, starting with Version 8.
See here.
Related
When creating spring-boot projects by using start.spring.io, some maven wrapper files get included:
mvnw
mvnw.bat
Should these files be ignored when committing to a git repo?
A mvnw Maven wrapper script allows you to run a Maven command without having Maven installed and present on your PATH. It does by looking for Maven on your PATH and, if not found, it downloads and installs Maven in a default location (your user home directory, IIRC).
They are a convenience but they are not necessarily part of your project, not in the same way as your project code and configuration is. In other words:
Any given mnvw file could be used for multiple, unrelated projects
A mnvw file will almost certainly not be different from one version of your project to another
On this basis you could make a case for not committing mvnw to your code repository.
However, including a mvnw script in your repo does have these benefits:
Allows anyone who clones / checks-out your repo to build your project without having to install Maven first.
Ensures that the version of Maven in use is the version with which your project is compatible.
On this basis you could make a case for committing mvnw to your code repository.
So, there are pros and cons on both sides. Just choose the side which best fits the needs of those who will use your repo. Either:
Include something in your readme which makes clear that (a) Maven is a prerequisite and (b) which version of Maven is required.
... or:
Include a mvnw script.
It depends, if you want to use the Maven wrapper or not. If not, then you can delete those files. If you want to use it, then you have to commit the files in the repository, otherwise it doesn't make sense to use it.
We have a git project that has some 3rd party jars which are not available in any Maven repo and are in a "lib" folder in the project. I need to include them for compiling, building and then package them into the WAR in WEB-INF/lib.
I cannot add them as a local maven repo from the command line because this projects needs to be buildable for anyone cloning the repo without requiring them to run extra commands (I have no way around this requirement).
I saw some people suggesting System scope but that then Maven won't package them into your WAR:
<dependency>
<groupId>com.roufid.tutorials</groupId>
<artifactId>example-app</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${basedir}/lib/yourJar.jar</systemPath>
</dependency>
How do I get these jars to be used for compiling/inspection, building and then packaged into the WAR?
You can use :
System scope but make the packaging yourself via assembly plugin
A maven repo along with your project (i.e. maven repo on-the-fly, basically same as local repo but without having a extra moving part to worry about because this repo follows your project).
For Maven repo on-the-fly option, you can do as described here (which is, take any already existing Maven repo, which already contains your needed jars, such as your local one, put it in your project, and then reference this repo from your project using relative paths).
I'll assume you've verified that whatever mechanism you might use to distribute these jars would be in compliance with the relevant licenses. If it would, then it seems there would be little reason for the jars' creators not to provide for official Maven distribution, so your best option might be to lobby for them to do that. But if not, and yet for some reason they'll allow for you distributing the jar (either through cloning of your repo, or via a separate Maven repo you maintain):
There are several ways. I give preference to approaches that don't put the jars in the git repo.
Publish a Maven Repo
So it's possible to host a public-facing repo and serve the artifacts that way. The pom can add your public-facing repo to the build, so that those who clone can build without having to run any special commands.
Running your own repo isn't terribly difficult. The OSS versions of Nexus or Artifactory jFrog would probably be perfectly capable.
But, if we're assuming the authors' refusal to publish their own jars via Maven means they don't want them distributed that way, then there's no reason to spend much time on the details of this option. So moving on...
Distribution in the Git Repo
I guess this is what you're doing, though again if Maven distribution violates the license I'd make sure you're splitting hairs the right way in thinking that this doesn't.
So the question would be how to get Maven to deal with the artifacts distributed in this way, and again there are some options.
Your objection to putting the jars in the local repo is that it would require extra commands of the user; but actually this could be automated in the "validate" phase of the build. Binding install:install-file to the validate phase should work.
Alternately, your objection to using system scope is that the file isn't copied into the final war. You might be able to use the dependency plugin to force the issue, but I'm not sure of that. What I am sure of is you could treat the directory containing the jars as a web resource with suitable configuration in the war plugin. (You'd want it to be treated as unfiltered and to map to the WEB-INF/lib folder.)
In any case, if you distribute jars (or other large binaries) in the git repo, I strongly recommend you look at git lfs. This will require one-time configuration by each of your users, but it will prevent your repo from gradually becoming bloated and unusable.
Use forward slash (/) to backslash () in the systemPath.
<dependency>
<groupId>com.roufid.tutorials</groupId>`enter code here`
<artifactId>example-app</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${basedir}\lib\yourJar.jar</systemPath>
I'm converting an existing Eclipse-based web project to a Maven-managed one.
Since the project has lots of dependencies, many of which are custom (they're either internally made or they've been taken from sources that have no public repository), is there some 'magic' Maven POM setting that will let me load every jar from WebContent/WEB-INF/lib and make the project work as before right now, so that I can configure each dependency and do the necessary refactoring to turn it to a proper Maven project with a little more time and care?
I have already seen this question, but the project must continue to compile inside Eclipse, so - or at least I guess - it is not just a matter of using the Maven war plugin
What you want to do is called "installing" your non-mavenized JARs into your maven repository. This can be a local or remote repo that you host.
The command to install to your local repo is something like this: mvn install:install-file -Dfile=My-lib.jar -DgroupId=com.mycompany -DartifactId=My-lib -Dversion=1.2.3 -Dpackaging=jar
You'll want to review the various options for install to suit your project.
Once the non-mavenized dependencies are installed to your repo you can add them to your pom like any other maven dependency. They will be fetched from your local repo.
You will have to set up your own remote repo (like Artifactory) or install each plugin for every developer and CI server in your environment for others on your team to build the project. I strongly reccomend Artifactory, it makes it easy on your and your team to use maven and get dependencies.
I have 2 Projects namely Project_1 and Project_2.
Both projects are Maven and I am using Netbeans.
I want to include the jar of Project_1 in Project_2 which I am doing like this.
The problem is when I include the jar I do not get any compile time error, however I get a NoClassDefFoundError exception at runtime.
When I include the Project_1 in Project_2 by performing the steps mentioned here. (The Open Project example). I do not get any errors. Neither runtime nor compile time.
Can you please explain me what am I missing here?
Update
Project_2 is deployed on a Server which is not in my local machine however Project_1 is in my local machine.
Inclusion of Project_1 into Project_2 as a project was done for testing in my local machine.
First of all, a good rule of thumb to adopt is never use the system scope and system path to pull in dependencies. In my experience there's always a better way :-)
If Project_2 depends on Project_1, then first install it's jar into the local repository:
cd Project_1
mvn clean install
Watch the output you'll discover the jar is placed somewhere under the following directory:
$HOME/.m2/repository
Once this is done the jar will be available as a normal dependency to the second build
cd Project_2
mvn clean compile
The local repository ensures the projects are now decoupled from each other. Assuming you're using snapshot revisions of Project_1, the Project_2 build will always retrieve the latest revision built and tested.
Update
You should use a Maven repository manager to share jars between machines/teams. Recommendations are contained in the following answer:
Share jar of the module with another team
How to configure Maven to use a repository like Nexus is described in it's documentation.
As described in the deploy plugin documentation you'll need to add a distributionManagement section to your POM (detailing the repository URL) and then upload the project's jar to your repository as follows:
cd Project_1
mvn clean deploy
Here's the problem: I love using Maven, as it completely simplifies development and dependency management. However, I'm working with a server which isn't Mavenized, so I can't just add it as a provided dependency. Is there a way to simply specify an additional library folder and add it to the Java compiler classpath, or would I need to actually create an entire local Maven repository for this? I know it completely limits my portability, but I'm okay with that. Thoughts? Also, after compiling, I'll need to copy all of my non-provided dependencies to the local server lib directory, I assume I can use the copy-dependencies plugin to move everything over.
Download Nexus for free from Sonatype, or Artifactory, or any of the other repository managers.
The alternative is to learn about install:install-file to shove jars into your personal local repo. However, having a full repo as above has so many advantages (not the least speed via caching) that it's easier to just install one.
You can use a Maven2 repository implementation such as Nexus, Artifactory, or Archiva.
You can create a simple POM for the non-maven dependency you are working with and use the deploy:deploy-file goal to deploy it to the repository.
If you just need the dependency locally you can use the install:install-file to install the dependency in your local repository. This approach requires nothing more than maven be installed on your machine.
If you just want to add libraries to the path of your build without worrying about repositories you can declare them as system dependencies. I do not recommend this approach but it should work fine.