I have two maven projects A and B, both of which I'm actively working on the source code for. Project A depends on B. If I want to build project A, does a snapshot (or release) of B need to exist in the repository? Or will maven check the parent directory of A to see if a project B exists (assuming my directory structure looks something like: projects/A projects/B)? And which would be better practice? thanks.
Jeff
Maven won't look anywhere except the repository hierarchy you specify, by default this is your .m2 directory (local repository) and the Maven Central Repository.
So yes, some version of B must exist in a repository.
You can also investigate project modules, where you have (for example) projects/pom.xml and when it is built, it will also build its children A and B in the correct order given their inter-dependencies - but you shouldn't see this as a solution to the problem you're describing without giving a lot of thought.
To get a good grasp on how the Dependency Mechanism works in maven and how to configure parent-child/submodule/subproject relations read this
Maven is a strange build tool in that it will look to the maven repository / artifactory for jars. As long as someone has built ProjectB and installed it in the artifactory, or as long as you have built ProjectB (with install) it will be available to ProjectA.
This also assumes you have setup the dependancy correctly in the pom file for ProjectA.
I used Maven on one project, and I'll go back to ant for a more standard build tool. It's really an odd duck.
Related
We have moved from Archiva to Nexus and are still using Maven 2.
We execute eclipse:eclipse locally so that Eclipse .project and .classpath files are generated, based on the dependencies in the POMs, and then we import the projects into Eclipse to do our development. We don't use M2Eclipse for a variety of reasons.
Since using Nexus, we have the problem that projects don't always reference each other in the workspace, rather they reference the respective JAR.
I have noticed that Nexus is appending a timestamp to the JAR name, and the MVN output states, e.g.:
[INFO] Artifact myapp-bom:jar:7.3.0.2.1-SNAPSHOT already available as a workspace project, but with different version. Expected: 7.3.0.2.1-20120508.115037-68, found: 7.3.0.2.1-SNAPSHOT
I get the feeling that is the reason why eclipse:eclipse generates .classpath files which contains JAR references (based on local maven repo) rather than project references. When we used Archiva (and there were no timestamps) then we used to get project references, and that is exactly what we want.
Has anyone else had this problem and how is it solved? I read that maven 3 forces timestamps to always be generated. Again, how do you get eclipse:eclipse to generate sensible .classpath files?
Cheers,
Ant
PS - some of our projects come from different SVN repositories. It seems that if the Eclipse Projects are refernced in the parent pom, eclipse:eclipse creates a project reference, but if the Eclipse Projects are from a different parent pom, but still in the workspace, then it can only generate JAR references.
The problem was resolved by using maven-eclipse-plugin (eclipse:eclipse) version 2.9, rather than 2.8! Doh...
We have a project which should be buildable by the customer using maven. It has some open source dependencies that are mavenized (no problem), some that aren't mavenized, proprietary stuff (oracle jdbc driver) and some internal stuff.
Until now we had everything but the first category packaged with the project itself in a local repository (repository with file://path-in-project-folder specified in the projects pom.xml).
We would love to move these out of the project, as we are about to use them in other projects as well. Currently we plan to use nexus as an internal maven repository.
Whats the best practice to make such dependencies/maven repositories available to the customer so he can continue to build the project.
Ideas so far:
Customer sets up a nexus repository as well, we somehow deploy all these non-public dependencies to his repository (like a mirror)
We provide a 'dumb' dump/snapshot of the non-public dependencies, customer adds this snapshot to this settings.xml as a repository, (but how is this possible).
Make our internal nexus repo available to the customers build server (not an option in our case)
I'm wondering how others solve these problems.
Thank you!
Of course, hosting a repository of some kind is a straightforward option, as long as you can cover the uptime / bandwidth / authentication requirements.
If you're looking to ship physical artifacts, you'll find this pattern helpful: https://brettporter.wordpress.com/2009/06/10/a-maven-friendly-pattern-for-storing-dependencies-in-version-control/
That relies on the repository being created in source control - if you want a project to build a repository, consider something like: http://svn.apache.org/viewvc/incubator/npanday/trunk/dist/npanday-repository-builder/pom.xml?revision=1139488&view=markup (using the assembly plugin's capability to build a repository).
Basically, by building a repository you can ship that with the source code and use file:// to reference it from within the build.
There are two options:
Document exactly what artifacts you need to compile which are not
available via Maven Central
Implement Nexus and make a export with Nexus give the export
to customer and they need to do a import of it. I'm not sure
if you come to licenses issues.
I assumed that you already have a Repository Manager already but it reads like you didn't.
I know there are various known issues with the M2eclipse plugin and I guess this is just one of them. Hopefully someone is aware of a solution or workaround.
We have like 30 projects in our workspace but for clarity lets assume there are only 2: A en B.
B includes A as a dependency in the pom.xml of B.
The problem we have is that in eclipse the classes of A can't be found so you get compilation errors. However, if you 'mvn install' A to deploy it in the local repository and the close project A then everything is fine; no compilation errors. So, if A exists in the project M2Eclipse does not seem to be able to correctly set the classpath in eclipse.
To make things stranger, we also have project C that also depends (in exactly the same way as B) on project A but here we have no compilation errors. We can't identify anything meaningful difference between project B or C; as said, they include A in the same manner.
thanks for your help,
Stijn
P.S. I'm using version 0.10.2.20100623 of the plugin
I've experienced this behavior before, and it has occurred for me in the past when I imported or checked out the maven projects separately.
Prerequisite: make sure you have m2extras installed before you check out a multi-module Maven project: update site
First thing to try: right-click each project and choose Maven -> update project configuration. The plugin might be smart enough to detect that it could be building project references between the projects.
Second thing to try (if your 30 projects are all submodules off one root): this would be easiest, because you could use the SCM integration of m2eclipse to do a "Checkout as Maven Project..." on the root pom. M2eclipse would make a project for the superpom and for each submodule, with project references built appropriately.
Third thing to try: I'd try manually creating project references in the project settings of each project to mirror their interdependencies. It'd be a lot of work, and unless you check in your eclipse .project/.settings (eww), it would have to be done individually for each working copy.
RESOLVED
finally, after agonizing hours I found the cause.
I was focussing on the .classpath and the .settings files but the problem was located in the .project file. This file in project A was missing following entry in the tag natures:
<nature>org.eclipse.wst.common.modulecore.ModuleCoreNature</nature>
Adding this resolved the issues.
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.