You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2003/01/15 17:48:15 UTC

[announce] CVSSource at cocoondev.org

Dear all,

I'm please to announce the availability of the CVSSource I talked about 
recently on cocoon-dev.

This component allows adding new protocols to the ones available in 
Cocoon (such as "resource:", "cocoon:", etc) which are linked "live" to 
a remote CVS repository. These protocols are _writeable_ : reading a 
CVSSource gets the latest revision of the corresponding file, and 
writing it creates a new revision.

The implementation is based on a LGPL'ed library and so cannot be hosted 
on Apache's CVS. Steven Noels kindly accepted to host it on 
cocoondev.org. So everything is available at :
   http://www.cocoondev.org/projects/cvssource.html

This is still to be considered experimental, although already used on 
real projects. So I'm awaiting your comments, suggestions and patches !

Enjoy,
Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: [announce] CVSSource at cocoondev.org

Posted by Steven Noels <st...@outerthought.org>.
Carsten Ziegeler wrote:

> Ok, but is there any apache project including lgpl'ed libraries in
> their release distribution?

not LGPL - I was referring to some Sun jars like mail/activation/jta 
which allow binary-only redistribution. As per LGPL: dunnow - slim 
chance, I guess.

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: [announce] CVSSource at cocoondev.org

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
> 
> Carsten Ziegeler wrote:
> 
> >Steven Noels wrote:
> >  
> >
> >>Yep. Some of these libraries can be redistributable in _binary_ form, 
> >>but cannot be stored in CVS. They should be included in the release 
> >>distro by the release manager, who downloaded the libraries 
> locally. But 
> >>they cannot be stored in ASF CVS for the ease of compilation.
> >>
> >Is this true? Does the licence and the ASF really allow this? 
> >Is any other apache project doing this already?
> >  
> >
> 
> Every Maven-enabled project does this...
> 
> The Tomcat or Axis builds don't automatically download libraries, but 
> require them to be present.
> 
Ok, but is there any apache project including lgpl'ed libraries in their
release distribution?

Carsten

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: [announce] CVSSource at cocoondev.org

Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:

>Steven Noels wrote:
>  
>
>>Yep. Some of these libraries can be redistributable in _binary_ form, 
>>but cannot be stored in CVS. They should be included in the release 
>>distro by the release manager, who downloaded the libraries locally. But 
>>they cannot be stored in ASF CVS for the ease of compilation.
>>
>Is this true? Does the licence and the ASF really allow this? 
>Is any other apache project doing this already?
>  
>

Every Maven-enabled project does this...

The Tomcat or Axis builds don't automatically download libraries, but 
require them to be present.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: [announce] CVSSource at cocoondev.org

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Steven Noels wrote:
> 
> Yep. Some of these libraries can be redistributable in _binary_ form, 
> but cannot be stored in CVS. They should be included in the release 
> distro by the release manager, who downloaded the libraries locally. But 
> they cannot be stored in ASF CVS for the ease of compilation.
> 
Is this true? Does the licence and the ASF really allow this? 
Is any other apache project doing this already?

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: [announce] CVSSource at cocoondev.org

Posted by Steven Noels <st...@outerthought.org>.
Sylvain Wallez wrote:

> Moreover, writing a detailed mock for a LGPL'ed library means copying 
> the library's structure. Legally, can't this be considered as some 
> derivative work, requiring the mocks to be also LGPL'ed ? I don't know.

I'm pretty sure that could be considered derivative work, and even more 
sure that the (L)GPL will go at length _not_ being explicit about it, so 
that it will be up to personal interpretation. This means uncertainty, 
and the policy over here appears to: if it isn't explicitly allowed, it 
is disallowed.

> The solution seems to me some changes to the build system so that 
> problematic libraries are downloaded from a remote location when needed.

Yep. Some of these libraries can be redistributable in _binary_ form, 
but cannot be stored in CVS. They should be included in the release 
distro by the release manager, who downloaded the libraries locally. But 
they cannot be stored in ASF CVS for the ease of compilation.

> Time to consider moving to Maven or Centipede ?

That would ease some of the issues, yes.

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: [announce] CVSSource at cocoondev.org

Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:

> Sylvain Wallez wrote:

<snip/>

>> Hope I won't be flamed by Nicola Ken for having written "Maven" 
>> _before_ "Centipede" ;-P
>
>
> No, not flamed, just going to lower my opinion on you from 1000% to 
> 999% ;-)
>
> For one thing, Maven projects don't yet compile with Maven under Gump. 
> Then they use Jelly, not Ant. Centiepde has Forrest-skinned reports 
> and Forrest usage integrated. And finally you need a descriptor for 
> every project, not a single Gump descriptor that Centipede uses.
>
> I can set up a centipede version of the build for you all to try.
>
> You all love me, don't you?   |-)


If you take the mess out of our build system then : YES, YES, YES !!!

Seriously, I've seen several "Centipede/Maven challenges" recently on 
various blogs, and I consider Cocoon's build to be a good showcase to 
demonstrate the power of a build system :
- several source directories
- source preprocessing (JDBC 2 / JDBC 3)
- download of remote libraries
- Cocoon-based documentation (soon Forrest ?)
- erm... no (or so little) unit tests :-/

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: [announce] CVSSource at cocoondev.org

Posted by Steven Noels <st...@outerthought.org>.
Nicola Ken Barozzi wrote:

> I can set up a centipede version of the build for you all to try.
> 
> You all love me, don't you?   |-)

Big Hug!

http://www.amazon.com/exec/obidos/ASIN/043913854X/

</Steven>
-- 
Steven Noels                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at            http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org                stevenn at apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: [announce] CVSSource at cocoondev.org

Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
> 
>> Sylvain Wallez wrote:
[...]
>>> Time to consider moving to Maven or Centipede ?
>>>
>> Argh, by this you start another excellent thread about whether to use
>> Maven or Centipede. Oh my, this will overcrowd our mail boxes for one
>> week ;)
>>
> 
> Yep. I hesitated to write these two words ;-)
> 
> Hope I won't be flamed by Nicola Ken for having written "Maven" _before_ 
> "Centipede" ;-P

No, not flamed, just going to lower my opinion on you from 1000% to 999% ;-)

For one thing, Maven projects don't yet compile with Maven under Gump. 
Then they use Jelly, not Ant. Centiepde has Forrest-skinned reports and 
Forrest usage integrated. And finally you need a descriptor for every 
project, not a single Gump descriptor that Centipede uses.

I can set up a centipede version of the build for you all to try.

You all love me, don't you?   |-)

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: Zombie code (was: Re: [announce] CVSSource at cocoondev.org)

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Carsten Ziegeler wrote:
>
> >Sylvain Wallez wrote:
> >
> >
> >>>Well, for the download feature we don't really need one of those. Ant
> >>>is able to download things as well. Look at the avalon framework build
> >>>script for example. It provides extra targets to download 3rd party
> >>>libraries.
> >>>
> >>Can be a way to go. However, I'd like to place an absolute requirement
> >>on the build system : the "dist" target *must compile all source files*.
> >>
> >>That means we may not require all libs to be present to build a local
> >>cocoon.jar (some users want to build their own jar but don't need the
> >>whole stuff), but the distro must include everything.
> >>
> >Hmm, interesting idea - this is currently not the case. I'm not sure, if
> >this is really a good idea. For example, how many downloaders need the
> >php support?
> >
> >
>
> Not that many, but if the class isn't included in the distro, then you
> can be sure _nobody_ will use it ! And so this becomes "zombie code" in
> our CVS repo !
>
> Look at [1] and [2] : this clearly shows that JSPEngineImplWLS _is_
> zombified. Users need it but don't know about it, and those who know
> about it find it to be out of date and give up... Had this code been
> included in the distro, we certainly would have received some patches to
> upgrade it for newer versions of WLS.
>
So, that's simple: we need better documentation :) (just kidding)

If I understand you right, you mean the compiled classes but not the
required libraries, right? If so, that's ok for me.

Carsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Zombie code (was: Re: [announce] CVSSource at cocoondev.org)

Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>  
>
>>>Well, for the download feature we don't really need one of those. Ant
>>>is able to download things as well. Look at the avalon framework build
>>>script for example. It provides extra targets to download 3rd party
>>>libraries.
>>>
>>Can be a way to go. However, I'd like to place an absolute requirement 
>>on the build system : the "dist" target *must compile all source files*.
>>
>>That means we may not require all libs to be present to build a local 
>>cocoon.jar (some users want to build their own jar but don't need the 
>>whole stuff), but the distro must include everything.
>>
>Hmm, interesting idea - this is currently not the case. I'm not sure, if
>this is really a good idea. For example, how many downloaders need the
>php support? 
>  
>

Not that many, but if the class isn't included in the distro, then you 
can be sure _nobody_ will use it ! And so this becomes "zombie code" in 
our CVS repo !

Look at [1] and [2] : this clearly shows that JSPEngineImplWLS _is_ 
zombified. Users need it but don't know about it, and those who know 
about it find it to be out of date and give up... Had this code been 
included in the distro, we certainly would have received some patches to 
upgrade it for newer versions of WLS.

Sylvain

[1] : http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=104125175308139&w=2
[2] : http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=103539082721215&w=2

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: [announce] CVSSource at cocoondev.org

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
> >Well, for the download feature we don't really need one of those. Ant
> >is able to download things as well. Look at the avalon framework build
> >script for example. It provides extra targets to download 3rd party
> >libraries.
> >
> 
> Can be a way to go. However, I'd like to place an absolute requirement 
> on the build system : the "dist" target *must compile all source files*.
> 
> That means we may not require all libs to be present to build a local 
> cocoon.jar (some users want to build their own jar but don't need the 
> whole stuff), but the distro must include everything.
> 
Hmm, interesting idea - this is currently not the case. I'm not sure, if
this is really a good idea. For example, how many downloaders need the
php support? 

But okay, for the 2.1 release we should consider this as an option.

Carsten

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: [announce] CVSSource at cocoondev.org

Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>  
>
>>Vadim Gritsenko wrote:
>>
>>>Sylvain Wallez wrote:
>>>
>>>>Dear all,
>>>>
>>>>I'm please to announce the availability of the CVSSource I talked 
>>>>about recently on cocoon-dev.
>>>>
>>>>This component allows adding new protocols to the ones available in 
>>>>Cocoon (such as "resource:", "cocoon:", etc) which are linked "live" 
>>>>to a remote CVS repository. These protocols are _writeable_ : reading 
>>>>a CVSSource gets the latest revision of the corresponding file, and 
>>>>writing it creates a new revision.
>>>>
>>>>The implementation is based on a LGPL'ed library and so cannot be 
>>>>hosted on Apache's CVS.
>>>>        
>>>>
>>>So, don't put library - put only mocks of needed classes. Can this be 
>>>done? 
>>>      
>>>
>
>Great work, Sylvain!
>  
>

Thanks :-)
But there's still a lot to do, mainly allowing traversal of the 
version/branch tree (it currently uses only the latest revision on the 
main branch).

>>I'm wondering to which extends mocks are a viable solution. They're ok 
>>when they mock interfaces that we cannot legally redistribute in binary 
>>form, or a limited number of methods on specific classes (such as Oracle 
>>JDBC driver or WLS JSP servlet), but they become a PITA when many 
>>classes and methods of the target library are used.
>>
>
>Yes, I was wondering this myself.
>
>  
>
>>Moreover, writing a detailed mock for a LGPL'ed library means copying 
>>the library's structure. Legally, can't this be considered as some 
>>derivative work, requiring the mocks to be also LGPL'ed ? I don't know.
>>
>>The solution seems to me some changes to the build system so that 
>>problematic libraries are downloaded from a remote location when needed.
>>
>Yes.
> 
>  
>
>>Time to consider moving to Maven or Centipede ?
>>
>Argh, by this you start another excellent thread about whether to use
>Maven or Centipede. Oh my, this will overcrowd our mail boxes for one
>week ;)
>

Yep. I hesitated to write these two words ;-)

Hope I won't be flamed by Nicola Ken for having written "Maven" _before_ 
"Centipede" ;-P

>Well, for the download feature we don't really need one of those. Ant
>is able to download things as well. Look at the avalon framework build
>script for example. It provides extra targets to download 3rd party
>libraries.
>

Can be a way to go. However, I'd like to place an absolute requirement 
on the build system : the "dist" target *must compile all source files*.

That means we may not require all libs to be present to build a local 
cocoon.jar (some users want to build their own jar but don't need the 
whole stuff), but the distro must include everything.

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


RE: [announce] CVSSource at cocoondev.org

Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
> 
> 
> Vadim Gritsenko wrote:
> 
> > Sylvain Wallez wrote:
> >
> >> Dear all,
> >>
> >> I'm please to announce the availability of the CVSSource I talked 
> >> about recently on cocoon-dev.
> >>
> >> This component allows adding new protocols to the ones available in 
> >> Cocoon (such as "resource:", "cocoon:", etc) which are linked "live" 
> >> to a remote CVS repository. These protocols are _writeable_ : reading 
> >> a CVSSource gets the latest revision of the corresponding file, and 
> >> writing it creates a new revision.
> >>
> >> The implementation is based on a LGPL'ed library and so cannot be 
> >> hosted on Apache's CVS.
> >
> >
> > So, don't put library - put only mocks of needed classes. Can this be 
> > done? 
> 
> 

Great work, Sylvain!

> I'm wondering to which extends mocks are a viable solution. They're ok 
> when they mock interfaces that we cannot legally redistribute in binary 
> form, or a limited number of methods on specific classes (such as Oracle 
> JDBC driver or WLS JSP servlet), but they become a PITA when many 
> classes and methods of the target library are used.
> 

Yes, I was wondering this myself.

> Moreover, writing a detailed mock for a LGPL'ed library means copying 
> the library's structure. Legally, can't this be considered as some 
> derivative work, requiring the mocks to be also LGPL'ed ? I don't know.
> 
> The solution seems to me some changes to the build system so that 
> problematic libraries are downloaded from a remote location when needed.
>
Yes.
 
> Time to consider moving to Maven or Centipede ?
> 
Argh, by this you start another excellent thread about whether to use
Maven or Centipede. Oh my, this will overcrowd our mail boxes for one
week ;)

Well, for the download feature we don't really need one of those. Ant
is able to download things as well. Look at the avalon framework build
script for example. It provides extra targets to download 3rd party
libraries. 

Carsten

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: [announce] CVSSource at cocoondev.org

Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:

> Sylvain Wallez wrote:
>
>> Dear all,
>>
>> I'm please to announce the availability of the CVSSource I talked 
>> about recently on cocoon-dev.
>>
>> This component allows adding new protocols to the ones available in 
>> Cocoon (such as "resource:", "cocoon:", etc) which are linked "live" 
>> to a remote CVS repository. These protocols are _writeable_ : reading 
>> a CVSSource gets the latest revision of the corresponding file, and 
>> writing it creates a new revision.
>>
>> The implementation is based on a LGPL'ed library and so cannot be 
>> hosted on Apache's CVS.
>
>
> So, don't put library - put only mocks of needed classes. Can this be 
> done? 


I'm wondering to which extends mocks are a viable solution. They're ok 
when they mock interfaces that we cannot legally redistribute in binary 
form, or a limited number of methods on specific classes (such as Oracle 
JDBC driver or WLS JSP servlet), but they become a PITA when many 
classes and methods of the target library are used.

Moreover, writing a detailed mock for a LGPL'ed library means copying 
the library's structure. Legally, can't this be considered as some 
derivative work, requiring the mocks to be also LGPL'ed ? I don't know.

The solution seems to me some changes to the build system so that 
problematic libraries are downloaded from a remote location when needed.

Time to consider moving to Maven or Centipede ?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: [announce] CVSSource at cocoondev.org

Posted by Vadim Gritsenko <va...@verizon.net>.
Sylvain Wallez wrote:

> Dear all,
>
> I'm please to announce the availability of the CVSSource I talked 
> about recently on cocoon-dev.
>
> This component allows adding new protocols to the ones available in 
> Cocoon (such as "resource:", "cocoon:", etc) which are linked "live" 
> to a remote CVS repository. These protocols are _writeable_ : reading 
> a CVSSource gets the latest revision of the corresponding file, and 
> writing it creates a new revision.
>
> The implementation is based on a LGPL'ed library and so cannot be 
> hosted on Apache's CVS.


So, don't put library - put only mocks of needed classes. Can this be done?

Vadim



> Steven Noels kindly accepted to host it on cocoondev.org. So 
> everything is available at :
>   http://www.cocoondev.org/projects/cvssource.html
>
> This is still to be considered experimental, although already used on 
> real projects. So I'm awaiting your comments, suggestions and patches !
>
> Enjoy,
> Sylvain
>



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: [announce] CVSSource at cocoondev.org

Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Dear all,
> 
> I'm please to announce the availability of the CVSSource I talked about 
> recently on cocoon-dev.
> 
> This component allows adding new protocols to the ones available in 
> Cocoon (such as "resource:", "cocoon:", etc) which are linked "live" to 
> a remote CVS repository. These protocols are _writeable_ : reading a 
> CVSSource gets the latest revision of the corresponding file, and 
> writing it creates a new revision.
> 
> The implementation is based on a LGPL'ed library and so cannot be hosted 
> on Apache's CVS. Steven Noels kindly accepted to host it on 
> cocoondev.org. So everything is available at :
>   http://www.cocoondev.org/projects/cvssource.html
> 
> This is still to be considered experimental, although already used on 
> real projects. So I'm awaiting your comments, suggestions and patches !
> 
> Enjoy,
> Sylvain
> 

Awesome!

-- 
Stefano Mazzocchi                               <st...@apache.org>
--------------------------------------------------------------------



---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <co...@xml.apache.org>
For additional commands, e-mail:   <co...@xml.apache.org>


Re: [announce] CVSSource at cocoondev.org

Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
> Dear all,
> 
> I'm please to announce the availability of the CVSSource I talked about 
> recently on cocoon-dev.
> 
> This component allows adding new protocols to the ones available in 
> Cocoon (such as "resource:", "cocoon:", etc) which are linked "live" to 
> a remote CVS repository. These protocols are _writeable_ : reading a 
> CVSSource gets the latest revision of the corresponding file, and 
> writing it creates a new revision.
> 
> The implementation is based on a LGPL'ed library and so cannot be hosted 
> on Apache's CVS. Steven Noels kindly accepted to host it on 
> cocoondev.org. So everything is available at :
>   http://www.cocoondev.org/projects/cvssource.html
> 
> This is still to be considered experimental, although already used on 
> real projects. So I'm awaiting your comments, suggestions and patches !
> 
> Enjoy,
> Sylvain
> 

Awesome!

-- 
Stefano Mazzocchi                               <st...@apache.org>
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: [announce] CVSSource at cocoondev.org

Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stephan Michels wrote:

>On Wed, 15 Jan 2003, Sylvain Wallez wrote:
>
>  
>
>>Dear all,
>>
>>I'm please to announce the availability of the CVSSource I talked about
>>recently on cocoon-dev.
>>
>>This component allows adding new protocols to the ones available in
>>Cocoon (such as "resource:", "cocoon:", etc) which are linked "live" to
>>a remote CVS repository. These protocols are _writeable_ : reading a
>>CVSSource gets the latest revision of the corresponding file, and
>>writing it creates a new revision.
>>
>>The implementation is based on a LGPL'ed library and so cannot be hosted
>>on Apache's CVS. Steven Noels kindly accepted to host it on
>>cocoondev.org. So everything is available at :
>>   http://www.cocoondev.org/projects/cvssource.html
>>
>>This is still to be considered experimental, although already used on
>>real projects. So I'm awaiting your comments, suggestions and patches !
>>    
>>
>
>Thank you.
>
><protocol name="cocodoco-cvs"
>
>Cocodoco?! What a funny name ;-)
>
>Stephan Michels.
>  
>

That's because, in the sample, this protocol is related to Cocoon's 
documentation. Hence "cocodoco", for "cocoon documentation". But you can 
name it as you want !

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Re: [announce] CVSSource at cocoondev.org

Posted by Stephan Michels <st...@apache.org>.

On Wed, 15 Jan 2003, Sylvain Wallez wrote:

> Dear all,
>
> I'm please to announce the availability of the CVSSource I talked about
> recently on cocoon-dev.
>
> This component allows adding new protocols to the ones available in
> Cocoon (such as "resource:", "cocoon:", etc) which are linked "live" to
> a remote CVS repository. These protocols are _writeable_ : reading a
> CVSSource gets the latest revision of the corresponding file, and
> writing it creates a new revision.
>
> The implementation is based on a LGPL'ed library and so cannot be hosted
> on Apache's CVS. Steven Noels kindly accepted to host it on
> cocoondev.org. So everything is available at :
>    http://www.cocoondev.org/projects/cvssource.html
>
> This is still to be considered experimental, although already used on
> real projects. So I'm awaiting your comments, suggestions and patches !

Thank you.

<protocol name="cocodoco-cvs"

Cocodoco?! What a funny name ;-)

Stephan Michels.


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org