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.
Related
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 looking for a way to create an executable jar file for my JavaFX application.
I'm currently using the zenjava maven plugin and I use the jfx:jar goal. Doing this, all the dependencies are generated on a folder called /lib.
The problem arises when one of the dependencies (a separate project handled by another group) is updated, I would need to rebuild my jar again.
Is it possible to just maybe refer to the dependencies using a pom? (not point to the lib) So I would only update the pom every time a dependency is updated?
Thanks in advance!
Short answer: nope, not possible
Long answer: the JavaFX-Maven-Plugin is usable for development (via mvn jfx:run) and deployment (via mvn jfx:jar or mvn jfx:native).
You are generating a potential deployable package, which already contains everything needed to execute on some targeted machine. You would have to encapsulate your javafx-application with a "pre-loader" which downloads all your required stuff to be executable.
What is the idea behind distributing an application which needs some internet-connection to gather all the required dependencies?
Disclaimer: I'm the maintainer of the javafx-maven-plugin.
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.
I want to use Maven for building my next Java Project.
So I have some questions about Maven before starting right off.
Does Maven need to be installed? Or can Maven binaries just be copied to a system (Windows) and be used in the same way.
Setup a Maven project required?
From a Maven tutorial i've seen that the first step in Maven is to setup a Maven project like this:
mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
Why is that? Is writing a POM file not enough when I only want to compile some Java files and include some jars?
Question 1 (Installation):
Well it mostly is simply copy, add to path, and run.
However in real world there is a bit more than that. For example,
- in a company, you may want to have a company central repository proxy. You will need to do extra set up in either HOME/.m2/settings.xml or MVN_DIR/conf/settings.xml (Wish I remember the path right :P )
You may want to put local repository in a different directory in some case, you will also need to change settings.xml.
In order to have building of big project works, you may need to adjust M2_OPTS environment variable.
etc...
All these things are extra manual installation work you may need (Not difficult though)
Question 2 (Archetype):
You are actually right. You can simply write your own pom.xml and forget about archetype (That's what I was doing in the past too :) ). You can think Archetype as some template-project-generation feature, so that you may generate some pre-defined project types, and the essential project directory structure, required dependencies and settings in POM are all done for you. Of course you may even provide your own archetype, so new projects in your company can make use of them to conform with guideline or standard you want.
Does Maven need to be installed? Or can Maven binaries just be copied to a system (windows) and be used in the same way.
Maven comes bundled as a zip archive that you just need to unzip. You then need to add the bin directory to the PATH environment variable and you are good to go.
Setup a Maven project required? From a Maven tutorial i've seen that the first step in Maven is to setup a Maven project like this:
mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
There are multiple ways to create a Maven project. However, it is important to remember that a Maven project only comes down to having a single pom.xml file. This file will be located at the root of your project. So you are right when you say that "writing a POM file is enough".
Now, since Maven is a tool that is built under the convention-over-configuration principle, several utilities have been created to help adhere with the basic conventions of Maven. One of those utilities is the maven-archetype-plugin, which is invoked by the call to mvn archetype:generate. This utility will create a basic pom.xml file along with the standard directory layout.
If you are using an IDE, you could also create a Maven project by using the corresponding Maven plugin of this IDE (for example for Eclipse, this is the M2Eclipse plugin).
Answer to 1st question:
Maven is available in distributed binary format.You just have to download it and extract it in your local machine. And then, you have to create one user variable named M2_HOME(sometime M2_OPTS is also required) and add it to PATH variable. That's all you need to set up basic needs.
If your system is inside some proxy network then you have to perform one additional settings. That is to copy secuirity xml, which is available inside the downloaded files, and modify the elements values inside it according to your network.
Answer to 1st question:
For the 1st time you need to use the command you specified. Once you get the file-structure, you may reuse it based on your need. But remember to follow predefined file-structure else you would be surely in a trouble.
However,it's always advisable to create the projects using maven command as it would do many things for you which you might have to do manually if you opt for manual maven project creation.
I am trying to build a project using Maven but I don't know Maven.
Anyway I had a problem and I found in a link to use an older version of Maven. So I did, since the instructions for the project were about 2.0.9 anyway.
But now I am not sure how to proceed. I see under my user.home directory a .m2 folder with a repository directory.
Should I delete this or not?
The .m2 folder contains the downloaded artifacts and some other repository info, which do not depend on the used maven version. So you dont need to delete anything, just use the maven binary of your choice.
EDIT: the contents of the artifacts - .jars, .poms, .boms etc. are defined by the artifacts themselves which are the accesible through repositories/catalogues. The .pom of your project references the needed artifacts. The maven binary downloads the artifacts (and does many other things which are OT here) to your local cache - the .m2 directory. The point is, no matter what version of the maven binary you use, the artifacts remain the same.
You surely can delete your repository. As long as you have an internet connection maven will simply download the artifacts again. But there is nothing to be gained by the removal except a longer initial build time and some traffic.
Sometimes it does make sence to delete certain metadata from the repo, like the .lastUpdated files. It is only advisable if maven is unable to find a dependency which you know for sure is in your repository. You can then run find ./ -name "*.lastUpdated" -exec rm {} \;.