Ant: Re: CoWarp (was Re: svn commit: r232855...)
--- Joerg Heinicke [EMAIL PROTECTED] schrieb: On 17.08.2005 11:22, Andrew Stevens wrote: Although as a mere user my vote probably doesn't count, It's a so-called non-binding vote, but your opinion is important though. from my perspective I'm extremely grateful that Cocoon still supports 1.3 and hope that remains the case for the 2.1.x releases. Our production servers are running Websphere 5.0.x, which only has JDK 1.3.1, and aren't likely to upgrade in the short term (a combination of internal bureaucracy and the amount of testing involved for all the other apps running on those servers). So if 2.1.8 drops support for 1.3, I'll probably have to stick at 2.1.7 for our team's app; either that or drop Cocoon altogether and migrate to the company standard (proprietary) framework, which I've managed to hold out against up till now ;-) Besides, wouldn't something like that justify a bigger change in version number i.e. if you're going to drop it, do it in 2.2? Yes, definitely. Such an important incompatibility would need a minor version number update IMO instead of just on the patch level. The change to Java 1.4 was already decided for Cocoon 2.2. I would not like to see Java 1.3 support been dropped for Cocoon 2.1.x. If it is just an issue for the library update we simply don't need to update each library to each version. Joerg I fully agree with you Jörg. If we make JDK 1.4 a requirement for Cocoon, then the next version should be 2.2 and not 2.1.8. -- Reinhard ___ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: CoWarp (was Re: svn commit: r232855...)
Ralph Goers wrote: Well, I see blocks a little differently. For example, in the portal block you want to build the block independently of the portal configuration (at least I do). I want the block available to someone who wants to create a portal. They then take the portal block and tweak the sample site to become their own block, which is dependent on the portal block. In effect, this means that samples really need to be a separate project from the blocks themselves. Yes, some time ago we agreed to make own blocks (or whatever it is) for the samples. So for the portal we end up in at least two modules, the portal itself and a sample. I could imagine splitting this up into more parts, JSR 168 support ,wsrp support, bridges support etc. And yes, I think building a plugin is going to be required. Also, I'm pretty sure a switch to maven would also mean a little bit of a change to the directory structure. Don't get me wrong, I'd love for this to happen and I'd be willing to help once we agree how to do it. I just don't think it is trivial. Actually I think it is trivial :) If we want it I guess we can do this in one week time. (That solution might then not be perfect but working) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: CoWarp (was Re: svn commit: r232855...)
Vadim Gritsenko schrieb: Ralph Goers wrote: Sylvain Wallez wrote: So let's switch Cocoon to Maven ;-) I wish it was that simple. I looked at it a month or so ago. A royal PITA. Unfortunately, I also think it is very necessary. We really need to get the 3rd party jars out of our download. -1: Complete download must stay. You can add another download option, though, if wanted. Are you both talking about the same? For development we simply can use Maven downloading our jars. The release/distribution will of course contain all required jars and work out of the box. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: CoWarp (was Re: svn commit: r232855...)
Ralph Goers wrote: The only concern I would have in bringing CoWarp into Cocoon (beside the name making me think it is an add-on for OS/2 :-) ) is that I'd want to evaluate it against using acegi as the standard authentication mechanism. Having said that, I have no familiarity with CoWarp and have only read some high level stuff about acegi, but from that reading it looks like a very robust framework. There was some discussion about it on the users list a few months ago http://marc.theaimsgroup.com/?t=11175500054r=1w=2 Acegi is a very robust framework. Although the author states it could be used without Spring [1] he strongly encourages not to :). I quite got the point when I implemented the first application context which just secures a single method in a dummy business service: beans bean id=roleVoter class=net.sf.acegisecurity.vote.RoleVoter/ bean id=accessDecisionManager class=net.sf.acegisecurity.vote.AffirmativeBased property name=allowIfAllAbstainDecisionsvaluefalse/value/property property name=decisionVoters list ref bean=roleVoter/ /list /property /bean bean id=authenticationDao class=net.sf.acegisecurity.providers.dao.memory.InMemoryDaoImpl property name=userMap value marissa=koala,ROLE_TELLER,ROLE_SUPERVISOR dianne=emu,ROLE_TELLER scott=wombat,ROLE_TELLER peter=opal,disabled,ROLE_TELLER ouzo=ouzo,ROLE_ADMIN /value /property /bean bean id=cacheManager class=org.springframework.cache.ehcache.EhCacheManagerFactoryBean property name=configLocationvalueclasspath:/ehcache-failsafe.xml/value/property /bean bean id=userCacheBackend class=org.springframework.cache.ehcache.EhCacheFactoryBean property name=cacheManagerref local=cacheManager//property property name=cacheNamevalueuserCache/value/property /bean bean id=userCache class=net.sf.acegisecurity.providers.dao.cache.EhCacheBasedUserCache property name=cacheref local=userCacheBackend//property /bean bean id=daoAuthenticationProvider class=net.sf.acegisecurity.providers.dao.DaoAuthenticationProvider property name=authenticationDaoref bean=authenticationDao//property property name=userCacheref bean=userCache//property /bean bean id=testingAuthenticationProvider class=net.sf.acegisecurity.providers.TestingAuthenticationProvider/ bean id=authenticationManager class=net.sf.acegisecurity.providers.ProviderManager property name=providers list !-- ref bean=daoAuthenticationProvider/ -- ref bean=testingAuthenticationProvider/ /list /property /bean bean id=beanSecurityInterceptor class=net.sf.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor property name=validateConfigAttributesvaluetrue/value/property property name=authenticationManagerref bean=authenticationManager//property property name=accessDecisionManagerref bean=accessDecisionManager//property !-- property name=runAsManagerref bean=runAsManager//property -- property name=objectDefinitionSource value com.mobilebox.acegi.SecureBean.*=ROLE_ADMIN /value /property /bean bean id=autoProxyCreator class=org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator property name=interceptorNames list idref local=beanSecurityInterceptor/ /list /property property name=beanNames list valuesecureBean/value /list /property /bean !-- 'application beans' -- bean id=secureBean class=com.mobilebox.acegi.SecureBeanImpl/ /beans This is ONLY business method security. Basic acegi sample has applicationContext.xml at least twice this big. Thing is: even if it's possible to use it without Spring it will be a total hell to wrap everything as ECM components without Dependency Injection. Still I would love to have a functionality that replaces ANT based request URI expressions: bean id=channelProcessingFilter class=net.sf.acegisecurity.securechannel.ChannelProcessingFilter property name=channelDecisionManagerref local=channelDecisionManager//property property name=filterInvocationDefinitionSource value CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON \A/secure/.*\Z=REQUIRES_SECURE_CHANNEL \A/acegilogin.jsp.*\Z=REQUIRES_SECURE_CHANNEL \A/j_acegi_security_check.*\Z=REQUIRES_SECURE_CHANNEL \A.*\Z=REQUIRES_INSECURE_CHANNEL /value /property /bean bean id=filterInvocationInterceptor
Re: CoWarp (was Re: svn commit: r232855...)
Although as a mere user my vote probably doesn't count, from my perspective I'm extremely grateful that Cocoon still supports 1.3 and hope that remains the case for the 2.1.x releases. Our production servers are running Websphere 5.0.x, which only has JDK 1.3.1, and aren't likely to upgrade in the short term (a combination of internal bureaucracy and the amount of testing involved for all the other apps running on those servers). So if 2.1.8 drops support for 1.3, I'll probably have to stick at 2.1.7 for our team's app; either that or drop Cocoon altogether and migrate to the company standard (proprietary) framework, which I've managed to hold out against up till now ;-) Besides, wouldn't something like that justify a bigger change in version number i.e. if you're going to drop it, do it in 2.2? Also, when you do drop the 1.3 support, why not drop the servlet 2.2 support as well and start using standard HttpRequest/ReponseWrappers in the JSP block instead of your own version? I'd have thought any app server that supports 1.4+ would also support servlet 2.3+. Plus, I've already had to write a custom JSPEngine implementation because Websphere won't do includes if the request isn't the standard wrapper class... Andrew. From: Vadim Gritsenko [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: CoWarp (was Re: svn commit: r232855...) Date: Tue, 16 Aug 2005 23:27:30 -0400 Antonio Gallardo wrote: If ..., I will like to propose for the next cocoon 2.1.x release to set the monimal JVM requirement to 1.4. Can I start a vote about moving to 1.4? -1 for change of JVM requirement in the 2.1.8 release, which should be released ASAP anyway - it is delayed too much already. +1 for the change in any release after 2.1.8. Vadim
Re: CoWarp (was Re: svn commit: r232855...)
Leszek Gawron wrote: Acegi is a very robust framework. Although the author states it could be used without Spring [1] he strongly encourages not to :). I quite got the point when I implemented the first application context which just secures a single method in a dummy business service: This is ONLY business method security. Basic acegi sample has applicationContext.xml at least twice this big. Thing is: even if it's possible to use it without Spring it will be a total hell to wrap everything as ECM components without Dependency Injection. Still I would love to have a functionality that replaces ANT based request URI expressions: I'm not going to proclaim myself an expert in security matters/frameworks, but when I needed to add security (authorization rather than just authentication) to my application I had a look at Acegi too and found it too cumbersome too. I came across XACML (by OASIS) [1] and it's implementation by Sun [2]. Priorities changed and I haven't looked into it further, but this at least doesn't rely on Spring. Maybe something to consider. My POV on security (i.e. authorization) is: - it should be easy to configure (XML config rather than code) - it should be role-based, preferably supporting multiple roles (hierarchical and occasional, e.g. a person can be 'doctor' and 'treating physician'. In his latter role he can see more information of the patient). - it should allow me to filter data based on roles (e.g. 'doctor' sees less info than 'treating physician') - it would be great if the roles could also be applied to the UI: when it is not possible to edit something the UI is adjusted (e.g. removal of 'edit' button or different display of widget). I know the latter is highly dependent on the application, but there are common tasks that could be integrated in the framework. Just my 2ct. Bye, Helma [1]http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml [2]http://sunxacml.sourceforge.net/
Re: CoWarp (was Re: svn commit: r232855...)
Andrew Stevens schrieb: Besides, wouldn't something like that justify a bigger change in version number i.e. if you're going to drop it, do it in 2.2? Also, when you do drop the 1.3 support, why not drop the servlet 2.2 support as well and start using standard HttpRequest/ReponseWrappers in the JSP block instead of your own version? I'd have thought any app server that supports 1.4+ would also support servlet 2.3+. Plus, I've already had to write a custom JSPEngine implementation because Websphere won't do includes if the request isn't the standard wrapper class... With 2.2 we alreay drop 1.3 support and servlet 2.2 support. You're right with using the wrappers, so can you post a patch please or can someone pick this up? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: CoWarp (was Re: svn commit: r232855...)
That is a lot of Spring definitions. Frankly, I suspect that to use Acegi we would require something like CoWarp in front of it anyway. The thing is, we ended up writing something like Acegi for our use and it would be nice to use an open source framework instead. I looked at CoWarp last night and I didn't see anything to support roles or permission. Ralph Leszek Gawron wrote: Ralph Goers wrote: The only concern I would have in bringing CoWarp into Cocoon (beside the name making me think it is an add-on for OS/2 :-) ) is that I'd want to evaluate it against using acegi as the standard authentication mechanism. Having said that, I have no familiarity with CoWarp and have only read some high level stuff about acegi, but from that reading it looks like a very robust framework. There was some discussion about it on the users list a few months ago http://marc.theaimsgroup.com/?t=11175500054r=1w=2 Acegi is a very robust framework. Although the author states it could be used without Spring [1] he strongly encourages not to :). I quite got the point when I implemented the first application context which just secures a single method in a dummy business service: beans bean id=roleVoter class=net.sf.acegisecurity.vote.RoleVoter/ bean id=accessDecisionManager class=net.sf.acegisecurity.vote.AffirmativeBased property name=allowIfAllAbstainDecisionsvaluefalse/value/property property name=decisionVoters list ref bean=roleVoter/ /list /property /bean bean id=authenticationDao class=net.sf.acegisecurity.providers.dao.memory.InMemoryDaoImpl property name=userMap value marissa=koala,ROLE_TELLER,ROLE_SUPERVISOR dianne=emu,ROLE_TELLER scott=wombat,ROLE_TELLER peter=opal,disabled,ROLE_TELLER ouzo=ouzo,ROLE_ADMIN /value /property /bean bean id=cacheManager class=org.springframework.cache.ehcache.EhCacheManagerFactoryBean property name=configLocationvalueclasspath:/ehcache-failsafe.xml/value/property /bean bean id=userCacheBackend class=org.springframework.cache.ehcache.EhCacheFactoryBean property name=cacheManagerref local=cacheManager//property property name=cacheNamevalueuserCache/value/property /bean bean id=userCache class=net.sf.acegisecurity.providers.dao.cache.EhCacheBasedUserCache property name=cacheref local=userCacheBackend//property /bean bean id=daoAuthenticationProvider class=net.sf.acegisecurity.providers.dao.DaoAuthenticationProvider property name=authenticationDaoref bean=authenticationDao//property property name=userCacheref bean=userCache//property /bean bean id=testingAuthenticationProvider class=net.sf.acegisecurity.providers.TestingAuthenticationProvider/ bean id=authenticationManager class=net.sf.acegisecurity.providers.ProviderManager property name=providers list !-- ref bean=daoAuthenticationProvider/ -- ref bean=testingAuthenticationProvider/ /list /property /bean bean id=beanSecurityInterceptor class=net.sf.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor property name=validateConfigAttributesvaluetrue/value/property property name=authenticationManagerref bean=authenticationManager//property property name=accessDecisionManagerref bean=accessDecisionManager//property !-- property name=runAsManagerref bean=runAsManager//property -- property name=objectDefinitionSource value com.mobilebox.acegi.SecureBean.*=ROLE_ADMIN /value /property /bean bean id=autoProxyCreator class=org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator property name=interceptorNames list idref local=beanSecurityInterceptor/ /list /property property name=beanNames list valuesecureBean/value /list /property /bean !-- 'application beans' -- bean id=secureBean class=com.mobilebox.acegi.SecureBeanImpl/ /beans This is ONLY business method security. Basic acegi sample has applicationContext.xml at least twice this big. Thing is: even if it's possible to use it without Spring it will be a total hell to wrap everything as ECM components without Dependency Injection. Still I would love to have a functionality that replaces ANT based request URI expressions: bean id=channelProcessingFilter class=net.sf.acegisecurity.securechannel.ChannelProcessingFilter property name=channelDecisionManagerref local=channelDecisionManager//property property name=filterInvocationDefinitionSource value
Re: CoWarp (was Re: svn commit: r232855...)
Ralph Goers schrieb: That is a lot of Spring definitions. Frankly, I suspect that to use Acegi we would require something like CoWarp in front of it anyway. The thing is, we ended up writing something like Acegi for our use and it would be nice to use an open source framework instead. I looked at CoWarp last night and I didn't see anything to support roles or permission. Right, it's not there (yet), it's somewhere in my todo list... Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: CoWarp (was Re: svn commit: r232855...)
hepabolu wrote: I came across XACML (by OASIS) [1] and it's implementation by Sun [2]. Priorities changed and I haven't looked into it further, but this at least doesn't rely on Spring. Maybe something to consider. I've heard about XACML too. IMHO CAuth should support XACML as one of the options. Vadim
Re: CoWarp (was Re: svn commit: r232855...)
Carsten Ziegeler wrote: Vadim Gritsenko schrieb: Ralph Goers wrote: Sylvain Wallez wrote: So let's switch Cocoon to Maven ;-) I wish it was that simple. I looked at it a month or so ago. A royal PITA. Unfortunately, I also think it is very necessary. We really need to get the 3rd party jars out of our download. -1: Complete download must stay. You can add another download option, though, if wanted. Are you both talking about the same? For development we simply can use Maven downloading our jars. The release/distribution will of course contain all required jars and work out of the box. I think it is simpler than that! I mean we don't need a special target. In maven a full cocoon build will download all the jars, right? ;-) /me hoping we can also create a shell script that will be able to download maven before maven start to build cocoon. ;-) Best Regards, Antonio Gallardo.
Re: CoWarp (was Re: svn commit: r232855...)
Vadim Gritsenko wrote: Antonio Gallardo wrote: /me hoping we can also create a shell script that will be able to download maven before maven start to build cocoon. ;-) You mean script should download maven source, build it, and start maven? Sounds good... and if this script uses ant, it should download ant source first, build it... ;-) Download Harmony, C++ compiler, either from releases, or from Subversion (only downloading the things that have changed since last downloaded), and build it all on the fly. Hmm, this reminds me of something[1]. Regards, Upayavira [1]http://mail-archives.apache.org/mod_mbox/incubator-general/200507.mbox/[EMAIL PROTECTED]
Re: CoWarp (was Re: svn commit: r232855...)
On 17.08.2005 11:22, Andrew Stevens wrote: Although as a mere user my vote probably doesn't count, It's a so-called non-binding vote, but your opinion is important though. from my perspective I'm extremely grateful that Cocoon still supports 1.3 and hope that remains the case for the 2.1.x releases. Our production servers are running Websphere 5.0.x, which only has JDK 1.3.1, and aren't likely to upgrade in the short term (a combination of internal bureaucracy and the amount of testing involved for all the other apps running on those servers). So if 2.1.8 drops support for 1.3, I'll probably have to stick at 2.1.7 for our team's app; either that or drop Cocoon altogether and migrate to the company standard (proprietary) framework, which I've managed to hold out against up till now ;-) Besides, wouldn't something like that justify a bigger change in version number i.e. if you're going to drop it, do it in 2.2? Yes, definitely. Such an important incompatibility would need a minor version number update IMO instead of just on the patch level. The change to Java 1.4 was already decided for Cocoon 2.2. I would not like to see Java 1.3 support been dropped for Cocoon 2.1.x. If it is just an issue for the library update we simply don't need to update each library to each version. Joerg
CoWarp (was Re: svn commit: r232855...)
Carsten Ziegeler wrote: For the demo portal, I replaced the authentication framework with CoWarp which provides imho a much nicer and cleaner way for plugging in your authentication mechanism. CoWarp is a 35 kb jar file containing 25 classes which seem highly tied to Cocoon and Avalon. Do you plan to move this code to the Cocoon repo? That would be IMHO a good thing to do to avoid the multiplication of small jars and give a better community oversight on this interesting stuff. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: CoWarp (was Re: svn commit: r232855...)
Sylvain Wallez schrieb: Carsten Ziegeler wrote: For the demo portal, I replaced the authentication framework with CoWarp which provides imho a much nicer and cleaner way for plugging in your authentication mechanism. CoWarp is a 35 kb jar file containing 25 classes which seem highly tied to Cocoon and Avalon. Do you plan to move this code to the Cocoon repo? That would be IMHO a good thing to do to avoid the multiplication of small jars and give a better community oversight on this interesting stuff. If there is *high* community interest in hosting it at Apache I'm willing to move. In fact, lack of a community was one of the main reasons in creating Cowarp outside of Apache. Look at many of our blocks (incl. the famous authentication block), most of them do not have a community. They're a one man show (or sometimes a two man show). Apache is about communities, and I think as long as the project does not have a real community it should not be at Apache. So, my suggestion is, if there are people interested in it, speak up, lets create a comunity outside at Apache first and then move it. And I think currently we have way too many blocks and adding another one makes Cocoon even complexer. It seems everyone who has a good idea just adds another block (with no or minimal community). Just adding a jar dependency is much simpler from the complexity point of view. Another advantage is that I can use Maven for building Cowarp - something our build system does not provide. But for me using Maven is another prerequisite :) In the end, yes, I'm willing to move if this creates a community here. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: CoWarp (was Re: svn commit: r232855...)
On 16 Aug 2005, at 11:27, Carsten Ziegeler wrote: And I think currently we have way too many blocks and adding another one makes Cocoon even complexer. It seems everyone who has a good idea just adds another block (with no or minimal community). Just adding a jar dependency is much simpler from the complexity point of view. Good thinking: +1. Just some passing thought: one way to move a little bit closer is to host it at cocoondev.org. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought Open Source Java XML stevenn at outerthought.orgstevenn at apache.org
Re: CoWarp (was Re: svn commit: r232855...)
Carsten Ziegeler wrote: And I think currently we have way too many blocks and adding another one makes Cocoon even complexer. It seems everyone who has a good idea just adds another block (with no or minimal community). Just adding a jar dependency is much simpler from the complexity point of view. +1 An important aspect of the block architecture is to make it as simple as possible for outsiders to develop blocks. Then the Cocoon community should IMO focus on core functionality and blocks (whatever that means). /Daniel
Re: CoWarp (was Re: svn commit: r232855...)
Carsten Ziegeler wrote: Sylvain Wallez schrieb: Carsten Ziegeler wrote: For the demo portal, I replaced the authentication framework with CoWarp which provides imho a much nicer and cleaner way for plugging in your authentication mechanism. CoWarp is a 35 kb jar file containing 25 classes which seem highly tied to Cocoon and Avalon. Do you plan to move this code to the Cocoon repo? That would be IMHO a good thing to do to avoid the multiplication of small jars and give a better community oversight on this interesting stuff. If there is *high* community interest in hosting it at Apache I'm willing to move. In fact, lack of a community was one of the main reasons in creating Cowarp outside of Apache. Look at many of our blocks (incl. the famous authentication block), most of them do not have a community. They're a one man show (or sometimes a two man show). Apache is about communities, and I think as long as the project does not have a real community it should not be at Apache. Hmm... chicken and egg. How can one create a community around a one man show hosted as SF.net? Furthermore, can there be a community around a bunch of interface and their default implementations? Not talking about the quality of the code, but about the interest these interfaces can generate, especially when they're so simple that they can already can be considered as finished. So, my suggestion is, if there are people interested in it, speak up, lets create a comunity outside at Apache first and then move it. Again, I don't think there ever be a community around this. But just as we have a lot of dedicated sub-frameworks in Cocoon that became standard ways of solving problems (e.g. source resolver, input modules, multipart interfaces, or the new location framework), why wouldn't there be a standard simple abstraction for authentication and authorization in Cocoon? And I think currently we have way too many blocks and adding another one makes Cocoon even complexer. It seems everyone who has a good idea just adds another block (with no or minimal community). Just adding a jar dependency is much simpler from the complexity point of view. It's not really here about adding a new block, but about providing a simple and unified way of solving a common problem in Cocoon, which the current pipeline-based auth-framework doesn't seem to solve (I personally never used it). The interfaces could be in core, along with the basic trivial implementations, and blocks could provide specialized implementations (e.g. JDBC, LDAP, JCR, etc). Another advantage is that I can use Maven for building Cowarp - something our build system does not provide. But for me using Maven is another prerequisite :) So let's switch Cocoon to Maven ;-) Now why is it a prerequisite? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: CoWarp (was Re: svn commit: r232855...)
Sylvain Wallez wrote: It's not really here about adding a new block, but about providing a simple and unified way of solving a common problem in Cocoon, which the current pipeline-based auth-framework doesn't seem to solve (I personally never used it). The interfaces could be in core, along with the basic trivial implementations, and blocks could provide specialized implementations (e.g. JDBC, LDAP, JCR, etc). Ah, ok adding the classes to core makes imho more sense, agreed. Another advantage is that I can use Maven for building Cowarp - something our build system does not provide. But for me using Maven is another prerequisite :) So let's switch Cocoon to Maven ;-) Now why is it a prerequisite? :) Perhaps someone picks this up and finally moves Cocoon to use Maven...(wishfull thinking) Maven is soo simple for simple structured projects like cowarp. I get a website and reports for free (incl junit tests - though cowarp currently has none... :) ). And I don't want to miss this. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: CoWarp (was Re: svn commit: r232855...)
Sylvain Wallez wrote: Carsten Ziegeler wrote: snip/ Hmm... chicken and egg. How can one create a community around a one man show hosted as SF.net? Furthermore, can there be a community around a bunch of interface and their default implementations? There can at least be community involvement. You are of course allready working on that by discussing it on the list.You could take it further by writting an RT about why you consider authentication being a core concern for Cocoon (something that at least I probbaly would agree about), how CoWarp solves it and why that is a good approach. Not talking about the quality of the code, but about the interest these interfaces can generate, especially when they're so simple that they can already can be considered as finished. snip/ And I think currently we have way too many blocks and adding another one makes Cocoon even complexer. It seems everyone who has a good idea just adds another block (with no or minimal community). Just adding a jar dependency is much simpler from the complexity point of view. It's not really here about adding a new block, but about providing a simple and unified way of solving a common problem in Cocoon, which the current pipeline-based auth-framework doesn't seem to solve (I personally never used it). The interfaces could be in core, along with the basic trivial implementations, and blocks could provide specialized implementations (e.g. JDBC, LDAP, JCR, etc). Implementig the interfaces is also a kind of community involvement. And by implementing them we migth get ideas about how to improve the interfaces which would be simplified by making them part of Cocoon. --- o0o --- Thinking further about it, I completely agree about that we have to many blocks rigth now. But that is not an argument against adding more, rather about removing or at least make optional, blocks that lacks community support. You might remember http://wiki.apache.org/cocoon/BlockStatusPoll. We could add more blocks, but it has to be based on community interest or involvement, not like some of the abandoned one man shows from our past. /Daniel
Re: CoWarp (was Re: svn commit: r232855...)
Daniel Fagerstrom wrote: Thinking further about it, I completely agree about that we have to many blocks rigth now. But that is not an argument against adding more, rather about removing or at least make optional, blocks that lacks community support. You might remember http://wiki.apache.org/cocoon/BlockStatusPoll. We could add more blocks, but it has to be based on community interest or involvement, not like some of the abandoned one man shows from our past. With CoWarp and flow and jxtg we could think about removing (deprecating first of course) the authentication-fw and the session-fw block. -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: CoWarp (was Re: svn commit: r232855...)
Sylvain Wallez wrote: So let's switch Cocoon to Maven ;-) I wish it was that simple. I looked at it a month or so ago. A royal PITA. Unfortunately, I also think it is very necessary. We really need to get the 3rd party jars out of our download. Ralph
Re: CoWarp (was Re: svn commit: r232855...)
Carsten Ziegeler wrote: If there is *high* community interest in hosting it at Apache I'm willing to move. In fact, lack of a community was one of the main reasons in creating Cowarp outside of Apache. I have no idea how to become part of a community at sourceforge. Most seem to have no mailing list activity. I do know that many folks are confused by our current authentication framework. I suspect that is why interest in it isn't higher. I happen to use it, but it is a little clunky. However, I've also considered looking into other authentication frameworks. Another advantage is that I can use Maven for building Cowarp - something our build system does not provide. But for me using Maven is another prerequisite :) Well, I vastly prefer maven as well, but I'm not sure why it is required. Ralph
Re: CoWarp (was Re: svn commit: r232855...)
Ralph Goers schrieb: Sylvain Wallez wrote: So let's switch Cocoon to Maven ;-) I wish it was that simple. I looked at it a month or so ago. A royal PITA. Unfortunately, I also think it is very necessary. We really need to get the 3rd party jars out of our download. I think we should start removing the links to the blocks from the core and start building each block separately. Deployment of a block into Cocoon is simple: adding the jars to the lib directory, adding the confs to the conf directory and adding the webapp to a mounted directory. I guess it's easy to write such a maven plugin. -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: CoWarp (was Re: svn commit: r232855...)
So let's switch Cocoon to Maven ;-) I wish it was that simple. I looked at it a month or so ago. A royal PITA. Unfortunately, I also think it is very necessary. We really need to get the 3rd party jars out of our download. I think we should start removing the links to the blocks from the core and start building each block separately. Deployment of a block into Cocoon is simple: adding the jars to the lib directory, adding the confs to the conf directory and adding the webapp to a mounted directory. I guess it's easy to write such a maven plugin. I've talked to Brett a few days ago. AFAIU the maven community would really love to see us switch to maven2 ...and help us as good as they can. They don't have the resources to give us hands-on support but maybe it would be worthwhile discussion a migration plan with them. I think the first step would be to explain how it works currently. cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: CoWarp (was Re: svn commit: r232855...)
Carsten Ziegeler wrote: Ralph Goers schrieb: Sylvain Wallez wrote: So let's switch Cocoon to Maven ;-) I wish it was that simple. I looked at it a month or so ago. A royal PITA. Unfortunately, I also think it is very necessary. We really need to get the 3rd party jars out of our download. I think we should start removing the links to the blocks from the core and start building each block separately. Deployment of a block into Cocoon is simple: adding the jars to the lib directory, adding the confs to the conf directory and adding the webapp to a mounted directory. I guess it's easy to write such a maven plugin. Well, I see blocks a little differently. For example, in the portal block you want to build the block independently of the portal configuration (at least I do). I want the block available to someone who wants to create a portal. They then take the portal block and tweak the sample site to become their own block, which is dependent on the portal block. In effect, this means that samples really need to be a separate project from the blocks themselves. And yes, I think building a plugin is going to be required. Also, I'm pretty sure a switch to maven would also mean a little bit of a change to the directory structure. Don't get me wrong, I'd love for this to happen and I'd be willing to help once we agree how to do it. I just don't think it is trivial. Ralph
Re: CoWarp (was Re: svn commit: r232855...)
Ralph Goers wrote: Sylvain Wallez wrote: So let's switch Cocoon to Maven ;-) I wish it was that simple. I looked at it a month or so ago. A royal PITA. Unfortunately, I also think it is very necessary. We really need to get the 3rd party jars out of our download. -1: Complete download must stay. You can add another download option, though, if wanted. Vadim
Re: CoWarp (was Re: svn commit: r232855...)
Vadim Gritsenko wrote: Ralph Goers wrote: Sylvain Wallez wrote: So let's switch Cocoon to Maven ;-) I wish it was that simple. I looked at it a month or so ago. A royal PITA. Unfortunately, I also think it is very necessary. We really need to get the 3rd party jars out of our download. -1: Complete download must stay. Out of curiosity, why? You can add another download option, though, if wanted. Vadim
Re: CoWarp (was Re: svn commit: r232855...)
On 16.08.2005, at 17:31, Vadim Gritsenko wrote: Ralph Goers wrote: Sylvain Wallez wrote: So let's switch Cocoon to Maven ;-) I wish it was that simple. I looked at it a month or so ago. A royal PITA. Unfortunately, I also think it is very necessary. We really need to get the 3rd party jars out of our download. -1: Complete download must stay. -(-1) ;) I also think we should get rid of this huge amount of jars. It should be a piece of cake to build a full distribution with all dependencies and provide that to make people like Vadim happy :) So only the one building the full release would have to download everything. Cocoon really starts to burst at the seams IMO. cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: CoWarp (was Re: svn commit: r232855...)
Ralph Goers wrote: Vadim Gritsenko wrote: Ralph Goers wrote: We really need to get the 3rd party jars out of our download. -1: Complete download must stay. Out of curiosity, why? Comparing lots of other software out there, Cocoon is among the best one with regards to the effort needed to get up and running. All you need is: download/unzip build.bat cocoon.bat No need to fight with dependency-fetching-tools, hunt for working mirror, mess with endorsed directories, install MySQL, rebuild kernel, etc. I think it should stay that way. Or, even better, add couple of lines to cocoon.bat so that it invokes build.bat if necessary. :-P Vadim
Re: CoWarp (was Re: svn commit: r232855...)
Torsten Curdt wrote: I also think we should get rid of this huge amount of jars. 0: Does not bother me but whatever :-) It should be a piece of cake to build a full distribution with all dependencies and provide that to make people like Vadim happy :) That's my point exactly; do whatever but keep full distro available. Even gentoo has one :-P Vadim
Re: CoWarp (was Re: svn commit: r232855...)
Torsten Curdt wrote: So let's switch Cocoon to Maven ;-) +1 I wish it was that simple. I looked at it a month or so ago. A royal PITA. Unfortunately, I also think it is very necessary. We really need to get the 3rd party jars out of our download. +1, but using maven should not stop us from building an all-in distribution like we do now. Maven is flexibly enough to handle both cases. I've talked to Brett a few days ago. AFAIU the maven community would really love to see us switch to maven2 ...and help us as good as they can. cool. The mailinglist is very responsive but it's always good to have a helping hand on the inside :) They don't have the resources to give us hands-on support but maybe it would be worthwhile discussion a migration plan with them. agreed, and therefore : I think the first step would be to explain how it works currently. Yup. Can we try and compile an overview of the different (logical) tasks the current build system handles ? Or is this a case of sifting through the ant build files and track the targets being executed ? Does anyone have the overview here? Jorg
Re: CoWarp (was Re: svn commit: r232855...)
Vadim Gritsenko wrote:
Ralph Goers wrote:
Sylvain Wallez wrote:
So let's switch Cocoon to Maven ;-)
I wish it was that simple. I looked at it a month or so ago. A royal
PITA. Unfortunately, I also think it is very necessary. We really
need to get the 3rd party jars out of our download.
-1: Complete download must stay.
You can add another download option, though, if wanted.
Looking at the source of the uberjar plugin, here's what it looks like
to copy all dependencies before making the big distro archive:
!-- Copy each dep to our working dir --
j:forEach var=lib items=${pom.artifacts}
j:set var=dep value=${lib.dependency}/
j:if test=${dep.getProperty('uberjar.bundle')!='false'}
j:if test=${dep.type =='jar'}
ant:copy tofile=${libdir}/${dep.artifact} file=${lib.path}/
/j:if
/j:if
/j:forEach
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: CoWarp (was Re: svn commit: r232855...)
Vadim Gritsenko wrote: Ralph Goers wrote: Sylvain Wallez wrote: So let's switch Cocoon to Maven ;-) I wish it was that simple. I looked at it a month or so ago. A royal PITA. Unfortunately, I also think it is very necessary. We really need to get the 3rd party jars out of our download. -1: Complete download must stay. You can add another download option, though, if wanted. Spring framework uses maven and handles it nicely. They provide springframework-XXX.zip and springframework-XXX-with-deps.zip. -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: CoWarp (was Re: svn commit: r232855...)
Torsten Curdt wrote: On 16.08.2005, at 17:31, Vadim Gritsenko wrote: Ralph Goers wrote: Sylvain Wallez wrote: So let's switch Cocoon to Maven ;-) I wish it was that simple. I looked at it a month or so ago. A royal PITA. Unfortunately, I also think it is very necessary. We really need to get the 3rd party jars out of our download. -1: Complete download must stay. -(-1) ;) I also think we should get rid of this huge amount of jars. It should be a piece of cake to build a full distribution with all dependencies and provide that to make people like Vadim happy :) So only the one building the full release would have to download everything. Cocoon really starts to burst at the seams IMO. -(-(-1)) ! :) I am often working using a lousy GPRS internet connection (like now :)). I download big things while connected to LAN and I need to be sure that I have all deps fetched when going on holiday. If I had to fetch all dependencies manually (and not only from cocoon) I would always miss something. A full download may not be the default one but we surely need it. -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: CoWarp (was Re: svn commit: r232855...)
I am often working using a lousy GPRS internet connection (like now :)). I download big things while connected to LAN and I need to be sure that I have all deps fetched when going on holiday. If I had to fetch all dependencies manually (and not only from cocoon) I would always miss something. A full download may not be the default one but we surely need it. Didn't you just send a message stating spring does the same any you are happy with it?? I don't see a problem with your GPRS connection. Maybe I did not make myself clear: o the checkout would not contain any 3rd party jars o the definition of what is meant to be built will define what jars need to be downloaded o a tailored cocoon like that will only have the jar ins WEB-INF/lib it really needs o for every release we also provide a with-all-deps version for vadim ;) o we have a target/goal to download all the deps once you are online So where is the problem again? cheers -- Torsten Btw: once we have all bundle based we wanted to move towards the download direction anyway ...at least to my understanding. PGP.sig Description: This is a digitally signed message part
Re: CoWarp (was Re: svn commit: r232855...)
Leszek Gawron wrote: -(-(-1)) ! :) I am often working using a lousy GPRS internet connection (like now :)). I download big things while connected to LAN and I need to be sure that I have all deps fetched when going on holiday. If I had to fetch all dependencies manually (and not only from cocoon) I would always miss something. A full download may not be the default one but we surely need it. That wouldn't be a problem if you built right after your download and before disconnecting. You'd have all the dependencies in the repository on your local machine. Unless, of course, you plan on upgrading a jar while disconnected ;-) BTW - fetching manually is perhaps not the best wording, since the person running the build just sits and watches it all happen. I've got to tell you, our configuration management folks absolutely love Maven because they can control what is in their repository and they see every dependency change, precisely because the build will fail if it isn't in the repository. We are supposed to identify all the 3rd party jars that are upgraded to them before they run the build and they can easily see when we forget one. Ralph
Re: CoWarp (was Re: svn commit: r232855...)
Torsten Curdt wrote: I am often working using a lousy GPRS internet connection (like now :)). I download big things while connected to LAN and I need to be sure that I have all deps fetched when going on holiday. If I had to fetch all dependencies manually (and not only from cocoon) I would always miss something. A full download may not be the default one but we surely need it. Didn't you just send a message stating spring does the same any you are happy with it?? I don't see a problem with your GPRS connection. Maybe I did not make myself clear: o the checkout would not contain any 3rd party jars o the definition of what is meant to be built will define what jars need to be downloaded o a tailored cocoon like that will only have the jar ins WEB-INF/lib it really needs o for every release we also provide a with-all-deps version for vadim ;) and me :) o we have a target/goal to download all the deps once you are online So where is the problem again? That's totally fine. Sorry for the noise. -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: CoWarp (was Re: svn commit: r232855...)
On 16.08.2005 17:51, Vadim Gritsenko wrote: Comparing lots of other software out there, Cocoon is among the best one with regards to the effort needed to get up and running. All you need is: download/unzip build.bat cocoon.bat No need to fight with dependency-fetching-tools, hunt for working mirror, mess with endorsed directories, install MySQL, rebuild kernel, etc. I think it should stay that way. +1 Me too. Joerg
Re: CoWarp (was Re: svn commit: r232855...)
On 16.08.2005 15:04, Carsten Ziegeler wrote: It's not really here about adding a new block, but about providing a simple and unified way of solving a common problem in Cocoon, which the current pipeline-based auth-framework doesn't seem to solve (I personally never used it). The interfaces could be in core, along with the basic trivial implementations, and blocks could provide specialized implementations (e.g. JDBC, LDAP, JCR, etc). Ah, ok adding the classes to core makes imho more sense, agreed. I would like to see it on the same level as CForms - not in the core, but as what was so called core block. So you can most easily remove it from your code base if you want to use another authentication framework. But delivering a webapplication framework without an authentication sub-framework is not imaginable ;-) Joerg
Re: CoWarp (was Re: svn commit: r232855...)
Joerg Heinicke wrote: On 16.08.2005 15:04, Carsten Ziegeler wrote: It's not really here about adding a new block, but about providing a simple and unified way of solving a common problem in Cocoon, which the current pipeline-based auth-framework doesn't seem to solve (I personally never used it). The interfaces could be in core, along with the basic trivial implementations, and blocks could provide specialized implementations (e.g. JDBC, LDAP, JCR, etc). Ah, ok adding the classes to core makes imho more sense, agreed. I would like to see it on the same level as CForms - not in the core, but as what was so called core block. So you can most easily remove it from your code base if you want to use another authentication framework. But delivering a webapplication framework without an authentication sub-framework is not imaginable ;-) CAuth :-) I like the idea. Vadim
Re: CoWarp (was Re: svn commit: r232855...)
Sylvain Wallez wrote: Carsten Ziegeler wrote: Sylvain Wallez schrieb: Carsten Ziegeler wrote: For the demo portal, I replaced the authentication framework with CoWarp which provides imho a much nicer and cleaner way for plugging in your authentication mechanism. CoWarp is a 35 kb jar file containing 25 classes which seem highly tied to Cocoon and Avalon. Do you plan to move this code to the Cocoon repo? That would be IMHO a good thing to do to avoid the multiplication of small jars and give a better community oversight on this interesting stuff. How much can grow a block that are already stabilized and provide the functionality most of the users needs? I think it is that people don't care about them. It is that this blocks just works. If there is *high* community interest in hosting it at Apache I'm willing to move. While 2 people cannot do a high community and I don't saw the Cowarp code nor how it works, but based on what I read on this thread, I can say, I have interest to see Cowarp in Cocoon. As suggested, Cowarp into cocoon can replace the current authentication-fw and session-fw blocks. The lastest mentioned blocks are part of the pre-flow era. So his deprecation is natural. I think it is time to have a new replacement for them. Also, I remember Carten's initial blogs about Cowarp 2 years ago. ;-) So let's switch Cocoon to Maven ;-) Big +1. I am really tired of updating jars. I will prefer to dedicate my 2 cents to other issues that need attention for example bug fixing. ;-) The only problem I see here is that cocoon 2.1.x requires JVM 1.3. Often the blocks on maven repo are for JVM 1.4 only. I hate to say that, because it takes a lot of time to check the compatibilty for 1.3 (mainly if I consider I never used it in my life for real work). If we are moving to maven, I will like to propose for the next cocoon 2.1.x release to set the monimal JVM requirement to 1.4. Can I start a vote about moving to 1.4? Best Regards, Antonio Gallardo.
Re: CoWarp (was Re: svn commit: r232855...)
Antonio Gallardo wrote: If ..., I will like to propose for the next cocoon 2.1.x release to set the monimal JVM requirement to 1.4. Can I start a vote about moving to 1.4? -1 for change of JVM requirement in the 2.1.8 release, which should be released ASAP anyway - it is delayed too much already. +1 for the change in any release after 2.1.8. Vadim
