Main Goal: deploy a project as jar and eclipse-plugin
current state: project builds fine as jar package
Now i want to create a second project which wraps the jar project as eclipse plugin
use tycho-maven-plugin to create eclipse-plugin
add the jar of the original project (with copy-dependency)
add an Activator
export packages from jar
create correct MANIFEST.MF
i tried to copy the jar with copy-dependencies bound to create-resources. This works as long the jar is found in repository, but the local project gets ignored.
This results in a build failure since the jar is not found.
Is it possible to tell copy-dependencies to take the jar from the target directory of the project? Or should i use some other method than using tycho?
Edit:
I solved my problem with 4 projects:
normal project (nothing special here)
the wrapper project using tycho maven and copy-dependencies.
bound copy dependencies to some goal before compile (e.g. generate-resources). Excluded all artefactid which were set as dependency in the MANIFEST.MF.
a prepare project, which calls the normal project and installs it into the repo. This is needed because the tycho-maven-plugin is bound to validate and it is not possible to call the exec plugin beforehand (at least not easy).
a multi module project which calls the prepare project before the wrapper project.
Build your local project (which artifact was missed) with "mvm install". It will be deployed in your local repository ($USER_HOME$/.m2/repositories). After this dependency should be resolved.
Alternatively you can "mvn deploy" if you have local company maven repository like Artifactory or Nexus.
Related
Is it possible deploy an artifact (.ear) into a application server (AS) without obtain its dependencies from a repository?
Let's me explain: the maven project I'm trying to configure for deploy into a AS has 3 modules:
Web (.war - front end)
EJB (.ejb - back end)
Entity (.jar - entities classes)
These modules are wrapped into a EAR module and none of then are available in some repository (like Nexus or JFrog Artifactory). When I try to use Cargo Maven plugin or JBoss Deployment Maven Plugin, both notify that cannot resolve dependencies for these modules.
UPDATED (03/01/2019)
The issue is similar to that quoted in items 6 and 7 of the following link: http://webdev.jhuep.com/~jcs/ejava-javaee/coursedocs/content/html/ejb-basicex-eardeploy.html#ejb-basicex-eardeploy-testmodule
It's a workaround but worked. Instead of the project depends on an internal repository (like Nexus or JFrog Artifactory), it's possible defines a folder as a repository on the local machine using the Maven's parameter -Dmaven.repo.local. Thus, the plugin to deploy the artifact also can use this property and obtaining the others artifacts.
That is, to build the application on the current folder:
mvn -Dmaven.repo.local=. package
To deploy the application (.ear, in this case) using Cargo Maven Plugin, for example, without depending on an internal repository:
mvn -pl app-ear/ -Dmaven.repo.local=. cargo:redeploy
OBS: Using the maven.repo.local property, the folder defined as value will be fill with all dependencies of the project. In my case, it isn't a problem because this commands are been used on a continuous integration pipeline and all files and folder are discard on the final.
One project A is added in project B as a source.
I want to add in POM.xml of project B.
1-A is non maven project.
2-B is Maven project
How non maven project can be added as a dependency in maven project as a dependency.And I don't want to run it as a separate project and place the jar in local repository.
You need to put the "non-maven-jar" into the local (or a remote) repository. You can either build it and use mvn install:install-file to install it locally (or the deploy plugin to use a remote repository) or you need to change project A into a Maven project.
Technically, it is also possible to include a dependency by a path (<systemPath>), but this is not recommended.
I have 3 gradle projects, projectA, projectB, projectC. All of which build a jar file named projectX-0.0.0.jar. On my jenkins server, all of these projects deploy these jars to my companies artifactory.
In projectA, I have multiple compile dependencies used throughout my entire project. Then in project B, I include project A by stating: compile group: 'com.company.projectName', name: 'projectA, version '0.0.0' So I can use these dependencies (i.e. slf4j) I do the same for projectC to include projectB dependencies, which in result includes projectA's dependencies.
This works great for our jenkins servers on deployment, after I have pushed the code to the server, however when trying to test locally I can not get the dependencies to update for testing my code.
I have tried:
Updating the gradle cache that downloads project A from artifactory with locally built project A jar. Located in C:/users/username/.gradle/caches/path-to-jar.
Removed the compile group: 'com.company.projectName', name: 'projectA, version '0.0.0' and replaced it with compile files('libs/projectA-0.0.0.jar'), placing projectA's jar within a lib folder in projectB
Using gradle offline mode in IntelliJ and repeating #1
Going offline completely on my pc and repeating #1
With all 4 attempts above I still have not been able to resolve dependencies declared in project A for project B.
My goal is to be able to update a compile,testCompile,runtime,etc. dependency in my projectA.gradle file, and then run my projects down my pipeline to ensure this update effects the dependencies in my project as I intended.
You need to update the .jar and .pom file within your gradle cache. The .jar file contains the source code while the pom contains the dependencies you brought in the previous project. Using a gradlew clean build install you can create the jar and the pom.
So to solve your problem, do a gradle build clean install on project-a. Grab the jar and pom from the build file generated and replace the project-a.jar and project-a.pom within the cache. Then do the same for project-b and you will see the changes in project-c after a gradle refresh.
I have a dependency application jar from other maven applications,and currently added it to my application path,
I want to know how this application related jar can be automatically moved my local repository folders.
I think it should be placed in somewhere in maven project folder structure so that when maven build the module it automatically moves to the repository.
Dependent project:
If built with maven, you would issue a mvn install, when building it.
If not built with maven, install it locally using mvn install:install-file
http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html
Forgive me if this is remedial, but I am still new to Maven and it's functionality.
In my project, when it "builds" and gets to the compile phase, it will create a target directory with just compiled libraries and update (or create if not there) the local .m2 directory.
When I get to the "test" phase, I want it to build against the target directory's library files, and not the local .m2 directory.
Any hints, recommendations, or suggests would be greatly appreciated. Thanks!
Maven has this concept of “the reactor”, which is just a fancy term for the list of projects being built. At the start of a Maven build, and at the end, Maven prints out this list of projects (using /project/name if defined or groupId:artifactId otherwise).
For each project in the reactor, Maven maintains a list of artifacts that have been attached. By default, each module's pom.xml is attached, and as each plugin runs, they have the option of attaching additional artifacts. Most plugins do not attach artifacts, here are some plugins that do:
jar:jar creates a .jar and attaches it
war:war creates a .war and attaches it
source:jar creates a .jar of the source Java code and attaches it with a classifier of source
java doc:jar creates a .jar of the JavaDocs ad attaches it with a classifier of javadoc
There is also a default primary artifact (this is the one that gets replaced by jar:jar) which is actually a directory and not a file, as such it will not get installed or deployed to the local repository cache or a remote repository.
So when in the reactor, and a plugin that attaches the primary artifact has not run yet, and another plugin asks for the primary artifact, it will be given the directory ${project.build.outputDirectory}. If after the primary artifact as been attached, then that primary artifact will be provided.
The test phase happens before the package phase, so will use the directory and not the .jar. The integation-test phase happens after, so will always use the .jar.
Things get more complex in a multi-module project (which is where my long intro should help you out)
Maven has to build the test classpath. If one of the dependencies is within the reactor, Maven will use the artifact attached to the reactor. Otherwise it will use the local cache (populating from the remote repositories if necessary).
When you run
mvn test
In a multimdule project from the root, there is no replacement of the default (directory-based) artifact, so intra-module classpath will be to the target/classes directories.
When you run
mvn package
In the same project, however, because each module completes its life cycle sequentially, all the dependent modules will have swapped in their .jar files as their attached artifact.
All of this should show you that Maven is doing the sensible thing. Hope this has helped.
The test phase is going to execute tests on your project. The project won't reference itself via the dependency mechanism. Only dependencies will be referenced via your local repository, i.e. .m2/repository
Also, it's not the compile phase that installs the artifact to the local repository, it's the install phase. And, then, there's a later phase, called deploy, that will deploy the artifact to a remote repository, provided you have a remote repository configured as the deploy target. Note, install and deploy are nearly identical phases except install is a local only thing; thus, it's the common build phase to hit when doing dev environment work. Normally the build server will do the deploy stuff.