Is it possible to specify sources and/or javadocs to be included in dependency JAR's with the Play Framework?
I want to be able to browse the source and javadocs for 3rd party libraries in Eclipse. The Maven Eclipse plugin can apparently be configured to provide this functionality as seen here, I'm wondering if Play provides similar facilities as well.
Have you looked at the Maven plugin? http://www.playframework.org/modules/maven
It explicitly mentions source and javadocs in its description.
Expected behavior this module:
Allow declaration dependencies in pom.xml, without putting
explicitly unless the transitive dependency does not work (for older
version or depending on undesirable big jar file)
Able to download all dependencies not provided by Play into lib
folder, with src and javadoc
Able to download source/javadoc artifiacts to depsrc folder for
declared or transitive dependency which is provided by Play, for
easier debugging (using command mvn:play-src)
Related
Let me explain first what I mean by necessary libs. I'm creating my first project using the Google App Engine for Java with the official Google Maven Plugin, the main problem that have Maven as a packaging solution (or maybe the Java development as a whole) is that if the dependency tree grows too much, the release process may be harder.
Let me illustrate it with an example. Let's start with the Jackson JSON library (it's a good starting point since it has no parent dependencies), now someone makes a JSON-RPC library and uses Jackson for the JSON serialization/deserialization. Imagine that this library not just provides a JSON-RPC client implementation, but also a server, that means that the POM of this lib will add some Java EE related libraries such us Jetty as dependencies.
Probably the guidelines say that the application should be either divided into modules or mark the server related deps as optional, but you know that many people don't follow the standards.
Now someone need a JSON-RPC client for his/her project, call it Project X, and uses the lib mentioned above, at compile time there will be no problems, Maven will successfully download the required libs and the application will compile fine, but the problem comes when that person wants to release the application. Which dependencies should be distributed along with the package (in a lib folder for example)?
Actually that's something that happened to me, I wasn't too much familiar with Maven so I used the Eclipse Runnable Jar Exporter, that produced jar file with all the maven libs copied to a lb subfolder, so the workaround that I did then was to just delete the libs that looked unnecessary and then tested if the application was still working. If there are classes that are not executed, as far as I know they are not loaded by the ClassLoader so they could be omitted and are unnecessary
I can't use the same trick now since the scenario is much more complex, we are talking of a Java Web Application, not a desktop application like the other one, and the library that I want to include is a Liquid Template Engine, which uses the ANTLR framework to generate the parsers plus Jackson for the JSON handler and Jsoup for HTML parsing.
Which libs should be packaged inside the WEB-INF/lib folder? I'm sure that I will need Jackson for JSON parsing but I'm not so sure about Jsoup, and what about ANTLR, it is necessary or is used just at compile time?
Update: I think I need to re-formulate my question, actually what I want is to determine which dependencies are really necessary for the application, and package those into the app WEB-INF/lib folder
Solution: It seems that the POM file that is packaged in the WAR file of the web app is used once the app is in the Google App Engine production environment to retrieve the necessary dependencies, and probably the appengine:update goal only packages those dependencies that can't be retrieved from the maven central repo, so there is no need to worry about that.
Thanks to David to point this.
You should check Maven's dependency scopes. Here's an extract from the documentation :
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.
So in a Maven project, the developer indicates which dependencies should be bundled in the application and which should not.
Basically there are two cases here :
If you're building a web application (WAR or EAR format) and want to deploy it, or if you're building an actual runnable jar, then you will need to bundle it with all the dependencies with scope compile and runtime.
If you're building a library, then you do not package any dependency with your library. Instead you include the pom.xml so that others know what dependency your library requires. For Maven to know how to find the associated POM for a given jar, the best and most common solution is to deploy the library to a Maven repository. Repos have a directory structure that helps Maven find the right version of a library, and find the POM that indicates the required dependencies.
Depending on wether your library is open source or not, you will be able to be hosted for free by some repositories such as Sonatype (complete list here). But you can also setup your own repository either by installing a dedicated software such as Nexus or by configuring a Github project as the repo, as is explained on this blog.
You can exclude any transitive dependency.
For your case, to remove jetty from this json-rpc-library, you need:
<dependency>
<groupId>com.somecomp</groupId>
<artifactId>jsonrpclib</artifactId>
<version>1.0</version>
<scope>compile</scope>
<exclusions>
<exclusion>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-server</artifactId>
</exclusion>
</exclusions>
</dependency>
See docs: http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html
I have inherited a big project with several subprojects.
all of them use several jar files, all of them located under each project's lib directory. I want to take all the projects and migrate them to maven, but dependencies are a problem (too many of them), some of them are commonly used libraries (apache projects, xerces, jms, etc) and others are not.
is there a way to autogenerate maven dependencies for those jars that can be found on public maven repositories. for example, see that my project use the spice-jndikit-1.2.jar file and automatically get the appropiate depedency with group, artifact and (if possible) version?
thank you
I wrote a groovy script to generate a starting set of Apache ivy files.
https://github.com/myspotontheweb/ant2ivy
In my case, I wanted to "Maven-ize" my ANT builds without switching completely away from ANT.
It is feasible to extend this code to generate a Maven POM, if people were interested in this feature.
You can convert a project to Maven using the m2e plugin, but this erases your jar references, and should not be used.
I doubt that such a thing exists since typical jars (unless themselves built with Maven) don't have the necessary information to correlate the groupId, artifactId and version back to a repository to get the proper path.
You might be able to write something that parses the file name for the name and version, but you still have the package-based path to figure out.
If you're building using Ant, you might also consider using Apache Ivy, and its file-system based resolution (very fast and easy to configure), to get you started, and slowly role over to the Maven repos for the artifacts, this way you're not spending a lot of time up-front finding Maven dependencies.
I have a library that I wrote in Scala that uses Bouncy Castle and has a whole bunch of dependencies. When I roll a jar, I can either roll a "fat" jar that has all the dependencies (including scala), which weighs in around 19 MB, or I can roll a skinny jar, which doesn't have dependencies, but is only a few hundred KB.
The problem is that I need to include the Bouncy Castle classes/jar with my library, because if its not on the classpath at runtime, all kinds of exceptions get thrown.
So, I think the ideal situation is if there is some way that I can get either Maven or SBT to include some but not all dependencies in the jar that gets rolled. Some dependencies are needed at compile-time, but not at run time, such as the Scala standard libraries. Is there some way to get that to happen?
Thanks!
I would try out the sbt proguard plugin from https://github.com/nuttycom/sbt-proguard-plugin . It should be able to weed out the classes that are not in use.
If it is sufficient to explicitly define which dependencies should be added (one the artifact-level, i.e., single JARs), you can define an assembly (in case of a single project) or an additional assembly project (in case of a multi-module project). Assembly descriptors can explicitly exclude/include artifacts from the dependencies.
Here is some good documentation on this topic (section 8.5.4), here is the official documentation.
Note that you can include all artifacts that belong to one group by using the wildcard notation in dependecySets, e.g. hibernate:*:jar would include all JAR files belonging to the hibernate group.
Covering maven...
Because you declare your project to be dependent upon bouncy castle in your maven pom, anybody using maven to depend upon your library will by default pull in bouncy castle as a transitive dependency.
You should set the appropriate scope on your dependencies, e.g. compile for stuff needed at compile and runtime, test for dependencies only needed in testing and provided for stuff you expect to be provided by the environment.
Whether your library's dependencies are packaged into dependent projects when they are built is a question of how those are projects configured and setting the scopes will influence the default behaviour.
For example, jar type packaging by default does not include dependencies, whereas war will include those in compile scope (but not test or provided). The design aim here was to have packaging plugins behave in the most commonly required way without needing configuration, but of course packaging plugins in maven can be configured to have different behaviour if needed. The plugins themselves which do packaging are well documented at the apache maven site.
If users of your library are unlikely to be using maven to build their projects, an option is to use the shade plugin which will allow you to produce an "uber-jar" which contains all the dependencies you wish. You can configure particular includes or excludes.
This can be a problematic way to deliver, for example where your library includes dependencies which version clash with the direct dependencies of projects using it, i.e. they use a different version of the same libraries yours does.
However if you can it is best that you leave this to maven to manage so that projects using your library can decide whether they want your dependencies or to specify particular versions giving them more flexibility. This is the idiomatic approach.
For more information on dependencies and scopes in maven, see the reference guide published by Sonatype.
I'm not a scala guy, but I have played around with assembling stuff in Java + Maven.
Have you tried looking into creating your own assembly descriptor for the assembly plugin? https://maven.apache.org/plugins/maven-assembly-plugin/assembly.html
You can copy / paste the jar-with-dependencies descriptor then just add some excludes to your < dependencySet >. I'm not a Maven expert, but you should be able to configure it so different profiles kick off different assembly builds.
EDIT: Ack, didn't see my HTML got hidden
I have a dependency on clj-record in my CounterClockwise project. What's the best way to manage this? Copy the source code or compile to a JAR and add it as a referenced library?
There are tools to help you:
http://github.com/technomancy/leiningen <- project based
http://github.com/liebke/cljr <- dependencies not project based
http://github.com/ninjudd/cake <- alternative build tool
Assuming your dependencies are available in a Maven repo (like central or clojars), you have a couple of options.
First, if you're using Leiningen, there is an eclipse plugin for it now that will manage project dependencies for you, based on the dependencies you define in your project.clj file. The plugin is in beta now, but has been working great for me so far. (Note that it uses Leiningen 2.0 under the covers, though that detail won't matter for many (most?) simple cases.)
If you're using Maven, the m2eclipse plugin makes it so that the dependencies you declare in your Maven pom.xml are automatically added to your eclipse project's build path, and are therefore available in CCW REPLs and such.
there seems to be no pattern for specifying dependencies apart from hacking the code into your project or building a jar externally.
Of course you can, just as with any java project. While dependency resolution isn't tied into eclipse (yet), once you retrieve the deps (via one of the command line tools nickik listed), you can specify which jars are to be included in the java build path of your eclipse project:
Retrieve the deps via cake, leiningen, etc.
Refresh the eclipse project so you see the deps (usually in the lib directory)
Highlight the jars you want eclipse to know about
Right-click, select Build Path > Add to Build Path
That's it. You can fiddle with the build path by going to the Java Build Path section of the project's properties window.
With the maven-eclipse-plugin, using mvn eclipse:eclipse, you can specifiy eclipse project natures and builders that will automatically be added to the eclipse project.
Earlier versions of m2eclipse used the configuration block of the maven-eclipse-plugin and also let you activate natures and builders using the same mechanisms. This seems to no longer be the case because a) I can't find any reference to maven-eclipse-plugin in the m2eclipse sources and b) it just doesn't work :-)
So this is my question: is there any way to configure the eclipse project generated by m2eclipse from the pom.xml? Specifically: project builders and natures, but I'd be interested in other options as well.
The following thread summarizes almost everything. First, it explains that m2eclipse doesn't and won't support anything from the Maven Eclipse Plugin anymore because:
Sonatype doesn't maintain it.
It causes them too much troubles.
Second, it states that the m2eclipse way to handle additional project natures and builders is to write project configurators:
(...) we encourage writing configurators to add the natures and builders you want based on what it available in the POM.
See this link for a guide and this project for some existing configurators for checkstyle, findbugs, pmd.
I have now implemented this as a maven plugin I call maven-eclipseconf-plugin.
Unfortunately it's proprietary work for a client, so I can't share it. But let me describe what I do:
Tied to the lifecycle verify, I check for the existence of an eclipse .project file. If it's there, I check it for the presence of the builders and natures I want to automatically add (and you can deactivate this behavior by using a maven property or a stop file with a configurable name). You can also define configuration files that will be written (like .pmd, which is related to this other question of mine). The contents of the Configuration files can be specified inline, it can come from an external file, or from a URL. I also tried to introduce variable substitution in the config files where a special placeholder would be replaced with a multi-moduke-project's root folder, but I had to give up on that approach.
Anyway, the plugin gives me pretty much all the functionality of the maven-eclipse-plugin I ever used (of course there is a lot more though) and I'm happy with that. Perhaps I will build something similar once more in open source when this contract is finished.
Project configurators are the proposed approach. But the latest version of m2e-extensions is from early 2010 and developed against m2eclipse 0.10.x. There is a successor project called m2e-code-quality which is more recent and active and developed against m2eclipse 0.12.x.
But neither m2e-extensions nor m2e-code-quality do support FindBugs at the moment. And there are some other limitations with header files, exclusions and modified JARs.
I have successfully used a universal approach with AntRun, Ant and XMLTask to automatically add project natures, builders and configuration files for Eclipse plugins from pom.xml.