I have a problem on maven dependencies when it tries to resolve dependencies that is not configured in the project level, but is configured on the plugin level. It always looks from maven central and won't check in our internal repo.
Below is the pom configuration. Problem is that it will always look for proguard version 4.2 in the central even if we have configured it as proguard 4.9 and supposed to be fethcing the one in our internal nexus:
<plugin>
<groupId>com.pyx4me</groupId>
<artifactId>proguard-maven-plugin</artifactId>
<version>2.0.4</version>
<executions>
<execution>
<phase>package</phase>
<goals><goal>proguard</goal></goals>
</execution>
</executions>
<configuration>
<proguardVersion>4.9</proguardVersion>
<obfuscate>true</obfuscate>
<proguardInclude>conf/proguard_gsma-sms-validator.conf</proguardInclude>
<includeDependency>false</includeDependency>
</configuration>
<dependencies>
<dependency>
<groupId>net.sf.proguard</groupId>
<artifactId>proguard</artifactId>
<version>4.9</version>
</dependency>
</dependencies>
</plugin>
Im not sure if this is Maven problem or pyx4me problem or proguard. But im guessing it's a problem with Maven.
This can only be resolved if we do a maven install:install-file to proguard version 4.9. But we want maven to settle dependencies by fetching the one from our internal Nexus.
Please advise. Thanks.
The plugin com.pyx4me:proguard-maven-plugin:2.0.4 depends on net.sf.proguard:proguard:4.3, which was initiated and maintained by the developers of Pyx4me.
However, recent versions of ProGuard are available as net.sf.proguard:proguard-base:4.2+ and related modules, as initiated by Marcel Patzlaff and currently maintained by myself.
You can find a list of all of them at maven.org. Note the latest version numbers. ProGuard itself should still be compatible, so you can try replacing the dependency by excluding the former and adding the latter.
Related
We pre-package a dependency with the application,and use Maven install plugin to inject into the classpath.
<dependencies>
<dependency>
<groupId>artifactXXX</groupId>
<artifactId>artifactXXX</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
In the install:
<executions>
<execution>
<id>install-artifactXXX</id>
<phase>install</phase>
<goals>
<goal>install-file</goal>
</goals>
<configuration>
<groupId>artifactXXX</groupId>
<artifactId>artifactXXX</artifactId>
<version>1.0</version>
<packaging>jar</packaging>
<file>${basedir}/jars/artifactXXX.jar</file>
<generatePom>true</generatePom>
</configuration>
</execution>
</executions>
However, during clean install Maven still tries to download the POM for the dependent JAR from Artifactory and produces a POM not found error.
What is to be done here?
Dependency resolution happens before <build> proccessing. So, at the time Maven processes the <dependencies> section the artifact hasn't been installed yet.
You have to perform install:install-file manually on the command line at least once before your POM build (and you have to be aware of that, if using a -SNAPSHOT version, the dependency installed by the previous build is used in the current build).
Furthermore, such a configuration doesn't comply with the declarative nature of Maven POMs. It's like trying to grow a plant from seeds of the plant that is to be grown.
I'm working on an Eclipse RCP + Maven project for the first time and I want to run some unit tests on my bundles with JUnit. It seems that the most recommended approach is to create a bundle fragment and use something like Tycho plugin to resolve dependencies. However, when I run mvn clean verify in my master pom, it should run the tests and deploy my application, but I'm get the following error instead:
[ERROR] Cannot resolve project dependencies:
[ERROR] You requested to install 'myproject.app.feature.feature.group 1.0.0' but it could not be found
[ERROR] Failed to execute goal org.eclipse.tycho:tycho-surefire-plugin:0.21.0:test (default-test) on project myproject.app.viewmanager-test: Execution default-test of goal org.eclipse.tycho:tycho-surefire-plugin:0.21.0:test failed: No solution found because the problem is unsatisfiable.: [Unable to satisfy dependency from tycho-extra-1408913392535 0.0.0.1408913392535 to myproject.app.feature.feature.group 1.0.0.; Unable to satisfy dependency from tycho-1408913392552 0.0.0.1408913392552 to myproject.app.feature.feature.group 1.0.0.; No solution found because the problem is unsatisfiable.] -> [Help 1]
I understand that Maven is failing to find 'myproject.app.feature.feature.group 1.0.0' but I don't know where it is getting this from because it seems that the name is wrong.
It might be worth to say that when I run the unit test inside Eclipse (not with Maven) it works.
This is the Tycho configuration in my test fragment:
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-surefire-plugin</artifactId>
<version>${tycho-version}</version>
<configuration>
<useUIHarness>true</useUIHarness>
<dependencies>
<dependency>
<type>eclipse-feature</type>
<artifactId>myproject.app.feature</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
</configuration>
</plugin>
As suggested here, I'm adding the feature as a dependency because my test fragment requires some other bundles besides its host, so I was expecting this to work.
Any tips? The most similar issue I have found is this one, but both solutions didn't work for me.
Starting with Tycho 0.21.0, there is only limited support for declaring dependencies to reactor projects in the tycho-surefire-plugin: They only work if the test project already has some other dependency to the referenced reactor project. In your use case, where you add a dependency to a feature, this is not the case.
You could make the tycho-surefire-plugin dependencies configuration work again by adding a POM dependency to the feature project:
<dependencies>
<dependency>
<!-- Maven GAV of the feature project -->
<groupId>myproject.groupId</groupId>
<artifactId>myproject.app.feature</artifactId>
<version>1.0.0-SNAPSHOT</version>
</dependency>
</dependencies>
<build>
<plugins>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-surefire-plugin</artifactId>
<version>${tycho-version}</version>
<configuration>
<dependencies>
<dependency>
<type>eclipse-feature</type>
<artifactId>myproject.app.feature</artifactId>
<version>1.0.0</version>
</dependency>
</dependencies>
</configuration>
</plugin>
</plugins>
</build>
However the recommended way to specify extra test dependencies is to do this in the target-platform-configuration instead of on the tycho-surefire-plugin:
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<configuration>
<dependency-resolution>
<extraRequirements>
<requirement>
<type>eclipse-feature</type>
<id>myproject.app.feature</id>
<versionRange>1.0.0</versionRange>
</requirement>
</extraRequirements>
</dependency-resolution>
</configuration>
</plugin>
Note: The element names to specify dependencies are different in the target-platform-configuration compared to the tycho-surefire-plugin. So when migrating your configuration, you need to adapt the tag names:
<type> (unchanged)
<artifactId> → <id>
<version> → <versionRange>
Remark: Although the tag names are different, the semantics of the elements are the same: So even though the old name was <version>, the value was always interpreted as a version range. A version range that consists of a single version like 1.0.0 stands for for a version range without upper bound, i.e. version 1.0.0 or later.
I just had essentially the same problem. It seems that with tycho 0.21 dependencies have to be added using the target-platform-configuration plugin. See tycho bug 436617 comment #11 for an example.
I have following maven projects (note : maven project, not maven modules). I know i will get questions, why not modules, but it has its own story, anyway.
myproj-common (JAR),
myproj-core (JAR),
myproj-product1-batch (EAR),
myproj-product2-batch (EAR)
myproj-core depends on myproj-common, and myproj-product1-batch depends on myproj-core.
If it is modules, i can simply create dependency. It if is standard archive, I can also create dependency and have JAR available in repository, if it is a library JAR, I can ...bla bla bla ...all standard dependency I can fix, I am not sure how to make a jar that is sitting somewhere on the disk, a dependency.
I am not able to get
C:\Documents and Settings\users\myproj-common\target\myproj-common-0.0.1-SNAPSHOT.jar
into following jar, as a dependency
C:\Documents and Settings\users\myproj-core\target\myproj-core-0.0.1-SNAPSHOT.jar
same problem for the JAR into EARs.
Any idea ? How ...hoping a small, quick and surprising fix, just not visible to me.
I don't see any reason why you shouldn't be able to use mvn install to install these jars and ears into your local repository. Then, you can just include them as dependencies anywhere you like.
I doubt that you'll be able to cleanly get maven to pull in a jar sitting anywhere on your filesystem other than your local repository.
To clarify, when you do mvn install it puts your JAR in the target folder, but it also puts it into your local repository (C:\Documents And Settings\.m2 by default in Windows). After that JAR is installed there, you can include that JAR in other projects as a maven dependency using a "dependencies" block in your pom like this:
<dependencies>
<dependency>
<groupId>group-a</groupId>
<artifactId>artifact-a</artifactId>
<version>1.0</version>
</dependency>
</dependencies>
The dependencies mechanism is explained in the Maven Docs.
In addition, you'll need to tell maven to actually package all dependencies in the JAR. You can do that by adding this to your POM. (Also check this question How can I create an executable JAR with dependencies using Maven? for the source of this code block).
<plugin>
<artifactId>maven-assembly-plugin</artifactId>
<configuration>
<descriptorRefs>
<descriptorRef>jar-with-dependencies</descriptorRef>
</descriptorRefs>
</configuration>
<executions>
<execution>
<id>make-assembly</id> <!-- this is used for inheritance merges -->
<phase>package</phase> <!-- bind to the packaging phase -->
<goals>
<goal>single</goal>
</goals>
</execution>
</executions>
</plugin>
So I'm finding that the more I use Maven, the buggier I'm finding it to be, especially when building the same project using different Maven versions. Is this to be expected?
A couple of examples:
I have a .ear I'm deploying to JBoss. As I'm bringing in wsdls, xsds and generated classes brought in on the class path, I'm bring the .jar in as a dependency then unpacking it into the .ear. To do this I'm using the unpack dependencies goal. Looks something like this...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<version>2.4</version>
<executions>
<execution>
<id>unpack-wsimport</id>
<phase>prepare-package</phase>
<goals>
<goal>unpack-dependencies</goal>
</goals>
<configuration>
<includeGroupIds>url.projectName</includeGroupIds>
<includeArtifactIds>projectName-wsimport</includeArtifactIds>
<outputDirectory>${project.build.outputDirectory}</outputDirectory>
</configuration>
</execution>
</executions>
</plugin>
Using Maven 3.0.3 (Which is what the project was originally built in), this works fine. Switch over to Maven 2.0.9 and all of a sudden it doesn't. On the Maven site it says this plugin has been supported since version 1.0, so why isn't it working?
In the same vein, but vice versa, when I'm trying to do a maven release of this project, using Maven 2.0.9 will prepare and perform correctly, however 3.0.3 doesn't copy across certain files when tagging a version in SVN.
Anyone else finding errors like this when switching between versions of Maven to build projects?
First it looks like you didn't understand the maven way of doing things like an ear, cause within a EAR you have to add the dependencies which should be put into the EAR not via the dependency-plugin you have to use them as dependencies instead.
for Example:
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<version>2.6</version>
</plugin>
</plugins>
</build>
<dependencies>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>webgui</artifactId>
<version>${project.version}</version>
<type>war</type>
</dependency>
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>service</artifactId>
<version>${project.version}</version>
<type>ejb</type>
</dependency>
</dependencies>
but the better approach is to use the correct configuration for the maven-ear-plugin.
Based on the information you gave i would have expected to have a multi-module build which contains your different modules (like web-part, wsdl-part etc.) which will be packaged into an EAR. This would have resulted into a structure like the following:
+-- root
+-- pom.xml
+-- war
+-- pom.xml
+-- wsdl
+-- pom.xml
+-- ...
+-- ejb
+-- pom.xml
+-- ear
+-- pom.xml
Furthermore it looks like you need to look into the orginization of projects like multi-module projects. Here is an example of such kind. The documentation about Maven is a good way to start with and last but not least Maven by Example.
About your point of buggines i can't acknowledge this, cause i'm working a long time with Maven in really large project (100 modules +)...Furthermore i would like to know where it's stated that this plugin works with version 1.0.
Despite the fact that it doesn't looke like that you read the release notes. There is large number of differences between the Maven versions in particular between Maven 2.0.X, 2.2.X and 3.0.X ..If you really need to run your build with differernt Maven version like 2.0, 2.2, and 3.0. This can be done and is working, but there are some drawbacks based on the technical detail in particular between 2.2.X and 3.0.X (reporting are). I would suggest to use only one Maven version to build your artifacts (currently 3.0.3/3.0.4). An other hint is that a Maven build which works for Maven 2/3 never will run with Maven 1, cause the POM has been changed dramatically.
I am writing a project for acceptance testing and for various reasons this is dependent on another project which is packaged as a WAR. I have managed to unpack the WAR using the maven-dependency-plugin, but I cannot get my project to include the unpacked WEB-INF/lib/*.jar and WEB-INF/classes/* to be included on the classpath so the build fails. Is there a way to include these files into the classpath, or is there a better way of depending on a WAR?
Many thanks.
There's another option since maven-war-plugin 2.1-alpha-2. In your WAR project:
<plugin>
<artifactId>maven-war-plugin</artifactId>
<version>2.1.1</version>
<configuration>
<attachClasses>true</attachClasses>
</configuration>
</plugin>
This creates a classes artifact which you can use in the acceptance tests project with:
<dependency>
<groupId>your-group-id</groupId>
<artifactId>your-artifact-id</artifactId>
<version>your-version</version>
<classifier>classes</classifier>
</dependency>
Indeed, by design, Maven doesn't resolve transitive dependencies of a war declared as dependency of a project. There is actually an issue about that, MNG-1991, but it won't be solved in Maven 2.x and I'm not sure that I don't know if overlays allow to workaround this issue. My understanding of the suggested solution is to duplicate the dependencies, for example in a project of type pom.
(EDIT: After some more digging, I found something interesting in this thread that I'm quoting below:
I have been helping out with the development of the AppFuse project over
the last month where we make heavy use of the war overlay feature in the
Maven war plugin. It is a really nifty feature!
To get max power with war overlays I have developed the Warpath plugin
that allows projects to use war artifacts as fully fledged dependencies.
In brief:
1) The contents of the /WEB-INF/classes directory in the war dependency
artifacts can be included in the project's classpath for normal compile,
etc tasks.
2) Transitive dependencies from the war dependency artifacts become
available for use by other plugins, e.g. compile and ear - so no more
having to include all the dependencies when creating skinny wars!
The plugin has now been actively used in the AppFuse project for the
last few months, and I feel it is at a point where it is both usable and
stable.
Would the war plugin team be interested in including the warpath
functionality inside the war plugin? It would seem to be the most
natural place to host it.
So, I don't have any experience with it, but the maven warpath plugin actually looks nice and simple and is available in the central repo. To use it,include the following plugin configuration element in your pom.xml file:
[...]
<build>
<plugins>
<plugin>
<groupId>org.appfuse</groupId>
<artifactId>maven-warpath-plugin</artifactId>
<version>1.0-SNAPSHOT</version>
<extensions>true</extensions>
<executions>
<execution>
<goals>
<goal>add-classes</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
[...]
And add the war dependencies you want included in the classpath as warpath type dependencies:
[...]
<dependencies>
<dependency>
<groupId>org.appfuse</groupId>
<artifactId>appfuse-web</artifactId>
<version>2.0</version>
<type>war</type>
</dependency>
<dependency>
<groupId>org.appfuse</groupId>
<artifactId>appfuse-web</artifactId>
<version>2.0</version>
<type>warpath</type>
</dependency>
</dependencies>
[...]
Both the war and warpath dependency types are needed: the war type is used by the Maven war plugin to do the war overlay, the warpath type is used by the Warpath plugin to determine the correct list of artifacts for inclusion in the project classpath.
I'd give it a try.)
Use overlays. First, your test project need to have also packaging war.
Declare dependency of war project you want to test:
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>your-project-arftifactId</artifactId>
<version>${project.version}</version>
<type>war</type>
<scope>test</scope>
</dependency>
then configure maven-war-plugin overlay:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<configuration>
<webResources>
<resource>
<directory>${basedir}/src/main/webresources</directory>
<filtering>true</filtering>
</resource>
</webResources>
<overlays>
<overlay/>
<overlay>
<groupId>your.group</groupId>
<artifactId>your-project-artifactId</artifactId>
</overlay>
</overlays>
</configuration>
</plugin>
In the above example in test project I overwrite webresources configuration files (like conxtext etc.).
EDIT: This solution wasn't tested with Maven 3.
Good point, Justin. That got me actually solving my problem, namely: including a war into an assembly AND including all its transitive dependencies.
I could not duplicate the war-dependency as 'jar' as you suggested since the assembly plugin would not find a jar referenced by that groupId/artefactId, but
duplicating the war-dependency as type pom
works!
The war and its transitive dependencies are not included in the assembly.
To exclude the (now also appearing) pom file I had to add an exclude element like this:
<excludes>
<exclude>*:pom</exclude>
</excludes>
into my assembly.xml file.
I think this could also be a workaround for the original question of this thread.
If you list the dependency on the war project as a jar dependency it seems to pickup the required jars/resources. I'm using Maven 2.2 + m2eclipse.