I have created a maven plugin. I have some classes in the plugin, which I want to make available to the plugin client after execution.
The problem is that a project of type maven-plugin is also a jar, so I simply can't use maven-jar-plugin and maven-install-plugin to install the jar (having the classes) as a dependency.
Any ideas on how to do this?
I have created a maven plugin. I have some classes in the plugin, which I want to make available to the plugin client after execution.
I see two options:
declare a dependency on the plugin in the client:
<dependency>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.0.2</version>
<type>maven-plugin</type>
</dependency>
put the shared classes in a shared module (with a packaging of type jar) and declare a dependency on this shared module in both the client and the plugin.
Personally, I find the second option cleaner (and you won't get all the transitive dependencies of the plugin on the classpath).
Related
I just finished converting one of our in-house framework projects from ant to maven. The maven build runs fine, and deploys to our repository with no issues.
The problem is when other projects try to consume the framework, it does not work. The only thing downloaded is top level framework pom.
I have tried adding some dependency entries to one or more of the various modules, but no matter which one I add, I get a circular dependency error. I also tried creating a 2nd top level pom file with no modules and a few dependencies to overwrite the one in the repository manager. This causes some of the dependencies to be downloaded, but then the maven build will hang in random places. based on windows task manager, it looks like its in an endless loop. So a 2nd pom file does not appear to be the answer (or im doing it wrong).
my framework pom file looks something like this:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>framework_snt</groupId>
<artifactId>SFP</artifactId>
<packaging>pom</packaging>
<name>SFP framework</name>
<version>6.3</version>
<modules>
.... 50+ modules here
</modules>
and then the usual properties, dependency management and pluginManagement entries for a top level pom.
in the consuming module I just have the following:
<dependency>
<groupId>framework_snt</groupId>
<artifactId>SFP</artifactId>
<version>6.3</version>
<type>pom</type>
</dependency>
This is in the top level pom so all submodules have access to the framework libraries to make it easier on the developers.
How do I set things up so so all the dependent jar files will be downloaded by my consuming projects ?
It sounds like your framework project produces several jar artifacts, one for each child module, but no jar artifact for the parent project. Thus, declaring a dependency on the parent project's pom is not what you want to do. Instead you need to declare a dependency on each of your framework project's child modules.
I have a similar setup where I have a "toolkit" project with several modules (each producing a jar artifact). Then in my other projects I declare dependencies on whatever modules I need to use. I do not, however, declare a dependency on my "toolkit" parent projects pom file. Instead I just declare dependencies on the child modules jar artifacts.
<dependency>
<groupId>com.mycompany.toolkits</groupId>
<artifactId>file-utils</artifactId>
<version>1.0.0</version>
</dependency>
Notice that my dependency declaration points to one of my child module's and does not declare <type>pom</type> like you did. If you wanted to be really explicit you could declare <type>jar</type> instead.
The framework pom as you call it is the parent pom of your multi-module project.
While the modules can depend on each other, it cannot depend on this parent pom. This is what is possibly causing the circular dependency.
You will need to relook at your modules and identify which modules depend on which and suitably specify the dependencies. Also, these dependencies are typically jar dependencies - a packaging which will contain sources and resources.
Maven By Example is one of the many resources available which gives further information.
I have a dependency in my POM that needs to be set to "provided" so it is not included at compilation, but it can still be referenced within my project. I would like the same dependency to have a scope of "test" when I go to run tests so I do not have to manually add the jar to my classpath. Is there a way to do this or achieve similar results?
Reasoning behind this is that I have some common jars that are provided in my JBOSS lib directory, so I want to use these and keep the "provided" scope of them for the war that is built. However, when I run JUnits from the command line, I want to use the jar from the repository without manually adding it to my classpath.
Thanks in Advance
From maven documentation:
provided This is much like compile, but indicates you expect the JDK
or a container to provide the dependency at runtime. For example, when
building a web application for the Java Enterprise Edition, you would
set the dependency on the Servlet API and related Java EE APIs to
scope provided because the web container provides those classes. This
scope is only available on the compilation and test classpath, and is
not transitive.
I checked this works for me in maven 3.0.3. Had the same issue that i needed to have a servlet dependency while compilation and test but not compiled in because it ships with the application server distribution.
You could use a profile that either declares those dependencies as test or as provided - depending on what is more convenient for you:
<profiles>
<profile>
<id>whatever</id>
<activation>
<property>
<name>env</name>
<value>whatever</value>
</property>
</activation>
<dependencies>
<dependency>
<groupId>yours</groupId>
<artifactId>yours</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>
</profile>
<profile>
<id>test</id>
<activation>
<property>
<name>env</name>
<value>test</value>
</property>
</activation>
<dependencies>
<dependency>
<groupId>yours</groupId>
<artifactId>yours</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
</profile>
</profiles>
Those profiles get activated by setting the property env but there are other ways, f.e. default activation - have a look here for that.
Try declaring the dependency twice, once with each scope. Works in Maven 2.2.1.
Confusing things happen with dependency resolution, when the same artifact is in the dependency tree twice with different scopes, but I don't think it should be a problem in your case.
Have the same issue, reason why i need two scopes for the same dependency is on phase integrating test i use jetty-plugin for run rest service, and make some JUnit testing while jetty is running, but i compile my package for jboss as, where i already have "resteasy-cdi", than absent for jetty servlet container...I have no found solution yet.
Use the maven-surefire-plugin to run your junit tests. The scope of provided will also make it available on the test classpath.
Please find the exact meaning of scopes in Maven
I refered to Maven http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
Dependency scope is used to limit the transitivity of a dependency, and also to affect the classpath used for various build tasks.
There are 6 scopes available:
compile:-
This is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects.
provided:-
This is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime. For example, when building a web application for the Java Enterprise Edition, you would set the dependency on the Servlet API and related Java EE APIs to scope provided because the web container provides those classes. This scope is only available on the compilation and test classpath, and is not transitive.
runtime:-
This scope indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath.
test:-
This scope indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases.
system:-
This scope is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository. import (only available in Maven 2.0.9 or later):- This scope is only used on a dependency of type pom in the section. It indicates that the specified POM should be replaced with the dependencies in that POM's section. Since they are replaced, dependencies with a scope of import do not actually participate in limiting the transitivity of a dependency.
We have a mother-ship project with several modules:
foo
+ foo-core
+ foo-resource
+ foo-util
+ foo-whatever
I want to allow developers to include the core, resource, and util modules as dependencies (excluding the -whatever module). I know that I can specify that they include each dependency, but it would be nice to allow for them to just specify something like
<artifactId>foo-sdk</artifactId>
And get everything that they need to develop a foo. This has the added advantage that it gives us the power to add (or remove) what goes into the sdk.
It would be best if foo-sdk was not just a jar with the other jars jammed in it. I'd rather it be a pom that simply points to the other artifacts.
I feel like I've seen this done before but can't find instructions to do it. I checked out Maven Assembly Plugin but it doesn't look like this is its intended use.
You can group dependencies in a project with a packaging of type pom. From the Maven book:
3.6.1. Grouping Dependencies
If you have a set of dependencies
which are logically grouped together.
You can create a project with pom
packaging that groups dependencies
together. For example, let's assume
that your application uses Hibernate,
a popular Object-Relational mapping
framework. Every project which uses
Hibernate might also have a dependency
on the Spring Framework and a MySQL
JDBC driver. Instead of having to
include these dependencies in every
project that uses Hibernate, Spring,
and MySQL you could create a special
POM that does nothing more than
declare a set of common dependencies.
You could create a project called
persistence-deps (short for
Persistence Dependencies), and have
every project that needs to do
persistence depend on this convenience
project:
Example 3.11. Consolidating Dependencies in a Single POM Project
<project>
<groupId>org.sonatype.mavenbook</groupId>
<artifactId>persistence-deps</artifactId>
<version>1.0</version>
<packaging>pom</packaging>
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate</artifactId>
<version>${hibernateVersion}</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-annotations</artifactId>
<version>${hibernateAnnotationsVersion}</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-hibernate3</artifactId>
<version>${springVersion}</version>
</dependency>
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>${mysqlVersion}</version>
</dependency>
</dependencies>
<properties>
<mysqlVersion>(5.1,)</mysqlVersion>
<springVersion>(2.0.6,)</springVersion>
<hibernateVersion>3.2.5.ga</hibernateVersion>
<hibernateAnnotationsVersion>3.3.0.ga</hibernateAnnotationsVersion>
</properties>
</project>
If you create this project in a
directory named persistence-deps, all
you need to do is create this
pom.xml and run mvn install. Since
the packaging type is pom, this POM
is installed in your local repository.
You can now add this project as a
dependency and all of its dependencies
will be added as transitive
dependencies to your project. When you
declare a dependency on this
persistence-deps project, don't
forget to specify the dependency type
as pom.
Example 3.12. Declaring a Dependency on a POM
<project>
<description>This is a project requiring JDBC</description>
...
<dependencies>
...
<dependency>
<groupId>org.sonatype.mavenbook</groupId>
<artifactId>persistence-deps</artifactId>
<version>1.0</version>
<type>pom</type>
</dependency>
</dependencies>
</project>
If you later decide to switch to a
different JDBC driver (for example,
JTDS), just replace the dependencies
in the persistence-deps project to use
net.sourceforge.jtds:jtds instead of
mysql:mysql-java-connector and update
the version number. All projects
depending on persistence-deps will use
JTDS if they decide to update to the
newer version. Consolidating related
dependencies is a good way to cut down
on the length of pom.xml files that
start having to depend on a large
number of dependencies. If you need to
share a large number of dependencies
between projects, you could also just
establish parent-child relationships
between projects and refactor all
common dependencies to the parent
project, but the disadvantage of the
parent-child approach is that a
project can have only one parent.
Sometimes it makes more sense to group
similar dependencies together and
reference a pom dependency. This way,
your project can reference as many of
these consolidated dependency POMs as
it needs. Note
Maven uses the depth of a dependency
in the tree when resolving conflicts
using a nearest-wins approach. Using
the dependency grouping technique
above pushes those dependencies one
level down in the tree. Keep this in
mind when choosing between grouping in
a pom or using dependencyManagement
in a parent POM
Wouldn't this just be another sub-module foo-sdk with packaging pom and dependencies on foo-{core,resource,util}?
If I was to use a 3rd party library that was not in the maven public repository, what is the best way to include it as dependency for my project so that when someone else checks out my code it will still be able to build?
i.e.
My Application "A" depends on jar "B" which does not exist in the public repository. I, however, wish to add "B" as a dependency to "A" such that when a person on the other side of the world could check out the code and still be able to build "A"
You can install the project yourself.
Or you can use the system scope like the following:
<dependency>
<groupId>org.group.project</groupId>
<artifactId>Project</artifactId>
<version>1.0.0</version>
<scope>system</scope>
<systemPath>${basedir}/lib/project-1.0.0.jar</systemPath>
</dependency>
systemPath requires the absolute path of the project. To make it easier, if the jar file is within the repository/project, you can use ${basedir} property, which is bound to the root of the project.
If you have a parent project with a module that is in this situation (requires a dependency not in a repository) you can setup your parent project to use the exec-maven-plugin plugin to auto-install your dependent file. For example, I had to do this with the authorize.net jar file since it is not publicly available.
Parent POM:
<build>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>exec-maven-plugin</artifactId>
<version>1.2.1</version>
<inherited>false</inherited>
<executions>
<execution>
<id>install-anet</id>
<phase>validate</phase>
<goals>
<goal>exec</goal>
</goals>
</execution>
</executions>
<configuration>
<executable>mvn</executable>
<arguments>
<argument>install:install-file</argument>
<argument>-Dfile=service/lib/anet-java-sdk-1.4.6.jar</argument>
<argument>-DgroupId=net.authorize</argument>
<argument>-DartifactId=anet-java-sdk</argument>
<argument>-Dversion=1.4.6</argument>
<argument>-Dpackaging=jar</argument>
</arguments>
</configuration>
</plugin>
</plugins>
</build>
In the above example, the location of the jar is in the lib folder of the "service" module.
By the time the service module enters the validate phase, the jar will be available in the local repository. Simply reference it in the way you set up the groupid, artifact, etc in the parent pom. For example:
<dependency>
<groupId>net.authorize</groupId>
<artifactId>anet-java-sdk</artifactId>
<version>1.4.6</version>
</dependency>
Using system scope may work but it is not recommended even in the Maven specification.
it is not portable.
from Maven book:
system- The system scope is similar to provided except that you
have to provide an
explicit path to the JAR on the local file system. This is intended to allow compilation
against native objects that may be part of the system libraries. The artifact is assumed
to always be available and is not looked up in a repository. If you declare the scope to
be system, you must also provide the systemPath element. Note that this scope is not
recommended (you should always try to reference dependencies in a public or custom Maven
repository).
The best approach is to install to your local repository or to your enterprise repository to be accessible to all your peers.
this is very easy if you are using a repository manager such as Nexus.
This solution worked for me;
1. Created a local-maven-repo in my project's root directory and copied all my jars in the
2. Executed the following command to generate the necessary pom files and metadata etc for each and every jar that I needed to use;
mvn deploy:deploy-file -DgroupId=<somegroupid> -DartifactId=<someartifact> -Dversion=1.0.0 -Durl=file:./local-maven-repo/ -DrepositoryId=local-maven-repo -DupdateReleaseInfo=true -Dfile=<path to jar file>
This generated a new jar file with a pom file inside the local-maven-repo and I was able to include into my project as a dependency like this;
<dependency>
<groupId>somegroupid</groupId>
<artifactId>someartifact</artifactId>
<version>1.0.0</version>
</dependency>
Then mvn package ensured that my project dependencies are resolved and packaged with my war file.
If you are using groovy/grail tool suite (GGTS) then you can directly import that third party dependency (but be sure you have that third party dependency in your local repository) using below steps :
Go to the Project Explorer and right click on project.
Click on import option.
Expend the maven option and select Install or deploy an
artifact to a maven repository and click next.
Brows and select that third party dependency using Artifact File
option and enter the detail of Group Id, Artifact Id and Version
using POM.xml file and click on finish
Wait some moment and possibly error would have gone for that problem.
Generally speaking, you should first put the 3rd party jar into your local repository. After that you can use it by adding the dependency into pom.xml.
For example.
1.put the jar into your local repository first:
mvn install:install-file -Dfile=<path-to-file>
Note: this command requires maven-install-plugin version 2.5 or later. If not, You can refer to Here
2.use the jar by adding the dependency into you project's pom.xml.
just add this into the pom.xml of your project:
<dependency>
<groupId>${the groupId in the jar's pom.xml}</groupId>
<artifactId>${the artifactId in the jar's pom.xml}</artifactId>
<version>${the version in the jar's pom.xml}</version>
</dependency>
3.you can then package or deploy your project by running mvn package or mvn deploy
The 3rd party jar will also be included in the package.
I have two maven modules, one that ends up as a jar, and one war that depends on that jar.
I want the jar module to package it's source code together with the compiled classes in the jar, so that the second module is able to access it. I have tried using the maven-source-plugin, but I am confused as to how to add a dependency on the output of that. It seems that the dependency by default goes to the compiled jar, and not the source-code jar (ending with "-source.jar") that maven-source-plugin creates.
How do I add the "-source.jar" as a dependency, while still preserving the dependency on the compiled sources?
I've not tried this, but I think you need to create two profiles in your project. One which builds the main jar. The other which builds the sources jar. Unfortunately, I'm not exactly sure how you would build that profile. I couldn't find a good example of it so far.
(Accoding to the comments, you don't actually need a profile. You can just use the sources-plugin which will deploy the sources and make them available via the sources classifier)
In theory, you'd use the 2nd profile to attach the sources to the project. This creates a 2nd entry in your repository for the sources using that classifier. Once you install/deploy the sources to your repository, you should be able to include the sources as a dependency by using the classifier tag on the dependency to specify the sources directly.
So you'd have something like this in your webapp POM:
<dependencies>
<dependency>
<groupId>myGroup</groupId>
<artifactId>myJar</artifactId>
<version>4.0</version>
<type>jar</type>
</dependency>
<dependency>
<groupId>myGroup</groupId>
<artifactId>myJar</artifactId>
<version>4.0</version>
<type>jar</type>
<classifier>sources</classifier>
</dependency>
</dependencies>
Did you try adding the src directory as a resource directory in the build section? That should copy the source into the jar on build.