This may be more of a process then technology solution. I am currently working on a project that is split into a library and an implementation application. Doing this has been a very effective way to debug the library as the application is built. I would like to use Maven for both projects but I do not want to do a build and deploy for each minor change. Is there a way for Maven to reference the project as the repository almost?
You can have a "super-pom" which has two sub-projects. One project would be your library and the other project would be your application. Both can be developed individually.
Your application would have a dependency on the project with the library.
For example:
"super-pom": store this pom.xml in the higher up directory. You would have something like this in it:
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>your.group</groupId>
<artifactId>project</artifactId>
<packaging>pom</packaging>
<version>1.0-SNAPSHOT</version>
<name>caap</name>
<modules>
<module>project-library</module>
<module>project-app</module>
</modules>
</project>
Then your library pom.xml would have something like this:
<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>project</artifactId>
<groupId>your.group</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<groupId>=your.group</groupId>
<artifactId>project-library</artifactId>
<version>1.0-SNAPSHOT</version>
<name>project-library</name>
</project>
And your app would have something like this:
<?xml version="1.0" encoding="UTF-8"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd" xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>project</artifactId>
<groupId>your.group</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<groupId>=your.group</groupId>
<artifactId>project-application</artifactId>
<version>1.0-SNAPSHOT</version>
<name>project-application</name>
<dependencies>
<dependency>
<artifactId>project-library</artifactId>
<groupId>your.group</groupId>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
</project>
mvn install
Looks like what I want. Just running it from project will add it to the local repo and the other apps can pick it up.
You're right, this is a process question. I interpret your question as wanting to avoid declaring a specific version of the library as a dependency in the implementation. The intent is to update either component independently, in particular you want to be able to update the library without having to rebuild the implementation.
You will obviously need to rebuild and redeploy something if you make a change. However, I can see two steps that should address your concern. I'm going to call your components 'lib' and 'app'.
- Create an empty "wrapper" project, dependent (scope=runtime) on both lib and app. This wrapper is what you will deploy. When you update lib or app, you only need to update the version of that dependency in the wrapper project. When you "build" (compile is a no-op) and test the wrapper project, you'll confirm that the old/new app still works with the new/old lib, and you can deploy the update. Of course, if your tests fail you will need to update the app's lib dependency to see if a rebuild fixes the problem, and try to find which component has the bug. So this is only a halfway solution, in my opinion.
- Better is to also create a 'lib-api' component, which declares the interface between lib and app. Make lib and app both dependent on lib-api, but the app is not dependent on a specific version of lib. You may still want a wrapper project as above, to facilitate deployment (since you'll need to actually deploy both lib and app). But as long as you don't need to affect the library api, you can be confident that your changes to either lib or app are protected from each other and won't (can't) require a rebuild. This might make it easier to track down any bugs as well. If you need to update lib-api, you will obviously need to rebuild everything, but that would be true anyway and at least this way it's exposed in the project structure.
Hopefully this makes sense to you and I've correctly interpreted your question.