You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by John Spackman <jo...@zenesis.com> on 2008/11/09 05:35:16 UTC
Re: [jelly] Is jelly still in development vs. Open/Federated Commons
Hi Paul,
I agree that the website needs some changes although I had thought that this
was largely for broken links and for a consistent left-hand side menu;
updating the documentation for the taglibs is a pretty herculean task, not
least because in order to document a taglib you have to fully understand it
first, and that would often mean having a test environment and ideally a
practical application for them.
Generally, however, although not perfect I think that the current
documentation is "adequate" - it certainly was enough for me to get the
concepts and get going with it quickly.
Using Henri's analogies from his recent blog, I took Jelly home from the
Commons a couple of years ago and we're now ready to "put it in the window
and see if we're invited to play". If we're invited to play then great -
any changes we make will be contributed back (and documentation will come
with those changes) - but my "home life" is a small business that keeps me
very busy and my focus here is on gradually contributing fixes/improvements
and documentation rather than taking Jelly a great leap forward as an O/S
product.
I am prepared to upgrade Jelly to Maven2 (not that I know much about what
that involves, yet) and to improve the website but I have to be confident
that the changes will happen quickly and easily, and that the project will
not be retired. Please don't get me wrong - I am very grateful for your
offer to apply patches etc sent via JIRA but I am cautious as I think of the
potential extra work that would entail and how much simpler it would be if I
could just issue an SVN commit.
Returning again to Henri's blog, instead of Jelly being a first use case for
retiring a commons project, how about it being a first use case for a
"Federated Commons" subproject? I appreciate the point that making commits
open to anybody has it's problems and is not something the team want to do
right now, but given that the list is contemplating retiring Jelly this
could be an ideal opportunity to experiment with something where the team
has little to lose. The original SVN archive would remain intact at Apache,
and I'd take a copy of it for my 1.x trunk so that I could create branches
(possibly using Git); any projects already using Jelly 1.0 would be
completely unaffected, but new users and users wishing to update would be
referred to the new Federated Jelly website & repository.
Regards,
John
----- Original Message -----
From: "Paul Libbrecht" <pa...@activemath.org>
To: "Commons Developers List" <de...@commons.apache.org>
Sent: Saturday, November 08, 2008 11:27 PM
Subject: Re: [jelly] Is jelly still in development
Hello John,
I think it would be lovely to start some maintenance and to get an
extra committer aboard.
The procedure to become so, however, really starts with the "other
methods" (mailing-list and jira in particular).
The focus on the core of jira is rather happy.
I am more than happy to restrict such things as the xml taglib which
has been my main usage of jelly (together with ant).
As a first maintenance suggestion, ignoring a possible retirement, I
would really like to get the web-pages in a more up-to-date state.
(correct getting-started, tag-ref somewhat consistent, ...).
How doable would it be for you to tackle such repair?
I could then try to apply a patch you submit to jira.
I am not sure (and hope not) that the web-site can only be fixed by
the migration to maven2...
paul
Le 08-nov.-08 à 10:20, John Spackman a écrit :
> We're still actively using Jelly and while the usefulness of some of the
> extension modules may be debatable (and definitely without wishing to
> enter into a debate of whether it is appropriate to have "executable"
> data), as a core tool Jelly has allowed us to rapidly produce pluggable
> languages for defining drawings, web services, schedules, JDBC
> configuration, and more where the tag implementation configures POJOs.
>
> Coincidentally, we've recently reached the point where we must make
> changes to the code base (bug fixes and new features) and so a couple of
> weeks ago I emailed James asking if he was still maintaining the project
> and if so what is plans were and whether I'd be able to contribute.
> Perhaps not surprisingly I didn't receive a reply, and now it seems I
> might have broken protocol by asking him direct instead of asking here.
> My apologies if that was inappropriate.
>
> We have a number of changes to make to Jelly, and I am prepared to put
> myself and my company forward as a maintainer. If that's acceptable to
> you all, the first task would be to briefly update the website and make a
> maintenance release (there are some essential bug fixes in SVN that are
> not in the official release), followed by various other fixes and
> additions in a beta release. Admittedly, my focus would be the core of
> Jelly and the core tags - I do not use the additional tag libraries and
> would find it difficult to provide a significant amount of regression
> testing and support for them but I'll keep them going where possible and
> try to help out any users with problems.
>
> Is this something you would be interested in? If the conclusion by the
> list is that Jelly should still be retired then as an alternative would
> it be possible for me to fork the Jelly project out of commons and into
> (for example) SourceForge?
>
> In case it makes a difference, I am not currently an Apache committer.
>
> Regards,
> John
>
> ----- Original Message ----- From: "Henri Yandell" <fl...@gmail.com>
> To: "Commons Developers List" <de...@commons.apache.org>; <rgoers@apache.org
> >
> Sent: Friday, November 07, 2008 12:00 AM
> Subject: Re: [jelly] Is jelly still in development
>
>
>> On Thu, Nov 6, 2008 at 3:11 PM, ralph.goers @dslextreme.com
>> <rg...@apache.org> wrote:
>>> On Thu, Nov 6, 2008 at 11:44 AM, Henri Yandell <fl...@gmail.com>
>>> wrote:
>>>
>>>>
>>>> I'm thinking we should:
>>>>
>>>> a) remove from trunks-proper
>>>> b) Update the homepage to say "Not Actively Maintained"
>>>> c) Update the Commons homepage to put this into a release subcategory
>>>> of "Not Actively Maintained"
>>>> d) Put said N.A.M. note on the JIRA page.
>>>>
>>>> Thoughts?
>>>>
>>> If it is removed from trunks-proper where does it go?
>>
>> trunks-proper is a dir of svn:externals, so it's not lost just not in
>> our active development set.
>>
>> Hen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
Posted by Rahul Akolkar <ra...@gmail.com>.
On Tue, Nov 11, 2008 at 4:05 AM, Russel Winder
<ru...@concertant.com> wrote:
> On Mon, 2008-11-10 at 17:27 -0500, Rahul Akolkar wrote:
>> On Mon, Nov 10, 2008 at 3:22 AM, Russel Winder
>> <ru...@concertant.com> wrote:
>> <big-snip/>
>>
>> I think the bulk of this message would have been better off in a new
>> thread, marked [OT].
>
> Possibly but I didn't think of it. On other lists that would have been
> seen as inappropriate. So many lists, so many different protocols :-)
>
<snip/>
Understandable :-)
>> Some of these discussions have been happening at the ASF, on a more
>> appropriate list whose public archives are here:
>>
>> http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/
>
> OK, it seems like Apache have already made the decision to go with Git,
> it appears to be the only DVCS mentioned in the posts.
>
<snap/>
There have been discussions mainly involving Git, but no such decision
has been made (and IMO, neither is it imminent).
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
Posted by Russel Winder <ru...@concertant.com>.
On Mon, 2008-11-10 at 17:27 -0500, Rahul Akolkar wrote:
> On Mon, Nov 10, 2008 at 3:22 AM, Russel Winder
> <ru...@concertant.com> wrote:
> <big-snip/>
>
> I think the bulk of this message would have been better off in a new
> thread, marked [OT].
Possibly but I didn't think of it. On other lists that would have been
seen as inappropriate. So many lists, so many different protocols :-)
> Some of these discussions have been happening at the ASF, on a more
> appropriate list whose public archives are here:
>
> http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/
OK, it seems like Apache have already made the decision to go with Git,
it appears to be the only DVCS mentioned in the posts.
[ . . . ]
--
Russel.
====================================================
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
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
Posted by Rahul Akolkar <ra...@gmail.com>.
On Mon, Nov 10, 2008 at 3:22 AM, Russel Winder
<ru...@concertant.com> wrote:
<big-snip/>
I think the bulk of this message would have been better off in a new
thread, marked [OT].
Some of these discussions have been happening at the ASF, on a more
appropriate list whose public archives are here:
http://mail-archives.apache.org/mod_mbox/www-infrastructure-dev/
>
> 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.
<snap/>
The fact is, any component in Commons Proper will continue to live on
as long as folks contribute to it (and contributions are welcome for
any part of Commons). Other options are often available, but thats
besides the point if folks care to continue contributing.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
Posted by Russel Winder <ru...@concertant.com>.
John,
On Tue, 2008-11-11 at 05:28 +0000, John Spackman wrote:
[ . . . ]
> I think you're talking about a different "problem" - Jelly is used for far
> more than Ant/Maven replacement (I don't usually use either) and maintaining
> it is not an altruistic choice for me, but a practical one because I find it
> so very useful.
Well that implies continued existence which implies Apache should not
retire it but allow those people who are prepared to maintain it some
mechanism to maintain and release.
But then I am pretty much an outsider here.
--
Russel.
====================================================
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
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
Posted by John Spackman <jo...@zenesis.com>.
Hi Russel,
>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:
I think you're talking about a different "problem" - Jelly is used for far
more than Ant/Maven replacement (I don't usually use either) and maintaining
it is not an altruistic choice for me, but a practical one because I find it
so very useful.
John
----- Original Message -----
From: "Russel Winder" <ru...@concertant.com>
To: "Commons Developers List" <de...@commons.apache.org>
Sent: Monday, November 10, 2008 8:22 AM
Subject: Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
Posted by Russel Winder <ru...@concertant.com>.
John,
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.
<light-marketing>
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.
</light-marketing>
> 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.
--
Russel.
====================================================
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
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
Posted by John Spackman <jo...@zenesis.com>.
Fair comment; I've created a seperate JIRA entry JELLY-286 so that this
conversation is kept seperate from the issues themselves and because it gets
virtually impossible to seperate subsequent patches.
I've started going through the JIRA issues from the top and have done 17 so
far; the patch in JELLY-286 fixes 5 bugs, and AFAICT many of the other 12
issues can be recategorised. Here's my list:
230 "Problem with default namespace in imported scripts" - NOTABUG
187 "Wrong composite expression evaluation" - FIXED
180 "ClassLoader Problems with XMLParser and XMLParser reuse" - DUPLICATE 44
184 "Using namespace-prefixes breaks Jelly" - FIXED
170 "Nested scripts should be compiled and cached" - IMPRACTICAL
193 & 167 "add 'public JellyContext newEmptyJellyContext()' to
JellyContext" - Pending patch being applied
165 "CatchTag closest from java tryCatch block (with expected exceptions
list)" - FIXED
163 "Allow Expressions to throw exceptions" - FIXED
144 "XMLParser should not depend on JellyContext" - POSTPONED (requires more
consideration and anyway would mandate API changes)
143 "Support for pluggable expression languages" - POSTPONED
121 "Policy for output of lexical XML data" - POSTPONED
188 "Core should have a forTokens tag" - POSTPONED (what conclusion from
comments in JIRA?)
112 "Create Script from SAX events" - NOTABUG
44 "[jelly] ClassLoader Problems with XMLParser and XMLParser reuse" -
POSTPONED
82 "Add UseVector tag" - POSTPONED (no response from submitter)
13 "Jelly should throw an exception if an unknown tag is used in a
TagLibrary" - FIXED
Regards,
John
----- Original Message -----
From: "sebb" <se...@gmail.com>
To: "Commons Developers List" <de...@commons.apache.org>
Sent: Tuesday, November 11, 2008 11:48 AM
Subject: Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
On 11/11/2008, John Spackman <jo...@zenesis.com> wrote:
> Hi Paul,
>
> Great :)
>
> I'm working on some addition patches for JELLY-184 and a few others; they
> don't always make a lot of sense added to a single JIRA entry though, IE
> patch for one bug affecting the patch script for another - is it OK to
> just
> email an update here instead?
>
Please do not send patches to the mailing list, unless they are *very*
small.
It's much more difficult to keep track of them, and to reference them
in SVN logs.
Also, JIRA has a checkbox to say that you grant ASF the rights to use the
patch.
If there are several JIRA issues, but one patch, then I suggest adding
the patch to one issue, and list which other issues it fixes. The
issues can also be linked together.
> John
>
> ----- Original Message ----- From: "Paul Libbrecht" <pa...@activemath.org>
> To: "Commons Developers List" <de...@commons.apache.org>
> Sent: Tuesday, November 11, 2008 9:19 AM
>
> Subject: Re: [jelly] Is jelly still in development vs.
> Open/FederatedCommons
>
>
> We're converging John here,
>
> I'll try to keep up with patches and commits in order for you to
> become a committer.
> Henri, can you please agree that we "try to make jelly enter a
> maintained mode", within a month or so, before we show "not actively
> maintained" on the web-page?
>
> thanks in advance
>
> paul
>
>
>
>
> Le 11-nov.-08 à 06:28, John Spackman a écrit :
>
>
> > Hi Paul,
> >
> > I agree that this is _not_ something where a technical solution is
> _needed_ to go forward, I'm simply trying to keep the options open so
> that
> Jelly does not disappear (IMHO marking a project as "Not Actively
> Maintained" is the beginning of the end).
> >
> > IMHO keeping Jelly in Commons Proper is the best choice for Jelly,
> > while
> the 2nd choice is to keep it alive elsewhere as a federated Commons is a
> close second, the 3rd choice as a last resort is to create a fork. And I
> also agree that you need to be able to see who you're supporting, hence
> the
> reason for a patch submission to JIRA yesterday (with a follow-up in
> response to your comments today).
> >
> > John
> >
> > ----- Original Message ----- From: "Paul Libbrecht" <paul@activemath.org
> > >
> > To: "Commons Developers List" <de...@commons.apache.org>
> > Sent: Monday, November 10, 2008 11:16 AM
> > Subject: Re: [jelly] Is jelly still in development vs. Open/
> FederatedCommons
> >
> >
> > John,
> >
> > Le 10-nov.-08 à 07:11, John Spackman a écrit :
> >
> > > 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.
> > > 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.
> > >
> >
> > Hey no!
> > It's lacking maintainer and we shall be more than happy to make you a
> > committer having been able to measure the quality of contributions!
> >
> > The problem is not the technical approach of DVCS, the problem is only
> > endorsement: it seems rather normal that a person that hasn't been
> > seen is first a bit observed or?
> >
> > Setting up a separate fork for a while to achieve this sounds an
> > avenue to me.
> > Suggesting patches on jira or any other method or paced-down
> > contribution should be supported.
> > I'm happy to receive your source tree from time to time, in full,
> > inspect it and commit it as is for example.
> >
> >
> > > 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 don't see any reason why commons would say "things are happening
> > elsewhere" while it could happen here real soon now. The issue is
> > endorsement and not distribution.
> >
> > paul
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
Posted by sebb <se...@gmail.com>.
On 11/11/2008, John Spackman <jo...@zenesis.com> wrote:
> Hi Paul,
>
> Great :)
>
> I'm working on some addition patches for JELLY-184 and a few others; they
> don't always make a lot of sense added to a single JIRA entry though, IE
> patch for one bug affecting the patch script for another - is it OK to just
> email an update here instead?
>
Please do not send patches to the mailing list, unless they are *very* small.
It's much more difficult to keep track of them, and to reference them
in SVN logs.
Also, JIRA has a checkbox to say that you grant ASF the rights to use the patch.
If there are several JIRA issues, but one patch, then I suggest adding
the patch to one issue, and list which other issues it fixes. The
issues can also be linked together.
> John
>
> ----- Original Message ----- From: "Paul Libbrecht" <pa...@activemath.org>
> To: "Commons Developers List" <de...@commons.apache.org>
> Sent: Tuesday, November 11, 2008 9:19 AM
>
> Subject: Re: [jelly] Is jelly still in development vs.
> Open/FederatedCommons
>
>
> We're converging John here,
>
> I'll try to keep up with patches and commits in order for you to
> become a committer.
> Henri, can you please agree that we "try to make jelly enter a
> maintained mode", within a month or so, before we show "not actively
> maintained" on the web-page?
>
> thanks in advance
>
> paul
>
>
>
>
> Le 11-nov.-08 à 06:28, John Spackman a écrit :
>
>
> > Hi Paul,
> >
> > I agree that this is _not_ something where a technical solution is
> _needed_ to go forward, I'm simply trying to keep the options open so that
> Jelly does not disappear (IMHO marking a project as "Not Actively
> Maintained" is the beginning of the end).
> >
> > IMHO keeping Jelly in Commons Proper is the best choice for Jelly, while
> the 2nd choice is to keep it alive elsewhere as a federated Commons is a
> close second, the 3rd choice as a last resort is to create a fork. And I
> also agree that you need to be able to see who you're supporting, hence the
> reason for a patch submission to JIRA yesterday (with a follow-up in
> response to your comments today).
> >
> > John
> >
> > ----- Original Message ----- From: "Paul Libbrecht" <paul@activemath.org
> > >
> > To: "Commons Developers List" <de...@commons.apache.org>
> > Sent: Monday, November 10, 2008 11:16 AM
> > Subject: Re: [jelly] Is jelly still in development vs. Open/
> FederatedCommons
> >
> >
> > John,
> >
> > Le 10-nov.-08 à 07:11, John Spackman a écrit :
> >
> > > 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.
> > > 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.
> > >
> >
> > Hey no!
> > It's lacking maintainer and we shall be more than happy to make you a
> > committer having been able to measure the quality of contributions!
> >
> > The problem is not the technical approach of DVCS, the problem is only
> > endorsement: it seems rather normal that a person that hasn't been
> > seen is first a bit observed or?
> >
> > Setting up a separate fork for a while to achieve this sounds an
> > avenue to me.
> > Suggesting patches on jira or any other method or paced-down
> > contribution should be supported.
> > I'm happy to receive your source tree from time to time, in full,
> > inspect it and commit it as is for example.
> >
> >
> > > 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 don't see any reason why commons would say "things are happening
> > elsewhere" while it could happen here real soon now. The issue is
> > endorsement and not distribution.
> >
> > paul
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
> >
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
Posted by Rahul Akolkar <ra...@gmail.com>.
On Tue, Nov 11, 2008 at 4:19 AM, Paul Libbrecht <pa...@activemath.org> wrote:
> We're converging John here,
>
> I'll try to keep up with patches and commits in order for you to become a
> committer.
> Henri, can you please agree that we "try to make jelly enter a maintained
> mode", within a month or so, before we show "not actively maintained" on the
> web-page?
>
<snip/>
I think that'd be quite appropriate, if you wanted to.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
Posted by John Spackman <jo...@zenesis.com>.
Hi Paul,
Great :)
I'm working on some addition patches for JELLY-184 and a few others; they
don't always make a lot of sense added to a single JIRA entry though, IE
patch for one bug affecting the patch script for another - is it OK to just
email an update here instead?
John
----- Original Message -----
From: "Paul Libbrecht" <pa...@activemath.org>
To: "Commons Developers List" <de...@commons.apache.org>
Sent: Tuesday, November 11, 2008 9:19 AM
Subject: Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
We're converging John here,
I'll try to keep up with patches and commits in order for you to
become a committer.
Henri, can you please agree that we "try to make jelly enter a
maintained mode", within a month or so, before we show "not actively
maintained" on the web-page?
thanks in advance
paul
Le 11-nov.-08 à 06:28, John Spackman a écrit :
> Hi Paul,
>
> I agree that this is _not_ something where a technical solution is
> _needed_ to go forward, I'm simply trying to keep the options open so
> that Jelly does not disappear (IMHO marking a project as "Not Actively
> Maintained" is the beginning of the end).
>
> IMHO keeping Jelly in Commons Proper is the best choice for Jelly, while
> the 2nd choice is to keep it alive elsewhere as a federated Commons is a
> close second, the 3rd choice as a last resort is to create a fork. And I
> also agree that you need to be able to see who you're supporting, hence
> the reason for a patch submission to JIRA yesterday (with a follow-up in
> response to your comments today).
>
> John
>
> ----- Original Message ----- From: "Paul Libbrecht" <paul@activemath.org
> >
> To: "Commons Developers List" <de...@commons.apache.org>
> Sent: Monday, November 10, 2008 11:16 AM
> Subject: Re: [jelly] Is jelly still in development vs. Open/
> FederatedCommons
>
>
> John,
>
> Le 10-nov.-08 à 07:11, John Spackman a écrit :
>> 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.
>> 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.
>
> Hey no!
> It's lacking maintainer and we shall be more than happy to make you a
> committer having been able to measure the quality of contributions!
>
> The problem is not the technical approach of DVCS, the problem is only
> endorsement: it seems rather normal that a person that hasn't been
> seen is first a bit observed or?
>
> Setting up a separate fork for a while to achieve this sounds an
> avenue to me.
> Suggesting patches on jira or any other method or paced-down
> contribution should be supported.
> I'm happy to receive your source tree from time to time, in full,
> inspect it and commit it as is for example.
>
>> 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 don't see any reason why commons would say "things are happening
> elsewhere" while it could happen here real soon now. The issue is
> endorsement and not distribution.
>
> paul
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
Posted by Paul Libbrecht <pa...@activemath.org>.
We're converging John here,
I'll try to keep up with patches and commits in order for you to
become a committer.
Henri, can you please agree that we "try to make jelly enter a
maintained mode", within a month or so, before we show "not actively
maintained" on the web-page?
thanks in advance
paul
Le 11-nov.-08 à 06:28, John Spackman a écrit :
> Hi Paul,
>
> I agree that this is _not_ something where a technical solution is
> _needed_ to go forward, I'm simply trying to keep the options open
> so that Jelly does not disappear (IMHO marking a project as "Not
> Actively Maintained" is the beginning of the end).
>
> IMHO keeping Jelly in Commons Proper is the best choice for Jelly,
> while the 2nd choice is to keep it alive elsewhere as a federated
> Commons is a close second, the 3rd choice as a last resort is to
> create a fork. And I also agree that you need to be able to see who
> you're supporting, hence the reason for a patch submission to JIRA
> yesterday (with a follow-up in response to your comments today).
>
> John
>
> ----- Original Message ----- From: "Paul Libbrecht" <paul@activemath.org
> >
> To: "Commons Developers List" <de...@commons.apache.org>
> Sent: Monday, November 10, 2008 11:16 AM
> Subject: Re: [jelly] Is jelly still in development vs. Open/
> FederatedCommons
>
>
> John,
>
> Le 10-nov.-08 à 07:11, John Spackman a écrit :
>> 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.
>> 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.
>
> Hey no!
> It's lacking maintainer and we shall be more than happy to make you a
> committer having been able to measure the quality of contributions!
>
> The problem is not the technical approach of DVCS, the problem is only
> endorsement: it seems rather normal that a person that hasn't been
> seen is first a bit observed or?
>
> Setting up a separate fork for a while to achieve this sounds an
> avenue to me.
> Suggesting patches on jira or any other method or paced-down
> contribution should be supported.
> I'm happy to receive your source tree from time to time, in full,
> inspect it and commit it as is for example.
>
>> 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 don't see any reason why commons would say "things are happening
> elsewhere" while it could happen here real soon now. The issue is
> endorsement and not distribution.
>
> paul
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
Posted by John Spackman <jo...@zenesis.com>.
Hi Paul,
I agree that this is _not_ something where a technical solution is _needed_
to go forward, I'm simply trying to keep the options open so that Jelly does
not disappear (IMHO marking a project as "Not Actively Maintained" is the
beginning of the end).
IMHO keeping Jelly in Commons Proper is the best choice for Jelly, while the
2nd choice is to keep it alive elsewhere as a federated Commons is a close
second, the 3rd choice as a last resort is to create a fork. And I also
agree that you need to be able to see who you're supporting, hence the
reason for a patch submission to JIRA yesterday (with a follow-up in
response to your comments today).
John
----- Original Message -----
From: "Paul Libbrecht" <pa...@activemath.org>
To: "Commons Developers List" <de...@commons.apache.org>
Sent: Monday, November 10, 2008 11:16 AM
Subject: Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
John,
Le 10-nov.-08 à 07:11, John Spackman a écrit :
> 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.
> 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.
Hey no!
It's lacking maintainer and we shall be more than happy to make you a
committer having been able to measure the quality of contributions!
The problem is not the technical approach of DVCS, the problem is only
endorsement: it seems rather normal that a person that hasn't been
seen is first a bit observed or?
Setting up a separate fork for a while to achieve this sounds an
avenue to me.
Suggesting patches on jira or any other method or paced-down
contribution should be supported.
I'm happy to receive your source tree from time to time, in full,
inspect it and commit it as is for example.
> 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 don't see any reason why commons would say "things are happening
elsewhere" while it could happen here real soon now. The issue is
endorsement and not distribution.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
Posted by Paul Libbrecht <pa...@activemath.org>.
John,
Le 10-nov.-08 à 07:11, John Spackman a écrit :
> 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.
> 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.
Hey no!
It's lacking maintainer and we shall be more than happy to make you a
committer having been able to measure the quality of contributions!
The problem is not the technical approach of DVCS, the problem is only
endorsement: it seems rather normal that a person that hasn't been
seen is first a bit observed or?
Setting up a separate fork for a while to achieve this sounds an
avenue to me.
Suggesting patches on jira or any other method or paced-down
contribution should be supported.
I'm happy to receive your source tree from time to time, in full,
inspect it and commit it as is for example.
> 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 don't see any reason why commons would say "things are happening
elsewhere" while it could happen here real soon now. The issue is
endorsement and not distribution.
paul
Re: [jelly] Is jelly still in development vs. Open/FederatedCommons
Posted by John Spackman <jo...@zenesis.com>.
Hi Russel,
> Forgive me for butting in on a conversation but . . .
Anytime :)
>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.
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.
>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.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jelly] Is jelly still in development vs. Open/Federated
Commons
Posted by Russel Winder <ru...@concertant.com>.
On Sun, 2008-11-09 at 04:35 +0000, John Spackman wrote:
[ . . . ]
> I am prepared to upgrade Jelly to Maven2 (not that I know much about what
> that involves, yet) and to improve the website but I have to be confident
> that the changes will happen quickly and easily, and that the project will
> not be retired. Please don't get me wrong - I am very grateful for your
> offer to apply patches etc sent via JIRA but I am cautious as I think of the
> potential extra work that would entail and how much simpler it would be if I
> could just issue an SVN commit.
[ . . . ]
Forgive me for butting in on a conversation but . . .
Isn't this whole Subversion centralism problem solved by using a DVCS
such as Bazaar, or Git -- and soon, I gather, Mercurial.
Bazaar and Git can both be used as Subversion clients, using the bzr-svn
and git-svn plugins respectively -- and I believe Mercurial will getting
equivalent capability in the future. A Bazaar branch and a Git
repository carry the entire history, can be rebased, can be used to
create patches, and indeed you can commit to a Subversion repository
direct from a branch or repository.
For a couple of my projects, Codehaus is the host so the central
mainline is a Subversion repository. However most work is done using
Bazaar or Git since people do not need an account to be able to work
using a full VCS. Using a DVCS makes working on a FOSS project truly
open.
--
Russel.
====================================================
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
Re: [jelly] Is jelly still in development vs. Open/Federated Commons
Posted by John Spackman <jo...@zenesis.com>.
Hi Henri,
>>> Using Henri's analogies from his recent blog, I took Jelly home from the
>>> Commons a couple of years ago and we're now ready to "put it in the
>>> window
>>> and see if we're invited to play" [...snip...]
>As below - analogy was about other Apache projects but probably
>applies here as you say.
It's slowly dawned on me that Commons isn't a collection of independant
projects under a title but a single project - that explained quite a bit
about how things work :)
>There's also a legal bit - need to get committers to sign CLAs as
>they're expected to do larger pieces of work.
I don't have a scanner here but I'll put that on my todo list for when I get
back next week
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jelly] Is jelly still in development vs. Open/Federated Commons
Posted by Henri Yandell <fl...@gmail.com>.
Repling inline to both Paul and John:
On Sun, Nov 9, 2008 at 2:26 PM, Paul Libbrecht <pa...@activemath.org> wrote:
>
> Le 09-nov.-08 à 05:35, John Spackman a écrit :
<snip>
>> Using Henri's analogies from his recent blog, I took Jelly home from the
>> Commons a couple of years ago and we're now ready to "put it in the window
>> and see if we're invited to play". If we're invited to play then great -
>> any changes we make will be contributed back (and documentation will come
>> with those changes) - but my "home life" is a small business that keeps me
>> very busy and my focus here is on gradually contributing fixes/improvements
>> and documentation rather than taking Jelly a great leap forward as an O/S
>> product.
As below - analogy was about other Apache projects but probably
applies here as you say. Don't worry about great leap forwards btw -
scratch your itch to reduce maintenance pain of your fork; that's all
anyone does and it adds up to value.
<snip>
> We can make a vote on that... or we can simply try to make it cleaner and
> start applying code patches. I don't think retirement was what Henri
> suggested.
Paul: Well... definitely a strong line towards retirement. :)
Informing users that it's an inactive project.
>> Please don't get me wrong - I am very grateful for your offer to apply
>> patches etc sent via JIRA but I am cautious as I think of the potential
>> extra work that would entail and how much simpler it would be if I could
>> just issue an SVN commit.
>
> I fully understand but Apache foundations' practice has really always been
> such.
There are a few bits at play here. There's a cultural pressure in that
we don't want to give committer rights to people until they show
commitment as we're indicating to the rest of Apache's communities
that this person has shown commitment somewhere.
There's also a legal bit - need to get committers to sign CLAs as
they're expected to do larger pieces of work.
>> Returning again to Henri's blog, instead of Jelly being a first use case
>> for retiring a commons project, how about it being a first use case for a
>> "Federated Commons" subproject?
Blog wise that was targetted more at the Commons like components
inside other Apache projects, than moving an item out of Commons.
>> I appreciate the point that making commits
>> open to anybody has it's problems and is not something the team want to do
>> right now, but given that the list is contemplating retiring Jelly this
>> could be an ideal opportunity to experiment with something where the team
>> has little to lose.
>> The original SVN archive would remain intact at Apache,
>> and I'd take a copy of it for my 1.x trunk so that I could create branches
>> (possibly using Git); any projects already using Jelly 1.0 would be
>> completely unaffected, but new users and users wishing to update would be
>> referred to the new Federated Jelly website & repository.
There's a separate concept called Apache Attic that this fits into.
Basically Apache will retire something and if people want it to
continue life there are various ways back, including the one above of
a fork being created elsewhere and linked to from Apache as a known
fork that people are recommended to go get involved in. Though the
plan isn't to do it for Commons components per se - as usual Commons
doesn't quite fit the model :) Reminds me that I need to send in the
board resolution/proposal for that ... I've been in a maintenance
process mood recently it seems :/
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jelly] Is jelly still in development vs. Open/Federated Commons
Posted by John Spackman <jo...@zenesis.com>.
Hi Paul,
>I wasn't talking about *writing the documentation* but cleanly linking to
>it.
Ah, ISWYM! In that case I completely agree :)
>> I am prepared to upgrade Jelly to Maven2 (not that I know much about
>> what that involves, yet)
>I would rather disadvise that especially for the huge effort of maven 1
>scripting that was put in jelly building.
Oh OK - this really underlines my lack of familiarity with the Commons group
because I was under the impression that M2 was wanted across the project.
>> Returning again to Henri's blog, instead of Jelly being a first use case
>> for retiring a commons project, how about it being a first use case for
>> a "Federated Commons" subproject? [...snip...]
>And you would host that?
Not me personally but an independent body such as SourceForge, Codehaus,
etc; anything so long as it's open and easily accessible for everyone, and
can have any/all Commons members immediately added as project administrators
>That might be a clean way to attempt maybe...
>and I see this fairly easy to use so as to port back changes although it
>might byte us from time to time.
>I think a self-hosted fixed web-site is, for example, a very useful thing
>to use!
Cool! This is actually my preferred option and I hope it would give the
Commons team a way to wind-down a project which is no longer key, but at the
same time to keep it alive and get some bugs fixed and patches applied.
Most importantly, using Git or similar would mean that there is a route back
into the Commons in the future if necessary.
>What about identifying a handful of issues that you think you could submit
>one or several patches for?
I'm on holiday right now so the quickest way for you to see something would
be to generate a patch for a bug I've recently found and fixed with
selecting the expression parser - please see JELLY-285. The patch includes
inline documentation and test cases.
I quickly went through the top 10 bugs in JIRA (ordered by priority) and
there are 6 bug reports already with patches ready to be added; of the
remaining 4, 1 was without a straightforward test case, 1 minor feature
request, 1 questionable report, leaving 1 to be worked on (JELLY-184). Some
of these date back to 2004.
(The 11th one was one reported by you via Hans Gilde, in 2004 - JELLY-163
about handling JEXL expression exceptions)
I can have a look at JELLY-184 when I get back but it's surprising to see
how many bug reports are still open which had been submitted with patches;
obviously this is only because the project has not been maintained for
several years but it's a real shame that they haven't been incorporated.
One of the first tasks I'd undertake in rejuvenating Jelly would be to
integrate patches and start updating JIRA.
Regards
John
----- Original Message -----
From: "Paul Libbrecht" <pa...@activemath.org>
To: "Commons Developers List" <de...@commons.apache.org>
Sent: Sunday, November 09, 2008 8:26 PM
Subject: Re: [jelly] Is jelly still in development vs. Open/Federated
Commons
Le 09-nov.-08 à 05:35, John Spackman a écrit :
> I agree that the website needs some changes although I had thought that
> this was largely for broken links and for a consistent left- hand side
> menu; updating the documentation for the taglibs is a pretty herculean
> task, not least because in order to document a taglib you have to fully
> understand it first, and that would often mean having a test environment
> and ideally a practical application for them.
Oh boy, sure!
I wasn't talking about *writing the documentation* but cleanly linking
to it.
There's been an attempt of making documentation a bit better with
examples' link... but it hasn't been pushed enough and, I think,
should mostly be retired going back to jelly doc which has a
sufficient amount of content I believe.
> Generally, however, although not perfect I think that the current
> documentation is "adequate" - it certainly was enough for me to get the
> concepts and get going with it quickly.
Right... but there are slightly misleading parts (including wrong tag-
doc-links and "take maven to start") which really need fixes.
> Using Henri's analogies from his recent blog, I took Jelly home from the
> Commons a couple of years ago and we're now ready to "put it in the
> window and see if we're invited to play". If we're invited to play then
> great - any changes we make will be contributed back (and documentation
> will come with those changes) - but my "home life" is a small business
> that keeps me very busy and my focus here is on gradually contributing
> fixes/improvements and documentation rather than taking Jelly a great
> leap forward as an O/S product.
I believe that this is what jelly needs... maintenance....
> I am prepared to upgrade Jelly to Maven2 (not that I know much about what
> that involves, yet)
I would rather disadvise that especially for the huge effort of maven
1 scripting that was put in jelly building.
> and to improve the website but I have to be confident that the changes
> will happen quickly and easily, and that the project will not be retired.
We can make a vote on that... or we can simply try to make it cleaner
and start applying code patches. I don't think retirement was what
Henri suggested.
> Please don't get me wrong - I am very grateful for your offer to apply
> patches etc sent via JIRA but I am cautious as I think of the potential
> extra work that would entail and how much simpler it would be if I could
> just issue an SVN commit.
I fully understand but Apache foundations' practice has really always
been such.
> Returning again to Henri's blog, instead of Jelly being a first use case
> for retiring a commons project, how about it being a first use case for a
> "Federated Commons" subproject? I appreciate the point that making
> commits open to anybody has it's problems and is not something the team
> want to do right now, but given that the list is contemplating retiring
> Jelly this could be an ideal opportunity to experiment with something
> where the team has little to lose. The original SVN archive would remain
> intact at Apache, and I'd take a copy of it for my 1.x trunk so that I
> could create branches (possibly using Git); any projects already using
> Jelly 1.0 would be completely unaffected, but new users and users wishing
> to update would be referred to the new Federated Jelly website &
> repository.
And you would host that?
That might be a clean way to attempt maybe...
and I see this fairly easy to use so as to port back changes although
it might byte us from time to time.
I think a self-hosted fixed web-site is, for example, a very useful
thing to use!
What about identifying a handful of issues that you think you could
submit one or several patches for?
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [jelly] Is jelly still in development vs. Open/Federated Commons
Posted by Paul Libbrecht <pa...@activemath.org>.
Le 09-nov.-08 à 05:35, John Spackman a écrit :
> I agree that the website needs some changes although I had thought
> that this was largely for broken links and for a consistent left-
> hand side menu; updating the documentation for the taglibs is a
> pretty herculean task, not least because in order to document a
> taglib you have to fully understand it first, and that would often
> mean having a test environment and ideally a practical application
> for them.
Oh boy, sure!
I wasn't talking about *writing the documentation* but cleanly linking
to it.
There's been an attempt of making documentation a bit better with
examples' link... but it hasn't been pushed enough and, I think,
should mostly be retired going back to jelly doc which has a
sufficient amount of content I believe.
> Generally, however, although not perfect I think that the current
> documentation is "adequate" - it certainly was enough for me to get
> the concepts and get going with it quickly.
Right... but there are slightly misleading parts (including wrong tag-
doc-links and "take maven to start") which really need fixes.
> Using Henri's analogies from his recent blog, I took Jelly home from
> the Commons a couple of years ago and we're now ready to "put it in
> the window and see if we're invited to play". If we're invited to
> play then great - any changes we make will be contributed back (and
> documentation will come with those changes) - but my "home life" is
> a small business that keeps me very busy and my focus here is on
> gradually contributing fixes/improvements and documentation rather
> than taking Jelly a great leap forward as an O/S product.
I believe that this is what jelly needs... maintenance....
> I am prepared to upgrade Jelly to Maven2 (not that I know much about
> what that involves, yet)
I would rather disadvise that especially for the huge effort of maven
1 scripting that was put in jelly building.
> and to improve the website but I have to be confident that the
> changes will happen quickly and easily, and that the project will
> not be retired.
We can make a vote on that... or we can simply try to make it cleaner
and start applying code patches. I don't think retirement was what
Henri suggested.
> Please don't get me wrong - I am very grateful for your offer to
> apply patches etc sent via JIRA but I am cautious as I think of the
> potential extra work that would entail and how much simpler it would
> be if I could just issue an SVN commit.
I fully understand but Apache foundations' practice has really always
been such.
> Returning again to Henri's blog, instead of Jelly being a first use
> case for retiring a commons project, how about it being a first use
> case for a "Federated Commons" subproject? I appreciate the point
> that making commits open to anybody has it's problems and is not
> something the team want to do right now, but given that the list is
> contemplating retiring Jelly this could be an ideal opportunity to
> experiment with something where the team has little to lose. The
> original SVN archive would remain intact at Apache, and I'd take a
> copy of it for my 1.x trunk so that I could create branches
> (possibly using Git); any projects already using Jelly 1.0 would be
> completely unaffected, but new users and users wishing to update
> would be referred to the new Federated Jelly website & repository.
And you would host that?
That might be a clean way to attempt maybe...
and I see this fairly easy to use so as to port back changes although
it might byte us from time to time.
I think a self-hosted fixed web-site is, for example, a very useful
thing to use!
What about identifying a handful of issues that you think you could
submit one or several patches for?
paul