Here's what I personally do/prefer in such cases, Broadly speaking, I like to keep the 'the-api' as a separate project from all 'killer-apps'.
I create a symbolic-name / reference to the latest version of 'the-api' that all 'killer-apps' should use, so they are all kept in sync. Killer-apps automaticaly use the latest version when a new version of 'the-api' is released. This can be as simple as sharing a version file pointer through Subversion/Git/S3/... though typically this file can contain the latest version of all shared dependencies between all 'killer-apps', and if you have common branches between killer-apps, you also branch the shared version file. (If you're familiar with Ivy, this is somewhat equivalent to the 'latest.release' and 'latest.integration' symbolic names) >From a development standpoint where I typically use Eclipse, I will often load both 'the-api' and one or more 'killer-app' into my workspace and link them as project instead of having killer-apps depend on the generated artifact. This allows for concurrent development across the-api and killer-apps without the overhead of separate projects pushing artifacts into the local repository for each change. alex On Fri, May 31, 2013 at 4:11 AM, Ingo Schmidt <[email protected]> wrote: > Hi! > > I have a general question about buildfiles and artifacts. > Let's say, I have 5 killer apps, much like in http://buildr.apache.org/** > packaging.html <http://buildr.apache.org/packaging.html>: > - la-web > - the-api > > For each killer app, "la-web" is different, but "the-api" is actually the > same. It is the core functionality which is used by "la-web". > > So now I see two options: > 1. Create a buildfile for "the-api", build a (maven) artifact with some > version number and include that in each killer app's build as a POM > dependency > 2. For each killer app, I create a folder layout as in > http://buildr.apache.org/**packaging.html<http://buildr.apache.org/packaging.html>and > build it all at once > > Currently, I have implemented option 1, however I am considering to use > version 2. The main reason is, that "the-api" is under heavy development > and gets new functionality very frequently. I would have to bump the > version like each week. Ok, I can use Snapshot versions, but what about > feature branches then? What versions to give them? And how to include in my > build? And also, why clutter my maven cache with lots of useless temporary > versions? > On the bright side, "the-api" project is self contained. Everything I need > to build is inside the project itself. > > With option 2, I would simply checkout the branches I want and build. No > hassle with version numbers, snapshots etc. But then I get other problems: > I would still want to be able to actually build "the-api" separately, but > where is my buildfile for it now? It is inside the killer-apps. Also, in > each killer app "the-api" is built in the same way, so the buildfile would > look identical. I would have redundant code, which I obviously want to > avoid. How to modularize? With include? With require? With some custom > tasks/extensions? > > Anyone who knows what I am talking about? What is your solution? > > Is there maybe a site with lot of buildfile examples where one could learn > some tricks? Maybe a Wiki could be created where people could post their > buildfiles and explain them? I would gladly post mine there. I think like > this everyone could benefit from each other. > > Anyway, glad to hearing opinions about my above scenario. > > Cheers, Ingo =;-> >
