Develop Reference

Jar not downloading from maven

I have a scenario, where in my maven repository, the required JAR is available, but it is not inside the version folder, instead, it is directly under the group.
For Example I need test-1.0.0.jar
In my Maven Repo, the jar is placed in the path like below,
com.java.test
----test-1.0.0.jar
But it is supposed to be like the below,
com.java.test
---1.0.0
------test-1.0.0.jar
Because of this, the jar is not downloading when I do maven install. Are there any workarounds to get the jar downloaded without changing the maven repository structure?

I think there is a problem with pom.xml of test.jar or jar uploaded to the remote repo incorrectly.
In that case, if you have control over test.jar codebase or remote repo, you can figure out what is wrong and fix it. If you don't have control over them, you can treat like it is 3rd party jar. Using below command you can populate the jar into your local maven repository.
mvn install:install-file
Basically, this command reads this dependency and installs into your local maven repository within the constraints you provided as a parameter.
Below example have been taken from Apache Maven Documentation.
mvn install:install-file -Dfile=<path-to-file> -DgroupId=<group-id> -DartifactId=<artifact-id> -Dversion=<version> -Dpackaging=<packaging>
But keep in mind, it is just a workaround for your local development. In the long run, the actual problem needs to be resolved. As mentioned earlier, either pom.xml of test.jar should be fixed or structure of remote repository should be corrected by re-uploading the jar.

You would need to re-upload your jar to the right path in Nexus, using mvn deploy:deploy-file :
In Windows:
cmd /v /c "set g=com.java&& set a=test&& set v=1.0.0&& mvn deploy:deploy-file -Dfile=!a!-!v!.jar -Dpackaging=jar -DgroupId=!g! -DartifactId=!a! -Dversion=!v! -DrepositoryId=your-nexus-id -Durl=https://nexus.your.comany.com repository/public"
You can execute that in the folder where the jar is, even without any pom.xml.

Jenkins job with multiple maven goals

I was assigned to maintain issues in a system created before time.
The system uses Jenkins as system integration tool and unfortunately I do not have previous experience with it.
The problem is following:
When following the steps for local build (via console) the archive files (.jars, .ear) are created correctly.
When using Jenkins job for this, one of the .jar files (call it module-one.jar) included in .ear does not contain a folder with .xsb and .class fiels.
So .ear application becomes incorrect and ClassNotFoundException is thrown.
Steps for building application locally:
cd my_project_path
cd ModuleOne
mvn xmlbeans:xmlbeans
mvn install
cd ..
mvn clean install
The Maven section in Jenkins contains only this goal clean install (the screenshot below section "Build"):
So what I wonder is how to add the following maven tasks in Jenkins job to be executed on ModuleOne:
mvn xmlbeans:xmlbeans
mvn install
My idea is to go to "Pre Steps" section and add following maven goal:
mvn xmlbeans:xmlbeans install
My questions are:
1. If I am on the right way how to define the goal "mvn xmlbeans:xmlbeans install" to be executed exactly on ModuleOne?
2. If I am not on the right way are there at all any solutions to do this with Jenkins?
Here is screenshot with my suggestion for "Pre Steps". In the current configuration (that skips to add proper dirctory with .xsb and .class fiels to ModuleOne) this section is missing, but the section "Build" is as it is used now.

I think your approach is good! But on "pre steps":
Remove "mvn" from Goals
Use Advanced configuration in order to specify the path of your pom.xml

Create a list of artifacts that are build by a maven project

Is there a way to create a list of all artifacts that are created by running
mvn clean install
similar to the output of :
mvn mvn dependency:tree/list

There is a way to do that:
mvn -q -Dexec.executable='echo' -Dexec.args='${project.groupId} ${project.version} ${project.artifactId} ${project.packaging}' --non-recursive exec:exec
If you want it for all artifacts in your project including sub-folders remove --non-recursive.

It can be achieved by writing a maven extension by extending org.apache.maven.AbstractMavenLifecycleParticipant which will run at the end of maven build afterSessionEnd and using MavenSession.getAllProjects(), Artifact.getArtifact(), getAttachedArtifacts(), getGroupID(), getArtifactId(), getClassifier(), getType() you can loop through all the projects and get the details for each artifact generated.
make sure to set the correct profile(if you have any) to not miss any info about the artifacts like reported here get classifier/id of maven assembly artifact

Maven Spring project: Adding a custom library using Eclipse IDE [duplicate]

I want to add jpoller.jar as a maven dependency, so I edited my pom.xml file to include it:
<dependency>
<groupId>org.sadun</groupId>
<artifactId>jpoller</artifactId>
<version>1.5.2</version>
</dependency>
Now, as expected, when I compile from the command line I get an error because jpoller isn't in any of the repositories I have listed in my pom, nor could I find one for it. Although I could create a repository for it, I'd rather not at this point. Thus, I get the following error:
[INFO] Failed to resolve artifact.
Missing:
---------- 1) org.sadun:jpoller:jar:1.5.2
Try downloading the file manually
from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.sadun -DartifactId=jpoller -Dversion=1.5.2 -Dpackaging=jar -Dfile=/path/to/file
How can I do this from the M2Eclipse plugin on machines where the maven CLI isn't available?

How can I do this from the M2Eclipse plugin on machines where the maven CLI isn't available?
Well, simply do it from Eclipse. First, get that jpoller jar and save it somewhere on your file system. Then, in Eclipse, from the top bar, Run > Run Configurations... then right-click on Maven Build and configure the New_configuration freshly created:
Select an arbitrary Base directory
Fill the Goals with install:install-file
Add parameters for each required parameters, without the -D prefix (e.g. file as Parameter name and /path/to/file as Value and so on for groupId, artifactId,packaging and version).
And run this configuration. Or... just install Maven.

The install command automates the creation of a folder structure in ~/.m2 and pom.xml file for the dependency artifact. This can be done manually. OR You can simply copy the ~/.m2/{group}/{artifact} folder from a machine that does have mvn installed.
Edit: This tool will help you find public repositories for a given dependency.
Edit2: See http://maven.apache.org/guides/mini/guide-coping-with-sun-jars.html for an explination of the process of installing dependencies manually. Note that most sun jars are now available in the java.net repository http://download.java.net/maven/2/

a quick way to maven install a lib folder

is there a quicker way to maven install say a complete lib folder to maven dependencies rather than the individual command for each jar:
mvn install:install-file -DgroupId=third-party -DartifactId=app-eventinfo -Dversion=1.0 -Dpackaging=jar -Dfile=EventInfoToOrder.jar
Is there a way I can say this is a folder of dependencies or a little work around in eclipse where I trick maven into using a user defined library as a dependency.
Yes I have a lot of folders that have been sitting on my buildpath which I must install to my local repo.
Cheers for reading :)

The problem is not about the folder contents, but specifying the correct values for groupId, artifactId and version.
If you are ok with random values for this, then you could write a dirty batch file/shell script to do this.
Otherwise, the time you spend trying to automate this (by having a mapping of groupId, artifactId and version for each jar in your folders), you can arguably do mvn install:install-file manually.
A better option would be to review your dependencies and see which are not available in maven repo and only install those. The remaining will be downloaded by maven on its own.

There is no standard way of doing this as it would go against Maven's philosophy of managed (versioned) dependencies.