Fix for ajax periodicalUpdate

[Christofer Dutz]

Hi,

I had some big trouble with the Internet-Explorer and periodical updates.
The Internet-Explorer didnt really send the requests to the sever, but 
answered them from it's cache.
Everytime the cache was manually cleared a real update was made, but 
only once.

The following modifications made periodicalUpdates work.

Hope this helps someone.

Chris


Index: 
D:/Projects/Univativ/Projects/Disco3/WebContent/rorg/apache/cocoon/ajax/reources/js/common.js

===
--- 
D:/Projects/Univativ/Projects/Disco3/WebContent/rorg/apache/cocoon/ajax/reources/js/common.js
(revision 395)
+++ 
D:/Projects/Univativ/Projects/Disco3/WebContent/rorg/apache/cocoon/ajax/reources/js/common.js
(working copy)

@@ -57,8 +57,9 @@
load: function(type, data, evt){
insertion(target, data);
},
-mimetype: text/plain
-// TODO: add an error-handling function
+mimetype: text/plain,
+useCache: false,
+preventCache: true
});
   
},

SuggestionLists and JavaFlow

[Christofer Dutz]

Hi,

I am currently having some problems with JavaFlow and SuggestionLists.
My application used to generate dynamic suggestion lists in the 
_cocoon/forms/suggest pipeline.
Unfortunately the FormsGenerator, SuggestionListGenerator, JXGenerator 
and Transformer and my custom Generator seem to be unable to get the 
form instance.


I think this might be a result of the way JavaFlow deals with 
Continuations (GetContext beeing implemented using 
Thread.currentThread()) as the SuggestionList pipeline is served by a 
different Thread.


A soltuion I thought about was using some sort of Singleton for storing 
form instance data ... but would really like to avoid this.


Any suggestions?


Chris

Re: SuggestionLists and JavaFlow

[Christofer Dutz]

Hi Thorsten,

Well I think the suggestion-list content must be served by a different 
thread. Here is my scenario in a little more detail:
I created a patch to make suggestion-lists support on-value-changed 
events and they seem to work nicely. When debuging the FormInstance 
class I can see how the cocoon-ajax-continue loop is executed every 
time the fields value changes. Usually the client side suggestion-list 
javascript should load the result of a cocoon pipeline with the exact 
name _cocoon/forms/suggest into an iframe. This Iframe contains the 
suggestion-list content. Since my suggestions-lists are 
context-sensitive (they contain different input for different 
form-states, I need to get my hands on the FormInstance object of the 
parent frames pipeline. This was no problem using the code of the 
SuggestionListGenerator, but when using JavaFlow this doen't work anymore :(


Here the code that puts everything into the continuation (from 
AbstractContunable sendPageAndWait)
   
FlowHelper.setContextObject(ContextHelper.getObjectModel(context.getAvalonContext()), 
bizdata);


If I add the following watch expression in the Debugger directly after 
this, I can see that the FormInstance is there
   
FlowHelper.getContextObject(ContextHelper.getObjectModel(context.getAvalonContext()))


One of my counterparts is (A second JavaFlow ... didn't expect this to 
work, because of the way getContext is implemented):
   VarMap bizData = (VarMap) 
FlowHelper.getContextObject(ContextHelper.getObjectModel(context.getAvalonContext()));


The other one is (A Generator using the ContinuationsManager to lookup a 
WebContinuation based upon the continuation-id)
   public void setup(SourceResolver resolver, Map objectModel, String 
src, Parameters par) throws ProcessingException, SAXException, IOException {

   super.setup(resolver, objectModel, src, par);

   Request req = ObjectModelHelper.getRequest(objectModel);

   String continuationId = par.getParameter(continuation-id, 
req.getParameter(continuation-id));


   // The interpreter id is the sitemap's URI
   String interpreterId = 
SitemapParameters.getLocation(parameters).getURI();
  
   wk = this.contManager.lookupWebContinuation(continuationId, 
interpreterId);

   if (wk == null || wk.disposed()) {
   throw new InvalidContinuationException(Cannot get 
continuation for suggestion list);

   }

   Continuation continuation = (Continuation) wk.getContinuation();
   ContinuationContext context = (ContinuationContext) 
continuation.getContext();
   VarMap bizData = (VarMap) 
FlowHelper.getContextObject(ContextHelper.getObjectModel(context.getAvalonContext()));


   Form form = (Form) bizData.getMap().get(CocoonFormsInstance);

   if (form == null) {
   throw new ProcessingException(No form is attached to the 
continuation);

   }
   }
unfortunately bizData is null in both cases since there is no 
cocoon.flow.context inside the object-model.


Do I really have to store the form instances in the Session as a 
workaround? Would really like to avoid this, since I have to do all the 
housekeeping :(
Am I looking up something different? Is the thing the 
ContinuationManager is returning really the Continuation I want?


Chris


Torsten Curdt schrieb:

On 09.05.2007, at 15:56, Christofer Dutz wrote:

I am currently having some problems with JavaFlow and SuggestionLists.
My application used to generate dynamic suggestion lists in the 
_cocoon/forms/suggest pipeline.
Unfortunately the FormsGenerator, SuggestionListGenerator, 
JXGenerator and Transformer and my custom Generator seem to be unable 
to get the form instance.


I think this might be a result of the way JavaFlow deals with 
Continuations (GetContext beeing implemented using 
Thread.currentThread()) as the SuggestionList pipeline is served by a 
different Thread.
It's been a while and I would have to dig into the code but are 
you sure the other pipeline is served by a different thread?


A known limitation is when you use a continuation in one pipeline and 
use the cocoon protocol to a pipeline that also provides creates 
continuations. That aint work as you (atm) only can have one 
continuation per thread. (Not that complicated to change though)

Re: SuggestionLists and JavaFlow

[Christofer Dutz]

Hi,

after another day of debuging, I was able to track down the main problem:
the JavaInterpreter fetches the WebContinuation and uses this to create 
a new cocoon-flow-context each time it is executed.
The FormInstance is bound to this object and is used for executing the 
display pipeline. After this the temporary Context is destroyed.


In order to make my SaveTheData Pipeline work I had to change:
   // Save the modified userdata.
   sendPage(save/user_db);
To:
   // Manually attach the form to the request.
   VarMap bizData = new VarMap();
   bizData.add(FormsPipelineConfig.CFORMSKEY, form.getModel());
   Locale locale = java.util.Locale.getDefault();;
   bizData.add(locale, locale);

   // Save the modified userdata.
   sendPage(save/user_db, bizData);
Since the JavaFlow implementation wouldn't make the FormInstance 
available automatically.


Unfortunately this doesn't solve my SuggestionListProblem. My guess and 
my next try would be, to manually attach the FormInstance to the 
WebContinuation object, since this is not destroyed.


Any suggestions or objections?

Chris


Christofer Dutz schrieb:

Hi Thorsten,

Well I think the suggestion-list content must be served by a different 
thread. Here is my scenario in a little more detail:
I created a patch to make suggestion-lists support on-value-changed 
events and they seem to work nicely. When debuging the FormInstance 
class I can see how the cocoon-ajax-continue loop is executed every 
time the fields value changes. Usually the client side suggestion-list 
javascript should load the result of a cocoon pipeline with the exact 
name _cocoon/forms/suggest into an iframe. This Iframe contains the 
suggestion-list content. Since my suggestions-lists are 
context-sensitive (they contain different input for different 
form-states, I need to get my hands on the FormInstance object of the 
parent frames pipeline. This was no problem using the code of the 
SuggestionListGenerator, but when using JavaFlow this doen't work 
anymore :(


Here the code that puts everything into the continuation (from 
AbstractContunable sendPageAndWait)
   
FlowHelper.setContextObject(ContextHelper.getObjectModel(context.getAvalonContext()), 
bizdata);


If I add the following watch expression in the Debugger directly after 
this, I can see that the FormInstance is there
   
FlowHelper.getContextObject(ContextHelper.getObjectModel(context.getAvalonContext())) 



One of my counterparts is (A second JavaFlow ... didn't expect this to 
work, because of the way getContext is implemented):
   VarMap bizData = (VarMap) 
FlowHelper.getContextObject(ContextHelper.getObjectModel(context.getAvalonContext())); 



The other one is (A Generator using the ContinuationsManager to lookup 
a WebContinuation based upon the continuation-id)
   public void setup(SourceResolver resolver, Map objectModel, String 
src, Parameters par) throws ProcessingException, SAXException, 
IOException {

   super.setup(resolver, objectModel, src, par);

   Request req = ObjectModelHelper.getRequest(objectModel);

   String continuationId = par.getParameter(continuation-id, 
req.getParameter(continuation-id));


   // The interpreter id is the sitemap's URI
   String interpreterId = 
SitemapParameters.getLocation(parameters).getURI();
 wk = this.contManager.lookupWebContinuation(continuationId, 
interpreterId);

   if (wk == null || wk.disposed()) {
   throw new InvalidContinuationException(Cannot get 
continuation for suggestion list);

   }

   Continuation continuation = (Continuation) wk.getContinuation();
   ContinuationContext context = (ContinuationContext) 
continuation.getContext();
   VarMap bizData = (VarMap) 
FlowHelper.getContextObject(ContextHelper.getObjectModel(context.getAvalonContext())); 



   Form form = (Form) bizData.getMap().get(CocoonFormsInstance);

   if (form == null) {
   throw new ProcessingException(No form is attached to the 
continuation);

   }
   }
unfortunately bizData is null in both cases since there is no 
cocoon.flow.context inside the object-model.


Do I really have to store the form instances in the Session as a 
workaround? Would really like to avoid this, since I have to do all 
the housekeeping :(
Am I looking up something different? Is the thing the 
ContinuationManager is returning really the Continuation I want?


Chris


Torsten Curdt schrieb:

On 09.05.2007, at 15:56, Christofer Dutz wrote:

I am currently having some problems with JavaFlow and SuggestionLists.
My application used to generate dynamic suggestion lists in the 
_cocoon/forms/suggest pipeline.
Unfortunately the FormsGenerator, SuggestionListGenerator, 
JXGenerator and Transformer and my custom Generator seem to be 
unable to get the form instance.


I think this might be a result of the way JavaFlow deals with 
Continuations (GetContext

[Solved] JavaFlow and SuggestionLists

[Christofer Dutz]

Hi,

For th last two weeks I was dealing with the problem, that 
SuggestionLists didn't work with JavaFlow anymore. In addition to this, 
also my Pipelines for saving form-data stopped workling.
I could track both of them down to the problem, that the JavaInterpreter 
class constructs a ContinuationContext obejct and coppies the data of 
the WebContinuation Context. When assigning a FormInstance to the 
Continuation everything works fine as long as the form is shown by 
sendPageAndWait (ok ok ... form.show() too, but that just uses 
sendPageAndWait). Since there is no link between WebContinuation and 
ContinuationContext, when loosing the reference to the temporary 
ContinuationContext it is gone for ever.


I solved my problem by adapting the ContinuationContext and the 
JavaInterpreter class so they provide a 
ContinuationContext.getParentWebContinuation() method. If I use this to 
manually set the FormInstance to this, my form is available for my 
modified SuggestionListGenerator.


I would gladly provide a patch, if this solution is nice-enough to be 
accepted. Without it I can see no way of beeing able to use any AJAX 
widget using IFrames (SuggestionList, Upload, ...)


Chris

Re: [Solved] JavaFlow and SuggestionLists

[Christofer Dutz]

Hi Torsten,

I am currently using an out-of-the-box Cocoon 2.1.10.
Generally there currently seems to be no way to use any of the 
IFrame-Based Cforms/Dojo widgets, because they simply can't find the 
FormInstance.


I know that this is pretty hack'ish ... but It was the only way for me 
to get everything runing without doing really big refactoring.


Chris


Torsten Curdt schrieb:

Hm... sounds a bit hack'ish (and even worse) more work that it should be.
What version of cocoon/javaflow are you talking about?

cheers
--
Torsten

On 11.05.2007, at 10:10, Christofer Dutz wrote:


Hi,

For th last two weeks I was dealing with the problem, that 
SuggestionLists didn't work with JavaFlow anymore. In addition to 
this, also my Pipelines for saving form-data stopped workling.
I could track both of them down to the problem, that the 
JavaInterpreter class constructs a ContinuationContext obejct and 
coppies the data of the WebContinuation Context. When assigning a 
FormInstance to the Continuation everything works fine as long as the 
form is shown by sendPageAndWait (ok ok ... form.show() too, but that 
just uses sendPageAndWait). Since there is no link between 
WebContinuation and ContinuationContext, when loosing the reference 
to the temporary ContinuationContext it is gone for ever.


I solved my problem by adapting the ContinuationContext and the 
JavaInterpreter class so they provide a 
ContinuationContext.getParentWebContinuation() method. If I use this 
to manually set the FormInstance to this, my form is available for my 
modified SuggestionListGenerator.


I would gladly provide a patch, if this solution is nice-enough to be 
accepted. Without it I can see no way of beeing able to use any AJAX 
widget using IFrames (SuggestionList, Upload, ...)


Chris

AW: Client-side validation in CForms

[Christofer Dutz]

When I was working on my first attempts to do exactly what you are trying to
do (CForms using dojo 1.1 and client side validation), I ran into exactly
the same problem as you did. I too think it would be easily possible to
implement client and server-side validation using dojo. Even if it would not
be possible to implement all. 

Unfortunately the fi-output is hard-coded into the widget class
implementation and no validation information is sent. Making client-side
validation work, it would make it necessary to patch every single Widget
class to output this validation-data, but should be easy to accomplish.

I stopped my work on this, since I had doubt's anyone would be interested in
a feature like this and the thought of having to maintain patches for so
many classes let me drop that idea.

Chris



-Ursprüngliche Nachricht-
Von: Jeremy Quinn [mailto:[EMAIL PROTECTED] 
Gesendet: Mittwoch, 9. Juli 2008 17:17
An: dev@cocoon.apache.org
Betreff: Client-side validation in CForms

Hi All

As you may know, I am working heavily on the revamp of Dojo on the  
client-side of CForms.

In Dojo it is possible to perform quite a lot of validation on form  
fields. There is a partial match between the validation capabilities  
of CForms and those of Dojo. Several people have thought in the past  
that it would be good to have the same validation occur on both the  
server and the client.

OTTOMH, the kind of validators we could probably make work in both  
places would be :
email, length, mod10, range and regexp (plus maybe javascript, if we

can sort out any context differences)

ATM however, no validation information is output by the form  
generation process. Datatypes are there (which I can initially use)  
but no validation.

So my question is, would someone volunteer to either add the  
definition's validation tags to the output or help work out the  
cleanest approach to adding it?

Many thanks


regards Jeremy

AW: AW: Client-side validation in CForms

[Christofer Dutz]

=fi:repeater-size
input type=hidden name=[EMAIL PROTECTED] value=[EMAIL PROTECTED]/
  /xsl:template
  !--
  
  Defaults
  
  --
  xsl:template match=@*|node() priority=-1 mode=forms-header
xsl:copy
  xsl:apply-templates select=@*|node()/
/xsl:copy
  /xsl:template

  xsl:template match=@*|node() priority=-1
xsl:copy
  xsl:apply-templates select=@*|node()/
/xsl:copy
  /xsl:template
  xsl:template match=fi:label/
/xsl:stylesheet





-Ursprüngliche Nachricht-
Von: Jeremy Quinn [mailto:[EMAIL PROTECTED] 
Gesendet: Montag, 14. Juli 2008 12:41
An: dev@cocoon.apache.org
Betreff: Re: AW: Client-side validation in CForms

Hi Christofer

On 13 Jul 2008, at 13:13, Christofer Dutz wrote:

 When I was working on my first attempts to do exactly what you are  
 trying to
 do (CForms using dojo 1.1 and client side validation), I ran into  
 exactly
 the same problem as you did. I too think it would be easily possible  
 to
 implement client and server-side validation using dojo. Even if it  
 would not
 be possible to implement all.

 Unfortunately the fi-output is hard-coded into the widget class
 implementation and no validation information is sent. Making client- 
 side
 validation work, it would make it necessary to patch every single  
 Widget
 class to output this validation-data, but should be easy to  
 accomplish.

 I stopped my work on this, since I had doubt's anyone would be  
 interested in
 a feature like this and the thought of having to maintain patches  
 for so
 many classes let me drop that idea.

I had a look as well and did not fancy ploughing in to the code to add  
this right now, as I have so much else to do before I can release the  
client-side stuff (hence asking for volunteers  )

What I am working on in the meantime is using the (existing)  
fi:datatype base=string|integer|long|double|float|decimal/ tags to  
perform basic datatype validation on the client. My hope is that  
adding support for this now, will make it easier to add fuller  
validation client-side in the future.

BTW. Christofer, I attempted to contact you earlier about the private  
work you said you had been doing on Dojo 1.1, to see if I could roll  
it into my work. If you are interested in contributing, please contact  
me off-list.


Many thanks

regards Jeremy




 -Ursprüngliche Nachricht-
 Von: Jeremy Quinn [mailto:[EMAIL PROTECTED]
 Gesendet: Mittwoch, 9. Juli 2008 17:17
 An: dev@cocoon.apache.org
 Betreff: Client-side validation in CForms

 Hi All

 As you may know, I am working heavily on the revamp of Dojo on the
 client-side of CForms.

 In Dojo it is possible to perform quite a lot of validation on form
 fields. There is a partial match between the validation capabilities
 of CForms and those of Dojo. Several people have thought in the past
 that it would be good to have the same validation occur on both the
 server and the client.

 OTTOMH, the kind of validators we could probably make work in both
 places would be :
   email, length, mod10, range and regexp (plus maybe javascript, if we

 can sort out any context differences)

 ATM however, no validation information is output by the form
 generation process. Datatypes are there (which I can initially use)
 but no validation.

 So my question is, would someone volunteer to either add the
 definition's validation tags to the output or help work out the
 cleanest approach to adding it?

 Many thanks


 regards Jeremy

AW: AW: AW: Client-side validation in CForms

[Christofer Dutz]

Hi Jeremy,

doesn't dojo load a i18n resource for the messages? I don’t think it should
be a problem taking over this or getting Dojo to load our i18n resources ...
xml-i18n resources for cocoon would have been really nice for this ... in
the worst case I think it should be possible (it even might already exist)
to create a resource-file-generator, that simply converts these nasty
text-form resource files to neat xml and then translate this to Dojo i18n
resources with a simple xslt.

With the other problems ... well I agree that they might be tricky ... but
what would the challenge be, if everything was easy? ;-)

I think the main difference in my approach and the old Cocoon approach is
not to reinvent the wheel. I never quite understood all the
double-implemention of widgets. But I have to admit the old Dojo was missing
quite some stuff and I even had to bugfix quite a lot in the Dojo0.4 Stuff.
At the moment simply using Dojo and providing some very basic JavaScripts
should be sufficient.

Chris



-Ursprüngliche Nachricht-
Von: Jeremy Quinn [mailto:[EMAIL PROTECTED] 
Gesendet: Mittwoch, 16. Juli 2008 12:45
An: dev@cocoon.apache.org
Betreff: Re: AW: AW: Client-side validation in CForms

Hi Chris

Thanks for this, it should speed me up a bit, I hope : )

Simple client-side validation based on datatype is working here.  
Dojo's constraints and filters are working too, so as a proof of  
concept it is working well.

One issue(?): when a field is invalid (while you are typing) you will  
see one of Dojo's generic i18n error messages until you have submitted  
the bad data to Cocoon, only then will you see the cform's error  
messages. Not sure if there will ever be a workaround for this ...

So currently, the main problem is that you'd have to specify the same  
validation twice ..

model :

fd:field id=name required=true
   fd:hintPlease name your datasource/fd:hint
   fd:helpdivThis is breally/b helpful advice!!/div/fd:help
   fd:datatype base=string/
 fd:validation
   fd:regexp pattern=C.*
 fd:failmessageSorry, the PMC really does insist the name  
should begin with the letter 'C'./fd:failmessage
  /fd:regexp
/fd:validation
  /fd:field

template (eg. with filters applied on the client) :

ft:widget id=name
   fi:styling propercase=true trim=true regExp=^C.*/
/ft:widget

Obviously it is ghastly to specify the same validation twice, so the  
next sensible step IMHO is to get the validation info generated out to  
the template in a form that can be processed by xslt into appropriate  
constraints for dojo.
eg: {min: 10, max: 1, places: 0} etc.

The main problem is going to be handling expressions . specially  
stuff that points to other objects :
   fd:validation
 fd:range min=number1 + 1

These are the constraints for Number types :
pattern: String?
override [formatting pattern]
(http://www.unicode.org/reports/tr35/#Number_Format_Patterns 
) with this string
type: String?
choose a format type based on the locale from the following:
decimal, scientific, percent, currency. decimal by default.
places: Number?
fixed number of decimal places to show.  This overrides any
information in the provided pattern.
round: Number?
5 rounds to nearest .5; 0 rounds to nearest whole (default). -1
means don't round.
currency: String?
an [ISO4217](http://en.wikipedia.org/wiki/ISO_4217) currency code,
 a three letter sequence like USD
symbol: String?
localized currency symbol
locale: String?
override the locale used to determine formatting rules

The constraints for Ranges :
min: Number?
the lowest value allowed
max: Number?
the highest number allowed

Hopefully we can pull out a usable subset of cforms validation and  
present it to the client-side.

I'll let you guys mull it over for a while :)

Thanks again

regards Jeremy



On 14 Jul 2008, at 14:45, Christofer Dutz wrote:

snip/

 I think generating the validation-output needed for client side- 
 validation
 shouldn't be a big problem, since it’s the same for almost all  
 widgets the
 class having to be patched should be the simple Widget base-classes.  
 I would
 volunteer implementing it, but only if it is really wanted.

 Chris

snip/

AW: AW: AW: AW: Client-side validation in CForms

[Christofer Dutz]

Hi ... well I never really used the I18N Stuff, I have to admit. 
Every time I got in contact with it (currently using Cocoon 2.1.10) I
thought they were text files and no Xml files.

Regarding your Expression-Interpreter. I do have quite some experience with
parsers and interpreters, so maybe this could be a part that I could help
you with. 

If we think of all Form elements as dojo widgets, we could use the dojo
query functions for finding elements, since it's a lot easier navigating in
the widget hierarchy than in the html page (dojo.byId vs. dijit.byId). 

Unfortunately I am currently struggling with some issues of my current
cocoon project, but I think I will have them solved in the next few days. I
would gladly help with these client side validators, but I would rather
suggest adjusting the Server Side Sax-Generation to output the needed
information first ... without this, all client side stuff is useless, since
we can't get the validator rules to our cforms-xslt.

Chris



-Ursprüngliche Nachricht-
Von: Jeremy Quinn [mailto:[EMAIL PROTECTED] 
Gesendet: Montag, 21. Juli 2008 13:45
An: dev@cocoon.apache.org
Betreff: Re: AW: AW: AW: Client-side validation in CForms

Hi Chris

Sorry it took me so long to reply.

On 17 Jul 2008, at 16:48, Christofer Dutz wrote:

 Hi Jeremy,

 doesn't dojo load a i18n resource for the messages?

It does, but this may be perceived as a problem because CForms users  
expect to supply all of their own i18n messages (and I personally find  
some of dojo's language a bit un-natural).

 I don’t think it should
 be a problem taking over this or getting Dojo to load our i18n  
 resources ...

This is most likely possible, but I have not looked into it yet.

 xml-i18n resources for cocoon would have been really nice for  
 this ... in
 the worst case I think it should be possible (it even might already  
 exist)
 to create a resource-file-generator, that simply converts these nasty
 text-form resource files to neat xml and then translate this to Dojo  
 i18n
 resources with a simple xslt.

Are you confusing java i18n properties-type bundles with Cocoon i18n  
xml message files?
Transforming Cocoon's XML bundles to Dojo's json-based format should  
not be too difficult.

 With the other problems ... well I agree that they might be  
 tricky ... but
 what would the challenge be, if everything was easy? ;-)

Well, we should start with the low hanging fruit :
regExp, min, max, email, mod10, value-count etc.

I was googling for a JavaScript implementation of the XReporter  
expression language, but no luck yet ;)

I have never written an interpreter before :)
But I was thinking about a simple case like this :
fd:validation
   fd:range min=number1 + 1
 fd:failmessageThis number should be larger than the first  
number./fd:failmessage
   /fd:range
/fd:validation

client-side (off the top of my head) :
var min = 0;
try {
   with (this.form) min = eval(number1 + 1)
} catch e {
   // could not evaluate expression
}

so 'number1' gets evaluated in the scope of this.form.

but it quickly gets nasty ..
The languages comparison operator is a single '=' not a double one :(
References to fields can be relative (../fieldname) etc. etc.

 I think the main difference in my approach and the old Cocoon  
 approach is
 not to reinvent the wheel. I never quite understood all the
 double-implemention of widgets. But I have to admit the old Dojo was  
 missing
 quite some stuff and I even had to bugfix quite a lot in the Dojo0.4  
 Stuff.
 At the moment simply using Dojo and providing some very basic  
 JavaScripts
 should be sufficient.

Well one of the problems is that there is a big mismatch between the  
assumptions behind Dojo and CForms.

eg. number fields

Cocoon expects no smarts on the client, so a user would typically have  
a converter for a form value to send a locale-formatted string  
representation of the number to edit to the client :

value: 1234567.89
sends: 1,234,567.89 (en_GB)
1 234 567,89 (fr_FR)
etc.

Cocoon then expects the formatted value in return.

Dojo however, expects to send and receive un-formatted numbers,  
performing l10n client-side.

This is not impossible to resolve, but it indicates some of the less- 
obvious complexities :)


Thanks for your feedback

regards Jeremy

AW: CForms and Dojo

[Christofer Dutz]

Well I can send you my Xslt, but it’s really pre-sub-alpha-0.0.0.0.1 Version
;-)

 

But I am using dojo widgets in repeaters though and they work as they
should. I can send you the file, but I’d suggest using it as inspiration and
not for production ;-)

 

Currently I am working myself into the mysteries of Cocoon 2.2 and it’s
build voodoo, so I haven’t had the time to make some real progress here. But
I am optimistic, that I will get the hang of C2.2 pretty soon. Jeremy is
currently working on client side validation and Dojo 1.1 … unfortunately I
haven’t had the time to make the changes needed for this. I promise I will
do my best to do this next week.

 

Chris

 

 

Von: Robin Wyles [mailto:[EMAIL PROTECTED] 
Gesendet: Donnerstag, 21. August 2008 11:08
An: dev@cocoon.apache.org
Betreff: Re: CForms and Dojo

 

Hi,

 

Can anyone tell me if this work in progress is available anywhere? I can't
seem to find it in trunk.. I am coming up against some bugs when using
certain dojo within a repeater - would love to see if dojo 1.1 resolves
these.

 

Chris... is your forms XSL available anywhere too?

 

Many thanks,

 

Robin

 

On 16 Jun 2008, at 08:00, Gabriel Gruber wrote:






Hi Chris! 

Jeremy is actually integrating Dojo 1.1 into cforms. I think he is doing
that in the 2.1.12dev branch and in trunk. It would be great, if you could
join forces with jeremy to have dojo 1.1 integrated into the next cocoon
release :-) 

greets, 
Gabriel 
__
Gabriel Gruber
Senior Consultant
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Workflow EDV GmbH, Dannebergplatz 6/23, A-1030 Wien





Christofer Dutz [EMAIL PROTECTED] 

12.06.2008 09:54 


Please respond to
[EMAIL PROTECTED]


To

[EMAIL PROTECTED] 


cc



Subject

CForms and Dojo

 






Hi there, 
  
I am still using Cocoon 2.1.9 and was wandering if the version of dojo used
for CForms in Ajax-Mode is used in 2.1.10 and 2.2? Since my current
application is currently using a lot of Dojo 1.1 Stuff and I was sort of
annoyed of the problem having to use dojo 0.4 and 1.1 together, I started
creating my own forms-styling.xsl, which does the same as the original
cocoon version, instead it uses dojo 1.1 with all its advanced features. It
is currently working nicely. 
  
Does Cocoon in a version greater than 2.1.9 still use Dojo 0.4? If yes, it
might be interesting for me to clean up my xslt and give it to the cocoon
guys (It looks a lot nicer). 
  
While working on the Dojo 1.1 integration I found out that none of the
validation-information is passed to the fi-stuff … it would be great if this
information was forwarded here, cause I could additionally use the Dojo
client-side validation in addition to the server-side validation of CForms
(I know this doesn’t work for all validators) reducing some
client-server-roundtrips. 
  
Chris 
  
  
  
[ C h r i s t o f e r  D u t z ]

C-Ware IT-Service
Inhaber
Dipl. Inf. Christofer Dutz
Karlstraße. 104, 64285 Darmstadt

fon:  0 61 51 / 27315 - 61
fax:  0 61 51 / 27315 - 64
mobil:  0171 / 7 444 2 33
email:   mailto:[EMAIL PROTECTED] [EMAIL PROTECTED]
 http://www.c-ware.de/ http://www.c-ware.de 
FA Darmstadt: 07 813 60581 
  
  
  
  

 

AW: [VOTE] Apache Cocoon 2.3.0 RC2 https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/

[Christofer Dutz]

Here’s the KEYS file … there wasn’t any, so I initialized it with my key.

https://dist.apache.org/repos/dist/dev/cocoon/KEYS

Chris

Von: Christofer Dutz 
Datum: Sonntag, 29. Oktober 2023 um 21:09
An: dev@cocoon.apache.org 
Cc: Cocoon PMC List 
Betreff: Re: [VOTE] Apache Cocoon 2.3.0 RC2 
https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
I added my key to the KEYS file in the svn repo one level up..

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: Peter Hunsberger 
Sent: Sunday, October 29, 2023 6:16:02 PM
To: dev@cocoon.apache.org 
Cc: Cocoon PMC List 
Subject: Re: [VOTE] Apache Cocoon 2.3.0 RC2 
https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/

Everything looks good except I can't check the signature, I get "No public key" 
from gpg.  I believe I need a copy of your public key to import?

Peter Hunsberger


On Sun, Oct 29, 2023 at 6:55 AM Christofer Dutz 
mailto:christofer.d...@c-ware.de>> wrote:

Apache Cocoon 2.3.0 has been staged under [2] and it’s time to vote

on accepting it for release. All Maven artifacts are available under [1].

Voting will be open for 72hr.



A minimum of 3 binding +1 votes and more binding +1 than binding -1

are required to pass.



Release tag: 
https://svn.apache.org/viewvc/cocoon/tags/cocoon-2.3/cocoon/cocoon-2.3.0/

Director revision of the tag: 1913422



Per [3] "Before voting +1 PMC members are required to download

the signed source code package, compile it as provided, and test

the resulting executable on their own platform, along with also

verifying that the package meets the requirements of the ASF policy

on releases."



You can achieve the above by following the guide of a fellow Apache project [4].



[ ]  +1 accept (indicate what you validated - e.g. performed the non-RM items 
in [4])

[ ]  -1 reject (explanation required)





[1] https://repository.apache.org/content/repositories/orgapachecocoon-1007

[2] https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/

[3] https://www.apache.org/dev/release.html#approving-a-release

[4] 
https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release

Re: [VOTE] Apache Cocoon 2.3.0 RC2 https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/

[Christofer Dutz]

I added my key to the KEYS file in the svn repo one level up..

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: Peter Hunsberger 
Sent: Sunday, October 29, 2023 6:16:02 PM
To: dev@cocoon.apache.org 
Cc: Cocoon PMC List 
Subject: Re: [VOTE] Apache Cocoon 2.3.0 RC2 
https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/

Everything looks good except I can't check the signature, I get "No public key" 
from gpg.  I believe I need a copy of your public key to import?

Peter Hunsberger


On Sun, Oct 29, 2023 at 6:55 AM Christofer Dutz 
mailto:christofer.d...@c-ware.de>> wrote:

Apache Cocoon 2.3.0 has been staged under [2] and it’s time to vote

on accepting it for release. All Maven artifacts are available under [1].

Voting will be open for 72hr.



A minimum of 3 binding +1 votes and more binding +1 than binding -1

are required to pass.



Release tag: 
https://svn.apache.org/viewvc/cocoon/tags/cocoon-2.3/cocoon/cocoon-2.3.0/

Director revision of the tag: 1913422



Per [3] "Before voting +1 PMC members are required to download

the signed source code package, compile it as provided, and test

the resulting executable on their own platform, along with also

verifying that the package meets the requirements of the ASF policy

on releases."



You can achieve the above by following the guide of a fellow Apache project [4].



[ ]  +1 accept (indicate what you validated - e.g. performed the non-RM items 
in [4])

[ ]  -1 reject (explanation required)





[1] https://repository.apache.org/content/repositories/orgapachecocoon-1007

[2] https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/

[3] https://www.apache.org/dev/release.html#approving-a-release

[4] 
https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release

[VOTE] Apache Cocoon 2.3.0 RC2 https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/

[Christofer Dutz]

Apache Cocoon 2.3.0 has been staged under [2] and it’s time to vote
on accepting it for release. All Maven artifacts are available under [1].
Voting will be open for 72hr.

A minimum of 3 binding +1 votes and more binding +1 than binding -1
are required to pass.

Release tag: 
https://svn.apache.org/viewvc/cocoon/tags/cocoon-2.3/cocoon/cocoon-2.3.0/
Director revision of the tag: 1913422

Per [3] "Before voting +1 PMC members are required to download
the signed source code package, compile it as provided, and test
the resulting executable on their own platform, along with also
verifying that the package meets the requirements of the ASF policy
on releases."

You can achieve the above by following the guide of a fellow Apache project [4].

[ ]  +1 accept (indicate what you validated - e.g. performed the non-RM items 
in [4])
[ ]  -1 reject (explanation required)


[1] https://repository.apache.org/content/repositories/orgapachecocoon-1007
[2] https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
[3] https://www.apache.org/dev/release.html#approving-a-release
[4] 
https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release

[CANCELLED] [VOTE] Apache Cocoon 2.3.0 RC1

[Christofer Dutz]

I’m cancelling this RC, as we noticed that it only worked on Mac with Java 11, 
17 and 21 and nothing on Windows and Linux or Java 1.8.
RC2 will support Java 1.8, 11, 17, 21 on Mac, Linux, Windows.

Chris

Von: Christofer Dutz 
Datum: Dienstag, 24. Oktober 2023 um 20:49
An: Cocoon PMC List 
Betreff: [VOTE] Apache Cocoon 2.3.0 RC1
Apache Cocoon 2.3.0 has been staged under [2] and it’s time to vote
on accepting it for release. All Maven artifacts are available under [1].
Voting will be open for 72hr.

A minimum of 3 binding +1 votes and more binding +1 than binding -1
are required to pass.

Release tag: 
https://svn.apache.org/viewvc/cocoon/tags/cocoon-2.3/cocoon/cocoon-2.3.0/
Director revision of the tag: 1913280

Per [3] "Before voting +1 PMC members are required to download
the signed source code package, compile it as provided, and test
the resulting executable on their own platform, along with also
verifying that the package meets the requirements of the ASF policy
on releases."

You can achieve the above by following the guide of a fellow Apache project [4].

[ ]  +1 accept (indicate what you validated - e.g. performed the non-RM items 
in [4])
[ ]  -1 reject (explanation required)


[1] https://repository.apache.org/content/repositories/orgapachecocoon-1006
[2] https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc1/
[3] https://www.apache.org/dev/release.html#approving-a-release
[4] 
https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release

AW: [VOTE] Apache Cocoon 2.3.0 RC1

[Christofer Dutz]

So,

I’ve started building the release with multiple JDK versions.

For every version I ran “mvn clean install -Pallblocks,alldists”:

  *   Java 1.8 didn’t work, as some libraries now baseline with Java 11
  *   Java 11: OK
  *   Java 17: OK
  *   Java 21: OK

Having a look at my JDKs I never found a tools.jar in the lib directory.
However, having a look at the XSP module I found out the dependency is only 
added for non-mac builds (Obviously me building on a Mac isn’t affected).

However, looking at the windows jdk zips of Java 1.8, 11, 17 and 21 it seems 
only Java 1.8 had the tools.jar.
I removed the profile of the tools.jar in XSP module and was successful 
building cocoon with Java 11, 17 and 21 on Mac, Windows, Linux (yeah … I tried 
all of them)

After that I tried making the build work with Java 1.8 and had to find out the 
last version supporting 1.8 for two libraries.
I added a profile “.java-1.8” which auto-enables on Java 1.8 systems.
With these changes we’re also able to build on Java 1.8 on Linux, Mac and 
Windows.

Maybe worth doing an RC2 as as it looks building currently only works on Mac 
11, 17, 21 and nothing else.

Chris


Von: Cédric Damioli 
Datum: Freitag, 27. Oktober 2023 um 11:18
An: dev@cocoon.apache.org 
Betreff: Re: [VOTE] Apache Cocoon 2.3.0 RC1
Hi Christofer,

First of all, many thanks for the huge work you made so far for helping us 
finally rolling out a release.

Which is the target JVM for this release ?
On my Windows laptop, I can't compile with JDK 8, due to external dependencies 
being only JDK11+
And I also can't compile with JDK11+, due to XSP block complaining that it 
can't find tools.jar

Cédric
Le 24/10/2023 à 20:50, Christofer Dutz a écrit :
Apache Cocoon 2.3.0 has been staged under [2] and it’s time to vote
on accepting it for release. All Maven artifacts are available under [1].
Voting will be open for 72hr.

A minimum of 3 binding +1 votes and more binding +1 than binding -1
are required to pass.

Release tag: 
https://svn.apache.org/viewvc/cocoon/tags/cocoon-2.3/cocoon/cocoon-2.3.0/
Director revision of the tag: 1913280

Per [3] "Before voting +1 PMC members are required to download
the signed source code package, compile it as provided, and test
the resulting executable on their own platform, along with also
verifying that the package meets the requirements of the ASF policy
on releases."

You can achieve the above by following the guide of a fellow Apache project [4].

[ ]  +1 accept (indicate what you validated - e.g. performed the non-RM items 
in [4])
[ ]  -1 reject (explanation required)


[1] https://repository.apache.org/content/repositories/orgapachecocoon-1006
[2] https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc1/
[3] https://www.apache.org/dev/release.html#approving-a-release
[4] 
https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release




--

Cédric Damioli

CMS - Java - Open Source

www.ametys.org<http://www.ametys.org>

[VOTE] Apache Cocoon 2.3.0 RC1

[Christofer Dutz]

Apache Cocoon 2.3.0 has been staged under [2] and it’s time to vote
on accepting it for release. All Maven artifacts are available under [1].
Voting will be open for 72hr.

A minimum of 3 binding +1 votes and more binding +1 than binding -1
are required to pass.

Release tag: 
https://svn.apache.org/viewvc/cocoon/tags/cocoon-2.3/cocoon/cocoon-2.3.0/
Director revision of the tag: 1913280

Per [3] "Before voting +1 PMC members are required to download
the signed source code package, compile it as provided, and test
the resulting executable on their own platform, along with also
verifying that the package meets the requirements of the ASF policy
on releases."

You can achieve the above by following the guide of a fellow Apache project [4].

[ ]  +1 accept (indicate what you validated - e.g. performed the non-RM items 
in [4])
[ ]  -1 reject (explanation required)


[1] https://repository.apache.org/content/repositories/orgapachecocoon-1006
[2] https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc1/
[3] https://www.apache.org/dev/release.html#approving-a-release
[4] 
https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release

[DISCUSS][VOTE] Apache Cocoon 2.3.0 RC1

[Christofer Dutz]

Moving this into a separate thread for making following the votes easier.

Let me please explain what happened in the last few months:

The project reported that with the current state of the build, nobody felt able 
to actually perform a release. So, I stepped in and completely rewrote the 
existing maven build with a completely new one. One that more follows best 
practices. With this doing a release was a matter of running two maven commands.

So, this release accumulates the changes of the last 10 years or so … loads of 
dependency updates (I think I tried to update things where CVEs were reported 
and I disabled modules that had no safe versions, as the projects they 
integrate were abandoned)

However, I only stepped up being a RM, as nobody else raised a hand to do so. 
So, with my board hat on, the thing I would be starting after the release, 
would be a public discussion on the project moving to the Attic.

If however we find a number of people willing and actually able to keep the 
lights on, I’d be more than happy to help with that.

After all Apache Cocoon was the first project at Apache that I got in touch 
with something round 20 years ago ;-)

Chris



Von: Gabriel Gruber 
Datum: Mittwoch, 25. Oktober 2023 um 07:23
An: dev@cocoon.apache.org 
Betreff: Re: [VOTE] Apache Cocoon 2.3.0 RC1
Hi,

great we move finally to a new release :-) Thanks Christopher for taking care 
of it. I was wondering if there was a github clone of the repo, where the 
commits can be traced to give some feedback. We also are still cocoon 2.2 users 
and I helped with the spring migration (3->4) some years ago  on trunk. However 
in our own product last year we even moved to spring 5 and so I justed wanted 
to check, if that is an option too.

Thanks a lot for your efforts
Gabriel Gruber

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: insigh...@gmail.com 
Sent: Tuesday, October 24, 2023 10:17:05 PM
To: dev@cocoon.apache.org 
Subject: Re: [VOTE] Apache Cocoon 2.3.0 RC1


Great work everyone on the Cocoon updates. To that end, was wondering if you 
are aware of the updates DSpace.org team/users did to their own Cocoon 2.2 
architecture?

DSpace v6 was the major version using Cocoon 2.2 (they have since moved to 
Angular JS)

Might be worth a look to see if some of that work can be ported into 2.3?

Dan


On 2023-10-24 12:50 p.m., Christofer Dutz wrote:

Apache Cocoon 2.3.0 has been staged under [2] and it’s time to vote

on accepting it for release. All Maven artifacts are available under [1].

Voting will be open for 72hr.



A minimum of 3 binding +1 votes and more binding +1 than binding -1

are required to pass.



Release tag: 
https://svn.apache.org/viewvc/cocoon/tags/cocoon-2.3/cocoon/cocoon-2.3.0/

Director revision of the tag: 1913280



Per [3] "Before voting +1 PMC members are required to download

the signed source code package, compile it as provided, and test

the resulting executable on their own platform, along with also

verifying that the package meets the requirements of the ASF policy

on releases."



You can achieve the above by following the guide of a fellow Apache project [4].



[ ]  +1 accept (indicate what you validated - e.g. performed the non-RM items 
in [4])

[ ]  -1 reject (explanation required)





[1] https://repository.apache.org/content/repositories/orgapachecocoon-1006

[2] https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc1/

[3] https://www.apache.org/dev/release.html#approving-a-release

[4] 
https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release

AW: "Fatal Error: Unable to locate package java.lang in classpath or bootclasspath" when upgrading to Tomcat9

[Christofer Dutz]

I think I remember this being an issue with XSP … it required an SDK and not 
just a Java Runtime as it needs to compile stuff at runtime.

Chris

Von: Modou DIA 
Datum: Mittwoch, 25. Oktober 2023 um 11:35
An: dev@cocoon.apache.org 
Betreff: "Fatal Error: Unable to locate package java.lang in classpath or 
bootclasspath" when upgrading to Tomcat9
Hello Cocoon community,

I am encountering an issue while migrating from Tomcat7 to Tomcat9. I am 
working with Cocoon 2.1.13 and Java11.

During the deployment process I don't have any problems. However when I try to 
access the application, I got a white page  and this StackTrace is generated

org.apache.cocoon.components.language.LanguageException: Error compiling 
userinfos_xsp:
Line 0, column 0:
Fatal Error: Unable to locate package java.lang in classpath or bootclasspath

at 
org.apache.cocoon.components.language.programming.java.JavaLanguage.compile(JavaLanguage.java:227)
at 
org.apache.cocoon.components.language.programming.CompiledProgrammingLanguage.load(CompiledProgrammingLanguage.java:174)
at 
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.loadProgram(ProgramGeneratorImpl.java:410)
at 
org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:290)
at 
org.apache.cocoon.generation.ServerPagesGenerator.setup(ServerPagesGenerator.java:170)
at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:386)
at 
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:717)
at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:511)
at 
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.prepareInternal(AbstractProcessingPipeline.java:525)
at 
org.apache.cocoon.components.source.impl.SitemapSource.init(SitemapSource.java:342)
...


In the class 
org.apache.cocoon.components.language.programming.java.JavaLangugae I have 
checked the method compile and this error suggests a problem with the classpath 
or bootclasspath configuration. I have tried the following steps to address the 
issue without success:

- Checked and verified the Java installation and the "JAVA_HOME" environment 
variable. It is important to note that the installation works well with Tomcat7 
and Java11
- Examined and updated the Cocoon configuration files, such as "cocoon.xconf," 
to ensure proper classpath settings. The parameter compiler is configured to 
work with org.apache.cocoon.components.language.programming.java.Javac

Despite these efforts, the issue persists. I suspect there might be an 
underlying compatibility issue or misconfiguration that I am overlooking.

If anyone has encountered a similar issue or has insights into resolving this 
problem, I would greatly appreciate your guidance and suggestions. 
Additionally, any general tips for configuring Cocoon with Apache Tomcat 9 
would be highly appreciated.

Thank you in advance for your support and assistance.

Best regards,

--
+ 
| Modou Dia,
| AJLSM
| E-mail : m...@ajlsm.com
| Tel : +33 (0)5 57 14 25 24
+ 

Mailing list threading improvements

[Christofer Dutz]

TL;DR: We’re updating how auto-generated email from Github will be
threaded on your mailing lists. If you want to keep the old defaults,
details are below.

We’re pleased to let you know that we’re tweaking the way that auto-
generated email from Github will appear on your mailing lists. This
will lead to more human-readable subject lines, and the ability of most
modern mail clients to correctly thread discussions originating on
Github.

Background: Many project mailing lists receive email auto-generated by
Github. The way that the subject lines are crafted leads to messages
from the same topic not being threaded together by most mail clients.
We’re fixing that.

The way that these messages are threaded is defined by a file -
.asf.yml - in your git repositories. We’re changing the way that it
will work by default if you don’t choose settings. If you’re happy for
us to make this change, don’t do anything - the change will happen on
October the 1st 2023.

Details of the current default, as well as the proposed changes, are on
the following page, along with instructions on how to keep your current
settings, if you prefer:

https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent

Please copy d...@community.apache.org
on any feedback.

Chris, on behalf of the Comdev PMC

Need help?

[Christofer Dutz]

Hi all,

as I mentioned in your last report. I could possibly help with getting cocoon 
into a releaseable shape.

Is there anything in particular, that you need help with?

Chris

AW: Probably first user-question since many years ;-)

[Christofer Dutz]

I really got to play around with these concepts … I know a PLC4X data-source 
will be super easy and not much more than a little coding exercise ;-)

Just got to finish all the little sub-projects I’ve currently got open ;-)


Chris


Von: Cédric Damioli 
Datum: Donnerstag, 14. Dezember 2023 um 10:54
An: dev@cocoon.apache.org 
Betreff: Re: Probably first user-question since many years ;-)
Don't know for 2.3, but in 2.1 there is an abstraction of the request/response 
model, allowing to have eg. CommandLineRequest/CommandLineResponse to achieve 
your needs.
It's actually very useful, I use it frequently to call Cocoon pipelines from 
random threads, not linked to an actual http request. I've developed my own 
BackgroundRequest/BackgroundResponse more suiting my needs, but the concept is 
the same.

Cédric
Le 14/12/2023 à 08:50, Christofer Dutz a écrit :
Hi all,

as we’re thinking of giving 2.3 another try … I’m trying to make the ideas I 
had a bit more concrete …

As some of you might know, I’m working mainly in the Industrial IoT area … here 
we have loads of data in odd data-structures and in general industial IoT 
consists of converting one odd format into another odd format.
Currently most use some super tricky conversion tools …. I would love to try 
setup Cocoon pipelines, that validate and transform this information.

So, my question is: Can Cocoon also be run as a pure xml pipelining framework 
that doesn’t necessarily serve Web-clients?

Chris




--

Cédric Damioli

CMS - Java - Open Source

www.ametys.org<http://www.ametys.org>

Probably first user-question since many years ;-)

[Christofer Dutz]

Hi all,

as we’re thinking of giving 2.3 another try … I’m trying to make the ideas I 
had a bit more concrete …

As some of you might know, I’m working mainly in the Industrial IoT area … here 
we have loads of data in odd data-structures and in general industial IoT 
consists of converting one odd format into another odd format.
Currently most use some super tricky conversion tools …. I would love to try 
setup Cocoon pipelines, that validate and transform this information.

So, my question is: Can Cocoon also be run as a pure xml pipelining framework 
that doesn’t necessarily serve Web-clients?

Chris

AW: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x

[Christofer Dutz]

How about a Mexican style funeral party at Community Over Code? ;-)
Cocoon 2.1 was such a big part of my early IT carreer …

Chris

Von: Cédric Damioli 
Datum: Montag, 18. Dezember 2023 um 19:40
An: dev@cocoon.apache.org 
Betreff: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
The vote is now over and successful with 4 binding +1 and no -1 :

  *   Francesco Chicchiriccò
  *   Peter Hunsberger
  *   Jörg Heinicke
  *   Cédric Damioli
The PMC is now tasked to do what is needed to effectively retire 2.1/3.0.

As discussed before, it's now time for volunteers to step up to do whatever is 
needed to actively maintain a now-refocused Cocoon project (migration to Git, 
dependencies upgrades, ...).

Farewell, good old 2.1 :)

Regards,
Cédric
Le 13/12/2023 à 15:00, Cédric Damioli a écrit :
Hi,

Following and according to last weeks' discussions, it seems that the general 
consensus would be to retire 2.1 (too old to be maintained) and 3.0 (too alpha 
to be maintained), and keep 2.x around for now.

If I try to summarize what have been said, refocusing on a single product would 
give the project a chance to 1) provide a clear upgrade path to existing 2.1 
users and 2) gather renewed interest.
For the still many existing 2.1 users, this would give a clear signal that it's 
time to consider other options.

It's now time to formally vote:

[ ] +1 accept (retire and officially stop the maintenance of 2.1/3.0 branches, 
only keeping 2.x)
[ ] -1 reject (explanation required)

A minimum of 3 binding +1 votes and more binding +1 than binding -1 are 
required to pass.
This vote will be open for at least 72 hours.
Best regards,
Cédric



--

Cédric Damioli

CMS - Java - Open Source

www.ametys.org

AW: [VOTE] Retire 2.1/3.0 and keep 2.x

[Christofer Dutz]

+1 (non-binding)

Chris


Von: Cédric Damioli 
Datum: Mittwoch, 13. Dezember 2023 um 15:00
An: dev@cocoon.apache.org 
Betreff: [VOTE] Retire 2.1/3.0 and keep 2.x
Hi,

Following and according to last weeks' discussions, it seems that the general 
consensus would be to retire 2.1 (too old to be maintained) and 3.0 (too alpha 
to be maintained), and keep 2.x around for now.

If I try to summarize what have been said, refocusing on a single product would 
give the project a chance to 1) provide a clear upgrade path to existing 2.1 
users and 2) gather renewed interest.
For the still many existing 2.1 users, this would give a clear signal that it's 
time to consider other options.

It's now time to formally vote:

[ ] +1 accept (retire and officially stop the maintenance of 2.1/3.0 branches, 
only keeping 2.x)
[ ] -1 reject (explanation required)

A minimum of 3 binding +1 votes and more binding +1 than binding -1 are 
required to pass.
This vote will be open for at least 72 hours.
Best regards,
Cédric

AW: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x

[Christofer Dutz]

So, I guess the deletion of the “retired” branches should probably be done by a 
PMC member.

I’m happy to help with migrating 2.3.x to git as soon as the old stuff is 
buried, if the project wants this to happen.

Chris


Von: Christofer Dutz 
Datum: Montag, 18. Dezember 2023 um 20:25
An: dev@cocoon.apache.org 
Betreff: AW: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
How about a Mexican style funeral party at Community Over Code? ;-)
Cocoon 2.1 was such a big part of my early IT carreer …

Chris

Von: Cédric Damioli 
Datum: Montag, 18. Dezember 2023 um 19:40
An: dev@cocoon.apache.org 
Betreff: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
The vote is now over and successful with 4 binding +1 and no -1 :

  *   Francesco Chicchiriccò
  *   Peter Hunsberger
  *   Jörg Heinicke
  *   Cédric Damioli
The PMC is now tasked to do what is needed to effectively retire 2.1/3.0.

As discussed before, it's now time for volunteers to step up to do whatever is 
needed to actively maintain a now-refocused Cocoon project (migration to Git, 
dependencies upgrades, ...).

Farewell, good old 2.1 :)

Regards,
Cédric
Le 13/12/2023 à 15:00, Cédric Damioli a écrit :
Hi,

Following and according to last weeks' discussions, it seems that the general 
consensus would be to retire 2.1 (too old to be maintained) and 3.0 (too alpha 
to be maintained), and keep 2.x around for now.

If I try to summarize what have been said, refocusing on a single product would 
give the project a chance to 1) provide a clear upgrade path to existing 2.1 
users and 2) gather renewed interest.
For the still many existing 2.1 users, this would give a clear signal that it's 
time to consider other options.

It's now time to formally vote:

[ ] +1 accept (retire and officially stop the maintenance of 2.1/3.0 branches, 
only keeping 2.x)
[ ] -1 reject (explanation required)
A minimum of 3 binding +1 votes and more binding +1 than binding -1 are 
required to pass.
This vote will be open for at least 72 hours.
Best regards,
Cédric


--

Cédric Damioli

CMS - Java - Open Source

www.ametys.org<http://www.ametys.org>

AW: [ANN] Apache Cocoon 2.3.0 Released

[Christofer Dutz]

Anyone sharing this on LinkedIn and X?

Chris


Von: Cédric Damioli 
Datum: Dienstag, 28. November 2023 um 14:17
An: us...@cocoon.apache.org , dev@cocoon.apache.org 
, annou...@apache.org 
Betreff: [ANN] Apache Cocoon 2.3.0 Released
Apache Cocoon 2.3.0 Released
-

   The Apache Cocoon Community is proud to announce the release of
   Cocoon 2.3.0.

   Apache Cocoon is a Spring-based framework (since version 2.2 of
   Cocoon) built around the concepts of separation of concerns and
   component-based development.

   Cocoon implements these concepts around the notion of component
   pipelines, each component on the pipeline specializing on a particular
   operation.

   This release, 11 years after 2.2.0, gathers all changes made since then,
   along with security fixes.

   The minimum Java version was also upgraded to 1.8

Apache Cocoon 2.3.0 may be downloaded from
https://cocoon.apache.org/1284_1_1.html

For more information about Apache Cocoon, please go to
https://cocoon.apache.org

Re: [DISCUSS] Retiring 3.0 ? (Was: Re: Future of the Cocoon project)

[Christofer Dutz]

I'd also vote +1 on retiring 3.0.
There's only little activity overall I'd opt for concentrating it instead of 
fuchsig on too many things in parallel.

Chris

Gesendet von Outlook für Android

From: Francesco Chicchiriccò 
Sent: Friday, December 1, 2023 6:45:42 PM
To: dev@cocoon.apache.org 
Subject: Re: [DISCUSS] Retiring 3.0 ? (Was: Re: Future of the Cocoon project)

On 01/12/23 18:24, Cédric Damioli wrote:
> Le 01/12/2023 à 17:41, Cédric Damioli a écrit :
>> We'd like to know whether you'd prefer:
>> [ ] retiring Cocoon 3.0
>> [ ] reviving/maintaining Cocoon 3.0, meaning that you volunteer to be 
>> somehow involved
>
> I'd vote +1 for retiring Cocoon 3.0, as during the past 10+ years, I had seen 
> no thread, no questions about it.
> I personally have never tried it.

Cocoon 3.0 has been my first "serious" approach to The ASF and also where I 
earned committership and PMC membership.

I am not pleased to admin that, but I think it is time to let it go: while its 
ground ideas were incredibly neat at the time, they never turned into 
mainstream, regrettably.

It has been even used by Syncope until 3.0.0-M0 [1] around Q4 2022.

Regards.

[1] https://github.com/apache/syncope/blob/syncope-3.0.0-M0/pom.xml#L1167-L1176

--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Member at The Apache Software Foundation
Syncope, Cocoon, Olingo, CXF, OpenJPA, PonyMail
http://home.apache.org/~ilgrosso/

Re: [DISCUSS] Retiring 2.1.x ? (Was: Re: Future of the Cocoon project)

[Christofer Dutz]

I'd be +1 to retire 2.1.x

Even if I have fond memories of it, as it was my first major apache project.

However it's grown quite old technically and refreshing things would be a huge 
effort. Some of the jvm versions needed are no longer available and I failed to 
even build it on 1.8.

Don't think it's worth the effort :-(

Chris



Gesendet von Outlook für Android

From: Cédric Damioli 
Sent: Friday, December 1, 2023 7:06:08 PM
To: dev@cocoon.apache.org 
Subject: Re: [DISCUSS] Retiring 2.1.x ? (Was: Re: Future of the Cocoon project)


Le 01/12/2023 à 18:13, Cédric Damioli a écrit :
>
> We'd like to know whether you'd prefer:
> [ ] retiring Cocoon 2.1.x
> [ ] reviving/maintaining Cocoon 2.1.x, meaning that you volunteer to
> be somehow involved
>

I'd vote +/-0 here ...
Definitively the toughest for me ...
I still heavily use Cocoon 2.1 core, but I recognize that it's an very
old piece of software, and that maintaining it here would demand more
and more work.

Perhaps it could be wiser to also let it go, and then fork the core
elsewhere if needed with a new build system, without all block stuff, ...
I'm curious to see what will others say about it.

Cédric

Re: [DISCUSS] Retiring 2.x ? (Was: Re: Future of the Cocoon project)

[Christofer Dutz]

I'd be -1 on retiring 2.x.

I put in the work to fix things, cause I still think there's valid usecases for 
it.

I would be willing to help and try to see, if we can reinitialize a small 
community around it.

Chris

Gesendet von Outlook für Android

From: Cédric Damioli 
Sent: Friday, December 1, 2023 6:42:08 PM
To: dev@cocoon.apache.org 
Subject: Re: [DISCUSS] Retiring 2.x ? (Was: Re: Future of the Cocoon project)



Le 01/12/2023 à 18:00, Cédric Damioli a écrit :
>
> We'd like to know whether you'd prefer:
> [ ] retiring Cocoon 2.x
> [ ] reviving/maintaining Cocoon 2.x, meaning that you volunteer to be
> somehow involved
>
I'd vote +0 for retiring 2.x, holding my thoughts until the result of
this thread.
I personally don't use it nor plan to use it, but with my PMC member hat
on, I see that there's still some interest around here.
The current PMC and committers roster is not sufficient to keep the
project alive, but with new volunteers, why not ...

Cédric

AW: [DISCUSS] Retiring 2.x ? (Was: Re: Future of the Cocoon project)

[Christofer Dutz]

Even if in the end we decide to keep 2.3.x running, we probably should go 
through the module list and retire some of the modules. I know that for some I 
couldn’t update to good versions, as the technology they use was abandoned. So, 
cutting the hair of our modules, might be necessary.

Chris



Von: Gabriel Gruber 
Datum: Samstag, 2. Dezember 2023 um 12:25
An: dev@cocoon.apache.org 
Betreff: Re: [DISCUSS] Retiring 2.x ? (Was: Re: Future of the Cocoon project)
-1 on retiring cocoon 2.3.x. It needs some more love in maintaining but it 
works even with spring 5 and java 11(for us). Would like to see it run with 
spring boot.

Migrating to github and having a fork/PR workflow could bring some Traktion on 
it's own from willing supporters/users.

What could be a valid goal would maybe to repackage cocoon with docker so that 
it can be easily used by 2.1.x users?

Cheers,
Gabriel



Gesendet von Outlook für Android

From: Peter Hunsberger 
Sent: Friday, December 1, 2023 9:45:24 PM
To: dev@cocoon.apache.org 
Subject: Re: [DISCUSS] Retiring 2.x ? (Was: Re: Future of the Cocoon project)



On Fri, Dec 1, 2023 at 11:00 AM Cédric Damioli 
mailto:cdami...@apache.org>> wrote:
Hi,

Second thread to discuss about Cocon 2.x branch, with the latest
release, 2.3.0, just being rolled out.
Cocoon 2.2 was initially meant to implements all stuff developed during
the 2.1 cycle on top of Spring and Maven, to drop old Avalon dependencies.

We'd like to know whether you'd prefer:
[-1 ] retiring Cocoon 2.x

[+0] reviving/maintaining Cocoon 2.x, meaning that you volunteer to be
somehow involved

Please note that the above proposal is not a formal vote, but more like
a open poll, so that everyone could speak out.

Should we continue the project and this branch particularly, there are
recent threads on this list proposing to switch to Git, to upgrade
dependencies, build system, ...

Cédric

Not sure I can really commit to helping much, other than testing releases, I 
don't see having the time to dive into the code anymore but I do still see 
people using this code base.

Peter Hunsberger

Le 30/11/2023 à 19:53, Cédric Damioli a écrit :
> Dear Cocoon users and developers,
>
> Sorry for crossposting here, I wanted to be sure that all involved
> people were aware of the ongoing discussions.
>
> We recently pushed a new release of Cocoon, 11 years after the
> previous one. This release gathers all changes made in between as well
> as two security fixes discovered last year.
> The journey to roll this release out was definitively not an easy one,
> and it's now time to think about what should be next for the project.
>
> We currently officially maintain 3 branches, not compatible with each
> others and having evolved differently over the years : 2.1.x, 2.2/2.3
> and 3.0, and we do not have enough active developers to be able to
> continue to properly and correctly maintain them.
>
> For a project as old as Cocoon (21 years!), there may be many users
> around here still using one branch or another, which could be
> interested to step up, contribute and try to revive the project, or at
> least some parts of it.
>
> I will soon start 3 threads on the developers list to decide what to
> do about each of the 3 branches (retiring or not), so I encourage
> volunteers to bring their voices.
>
> Best regards,
> Cédric, on behalf of the Apache Cocoon PMC
>

--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org

AW: AW: AW: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x

[Christofer Dutz]

Possibly worth discussing if it’s easier to port to Git and do that then … or 
if better done in SVN … I guess the final discussion Git vs. SVN still needs to 
formally be done, right?

Chris

Von: Cédric Damioli 
Datum: Dienstag, 23. Januar 2024 um 17:30
An: dev@cocoon.apache.org 
Betreff: Re: AW: AW: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
+1

Cédric
Le 23/01/2024 à 17:25, Christofer Dutz a écrit :
Yeah … I also think that possibly making them read-only (and additionally 
prefixing them with a “retired/” prefix should be enough.

Chris

Von: Cédric Damioli <mailto:cdami...@apache.org>
Datum: Freitag, 12. Januar 2024 um 20:48
An: dev@cocoon.apache.org<mailto:dev@cocoon.apache.org> 
<mailto:dev@cocoon.apache.org>
Betreff: Re: AW: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
Why should retired branches be deleted ?
Shouldn't they instead be somehow put in read-only state but kept available for 
anyone needing them ?

My 2 cents,
Cédric
Le 09/01/2024 à 14:40, Christofer Dutz a écrit :
So, I guess the deletion of the “retired” branches should probably be done by a 
PMC member.

I’m happy to help with migrating 2.3.x to git as soon as the old stuff is 
buried, if the project wants this to happen.

Chris


Von: Christofer Dutz 
<mailto:christofer.d...@c-ware.de>
Datum: Montag, 18. Dezember 2023 um 20:25
An: dev@cocoon.apache.org<mailto:dev@cocoon.apache.org> 
<mailto:dev@cocoon.apache.org>
Betreff: AW: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
How about a Mexican style funeral party at Community Over Code? ;-)
Cocoon 2.1 was such a big part of my early IT carreer …

Chris

Von: Cédric Damioli <mailto:cdami...@apache.org>
Datum: Montag, 18. Dezember 2023 um 19:40
An: dev@cocoon.apache.org<mailto:dev@cocoon.apache.org> 
<mailto:dev@cocoon.apache.org>
Betreff: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
The vote is now over and successful with 4 binding +1 and no -1 :

  *   Francesco Chicchiriccò
  *   Peter Hunsberger
  *   Jörg Heinicke
  *   Cédric Damioli
The PMC is now tasked to do what is needed to effectively retire 2.1/3.0.

As discussed before, it's now time for volunteers to step up to do whatever is 
needed to actively maintain a now-refocused Cocoon project (migration to Git, 
dependencies upgrades, ...).

Farewell, good old 2.1 :)

Regards,
Cédric
Le 13/12/2023 à 15:00, Cédric Damioli a écrit :
Hi,

Following and according to last weeks' discussions, it seems that the general 
consensus would be to retire 2.1 (too old to be maintained) and 3.0 (too alpha 
to be maintained), and keep 2.x around for now.

If I try to summarize what have been said, refocusing on a single product would 
give the project a chance to 1) provide a clear upgrade path to existing 2.1 
users and 2) gather renewed interest.
For the still many existing 2.1 users, this would give a clear signal that it's 
time to consider other options.

It's now time to formally vote:

[ ] +1 accept (retire and officially stop the maintenance of 2.1/3.0 branches, 
only keeping 2.x)
[ ] -1 reject (explanation required)
A minimum of 3 binding +1 votes and more binding +1 than binding -1 are 
required to pass.
This vote will be open for at least 72 hours.
Best regards,
Cédric

AW: AW: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x

[Christofer Dutz]

Yeah … I also think that possibly making them read-only (and additionally 
prefixing them with a “retired/” prefix should be enough.

Chris

Von: Cédric Damioli 
Datum: Freitag, 12. Januar 2024 um 20:48
An: dev@cocoon.apache.org 
Betreff: Re: AW: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
Why should retired branches be deleted ?
Shouldn't they instead be somehow put in read-only state but kept available for 
anyone needing them ?

My 2 cents,
Cédric
Le 09/01/2024 à 14:40, Christofer Dutz a écrit :
So, I guess the deletion of the “retired” branches should probably be done by a 
PMC member.

I’m happy to help with migrating 2.3.x to git as soon as the old stuff is 
buried, if the project wants this to happen.

Chris


Von: Christofer Dutz 
<mailto:christofer.d...@c-ware.de>
Datum: Montag, 18. Dezember 2023 um 20:25
An: dev@cocoon.apache.org<mailto:dev@cocoon.apache.org> 
<mailto:dev@cocoon.apache.org>
Betreff: AW: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
How about a Mexican style funeral party at Community Over Code? ;-)
Cocoon 2.1 was such a big part of my early IT carreer …

Chris

Von: Cédric Damioli <mailto:cdami...@apache.org>
Datum: Montag, 18. Dezember 2023 um 19:40
An: dev@cocoon.apache.org<mailto:dev@cocoon.apache.org> 
<mailto:dev@cocoon.apache.org>
Betreff: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
The vote is now over and successful with 4 binding +1 and no -1 :

  *   Francesco Chicchiriccò
  *   Peter Hunsberger
  *   Jörg Heinicke
  *   Cédric Damioli
The PMC is now tasked to do what is needed to effectively retire 2.1/3.0.

As discussed before, it's now time for volunteers to step up to do whatever is 
needed to actively maintain a now-refocused Cocoon project (migration to Git, 
dependencies upgrades, ...).

Farewell, good old 2.1 :)

Regards,
Cédric
Le 13/12/2023 à 15:00, Cédric Damioli a écrit :
Hi,

Following and according to last weeks' discussions, it seems that the general 
consensus would be to retire 2.1 (too old to be maintained) and 3.0 (too alpha 
to be maintained), and keep 2.x around for now.

If I try to summarize what have been said, refocusing on a single product would 
give the project a chance to 1) provide a clear upgrade path to existing 2.1 
users and 2) gather renewed interest.
For the still many existing 2.1 users, this would give a clear signal that it's 
time to consider other options.

It's now time to formally vote:

[ ] +1 accept (retire and officially stop the maintenance of 2.1/3.0 branches, 
only keeping 2.x)
[ ] -1 reject (explanation required)
A minimum of 3 binding +1 votes and more binding +1 than binding -1 are 
required to pass.
This vote will be open for at least 72 hours.
Best regards,
Cédric

AW: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x

[Christofer Dutz]

I’d be happy to take care of that.

Chris

Von: Gabriel Gruber 
Datum: Sonntag, 28. Januar 2024 um 16:50
An: dev@cocoon.apache.org 
Betreff: Re: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
Going to github would make things a lot easier. Who could do that?
Gabriel

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: Jörg Heinicke 
Sent: Sunday, January 28, 2024 4:37:25 PM
To: dev@cocoon.apache.org 
Subject: Re: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x

I'd also rather go with porting to Git as next step.

Besides, this seems a necessary prerequisite to revive the community
since it reduces the hurdle to get people involved.

Jörg

On 23.01.24 17:54, Christofer Dutz wrote:
> Possibly worth discussing if it’s easier to port to Git and do that then
> … or if better done in SVN … I guess the final discussion Git vs. SVN
> still needs to formally be done, right?
>
> Chris
>
> *Von: *Cédric Damioli 
> *Datum: *Dienstag, 23. Januar 2024 um 17:30
> *An: *dev@cocoon.apache.org 
> *Betreff: *Re: AW: AW: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
>
> +1
>
> Cédric
>
> Le 23/01/2024 à 17:25, Christofer Dutz a écrit :
>
> Yeah … I also think that possibly making them read-only (and
> additionally prefixing them with a “retired/” prefix should be enough.
>
> Chris

AW: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x

[Christofer Dutz]

Well,

I guess as there were no objections, I’ll go forward with this.


Chris


Von: Christofer Dutz 
Datum: Dienstag, 30. Januar 2024 um 10:41
An: dev@cocoon.apache.org 
Betreff: AW: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
I’d be happy to take care of that.

Chris

Von: Gabriel Gruber 
Datum: Sonntag, 28. Januar 2024 um 16:50
An: dev@cocoon.apache.org 
Betreff: Re: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
Going to github would make things a lot easier. Who could do that?
Gabriel

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: Jörg Heinicke 
Sent: Sunday, January 28, 2024 4:37:25 PM
To: dev@cocoon.apache.org 
Subject: Re: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x

I'd also rather go with porting to Git as next step.

Besides, this seems a necessary prerequisite to revive the community
since it reduces the hurdle to get people involved.

Jörg

On 23.01.24 17:54, Christofer Dutz wrote:
> Possibly worth discussing if it’s easier to port to Git and do that then
> … or if better done in SVN … I guess the final discussion Git vs. SVN
> still needs to formally be done, right?
>
> Chris
>
> *Von: *Cédric Damioli 
> *Datum: *Dienstag, 23. Januar 2024 um 17:30
> *An: *dev@cocoon.apache.org 
> *Betreff: *Re: AW: AW: [RESULT][VOTE] Retire 2.1/3.0 and keep 2.x
>
> +1
>
> Cédric
>
> Le 23/01/2024 à 17:25, Christofer Dutz a écrit :
>
> Yeah … I also think that possibly making them read-only (and
> additionally prefixing them with a “retired/” prefix should be enough.
>
> Chris

Re: [VOTE] Apache Cocoon 2.3.0 RC2 https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/

[Christofer Dutz]

I'll do that as soon as I'm back from my business trip.

Chris

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: David Crossley 
Sent: Wednesday, November 15, 2023 3:57:44 AM
To: dev@cocoon.apache.org 
Cc: Cocoon PMC List 
Subject: Re: [VOTE] Apache Cocoon 2.3.0 RC2 
https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/

Our KEYS file is at https://dist.apache.org/repos/dist/release/cocoon/KEYS

Chris, please add yours to that one, rather than "replacing" it
as is indicated in your temporary KEYS file.

And extensive gratitude to you for taking on this task.

-David

On Sun, Oct 29, 2023 at 09:01:12PM +0000, Christofer Dutz wrote:
> Here’s the KEYS file … there wasn’t any, so I initialized it with my key.
>
> https://dist.apache.org/repos/dist/dev/cocoon/KEYS
>
> Chris
>
> Von: Christofer Dutz 
> Datum: Sonntag, 29. Oktober 2023 um 21:09
> An: dev@cocoon.apache.org 
> Cc: Cocoon PMC List 
> Betreff: Re: [VOTE] Apache Cocoon 2.3.0 RC2 
> https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
> I added my key to the KEYS file in the svn repo one level up..
>
> Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>
> 
> From: Peter Hunsberger 
> Sent: Sunday, October 29, 2023 6:16:02 PM
> To: dev@cocoon.apache.org 
> Cc: Cocoon PMC List 
> Subject: Re: [VOTE] Apache Cocoon 2.3.0 RC2 
> https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
>
> Everything looks good except I can't check the signature, I get "No public 
> key" from gpg.  I believe I need a copy of your public key to import?
>
> Peter Hunsberger
>
>
> On Sun, Oct 29, 2023 at 6:55 AM Christofer Dutz 
> mailto:christofer.d...@c-ware.de>> wrote:
>
> Apache Cocoon 2.3.0 has been staged under [2] and it’s time to vote
>
> on accepting it for release. All Maven artifacts are available under [1].
>
> Voting will be open for 72hr.
>
>
>
> A minimum of 3 binding +1 votes and more binding +1 than binding -1
>
> are required to pass.
>
>
>
> Release tag: 
> https://svn.apache.org/viewvc/cocoon/tags/cocoon-2.3/cocoon/cocoon-2.3.0/
>
> Director revision of the tag: 1913422
>
>
>
> Per [3] "Before voting +1 PMC members are required to download
>
> the signed source code package, compile it as provided, and test
>
> the resulting executable on their own platform, along with also
>
> verifying that the package meets the requirements of the ASF policy
>
> on releases."
>
>
>
> You can achieve the above by following the guide of a fellow Apache project 
> [4].
>
>
>
> [ ]  +1 accept (indicate what you validated - e.g. performed the non-RM items 
> in [4])
>
> [ ]  -1 reject (explanation required)
>
>
>
>
>
> [1] https://repository.apache.org/content/repositories/orgapachecocoon-1007
>
> [2] https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
>
> [3] https://www.apache.org/dev/release.html#approving-a-release
>
> [4] 
> https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release
>
>

AW: [VOTE] Apache Cocoon 2.3.0 RC2 https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/

[Christofer Dutz]

Ok.

So I didn’t wait for the business trip to end and gave it another try.
I Added my key to the end of the existing KEYS file, and whenever I wanted to 
commit it, I get “permission denied”.

Someone pointed out here, that this is usually because of an “http” instead of 
a “https” url, but I checked that and this was not the case:


cdutz@MacBook-Pro-von-Christofer cocoon % svn info --show-item repos-root-url

https://dist.apache.org/repos/dist

I also tried providing my apache user-id and password, but I still get this 
reply:


svn: E195023: Ändern der Datei »/Users/cdutz/Temp/cocoon/cocoon/KEYS« durch den 
Server zurückgewiesen

svn: E175013: Zugriff auf »/repos/dist/!svn/txr/65331-1j1c/release/cocoon/KEYS« 
verboten

So … I’d love to add my key, but seems I’m not allowed … so If any of you would 
be so kind and do that for me, I’d love to finalize the RC process (However I 
expect someone else to also have to move the RC to the distribution area, 
because I would expect to also not be allowed to move the files in SVN.

Chris



Von: Christofer Dutz 
Datum: Mittwoch, 15. November 2023 um 21:40
An: Cocoon PMC List , dev@cocoon.apache.org 

Cc: Cocoon PMC List 
Betreff: Re: [VOTE] Apache Cocoon 2.3.0 RC2 
https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
I'll do that as soon as I'm back from my business trip.

Chris

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: David Crossley 
Sent: Wednesday, November 15, 2023 3:57:44 AM
To: dev@cocoon.apache.org 
Cc: Cocoon PMC List 
Subject: Re: [VOTE] Apache Cocoon 2.3.0 RC2 
https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/

Our KEYS file is at https://dist.apache.org/repos/dist/release/cocoon/KEYS

Chris, please add yours to that one, rather than "replacing" it
as is indicated in your temporary KEYS file.

And extensive gratitude to you for taking on this task.

-David

On Sun, Oct 29, 2023 at 09:01:12PM +0000, Christofer Dutz wrote:
> Here’s the KEYS file … there wasn’t any, so I initialized it with my key.
>
> https://dist.apache.org/repos/dist/dev/cocoon/KEYS
>
> Chris
>
> Von: Christofer Dutz 
> Datum: Sonntag, 29. Oktober 2023 um 21:09
> An: dev@cocoon.apache.org 
> Cc: Cocoon PMC List 
> Betreff: Re: [VOTE] Apache Cocoon 2.3.0 RC2 
> https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
> I added my key to the KEYS file in the svn repo one level up..
>
> Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>
> 
> From: Peter Hunsberger 
> Sent: Sunday, October 29, 2023 6:16:02 PM
> To: dev@cocoon.apache.org 
> Cc: Cocoon PMC List 
> Subject: Re: [VOTE] Apache Cocoon 2.3.0 RC2 
> https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
>
> Everything looks good except I can't check the signature, I get "No public 
> key" from gpg.  I believe I need a copy of your public key to import?
>
> Peter Hunsberger
>
>
> On Sun, Oct 29, 2023 at 6:55 AM Christofer Dutz 
> mailto:christofer.d...@c-ware.de>> wrote:
>
> Apache Cocoon 2.3.0 has been staged under [2] and it’s time to vote
>
> on accepting it for release. All Maven artifacts are available under [1].
>
> Voting will be open for 72hr.
>
>
>
> A minimum of 3 binding +1 votes and more binding +1 than binding -1
>
> are required to pass.
>
>
>
> Release tag: 
> https://svn.apache.org/viewvc/cocoon/tags/cocoon-2.3/cocoon/cocoon-2.3.0/
>
> Director revision of the tag: 1913422
>
>
>
> Per [3] "Before voting +1 PMC members are required to download
>
> the signed source code package, compile it as provided, and test
>
> the resulting executable on their own platform, along with also
>
> verifying that the package meets the requirements of the ASF policy
>
> on releases."
>
>
>
> You can achieve the above by following the guide of a fellow Apache project 
> [4].
>
>
>
> [ ]  +1 accept (indicate what you validated - e.g. performed the non-RM items 
> in [4])
>
> [ ]  -1 reject (explanation required)
>
>
>
>
>
> [1] https://repository.apache.org/content/repositories/orgapachecocoon-1007
>
> [2] https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
>
> [3] https://www.apache.org/dev/release.html#approving-a-release
>
> [4] 
> https://cwiki.apache.org/confluence/display/PLC4X/Validating+a+staged+Release
>
>

[RESULT] [VOTE] Apache Cocoon 2.3.0 RC2 https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/

[Christofer Dutz]

Ok,

So, I will now announce the vote as over and as successful, as we have 3 
binding +1 votes.


  *   Francesco Chicchiriccò
  *   Cédric Damioli
  *   David Crossley

As it seems that nobody here is able/willing to help with getting my key into 
the dist KEYS file and I can’t move the release from dev to dist … I will work 
with infra on doing this and potentially using some board-overrides. Which is 
super unfortunate that I have to use this tool in order to get the release out, 
as this implies an inability of the current PMC to actually perform releases, 
which is number 1 cause for going to the attic.

Chris


Von: Christofer Dutz 
Datum: Donnerstag, 16. November 2023 um 10:03
An: Cocoon PMC List , dev@cocoon.apache.org 

Cc: Cocoon PMC List 
Betreff: AW: [VOTE] Apache Cocoon 2.3.0 RC2 
https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
Ok.

So I didn’t wait for the business trip to end and gave it another try.
I Added my key to the end of the existing KEYS file, and whenever I wanted to 
commit it, I get “permission denied”.

Someone pointed out here, that this is usually because of an “http” instead of 
a “https” url, but I checked that and this was not the case:


cdutz@MacBook-Pro-von-Christofer cocoon % svn info --show-item repos-root-url

https://dist.apache.org/repos/dist

I also tried providing my apache user-id and password, but I still get this 
reply:



svn: E195023: Ändern der Datei »/Users/cdutz/Temp/cocoon/cocoon/KEYS« durch den 
Server zurückgewiesen

svn: E175013: Zugriff auf »/repos/dist/!svn/txr/65331-1j1c/release/cocoon/KEYS« 
verboten

So … I’d love to add my key, but seems I’m not allowed … so If any of you would 
be so kind and do that for me, I’d love to finalize the RC process (However I 
expect someone else to also have to move the RC to the distribution area, 
because I would expect to also not be allowed to move the files in SVN.

Chris



Von: Christofer Dutz 
Datum: Mittwoch, 15. November 2023 um 21:40
An: Cocoon PMC List , dev@cocoon.apache.org 

Cc: Cocoon PMC List 
Betreff: Re: [VOTE] Apache Cocoon 2.3.0 RC2 
https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
I'll do that as soon as I'm back from my business trip.

Chris

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: David Crossley 
Sent: Wednesday, November 15, 2023 3:57:44 AM
To: dev@cocoon.apache.org 
Cc: Cocoon PMC List 
Subject: Re: [VOTE] Apache Cocoon 2.3.0 RC2 
https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/

Our KEYS file is at https://dist.apache.org/repos/dist/release/cocoon/KEYS

Chris, please add yours to that one, rather than "replacing" it
as is indicated in your temporary KEYS file.

And extensive gratitude to you for taking on this task.

-David

On Sun, Oct 29, 2023 at 09:01:12PM +0000, Christofer Dutz wrote:
> Here’s the KEYS file … there wasn’t any, so I initialized it with my key.
>
> https://dist.apache.org/repos/dist/dev/cocoon/KEYS
>
> Chris
>
> Von: Christofer Dutz 
> Datum: Sonntag, 29. Oktober 2023 um 21:09
> An: dev@cocoon.apache.org 
> Cc: Cocoon PMC List 
> Betreff: Re: [VOTE] Apache Cocoon 2.3.0 RC2 
> https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
> I added my key to the KEYS file in the svn repo one level up..
>
> Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>
> 
> From: Peter Hunsberger 
> Sent: Sunday, October 29, 2023 6:16:02 PM
> To: dev@cocoon.apache.org 
> Cc: Cocoon PMC List 
> Subject: Re: [VOTE] Apache Cocoon 2.3.0 RC2 
> https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
>
> Everything looks good except I can't check the signature, I get "No public 
> key" from gpg.  I believe I need a copy of your public key to import?
>
> Peter Hunsberger
>
>
> On Sun, Oct 29, 2023 at 6:55 AM Christofer Dutz 
> mailto:christofer.d...@c-ware.de>> wrote:
>
> Apache Cocoon 2.3.0 has been staged under [2] and it’s time to vote
>
> on accepting it for release. All Maven artifacts are available under [1].
>
> Voting will be open for 72hr.
>
>
>
> A minimum of 3 binding +1 votes and more binding +1 than binding -1
>
> are required to pass.
>
>
>
> Release tag: 
> https://svn.apache.org/viewvc/cocoon/tags/cocoon-2.3/cocoon/cocoon-2.3.0/
>
> Director revision of the tag: 1913422
>
>
>
> Per [3] "Before voting +1 PMC members are required to download
>
> the signed source code package, compile it as provided, and test
>
> the resulting executable on their own platform, along with also
>
> verifying that the package meets the requirements of the ASF policy
>
> on releases."
>
>
>
> You can achieve the above by following the guide of a fellow Apache project 
> [4].
>
>
>
> [ ]  +1 accept (indicate what you va

AW: [RESULT] [VOTE] Apache Cocoon 2.3.0 RC2 https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/

[Christofer Dutz]

Ok,

So, copying stuff from dev to release can only be done by PMC members, so I 
guess I’m out of the game and one of you folks needs to do it.

I’d say if this is not done by the end of the coming week, I’ll probably go a 
different route and have someone appointed PMC membership by the board to 
finish this release.

Chris

Von: Christofer Dutz 
Datum: Sonntag, 19. November 2023 um 11:11
An: Cocoon PMC List , dev@cocoon.apache.org 

Cc: Cocoon PMC List 
Betreff: [RESULT] [VOTE] Apache Cocoon 2.3.0 RC2 
https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
Ok,

So, I will now announce the vote as over and as successful, as we have 3 
binding +1 votes.


  *   Francesco Chicchiriccò
  *   Cédric Damioli
  *   David Crossley

As it seems that nobody here is able/willing to help with getting my key into 
the dist KEYS file and I can’t move the release from dev to dist … I will work 
with infra on doing this and potentially using some board-overrides. Which is 
super unfortunate that I have to use this tool in order to get the release out, 
as this implies an inability of the current PMC to actually perform releases, 
which is number 1 cause for going to the attic.

Chris


Von: Christofer Dutz 
Datum: Donnerstag, 16. November 2023 um 10:03
An: Cocoon PMC List , dev@cocoon.apache.org 

Cc: Cocoon PMC List 
Betreff: AW: [VOTE] Apache Cocoon 2.3.0 RC2 
https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
Ok.

So I didn’t wait for the business trip to end and gave it another try.
I Added my key to the end of the existing KEYS file, and whenever I wanted to 
commit it, I get “permission denied”.

Someone pointed out here, that this is usually because of an “http” instead of 
a “https” url, but I checked that and this was not the case:


cdutz@MacBook-Pro-von-Christofer cocoon % svn info --show-item repos-root-url

https://dist.apache.org/repos/dist

I also tried providing my apache user-id and password, but I still get this 
reply:




svn: E195023: Ändern der Datei »/Users/cdutz/Temp/cocoon/cocoon/KEYS« durch den 
Server zurückgewiesen

svn: E175013: Zugriff auf »/repos/dist/!svn/txr/65331-1j1c/release/cocoon/KEYS« 
verboten

So … I’d love to add my key, but seems I’m not allowed … so If any of you would 
be so kind and do that for me, I’d love to finalize the RC process (However I 
expect someone else to also have to move the RC to the distribution area, 
because I would expect to also not be allowed to move the files in SVN.

Chris



Von: Christofer Dutz 
Datum: Mittwoch, 15. November 2023 um 21:40
An: Cocoon PMC List , dev@cocoon.apache.org 

Cc: Cocoon PMC List 
Betreff: Re: [VOTE] Apache Cocoon 2.3.0 RC2 
https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
I'll do that as soon as I'm back from my business trip.

Chris

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: David Crossley 
Sent: Wednesday, November 15, 2023 3:57:44 AM
To: dev@cocoon.apache.org 
Cc: Cocoon PMC List 
Subject: Re: [VOTE] Apache Cocoon 2.3.0 RC2 
https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/

Our KEYS file is at https://dist.apache.org/repos/dist/release/cocoon/KEYS

Chris, please add yours to that one, rather than "replacing" it
as is indicated in your temporary KEYS file.

And extensive gratitude to you for taking on this task.

-David

On Sun, Oct 29, 2023 at 09:01:12PM +0000, Christofer Dutz wrote:
> Here’s the KEYS file … there wasn’t any, so I initialized it with my key.
>
> https://dist.apache.org/repos/dist/dev/cocoon/KEYS
>
> Chris
>
> Von: Christofer Dutz 
> Datum: Sonntag, 29. Oktober 2023 um 21:09
> An: dev@cocoon.apache.org 
> Cc: Cocoon PMC List 
> Betreff: Re: [VOTE] Apache Cocoon 2.3.0 RC2 
> https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
> I added my key to the KEYS file in the svn repo one level up..
>
> Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>
> 
> From: Peter Hunsberger 
> Sent: Sunday, October 29, 2023 6:16:02 PM
> To: dev@cocoon.apache.org 
> Cc: Cocoon PMC List 
> Subject: Re: [VOTE] Apache Cocoon 2.3.0 RC2 
> https://dist.apache.org/repos/dist/dev/cocoon/2.3.0/rc2/
>
> Everything looks good except I can't check the signature, I get "No public 
> key" from gpg.  I believe I need a copy of your public key to import?
>
> Peter Hunsberger
>
>
> On Sun, Oct 29, 2023 at 6:55 AM Christofer Dutz 
> mailto:christofer.d...@c-ware.de>> wrote:
>
> Apache Cocoon 2.3.0 has been staged under [2] and it’s time to vote
>
> on accepting it for release. All Maven artifacts are available under [1].
>
> Voting will be open for 72hr.
>
>
>
> A minimum of 3 binding +1 votes and more binding +1 than binding -1
>
> are required to pass.
>
>
>
> Release tag: 
> https://svn.apache.org/viewvc/cocoon/tags/cocoon-2.3/cocoon/coc

Now that the release is out, what's next?

[Christofer Dutz]

Hi folks,

So, it seems that we finally have finished the last missing steps to formally 
get the release out the door. Now I think comes a time where we should reflect 
and discuss, what should happen with the Project.

So instead of simply saying: Releasing it was such a struggle (not technically, 
but from a participation side) I wouldn’t say this project is healthy and we 
should discuss a move into the Attic.

However, I could also imagine that the changes I implemented in the build might 
encourage some folks to give it another go.

I know when I was doing projects with Cocoon as part of my day-job 20 years 
ago, Cocoon 2.2 sort of completely broke my flow. Not only my inexperience with 
Maven, but also that of Spring and the versioning scheme where all sorts of 
cocoon modules had different versions just made me give up at that time and 
switch to Adobe Flex ;-)

Now (15 years later) Maven and Spring have evolved and with the cleanups in the 
build, it should be a lot simpler to work with Cocoon and with all modules 
sharing the same version, also this should be a lot simpler.

So, I would like to ask you folks:

  *   Should we aim directly for the Attic?
  *   Does anyone want to revive the project? (I’m intentionally not only 
addressing committers and PMC members, but also people wanting to keep the 
project alive)


Chris

AW: Now that the release is out, what's next?

[Christofer Dutz]

Hi Gabriel,

I was more referring to the first response and I have seen loads of similar 
responses when initiating Attic discussions in the past with other projects. I 
just wanted to make it clear, that a projects livelihood is defined by the 
people giving and not the people wanting ;-)

Becoming a contributor is easy. Perhaps it would make sense for us to formally 
switch to Git, because then it would be a lot simpler:

  *   Create a fork
  *   Do your changes in that fork
  *   Create a PR
  *   Have someone merge these changes
  *   Hopefully get voted in as committer soon
Perhaps switching to Git would be a good first step.

Chris


Von: Gabriel Gruber 
Datum: Montag, 20. November 2023 um 10:26
An: dev@cocoon.apache.org 
Betreff: Re: Now that the release is out, what's next?
Hello Christopher,
just to make it clear. I AM willing to participate and contribute. I was the 
pushing force on the Spring 4 dependency upgrade. And meanwhile our cocoon 2 
instance runs on spring 5 and java 11 – so I have some stuff, which I would 
love to get into the OS project again.
As I said I would like to contribute further to make cocoon 2 compatible with 
state-of-the-art dependencies like java 21 and spring 6.
However I need some help to become a formal contributor. Maybee you could help 
me in that?
Thank you
Gabriel


From: Christofer Dutz 
Date: Monday, 20. November 2023 at 10:08
To: dev@cocoon.apache.org 
Subject: AW: Now that the release is out, what's next?
Hi all,

let me mention one thing here … Open-Source is not a need-driven thing, that 
anyone is entitled to exist to solve one owns needs. It’s an initiative-driven 
thing that anyone can participate.

So, if you need some open-source solution, you should consider actively 
contributing. Because if nobody contributes, then the open-source project will 
die and move into the attic.

An alternative for this is that people and companies can pay someone else to 
participate in their place.

But in the end, if nobody works on it, it’s going to go into the attic.

I hope with my general overhaul of the build and project structure, I have made 
contributing and releasing a lot simpler, but I’m not planning on keeping the 
lights on, if I’m the only one working.

Chris



Von: Gabriel Gruber 
Datum: Sonntag, 19. November 2023 um 19:55
An: dev@cocoon.apache.org 
Betreff: Re: Now that the release is out, what's next?
Hi cocoon team,

as we are still using cocoon 2.2 in PROD as base for our product, we have a 
high interest that the open source project stays alive.  Our main motivation 
here would be framework and java compatibility as well as security patches.

Of course I am also willing to actively support and maintain. A great 
improvement would be, if the source-code could move to github.

Thanks Chris for your enormous efforts to get this release through! Thanks to 
all the committers for building such a great and long lasting project.

Gabriel

From: insigh...@gmail.com 
Date: Sunday, 19. November 2023 at 19:36
To: dev@cocoon.apache.org 
Subject: Re: Now that the release is out, what's next?

I mentioned this early, the DSpace Content Management project used Cocoon 2.2 
until version 6.4 (v7 moved to Angular JS). They integrated with Solr and did a 
bunch of other things that may be worth a look.

The Cocoon interface was called xmlui (look for the subfolder), and available 
via Github:

https://github.com/DSpace/DSpace/releases

Source Code: 
https://github.com/DSpace/DSpace/archive/refs/tags/dspace-6.4.tar.gz

Great work on continuing the Cocoon legacy!

Dan


On 2023-11-19 10:20 a.m., Christofer Dutz wrote:
Hi folks,

So, it seems that we finally have finished the last missing steps to formally 
get the release out the door. Now I think comes a time where we should reflect 
and discuss, what should happen with the Project.

So instead of simply saying: Releasing it was such a struggle (not technically, 
but from a participation side) I wouldn’t say this project is healthy and we 
should discuss a move into the Attic.

However, I could also imagine that the changes I implemented in the build might 
encourage some folks to give it another go.

I know when I was doing projects with Cocoon as part of my day-job 20 years 
ago, Cocoon 2.2 sort of completely broke my flow. Not only my inexperience with 
Maven, but also that of Spring and the versioning scheme where all sorts of 
cocoon modules had different versions just made me give up at that time and 
switch to Adobe Flex ;-)

Now (15 years later) Maven and Spring have evolved and with the cleanups in the 
build, it should be a lot simpler to work with Cocoon and with all modules 
sharing the same version, also this should be a lot simpler.

So, I would like to ask you folks:

  *   Should we aim directly for the Attic?
  *   Does anyone want to revive the project? (I’m intentionally not only 
addressing committers and PMC members, but also people wanting to keep the 
project alive)


Chris

AW: Now that the release is out, what's next?

[Christofer Dutz]

Hi all,

let me mention one thing here … Open-Source is not a need-driven thing, that 
anyone is entitled to exist to solve one owns needs. It’s an initiative-driven 
thing that anyone can participate.

So, if you need some open-source solution, you should consider actively 
contributing. Because if nobody contributes, then the open-source project will 
die and move into the attic.

An alternative for this is that people and companies can pay someone else to 
participate in their place.

But in the end, if nobody works on it, it’s going to go into the attic.

I hope with my general overhaul of the build and project structure, I have made 
contributing and releasing a lot simpler, but I’m not planning on keeping the 
lights on, if I’m the only one working.

Chris



Von: Gabriel Gruber 
Datum: Sonntag, 19. November 2023 um 19:55
An: dev@cocoon.apache.org 
Betreff: Re: Now that the release is out, what's next?
Hi cocoon team,

as we are still using cocoon 2.2 in PROD as base for our product, we have a 
high interest that the open source project stays alive.  Our main motivation 
here would be framework and java compatibility as well as security patches.

Of course I am also willing to actively support and maintain. A great 
improvement would be, if the source-code could move to github.

Thanks Chris for your enormous efforts to get this release through! Thanks to 
all the committers for building such a great and long lasting project.

Gabriel

From: insigh...@gmail.com 
Date: Sunday, 19. November 2023 at 19:36
To: dev@cocoon.apache.org 
Subject: Re: Now that the release is out, what's next?

I mentioned this early, the DSpace Content Management project used Cocoon 2.2 
until version 6.4 (v7 moved to Angular JS). They integrated with Solr and did a 
bunch of other things that may be worth a look.

The Cocoon interface was called xmlui (look for the subfolder), and available 
via Github:

https://github.com/DSpace/DSpace/releases

Source Code: 
https://github.com/DSpace/DSpace/archive/refs/tags/dspace-6.4.tar.gz

Great work on continuing the Cocoon legacy!

Dan


On 2023-11-19 10:20 a.m., Christofer Dutz wrote:
Hi folks,

So, it seems that we finally have finished the last missing steps to formally 
get the release out the door. Now I think comes a time where we should reflect 
and discuss, what should happen with the Project.

So instead of simply saying: Releasing it was such a struggle (not technically, 
but from a participation side) I wouldn’t say this project is healthy and we 
should discuss a move into the Attic.

However, I could also imagine that the changes I implemented in the build might 
encourage some folks to give it another go.

I know when I was doing projects with Cocoon as part of my day-job 20 years 
ago, Cocoon 2.2 sort of completely broke my flow. Not only my inexperience with 
Maven, but also that of Spring and the versioning scheme where all sorts of 
cocoon modules had different versions just made me give up at that time and 
switch to Adobe Flex ;-)

Now (15 years later) Maven and Spring have evolved and with the cleanups in the 
build, it should be a lot simpler to work with Cocoon and with all modules 
sharing the same version, also this should be a lot simpler.

So, I would like to ask you folks:

  *   Should we aim directly for the Attic?
  *   Does anyone want to revive the project? (I’m intentionally not only 
addressing committers and PMC members, but also people wanting to keep the 
project alive)


Chris

[DISCUSS] Switching to GIt?

[Christofer Dutz]

Hi all,

I know that we currently have a mirror of the SVN in Github, however still the 
root repository is SVN, I would like to propose switching to using Git as the 
main repo.

This would allow us to start using the normal GitHub Pull-Request workflow and 
possibly make it a lot easier for new contributors to contribute.

Also, would I propose to start using GitHub Actions, GitHub Issues and GitHub 
discussions as in other projects this has proven to lower the barriers for new 
contributors (And it avoids the Jira account approving nightmare). With the 
changes in the messaging defaults, that I recently deployed, mirroring GitHub 
activity to the dev-list should allow everyone to participate.

What do the others think?

Chris

Re: Now that the release is out, what's next?

[Christofer Dutz]

Well guess I haven't stated it yet: I would be willing to work on it (I've 
especially for some ideas on streaming industrial data from plc4x).

Personally I would let the pre-2.2 branch rest in peace. All is dependencies 
are so extremely old and the jdks for some are no longer available. At least I 
probably wouldn't touch it and focus on the "middle"... Possibly have a look at 
3.0 (haven't done that yet).

Chris

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: Cédric Damioli 
Sent: Monday, November 20, 2023 3:47:14 PM
To: dev@cocoon.apache.org 
Subject: Re: Now that the release is out, what's next?

Hi,

On top of that, as a community, we now have to formally answer to the below 
question (going or not to the Attic) not only once, but three times, one time 
for each subproject we still officially maintain since more than 10 years :
 - Cocoon 2.1.x (pre-Spring, pre-Maven). Last release 2.1.13 was rolled out 3 
years ago.
 - Cocoon 2.2x (now 2.3.x). Last release these days.
 - Cocoon 3.0.x. Last release 3.0.0-alpha-3 back in 2011

Those 3 versions are not compatible with each other, are not meant as drop-in 
replacements, and have evolved differently over the years.

The community could either decide to stop the project as-is and go to the 
Attic, or start over maintaining only one or two branches.

Cédric

Le 19/11/2023 à 18:20, Christofer Dutz a écrit :

Hi folks,



So, it seems that we finally have finished the last missing steps to formally 
get the release out the door. Now I think comes a time where we should reflect 
and discuss, what should happen with the Project.



So instead of simply saying: Releasing it was such a struggle (not technically, 
but from a participation side) I wouldn’t say this project is healthy and we 
should discuss a move into the Attic.



However, I could also imagine that the changes I implemented in the build might 
encourage some folks to give it another go.



I know when I was doing projects with Cocoon as part of my day-job 20 years 
ago, Cocoon 2.2 sort of completely broke my flow. Not only my inexperience with 
Maven, but also that of Spring and the versioning scheme where all sorts of 
cocoon modules had different versions just made me give up at that time and 
switch to Adobe Flex ;-)



Now (15 years later) Maven and Spring have evolved and with the cleanups in the 
build, it should be a lot simpler to work with Cocoon and with all modules 
sharing the same version, also this should be a lot simpler.



So, I would like to ask you folks:

  *   Should we aim directly for the Attic?
  *   Does anyone want to revive the project? (I’m intentionally not only 
addressing committers and PMC members, but also people wanting to keep the 
project alive)





Chris


--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org<http://www.ametys.org>

Re: Now that the release is out, what's next?

[Christofer Dutz]

Well for me, the one thing at has changed since then, is that I've become a 
maven wizard  and a certified spring professional myself. Maven is my primary 
build tool and spring my primary component framework. Cocoon was just a read 
ahead of its time then.

Now I wouldn't want to touch an Ant build anymore and am happy we left the 
jakarta/avalon times behind us ;-)

Chris

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: insigh...@gmail.com 
Sent: Tuesday, November 21, 2023 10:26:05 PM
To: dev@cocoon.apache.org 
Subject: Re: Now that the release is out, what's next?

Like Chris, I never could adapt to the build and Spring changes in Cocoon 2.2, 
and continued (until a few years ago) to develop projects from Cocoon 2.1 
(v2.1.13). I love and am still passionate about the original 2.1 framework, 
having used it since 2002. In fact, I would still be using it if not for 
security, and other, challenges with the old code.

The thing that drew me to Cocoon in the first place was the terrific pipeline 
transformer architecture: it really fit the text transforming ability of XSLT. 
It is something I greatly miss in Python.

I like the idea of using GitHub (https://github.com/apache/cocoon), as it may 
expose more people to the project. In this regard, explaining what Cocoon does, 
benefits of using it etc., might attract some passers by.

Thank you to all of you, who have, over the years, contributed and participated 
in this beautiful piece of software.

Dan

===


On 2023-11-21 6:46 a.m., Peter Hunsberger wrote:

On Tue, Nov 21, 2023 at 12:15 AM Christofer Dutz 
mailto:christofer.d...@c-ware.de>> wrote:
Well guess I haven't stated it yet: I would be willing to work on it (I've 
especially for some ideas on streaming industrial data from plc4x).

Personally I would let the pre-2.2 branch rest in peace. All is dependencies 
are so extremely old and the jdks for some are no longer available. At least I 
probably wouldn't touch it and focus on the "middle"...
 +1 !

Possibly have a look at 3.0 (haven't done that yet).

I tried using 3.0 for a project.  Some good ideas and simple enough 
implementation but I don't think there is enough there for it to be worth 
saving

Chris

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: Cédric Damioli mailto:cdami...@apache.org>>
Sent: Monday, November 20, 2023 3:47:14 PM
To: dev@cocoon.apache.org<mailto:dev@cocoon.apache.org> 
mailto:dev@cocoon.apache.org>>
Subject: Re: Now that the release is out, what's next?

Hi,

On top of that, as a community, we now have to formally answer to the below 
question (going or not to the Attic) not only once, but three times, one time 
for each subproject we still officially maintain since more than 10 years :
 - Cocoon 2.1.x (pre-Spring, pre-Maven). Last release 2.1.13 was rolled out 3 
years ago.
 - Cocoon 2.2x (now 2.3.x). Last release these days.
 - Cocoon 3.0.x. Last release 3.0.0-alpha-3 back in 2011

Those 3 versions are not compatible with each other, are not meant as drop-in 
replacements, and have evolved differently over the years.

The community could either decide to stop the project as-is and go to the 
Attic, or start over maintaining only one or two branches.

Cédric

Le 19/11/2023 à 18:20, Christofer Dutz a écrit :

Hi folks,



So, it seems that we finally have finished the last missing steps to formally 
get the release out the door. Now I think comes a time where we should reflect 
and discuss, what should happen with the Project.



So instead of simply saying: Releasing it was such a struggle (not technically, 
but from a participation side) I wouldn’t say this project is healthy and we 
should discuss a move into the Attic.



However, I could also imagine that the changes I implemented in the build might 
encourage some folks to give it another go.



I know when I was doing projects with Cocoon as part of my day-job 20 years 
ago, Cocoon 2.2 sort of completely broke my flow. Not only my inexperience with 
Maven, but also that of Spring and the versioning scheme where all sorts of 
cocoon modules had different versions just made me give up at that time and 
switch to Adobe Flex ;-)



Now (15 years later) Maven and Spring have evolved and with the cleanups in the 
build, it should be a lot simpler to work with Cocoon and with all modules 
sharing the same version, also this should be a lot simpler.



So, I would like to ask you folks:

  *   Should we aim directly for the Attic?
  *   Does anyone want to revive the project? (I’m intentionally not only 
addressing committers and PMC members, but also people wanting to keep the 
project alive)





Chris


--
Cédric Damioli
CMS - Java - Open Source
www.ametys.org<http://www.ametys.org>

Re: Now that the release is out, what's next?

[Christofer Dutz]

I agree... 2.3.x seems to be the best option to keep.

Chris

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: Gabriel Gruber 
Sent: Wednesday, November 22, 2023 12:32:12 AM
To: dev@cocoon.apache.org 
Subject: Re: Now that the release is out, what's next?

Maybe a docker version could be attractive for non java users, who just want to 
work with xslt Pipelines and web resources?

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>
____
From: Christofer Dutz 
Sent: Tuesday, November 21, 2023 10:55:50 PM
To: dev@cocoon.apache.org 
Subject: Re: Now that the release is out, what's next?

Well for me, the one thing at has changed since then, is that I've become a 
maven wizard  and a certified spring professional myself. Maven is my primary 
build tool and spring my primary component framework. Cocoon was just a read 
ahead of its time then.

Now I wouldn't want to touch an Ant build anymore and am happy we left the 
jakarta/avalon times behind us ;-)

Chris

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: insigh...@gmail.com 
Sent: Tuesday, November 21, 2023 10:26:05 PM
To: dev@cocoon.apache.org 
Subject: Re: Now that the release is out, what's next?

Like Chris, I never could adapt to the build and Spring changes in Cocoon 2.2, 
and continued (until a few years ago) to develop projects from Cocoon 2.1 
(v2.1.13). I love and am still passionate about the original 2.1 framework, 
having used it since 2002. In fact, I would still be using it if not for 
security, and other, challenges with the old code.

The thing that drew me to Cocoon in the first place was the terrific pipeline 
transformer architecture: it really fit the text transforming ability of XSLT. 
It is something I greatly miss in Python.

I like the idea of using GitHub (https://github.com/apache/cocoon), as it may 
expose more people to the project. In this regard, explaining what Cocoon does, 
benefits of using it etc., might attract some passers by.

Thank you to all of you, who have, over the years, contributed and participated 
in this beautiful piece of software.

Dan

===


On 2023-11-21 6:46 a.m., Peter Hunsberger wrote:

On Tue, Nov 21, 2023 at 12:15 AM Christofer Dutz 
mailto:christofer.d...@c-ware.de>> wrote:
Well guess I haven't stated it yet: I would be willing to work on it (I've 
especially for some ideas on streaming industrial data from plc4x).

Personally I would let the pre-2.2 branch rest in peace. All is dependencies 
are so extremely old and the jdks for some are no longer available. At least I 
probably wouldn't touch it and focus on the "middle"...
 +1 !

Possibly have a look at 3.0 (haven't done that yet).

I tried using 3.0 for a project.  Some good ideas and simple enough 
implementation but I don't think there is enough there for it to be worth 
saving

Chris

Gesendet von Outlook für Android<https://aka.ms/AAb9ysg>

From: Cédric Damioli mailto:cdami...@apache.org>>
Sent: Monday, November 20, 2023 3:47:14 PM
To: dev@cocoon.apache.org<mailto:dev@cocoon.apache.org> 
mailto:dev@cocoon.apache.org>>
Subject: Re: Now that the release is out, what's next?

Hi,

On top of that, as a community, we now have to formally answer to the below 
question (going or not to the Attic) not only once, but three times, one time 
for each subproject we still officially maintain since more than 10 years :
 - Cocoon 2.1.x (pre-Spring, pre-Maven). Last release 2.1.13 was rolled out 3 
years ago.
 - Cocoon 2.2x (now 2.3.x). Last release these days.
 - Cocoon 3.0.x. Last release 3.0.0-alpha-3 back in 2011

Those 3 versions are not compatible with each other, are not meant as drop-in 
replacements, and have evolved differently over the years.

The community could either decide to stop the project as-is and go to the 
Attic, or start over maintaining only one or two branches.

Cédric

Le 19/11/2023 à 18:20, Christofer Dutz a écrit :

Hi folks,



So, it seems that we finally have finished the last missing steps to formally 
get the release out the door. Now I think comes a time where we should reflect 
and discuss, what should happen with the Project.



So instead of simply saying: Releasing it was such a struggle (not technically, 
but from a participation side) I wouldn’t say this project is healthy and we 
should discuss a move into the Attic.



However, I could also imagine that the changes I implemented in the build might 
encourage some folks to give it another go.



I know when I was doing projects with Cocoon as part of my day-job 20 years 
ago, Cocoon 2.2 sort of completely broke my flow. Not only my inexperience with 
Maven, but also that of Spring and the versioning scheme where all sorts of 
cocoon modules had different versions just made me give up at that time and 
switch to Adobe Flex ;-)



Now (15 years 

Next steps?

[Christofer Dutz]

Hi all,

So, it’s been a while and I think we were waiting for the results of the survey.

Not quite sure what we agreed upon what the next steps were.

So far, I think one of the first steps I recall was a formal migration to using 
Git as a primary SCM.
If that’s the case I would volunteer to do that.


Chris

AW: Next steps?

[Christofer Dutz]

So, as this project is so low-volume … I think I’ll do what I did with similar 
projects.

So, if I don’t hear anything else within the next 72h, I’ll initiate the Git 
migration.

Chris



Von: Christofer Dutz 
Datum: Samstag, 11. Mai 2024 um 19:12
An: dev@cocoon.apache.org 
Betreff: Next steps?
Hi all,

So, it’s been a while and I think we were waiting for the results of the survey.

Not quite sure what we agreed upon what the next steps were.

So far, I think one of the first steps I recall was a formal migration to using 
Git as a primary SCM.
If that’s the case I would volunteer to do that.


Chris

AW: [IMPORTANT] Developer Survey on the State of Cocoon

[Christofer Dutz]

Hi all,

So, what’s the status of this?
I haven’t started the Git migration as I thought it might make more sense to 
wait for the end of this.

Chris


Von: Torsten Curdt 
Datum: Dienstag, 20. Februar 2024 um 15:03
An: dev@cocoon.apache.org 
Betreff: [IMPORTANT] Developer Survey on the State of Cocoon
The PMC wants to gather feedback on the state of the project.
If you can, please spend the 2 minutes answering our quick survey.
The survey is anonymous.

https://app.edkimo.com/feedback/ewevipve

This is for EVERYONE on the dev list - not just committers!
Even if you have already participated in the PMC survey, please also answer 
this one.

Thanks!
cheers,
Torsten
In behalf of the Cocoon PMC

AW: Developer Survey Results

[Christofer Dutz]

Hi all,

Admittedly the Chair position is a simple secretarial role.
So, if this is the problem nobody wants to take on … I’d be willing to do that 
paperwork for a while.

Chris


Von: Torsten Curdt 
Datum: Donnerstag, 29. Februar 2024 um 01:19
An: dev@cocoon.apache.org 
Betreff: Developer Survey Results
The Developer survey is now open for 9 days.

We have received 10 responses.
5 were from PMC members.

Here are the results

https://app.edkimo.com/results/ewevipve

My takeaways:

- 7 disagree to retire
- only 10 responses is discouraging
- but 6 say they can make time and imagine to continue work on Cocoon
- I really hope the person that can imagine to be PMC chair will step forward
- 2.1 is still the most widely used version (and I am curious how this can be 
merged into a single path forward)

cheers,
Torsten

AW: AW: Developer Survey Results

[Christofer Dutz]

Hi all,

What does another hat on the wall change?

It’s sort of a slightly increased number of hats here ;-)

Chris

Von: Torsten Curdt 
Datum: Donnerstag, 29. Februar 2024 um 21:19
An: dev@cocoon.apache.org 
Betreff: Re: AW: Developer Survey Results
During the past years, I always felt it was somehow my duty as chair to write 
reports, ensure someone answers to incoming requests, etc...
So yes it is formally a simple secretarial role, but as a someone only involved 
in a now-retired-version (2.1), I think it'd be good for the project that the 
chair is actually involved in the current live branch.

So good news if you're willing to take the hat :)

+1 to all of that

[jira] [Commented] (COCOON-2359) [2.2] Fix incompatibility of cocoon-captcha with JDK 1.7/1.8

[Christofer Dutz (Jira)]

[ 
https://issues.apache.org/jira/browse/COCOON-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17791653#comment-17791653
 ] 

Christofer Dutz commented on COCOON-2359:
-

Yeah ... I actually replaced all usages of JPEG types with ImageIO types ;-)

> [2.2] Fix incompatibility of cocoon-captcha with JDK 1.7/1.8
> 
>
> Key: COCOON-2359
> URL: https://issues.apache.org/jira/browse/COCOON-2359
> Project: Cocoon
>  Issue Type: Bug
>  Components: Blocks: Captcha
>Affects Versions: 2.2
>Reporter: Gabriel Gruber
>Priority: Major
> Fix For: 2.3.1
>
>
> Goal is to remove the direct usage of 
> - JPEGImageEncoder
> - JPEGEncodeParam
> inside CaptchaReader.java
> And replace them with the newer 1.6 API of ImageIO
> https://blog.idrsolutions.com/2012/05/replacing-the-deprecated-java-jpeg-classes-for-java-7/



--
This message was sent by Atlassian Jira
(v8.20.10#820010)