Re: vitality of Cocoon: a good basket to put eggs in?
Am 11.07.2011 17:10, schrieb Lars Huttar: Dear Cocoon developers, Congratulations on the alpha-3 release of C3. I was just telling my customer how Cocoon seemed to have languished, when I saw the announcement about C3a3. That is encouraging. We have been developing and using Cocoon applications since about 2004. We are still using Cocoon 2.1.11 for these, since we've not wanted to invest the time/risk in an upgrade to 2.2. But now we've come to a project where we have a further horizon to look toward... we have about a year, in which we could try 2.2 or even 3.0 and see if they are stable and featureful enough to support the work we want to do. In light of the trailoff of activity on this mailing list (see graph on http://cocoon.markmail.org/), and lack of maintenance releases for Cocoon 2.2, my customer and I were looking for alternatives to Cocoon: an XML-centric web app development framework, where XSLT can be pipelined (no serialization between steps), and where URLs are mapped to pipelines via a declarative sitemap. As far as we can tell, there is still nothing out there like Cocoon! It's such an elegant model, it's surprising that it hasn't been duplicated more often. There are a couple of other candidates, but nothing that is mature and proven as well as Cocoon. So we're looking at trying Cocoon 3.0. So far, the alpha release and beta snapshots are encouraging. The amount of documentation still TBW is not as encouraging. Our plan would be to try and port the Cocoon 2.1.11 project we're working on over to 3.0, and see how it goes. If we find bugs and missing features relative to 2.1.11, we'll have some time to request fixes. I may even be able to help with those fixes, though I would need help... the times I've tried to get into the internals of Cocoon, I find the Java classes rather overwhelming, especially as I know little about Java EE. I guess my main question is, how reliable is the Cocoon dev team's commitment to Cocoon 3.0? How likely are we to see a release version in the next 6 months to a year? Will there be bug-fix releases, or will 3.0 be dropped in favor of another rewrite? I realize no one can 100% predict the future, especially when the code is being developed on a volunteer basis; but I would like to at least ask the question and gauge the level of seriousness about the project. I also would be interested to know whether any of the Cocoon committers would be open to contract work on Cocoon, and whether that would make a difference to the vitality of the project. We have derived a great deal of benefit from Cocoon, and hope to see it grow and succeed into the future as the technology environment changes. Regards, Lars Hey Lars, I agree that the activity in here is rather low and it looks like not much is going on. But I see that like Peter explained in his mail: Cocoon 2.x has matured so far that nothing really is missing; Cocoon 3 has not received much attention (yet?), so there isn't a huge demand for changes or additions. However that does not change anything about the seriousness of this community. Reinhard and I started working on Cocoon 3 because we wanted to have a Pipeline API and a very slim and lightweight Cocoon. When we reached the feature set we needed for our project we stopped adding to it - there isn't much sense in adding stuff you don't even have a use case for. Simone joined very quickly and added things he needed for his project(s) and then some people kicked in and had ideas and improvements. I find that kind of growth very natural and healthy. So I see the rather long release cycles and slowly growing feature list as a sign of less demand, not of less commitment and I'm absolutely confident that new (reasonable) ideas and requests will be met and integrated. Bug-fix and feature releases should be expected as with any other project (albeit with a slightly increased cycle) I don't expect another rewrite in the foreseeable future. Contract work on Cocoon 3 is definitely a possibility, assuming the usual conditions (time, budget, etc.) work out. Steven
Re: Using XQJ API with Cocoon3
Am 05.07.2011 14:49, schrieb Simone Tripodi: Hi Robby!!! as I wrote you on Twitter, this is something *really* interesting that must be included in the Cocoon distribution :) We can include that module quite easy, all you have to do is * checkout/update the C3 /trunk; * add needed dependencies in thedependenciesManagement in the /parent/pom.xml * add your code in the /cocoon-optional module in a proper package - see the existing codebase as samples how we already managed 3rd parties integrations * make a patch and submit it on JIRA Hey, a little late to the party, but I wanted to add some comments. We should take a look at introducing topic specific modules. I fear that the optional module turns into a giant clump of all things unrelated. That's pretty much the opposite of the original intention: Have small, lightweight modules that you choose to use based on your actual requirements, allowing you to tailor your application package exactly to your needs. If I'm forced to use the optional module that brings dozens (::hyperbole::) of undesired features and dependencies just because I need one very specific feature, I'd be a little upset. (I don't like uploading 100 MB war files :/ ) But I wholeheartedly agree to the feature idea. DO WANT! :P Cheers, Steven Looking forward to hear from you soon, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Jul 5, 2011 at 2:42 PM, Robby Pelssersrobby.pelss...@ciber.com wrote: Hi all, As Cocoon is an excellent framework for dealing with XML and hence in a lot of cases is stored in a XML Database it makes sense to offer out-of-the box functionality to extract data from it. From my personal experience I think most XMLDB implementers have abondoned the XMLDB API initiative and are focusing on XQuery for Java (XQJ) instead. I just started playing with the API today and wrote a bit of code to get more acquainted. I would like to start a little thread to find out if we can add a new XQJGenerator to the optional cocoon module. A first little exercise is mentioned on my blog but it's far from production ready. - TODO: allow wrapping query result in 1 root tag - Problem: the XQJ interface jar is packaged along with the implementations (Sedna, Exist, Marklogic). This means I had to actually declare a maven dependency on the implementation specific jar (in this case sedna-xqj-beta-5.jar). For the ones who think this would be a great add-on, check my first post at http://robbypelssers.blogspot.com/2011/07/using-xqj-api-with-cocoon3.html Kind regards, Robby Pelssers
RE: Using XQJ API with Cocoon3
Hi Steven, I agree that an XQJ generator would be a perfect fit for a separate maven project. Either you need it or you don't and you get the freedom by (not) declaring the dependency. I think for non-general purpose code this makes perfect sense. Robby -Oorspronkelijk bericht- Van: Steven Dolg [mailto:steven.d...@indoqa.com] Verzonden: wo 13-7-2011 9:30 Aan: dev@cocoon.apache.org Onderwerp: Re: Using XQJ API with Cocoon3 Am 05.07.2011 14:49, schrieb Simone Tripodi: Hi Robby!!! as I wrote you on Twitter, this is something *really* interesting that must be included in the Cocoon distribution :) We can include that module quite easy, all you have to do is * checkout/update the C3 /trunk; * add needed dependencies in thedependenciesManagement in the /parent/pom.xml * add your code in the /cocoon-optional module in a proper package - see the existing codebase as samples how we already managed 3rd parties integrations * make a patch and submit it on JIRA Hey, a little late to the party, but I wanted to add some comments. We should take a look at introducing topic specific modules. I fear that the optional module turns into a giant clump of all things unrelated. That's pretty much the opposite of the original intention: Have small, lightweight modules that you choose to use based on your actual requirements, allowing you to tailor your application package exactly to your needs. If I'm forced to use the optional module that brings dozens (::hyperbole::) of undesired features and dependencies just because I need one very specific feature, I'd be a little upset. (I don't like uploading 100 MB war files :/ ) But I wholeheartedly agree to the feature idea. DO WANT! :P Cheers, Steven Looking forward to hear from you soon, all the best!!! Simo http://people.apache.org/~simonetripodi/ http://www.99soft.org/ On Tue, Jul 5, 2011 at 2:42 PM, Robby Pelssersrobby.pelss...@ciber.com wrote: Hi all, As Cocoon is an excellent framework for dealing with XML and hence in a lot of cases is stored in a XML Database it makes sense to offer out-of-the box functionality to extract data from it. From my personal experience I think most XMLDB implementers have abondoned the XMLDB API initiative and are focusing on XQuery for Java (XQJ) instead. I just started playing with the API today and wrote a bit of code to get more acquainted. I would like to start a little thread to find out if we can add a new XQJGenerator to the optional cocoon module. A first little exercise is mentioned on my blog but it's far from production ready. - TODO: allow wrapping query result in 1 root tag - Problem: the XQJ interface jar is packaged along with the implementations (Sedna, Exist, Marklogic). This means I had to actually declare a maven dependency on the implementation specific jar (in this case sedna-xqj-beta-5.jar). For the ones who think this would be a great add-on, check my first post at http://robbypelssers.blogspot.com/2011/07/using-xqj-api-with-cocoon3.html Kind regards, Robby Pelssers winmail.dat
Re: vitality of Cocoon: a good basket to put eggs in?
On Mon, 2011-07-11 at 10:40 -0500, Peter Hunsberger wrote: On Mon, Jul 11, 2011 at 10:10 AM, Lars Huttar lars_hut...@sil.org wrote: I guess my main question is, how reliable is the Cocoon dev team's commitment to Cocoon 3.0? How likely are we to see a release version in the next 6 months to a year? Will there be bug-fix releases, or will 3.0 be dropped in favor of another rewrite? Hi Lars, a couple of thoughts. I think C2.1 is pretty stable and as a result doesn't see a lot of activity. It is however still widely used. Personally, I hope to start a C3 project some time in the next year or so. Like any Open Source project it's as active and safe as the participants make it. If you see it as being attractive you should check it out and see to what extent it meets your needs and if it doesn't how much work you think it would take to get it where it needs to be. I suspect that for the XML pipeline world C3 is still more cost / time effective than a lot of other approaches. Also, C3 seems to be slowly attracting more attention, I don't think it would take much to tip it over to being a pretty active project. It certainly isn't going anywhere! Actually since the end of the last year we at codeBusters are developing almost all new projects with c3 and are very happy to do so. ATM our main use is based on the REST module but we started as well to migrate different old-school components to c3 (see e.g. directoryGenerator r1142139 on the difference to the old-school one) and have some committs still to sync with trunk. Regarding doing c4 before maintain c3 I doubt that. IMO c3 is the future of this project and when people start to send patches it will become the standard again that we were all the years before for xml. There a lots of people still in love with cocoon. ;) Like other pointed out c3 has not the componente base as 2.2. or 2.1. and some componentes will be more difficult to migrate then other, but IMO what is missing ATM is a community effort to migrate 2.1/2 componentes to c3. We at codebusters do the migration for some of those in the near future but we should plan a couple of community days to organize the big migration of the most important old-school components to c3 with the help of the community. ...but the biggest problem I see is helping hands. If you and other are looking into using c3 please be prepare to make your hands dirty to document, send patches, ... Every helping hand is welcome and every contribution matter. salu2 -- Thorsten Scherler thorsten.at.apache.org codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
RE: vitality of Cocoon: a good basket to put eggs in?
Hi Thorsten, My opinion exactly. Unless you're prepared to write a bit of java code yourself to fill the missing gaps you might be better of waiting till C3 ships with all components out-of-the-box. Or file a request for new feature in JIRA. In the end this is still a open-source project which would fit the remark a previous boss of mine used to say when I asked for a new product feature... This is a DO-OCRACY so get your hands dirty. My contribution for the next few months will be writing blogs about my experience of moving from C2.2 to C3. And hopefully contributing a few lines of code in the end as well ;-0 Robby -Original Message- From: Thorsten Scherler [mailto:scher...@gmail.com] Sent: Wednesday, July 13, 2011 12:18 PM To: dev@cocoon.apache.org Subject: Re: vitality of Cocoon: a good basket to put eggs in? On Mon, 2011-07-11 at 10:40 -0500, Peter Hunsberger wrote: On Mon, Jul 11, 2011 at 10:10 AM, Lars Huttar lars_hut...@sil.org wrote: I guess my main question is, how reliable is the Cocoon dev team's commitment to Cocoon 3.0? How likely are we to see a release version in the next 6 months to a year? Will there be bug-fix releases, or will 3.0 be dropped in favor of another rewrite? Hi Lars, a couple of thoughts. I think C2.1 is pretty stable and as a result doesn't see a lot of activity. It is however still widely used. Personally, I hope to start a C3 project some time in the next year or so. Like any Open Source project it's as active and safe as the participants make it. If you see it as being attractive you should check it out and see to what extent it meets your needs and if it doesn't how much work you think it would take to get it where it needs to be. I suspect that for the XML pipeline world C3 is still more cost / time effective than a lot of other approaches. Also, C3 seems to be slowly attracting more attention, I don't think it would take much to tip it over to being a pretty active project. It certainly isn't going anywhere! Actually since the end of the last year we at codeBusters are developing almost all new projects with c3 and are very happy to do so. ATM our main use is based on the REST module but we started as well to migrate different old-school components to c3 (see e.g. directoryGenerator r1142139 on the difference to the old-school one) and have some committs still to sync with trunk. Regarding doing c4 before maintain c3 I doubt that. IMO c3 is the future of this project and when people start to send patches it will become the standard again that we were all the years before for xml. There a lots of people still in love with cocoon. ;) Like other pointed out c3 has not the componente base as 2.2. or 2.1. and some componentes will be more difficult to migrate then other, but IMO what is missing ATM is a community effort to migrate 2.1/2 componentes to c3. We at codebusters do the migration for some of those in the near future but we should plan a couple of community days to organize the big migration of the most important old-school components to c3 with the help of the community. ...but the biggest problem I see is helping hands. If you and other are looking into using c3 please be prepare to make your hands dirty to document, send patches, ... Every helping hand is welcome and every contribution matter. salu2 -- Thorsten Scherler thorsten.at.apache.org codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
RE: vitality of Cocoon: a good basket to put eggs in?
On Wed, 2011-07-13 at 12:28 +0200, Robby Pelssers wrote: Hi Thorsten, My opinion exactly. Unless you're prepared to write a bit of java code yourself to fill the missing gaps you might be better of waiting till C3 ships with all components out-of-the-box. Or file a request for new feature in JIRA. In the end this is still a open-source project which would fit the remark a previous boss of mine used to say when I asked for a new product feature... This is a DO-OCRACY so get your hands dirty. My contribution for the next few months will be writing blogs about my experience of moving from C2.2 to C3. And hopefully contributing a few lines of code in the end as well ;-0 that is good to hear. If you can manage to commit as well to the docu where you see place to enhancement that would be awesome. I reckon you will stumble over some missing components like i18n where we can cooperate on migrating the code. Well actually i18n is not that easy since it has heaps of deps on other cocoon packages and maybe it makes sense to even rewrite the component. If we can manage to make it compatible with the old-school way of configuration we lower the barrier for people to switch from 2.1/2 to c3. Ideally the migration old-school standard component based development to c3 would be less then an hour. That would bring us back the old user base. c3 is really worth to use due to all the annotation and spring based config possibilities. Our classes can be slimed down to a couple of lines since all the manger.lookup nightmare is gone. Our current development is using a axis generated client which we initialize in spring and then injected to the class with @Autowired protected MyEndPoint myAxisEndpoint; and then in our public abstract RestResponse doGet() we can use it right away with no boilerplate code, that is so much cleaner and nicer. ...leading us back to the subject of the mail for me a big +1 (that is getting popular this days ;) )IMO a very good basket! salu2 -- Thorsten Scherler thorsten.at.apache.org codeBusters S.L. - web based systems consulting, training and solutions http://www.codebusters.es/
@Logger in RestController or independent?
Hi all,
I developed a small @Logger annotation for a customer project which I
would like to contribute. The question is ATM what is the best way?
ATM I have implemented the annotation based on an independent
BeanPostProcessor which I then invoke with adding
!-- logger annotation implementation --
bean class=org.apache.cocoon.common.LoggerInjector/
Basically the class is doing:
if (field.getAnnotation(Logger.class) != null) {
Log log = LogFactory.getLog(bean.getClass());
field.set(bean, log);
}
I saw SpringRESTController and I wonder whether we should add it there
in getController as populateLogger(configuration, unpackedController,
annotatedFields);
or to leave it independent to allow usages as well in REST independent
components such as generators, etc.
WDYT?
salu2
--
Thorsten Scherler thorsten.at.apache.org
codeBusters S.L. - web based systems
consulting, training and solutions
http://www.codebusters.es/
