I am trying to add a WSDL module to my existing application, but I'm struggling to get the dependencies resolved.
According to their website, this is the correct dependency
<dependency>
<groupId>org.ow2.easywsdl</groupId>
<artifactId>easywsdl-wsdl</artifactId>
<version>2.1</version>
</dependency>
After a search (search.maven.org), I already changed the version to 2.3 and there are a bunch of files that are downloaded into my local repository, but when running the application (with the websites demo code), I bump into this error:
java.lang.ClassNotFoundException: com.ebmwebsourcing.easycommons.uri.UriManager
And I believe it has something to do with the missing artifacts :
com.ebmwebsourcing.easycommons:easycommons.uri:jar:1.1
com.ebmwebsourcing.easycommons:easycommons.logger:jar:1.1
In particular the first one. Now, I'm relatively new to using Maven... How would I go about solving this?
Thanks.
The solution is to add the petalslink repository. Appearantly the standard maven repository doesn't contain the easycommons dependency. The petalslink repository does.
Related
All of a sudden all my Mule Maven projects are throwing this error when running mvn clean test:
java.lang.NoClassDefFoundError: org/apache/commons/cli/ParseException
at org.mule.tck.junit4.AbstractMuleTestCase.(AbstractMuleTestCase.java:71)
I can add a dependency for it, but I shoudln't really have to.
Nothings changed in my code. I am using Mule 3.4
You need commons-cli.jar in your classpath, add this Maven dependency to your pom
<dependency>
<groupId>commons-cli</groupId>
<artifactId>commons-cli</artifactId>
<version>1.1</version>
</dependency>
Update: OP's code was fixed after adding commons-cli 1.1 dependency.
Issue description and how to fix it: http://ricston.com/blog/mule-classnotfoundexception-tests-commons-cli/
In a nutshell, you probably have an incorrect JAR named commons-cli-1.2. Delete that and rerun your maven build. You should be good after that.
If the follogin dependency in available in the POM. it should be working fine.
<dependency>
<groupId>org.mule.tests</groupId>
<artifactId>mule-tests-functional</artifactId>
<version>3.4.0</version>
<scope>test</scope>
</dependency>
Then use mvn clean compile to update the dependency.
mvn eclipse:clean eclipse:eclipse clean compile
Hope this helps.
Maven behaviour isn't reproducible from one run to the next: apart from generic network problems and repository corruption problems, anything might be updated automatically at any time, breaking any step of the execution, even if you don't change any of your files.
Your error message about a class in some Apache Commons library suggests a disagreement between the version of that library Mule should be using (one that has the ParseException class) and the library version it actually loads (without the class and causing the exception).
Plausible version mismatch scenarios include an update to a buggy new version of Mule (maybe only to a wrong or corrupted POM) which specifies an incompatible library version, or a random upgrade or downgrade of the latest library version in your repository as a consequence of adding or updating something unrelated to Mule.
Analysis suggestions:
What plugins in your Maven repository have a snapshot version? Which ones of these snapshots were updated around the time the error first appeared?
Which library jars, and which versions, include the ParseException class? What depends on specific versions or on the latest version of those jars?
We've just recently converted our project to using Maven for builds and dependency management, and after the conversion I'm getting the following exception while trying to run any JSFUnit tests in my project.
Exception class=[java.lang.UnsupportedOperationException]
com.gargoylesoftware.htmlunit.ScriptException: CSSRule com.steadystate.css.dom.CSSCharsetRuleImpl is not yet supported.
at com.gargoylesoftware.htmlunit.javascript.JavaScriptEngine$HtmlUnitContextAction.run(JavaScriptEngine.java:527)
at net.sourceforge.htmlunit.corejs.javascript.Context.call(Context.java:537)
...
All the dependencies and JARs for JSFUnit were pulled with Maven using the JBoss repository (http://repository.jboss.com/maven2/).
We're using the following dependencies in the project:
jboss-jsfunit-core 1.2.0.Final
jboss-jsfunit-richfaces 1.2.0.Final
richfaces-ui 3.3.2.GA
openfaces 2.0
JSF 1.2_12
Facelets 1.1.14
Before the dependencies were being managed by Maven, we were able to run our JSFUnit tests just fine. I was able to semi-fix the issue by using a ss_css2.jar file that someone had tucked into our WEB-INF/lib directory (from before the Maven conversion). I'm hoping to find out if there's something else I can do to fix the dependencies in Maven rather than resorting to managing some of the dependencies myself.
You're very likely getting an "incompatible" version of HtmlUnit or another JAR (pulled transitively). Try with the version you were using previously and declare it under the dependencyManagement section, e.g.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>net.sourceforge.htmlunit</groupId>
<artifactId>htmlunit</artifactId>
<version>2.7</version><!-- put "your" version here -->
</dependency>
</dependencies>
</dependencyManagement>
Or, if you changed any version, try to revert to the exact previous state (by the way, could you clarify the differences between the previous versions and the one currently used?).
Update: It appears that the problem was related to the version of the cssparser artifact. I hadn't all the required elements to figure this out but the OP did :)
I changed the version from jFreeChart in the pom.xml of my maven project from 1.0.12 to 1.0.13.
Now I get the error
"The type org.jfree.ui.layer cannot be resolved to a type. It is indirectly referenced from required class files."
What does this mean? I just updated the jfreechart dependency.
The type is in the JCommons library. I think the problem is that the JFreeChart has not been properly distributed to maven in version 1.0.13. In the IBiblio directory listing, you can see that a .pom file is missing (as opposed to version 1.0.12, where it's present).
This means that maven has no ideas what the dependencies are. It still downloads the artifact through it's filename by convention, but it doesn't know anything about the context.
Now you can either complain to the vendor and demand a proper pom or create your own pom file (start with the old version and adjust it until things start working) and deploy it to your company's repository (or your local repository) using install:install-file or deploy:deploy-file.
My guess is that you'll at least have to include the following dependency
<dependency>
<groupId>jfree</groupId>
<artifactId>jcommon</artifactId>
<version>1.0.15</version>
</dependency>
(If you want to do it the easy way, just add the above dependency to your own project pom)
I need to download a file from a non-standard layout repository.
The standard repository layout is groupId>/<artifactId>/<version>/<artifactId>-<version>.<packaging> however, I need to download the following file:
http://hudson.myserver.com:10000/repo/ocp-services/schemas/trunk/201/archive/schemas/dist/schemas.jar
where ocp-services is effectively the groupId, schemas is the artifactId and 201 is the version.
How would I add a dependency to this file and get it downloaded into my project and local repository?
This is a Hudson file repository if this is of any help, but it is a third parties so difficult to get them to change any location.
One option would be to register a custom ArtifactRepositoryLayout implementation and to declare a repository using this custom layout. I've never done that but it should be possible, check this blog post.
A second option would be to configure Maven to go through some kind of custom proxy (e.g. a Servlet) and to rewrite the URL on the fly for this particular dependency.
In both cases, I'm afraid Maven will complain about missing metadata ("A dependency in Maven isn't just a JAR file", see 3.5.5. Maven's Dependency Management) because the hudson file repository is just not a Maven repository. Maybe this can be handled programmatically though. But as I said, I've never done this.
A third option would be to ask the project building the JAR you need to deploy it (in the maven sense). That would be of course the best solution.
A last one option would be to just download this JAR and to install it manually in your local repository. If this is an option, go for it.
Have you tried adding this to your pom.xml :
<dependencies>
<dependency>
<groupId>ocp-services</groupId>
<artifactId>schemas</artifactId>
<version>201</version>
<type>jar</type>
</dependency>
</dependencies>
or if that don't work as Pascal says install it manually
I'm just starting to use Apache Buildr and I'm constantly running into the problem of not knowing what repo urls and versions are available for me to use.
For example I want to use Scala 2.8 in a build file, the id i previously used was:
2.8.0-SNAPSHOT
But now this is not found. I also want to use the latest version of Apache POI. If I look on the maven2 repo:
http://mirrors.ibiblio.org/maven2/
I can see that it only has up to version 3.2.
Is there any standard way of finding repos and searching them for what they have available?
Is there any standard way of finding repos and searching them for what they have available?
No, there is no directory of repositories (actually, having many repositories kinda defeats the concept of a central and unique repository but I guess that centralizing everything is a bit utopia).
But there are several repository search engines that index the most "famous" one (like central, java.net, codehaus, jboss):
http://repository.apache.org/
http://www.artifact-repository.org/
http://mvnrepository.com/
http://www.mvnbrowser.com/
http://www.jarvana.com/
http://mavensearch.net/
http://maven.ozacc.com/
http://www.mavenreposearch.com/
http://www.mvnsearch.org/
http://repository.sonatype.org/
In the particular case of Apache POI, version 3.6 is available in the central repo. To use it, just declare the following dependency:
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi</artifactId>
<version>3.6</version>
</dependency>
To search the repositories try NetBeans. It provides a nice repository browser, where you can add the repositories which you like.
Here are some (see Pascal's for more):
http://download.java.net/maven/2/ ('java.net')
http://repository.jboss.com/maven2/ ('jboss.org')
http://bits.netbeans.org/maven2/
http://repo1.maven.org/eclipse
NetBeans also provides autocompletion within the pom.xml for dependencies etc (e.g. to get the latest version) ... but for scala I am not sure if this is useful.