clojure-contrib modularization, versions, and releases

[Stuart Sierra]

I am trying to prepare clojure-contrib for future development and
releases. What appears below is a proposal, for feedback and
suggestions from clojure-contrib committers. -S



BLOCKERS
========================================

Currently I am blocked by a failing test in clojure.contrib.logging,
which you can see here:
http://build.clojure.org/job/clojure-contrib/190/org.clojure.contrib$logging/console
I can't reproduce this failure on my machine.



clojure-contrib module versioning
========================================

All modules and functions which were deprecated in 1.2.0 have been
removed from clojure-contrib on the master branch. Thanks to Ben
Smith-Mannschott for fixing all the breakages.

The first release of modularized clojure-contrib will have all modules
at version "1.3.0". From that point forward, individual modules may
evolve and release new versions independently.

clojure-contrib version numbers will no longer correspond to Clojure
version numbers.



clojure-contrib module deployment
========================================

SNAPSHOT releases of modules will be automatically deployed to
build.clojure.org/snapshots by Hudson.

Stable (i.e., non-SNAPSHOT) releases of modules should be deployed to
build.clojure.org/releases but I don't yet know how to make this
happen.



clojure-contrib dependencies on Clojure
========================================

Every clojure-contrib module inherits configuration and dependencies
from the "parent" module. The parent module declares a dependency on
Clojure versions "[1.0.0,2.0.0)". This means "any version greater
than or equal to 1.0.0 but less than 2.0.0".

Individual sub-modules may override the Clojure dependency with
stricter version constraints.



clojure-contrib AOT-compilation
========================================

Only 4 modules require AOT-compilation: condition, fnmap, jmx, and
repl-ln.

By default, the parent module configuration disables all AOT-
compilation. This can be overridden on a per-module basis, see
http://github.com/clojure/clojure-contrib/blob/master/modules/condition/pom.xml#L26
for an example of how to enable AOT-compilation of specific
namespaces.

Unfortunately, AOT-compilation is still indiscriminately transitive.
This is slated to be fixed in a future release, see
https://www.assembla.com/spaces/clojure/tickets/322
This means that any dependencies of an AOT-compiled namespace will be
included in the compiled JAR for that module.

For now, clojure-contrib modules which require AOT-compilation *must*
declare a dependency on one specific version of Clojure, because the
compiled classes will be incompatible with any version of Clojure
other than the one they were compiled with.

[ataggart]

On Sep 3, 12:30 pm, Stuart Sierra <the.stuart.sie...@gmail.com> wrote:
> BLOCKERS
> ========================================
>
> Currently I am blocked by a failing test in clojure.contrib.logging,

> which you can see here:http://build.clojure.org/job/clojure-contrib/190/org.clojure.contrib$...

> I can't reproduce this failure on my machine.

I can't reproduce it either. The common theme across all 3 is they
check that an agent was used by binding send-off to a fn that flips a
flag (boolean atom) prior to calling the real send-off. Since the
immediately preceding assertion passes, either the test truly failed
(i.e., the agent wasn't used), or the flag-flip binding isn't being
applied. It's not clear to me why either should happen only on the
build machine.

Perhaps there's an alternate test that will pass, but without being
able to reproduce things I'll be stabbing in the dark.

At this point it's probably worthwhile to simply comment out those
three tests and get you moving again.

[bpsm]

On Sep 3, 9:30 pm, Stuart Sierra <the.stuart.sie...@gmail.com> wrote:
> I am trying to prepare clojure-contrib for future development and
> releases.  What appears below is a proposal, for feedback and
> suggestions from clojure-contrib committers.  -S
>
> BLOCKERS
> ========================================
>
> Currently I am blocked by a failing test in clojure.contrib.logging,

> which you can see here:http://build.clojure.org/job/clojure-contrib/190/org.clojure.contrib$...

> I can't reproduce this failure on my machine.
>
> clojure-contrib module versioning
> ========================================
>
> All modules and functions which were deprecated in 1.2.0 have been
> removed from clojure-contrib on the master branch.  Thanks to Ben
> Smith-Mannschott for fixing all the breakages.
>
> The first release of modularized clojure-contrib will have all modules
> at version "1.3.0".  From that point forward, individual modules may
> evolve and release new versions independently.
>
> clojure-contrib version numbers will no longer correspond to Clojure
> version numbers.

How will we handle the versioning of org.clojure.contrib:clojure-
contrib,
org.clojure.contrib:parent and org.clojure.contrib:complete?

I don't have a good pat answer for this one, I just know form
experience
that finding a good consistent way to do versioning in a multi-module
build,
particularly one providing something akin to 'combined' is tricky.

// Ben

[Stuart Sierra]

On Sep 8, 11:13 am, bpsm <bsmith.o...@gmail.com> wrote:
> How will we handle the versioning of org.clojure.contrib:clojure-
> contrib, org.clojure.contrib:parent and org.clojure.contrib:complete?

My thought is to have periodic "complete" releases, possibly
coinciding with Clojure releases, that gather the latest stable
versions of all other modules.

-S