Received: by 10.90.82.14 with SMTP id f14mr990851agb.17.1289567158541;
        Fri, 12 Nov 2010 05:05:58 -0800 (PST)
X-BeenThere: projectclj---spec@googlegroups.com
Received: by 10.91.149.14 with SMTP id b14ls675013ago.6.p; Fri, 12 Nov 2010
 05:05:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.91.113.9 with SMTP id q9mr200118agm.2.1289567158202; Fri, 12
 Nov 2010 05:05:58 -0800 (PST)
Received: by f16g2000prj.googlegroups.com with HTTP; Fri, 12 Nov 2010 05:05:58
 -0800 (PST)
Date: Fri, 12 Nov 2010 05:05:58 -0800 (PST)
X-IP: 71.192.208.53
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12,gzip(gfe)
Message-ID: <68bd5e1b-62bb-44a1-8bdd-e5136dffab7b@f16g2000prj.googlegroups.com>
Subject: Minimizing the number of model implementations
From: Chas Emerick <cemer...@snowtide.com>
To: "Project.clj - SPEC" <projectclj---spec@googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1

It looks like the one other thread descended into minutiae pretty
quickly, but I wanted to raise an important meta issue.

AFAIK, it is relatively straightforward to add new serializations for
the POM in Polyglot Maven; IIRC it was Antony Blakey that added the
lein-compatible de/serializer to the Clojure pmaven project earlier
this year.

Assuming the cake and lein leads/communities can settle on a
serialization of project.clj and the semantics associated with each
key, etc, etc...it would seem to be a huge loss for everyone if
multiple implementations of that model were maintained.

Why not ensure that pmaven can consume/produce the serialization that
you agree upon?  Then, assuming cake and lein used pmaven (for the
model at the very least), *all* build tooling for Clojure will be
working off of the same model, and you guys wouldn't have to maintain
your own (surely slightly different) implementations of it.  Even
better, as tools add support for maven 3 / pmaven (such as hudson,
bamboo, IDE plugins, etc), lein and cake projects will be
indistinguishable to them.  Finally, you could add commands to your
respective frontends to drive various pmaven/maven-provided
functionality, such as generalized deployment, using existing maven
plugins, etc.

Perhaps this is already implicitly the plan, but I wanted to throw
this out there to either confirm that, or if not, suggest it.

Cheers,