I've been fighting with this for a while and reading a lot of docs pages and other questions but still can't get it to work.
In my ORMLite project, I have a ormlite-core project which has core functionality and then a -jdbc and -android projects (with more planned). Each of these sub-projects include the core functionality but add per-architecture implementations. I want to release a single set of jars for both the -jdbc and -android versions -- i.e. I want to copy the -core javadocs and sources into the resulting jars.
For the javadocs, it was cake with the includeDependencySources config entry set to true. However, I've been fighting for a while now on how to get the source jars released by the -android package to include the -core sources. I've tried the maven-dependency-plugin to copy and unpack the dependency sources to target/sources but I see no easy way to get them to be included in the source jar -- with the appropriate paths. I've gone over the maven-source-plugin and maven-assembly-plugin docs but I'm still in the dark.
If someone has figured out the magic maven fu to get this done, can they please share the appropriate working pom.xml examples? Thanks much.
I've reviewed the following similar questions among others. I've also looked at the Sonatype Maven manual and read a bunch web pages posing similar questions.
Delivering a single jar with a Maven project
Maven - 'all' or 'parent' project for aggregation?
While not an answer to the question, a possible reason why a parameter like <includeDependencySources> is not present for maven source plugin is because, while javadocs can be generated from a jar containing classes, the sources cannot be. The plugin cannot assume that the sources of the dependencies are available to it since they do not get installed by default.
I guess the best answer to this question at this time is "you can't get there from here". This requires extensions to the maven-source-plugin.
I ended up determining that combining these sub-projects into the same jar was not a good idea and now I release 3 separate jars.
Related
It's a .jar available in various versions at Maven Repo.
But what category is it? It is published by org.codehaus.groovy, the same outfit that I get my groovy-all dependency from. I also find that import groovy.sql doesn't work in a script unless I specifically include this dependency. So it would appear not to be part of the core language.
Outside a Gradle context I find that I have to manually put the .jar file under ~/.groovy/lib in order to use it. If I put the wrong version (e.g. 2.5.9 for 3.0.2) under ~/.groovy/lib the script won't run... even if I'm not using groovy.sql at all!
Is this a "dependency"? It seems a typically powerful and hassle-free Groovy way of manipulating databases. Are there any other powerful add-on (non-core) Groovy .jar file modules like this, which have to be manually placed under ~/.groovy/lib, that I should know about?
groovy consists of subprojects:
https://github.com/apache/groovy/tree/master/subprojects
and groovy-sql one of the subprojects
all subprojects are published in maven as separate libraries
prior to version 2.5 there was groovy-all-XX.jar that includes all other groovy libraries
https://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/2.4.19/
however starting from v 2.5 groovy-all represented by groovy-all-XX.pom that depends on all other groovy libraries
https://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/2.5.0/
so, to include all groovy features you have to specify groovy-all in your maven/gradle/... dependency
and finally useful site to dig dependencies:
https://mvnrepository.com/artifact/org.codehaus.groovy/groovy-all/3.0.2
When setting up h2o.ai for production the documentation tells you how "Build and extract a model" which ultimately leads you to
Download the MOJO and the resulting h2o-genmodel.jar
What I'm wondering, is if that h2o-genmodel.jar is really tied to the mojo zip file, or if one jar can work with multiple different model zips?
The latest h2o-genmodel.jar will work with all MOJO files. (Note that this is not the case for POJOs or with early versions of the h2o-genmodel.jar.)
I can update the documentation to include this clarification.
I'm new to Maven and have skimmed over the documentation as I am following the Hibernate tutorial at http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#tutorial-firstapp-mvn.
I have installed Maven and successfully setup a web-app but this does not contain all of the standard directories mentioned in the tutorial. Am I going mad?
When building my Maven project I am using the maven-archetype-webapp. This gives me the arh-webapp\src\main\resources and arh-webapp\src\main\webapp directories but I'm missing quite a few directories mentioned on the link http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html.
Surely I don't have to manually add these? If not then the Hibernate documentation does not mention what archetype to use in order to achieve the directory structure used in their tutorial. Please can someone enlighten me.
What archetype do I need to use in order to have the above directory plus the src/main/java directory? If there is no such archetype then can easily append these using Maven? and how?
Surely you'll have to manually add these.
Just create those directories that according to the Maven convention are missing. Remember, a Maven Archetype is just a starting point to save you time configuring your workspace. After encountering many problems in some Archetypes myself I've been accustomed to just use a basic-web-app-archetype and then customize it myself, as a beginner with Maven you'll be better off doing that, and will learn a lot.
Regards.
Not all the directories mentioned are required for your standard web application. In fact, the reason behind the presence of the src/main/java, src/main/resources and the src/main/webapp directories is due to the archetype that you've used.
IMHO, the book titled "Better Builds with Maven" will serve you better; the Sonatype books on Maven might also help. The complete Maven documentation is also available as a PDF file, for future reference.
But just in case, you need some clarity on the terms used, here's some:
Archetype: A pattern for projects. Simple web applications (with no dependencies on other frameworks/libraries) have their own archetypes, so do applications using Spring, Hibernate, Seam, etc. Some archetypes will result in creation of different directories, as they are coded that way. You might be able to change the directory structures in most cases, although I cannot vouch for every archetype. For instance, it is quite possible to place your sources in 'src' instead of 'src/main/java', although this requires additional configuration in the POM.
Lifecycles, Phases and Goals: A Maven build lifecycle is a series of phases, with each phase executing a set of goals. Maven can be commanded to execute a build phase, which results in execution of all phases until and including the specified phase.
Maven plugins: Maven plugins contain one or more goals. Goals need not be bound to phases, but usually you would bind them to particular phases. Plugins are the basis for everything operational in Maven; you're using plugins even though you are just compiling the application (the Maven compiler plugin is a core plugin that is present in the Maven distribution).
I hope the above helps, but I would suggest that the reference books be followed.
We are planning on restructuring a complex project with many modules/pieces, what ever you wanna call it. In order to move toward a standard directory structure, we would like to adopt the maven file structure.
So the big question is: Can anybody provide a description of the maven file structure, where we don't have to dig through all the maven speak?
Please see
http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
src/main/java Application/Library sources
src/main/resources Application/Library resources
src/main/filters Resource filter files
src/main/assembly Assembly descriptors
src/main/config Configuration files
src/main/webapp Web application sources
src/test/java Test sources
src/test/resources Test resources
src/test/filters Test resource filter files
src/site Site
LICENSE.txt Project's license
README.txt Project's readme
BTW, we did that migration on existing projects.
It was a really long and hard task to make everything work as intended, but we are finally done and happy with it.
UPDATED
When you have many projects, you have the same structure for each project.
Now the real problem starts when you want to group them. We had a hard time reading Maven documentation and best-practices, and deciding what was the appropriate structure for us.
The basic idea would be to group related projects in a common directory (that we call a module), allowing to process the module as a whole without listing them. But if you open the module in an IDE (Eclipse in our case), the projects themselves belong to it, but are not opened as subprojects (that notion doesn't exist in Eclipse).
We ended up with a strict hierarchy, that freed us from many maven problems:
The actual coding projects (java projects) are always leaf in our directory tree. They are the only ones we open in the IDE. They are of type JAR, or WAR.
Their parents/modules are always of type POM. They have no java code.
I've been using the same approach as Jens on a number of projects both with Maven 2.2.1 and now with Maven 3.0-alpha-6: POM modules define the module structure of your project tree, JAR/WAR modules are the leaves of the tree. All modules have the same version.
Advantages:
You can
place properties or dependencies on
specific levels in the module
hierarchy and they will be inherited
to all sub-modules.
You can build
related modules simply by going to
the appropriate level in the tree and
running "mvn install" - Maven will
work out the correct build order
according.
Various Maven plugins such
as the release plugin rely on this
tree structure.
The latest Maven
Eclipse plugin can handle this
structure very well and will
represent the tree as a flat list.
There is an experimental feature in
the plugin which ensures that
so-called "shadowed" artifacts appear
only once which helps when searching
for resources in Eclipse.
Disadvantages:
Extension takes some time. For instance, if you decide that a JAR module requires sub-modules, you will need to convert the existing JAR module into a POM module and then distribute its contents to the newly created JAR sub-modules as POM modules cannot contain any code themselves.
All the POM modules will appear in Eclipse and can slow down the build somewhat. Hoever, you can close them and Eclipse will source them from the repository instead.
Hi i am studying Spring In Action 2.0 and i am new to maven.
I am walking through the chapters and codes but i i got following error when i imported project through pom.xml on the pom editor in eclipse.
6/21/09 3:19:42 AM CDT: Missing
indirectly referenced artifact
incubator-activemq:activeio-core:jar:3.0-beta3:compile
6/21/09 3:19:42 AM CDT: Missing
indirectly referenced artifact
incubator-activemq:activemq-core:jar:4.0:compile
I downloaded the jar file and added to the library. still it does not work.
I am stuck what to do next? Can anyone help me with this?
Thanks in advance.
The referenced jars aren't available on the Maven2 central repository, so unless you have an additional repository declaration in your POM or an active profile in your settings, Maven will not know where to obtain the artifacts from.
There are a few public repositories like here and here hosting these artifacts.
To use these repositories you could add the relevant repository declaration to your POM or settings. See here for an example configuration.
Alternatively if you don't trust the repositories you could manually download the jars and put them into your local Maven repository, though you'd need to be careful to replicate the structure Maven expects, and you may well encounter the same problem for different jars.
Another alternative is to use a Maven repository manager like Nexus or Artifactory, to manage Maven's interactions with external repositories, though that is almost certainly too much information if you're just starting out.
For general help/information on Maven, check out the Maven book.