commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russel Winder <>
Subject Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
Date Mon, 10 Nov 2008 08:22:02 GMT

On Mon, 2008-11-10 at 06:11 +0000, John Spackman wrote:
[ . . . ]
> >Isn't this whole Subversion centralism problem solved by using a DVCS
> >such as Bazaar, or Git -- and soon, I gather, Mercurial.
> Yes, kind of - I've only recently come across Git and the concept of DVCS 
> but it was my intention to look at using a DVCS for this.

Bazaar is probably easier for Subversion users to get used to as the
command set is more aligned with that of Subversion.  (The same goes for
Mercurial, but it's Subversion interworking is not yet usable for
production working as far as I know.)

> But DVCS "only" does source code - setting up a seperate branch only works 
> if the community at large see the new branch, whereas the Commons group are 
> considering marking Jelly as "No Longer Maintained" and moving the 
> repository out of the main branch.

I tend to use Launchpad as a place to store Bazaar branches where the
host of the Subversion repository cannot support Bazaar.  GitHub seems
to be the place to store a Git repository in a similar circumstance.

A word of warning:  Using Bazaar or Git as a Subversion client is not
the same as using them as fully-fledged DVCS.  The need to rebase so as
to remain consistent with the Subversion repository means that  many of
the aspects of workflow of using DVCS have to be amended.  A Bazaar
branch of a Subversion repository or a Git clone of a Subversion
repository must always be treated as a view on the Subversion repository
and not used as a free standing branch/repository.

If anyone is in Oxford, UK 2009-04 then you might think about attending
the ACCU 2009 conference.  Jim Hague, Time Penhey and myself are doing a
session on DVCS.

> From my point of view, I would only want to perform a public branch with the 
> endorsment of the Commons team; IMHO it's important for new and existing 
> users to see a future for the project, and for there to be a link from the 
> official Commons website to the federated Jelly site.  The original 
> downloads would remain for backward compatability, but the Commons site 
> would clearly refer users onto the new site for upgrades and future 
> development.

I guess I am in the "XML is a data specification language and has no
right having a computational model, that's what dynamic languages like
Groovy, Python and Ruby are for." camp, so I don't see the demise of
Jelly as a problem.

Of course graceful demise is entirely appropriate.  The question I have
is whether putting effort into maintaining a demising system is worth it
compared to putting that effort into transferring to a different (more
appropriate, in my view) technology for dealing with the problem.  There
are some very nice candidates for Ant and Maven replacements out there:
Gant, Gradle and Buildr to name the obvious trio. (Disclosure:  I work
on Gant and Gradle :-) These provides for scripting rather than having
to create a plugin.

Dr Russel Winder                 Partner

Concertant LLP                   t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,              f: +44 8700 516 084
London SW11 1EN, UK.             m: +44 7770 465 077

View raw message