buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Boisvert <>
Subject Re: Buildfiles and Artifacts
Date Sat, 01 Jun 2013 15:40:24 GMT
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.


On Fri, May 31, 2013 at 4:11 AM, Ingo Schmidt <> wrote:

> Hi!
> I have a general question about buildfiles and artifacts.
> Let's say, I have 5 killer apps, much like in**
> 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
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 =;->

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message