date:20070605


Grzegorz Kossakowski (JIRA) pisze:

 [ 
https://issues.apache.org/jira/browse/COCOON-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Grzegorz Kossakowski closed COCOON-2073.


Resolution: Fixed

Thanks for report. I updated please test and close the issue.


Of course the issue is already closed. I'm just experimenting with new Mylar 
version so some quirks may happen.

--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

[jira] Closed: (COCOON-2073) Upgrade to dojo 0.4.3 (security fixes!)

2007-06-05 Thread Grzegorz Kossakowski (JIRA)


 [ 
https://issues.apache.org/jira/browse/COCOON-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Grzegorz Kossakowski closed COCOON-2073.


Resolution: Fixed

Thanks for report. I updated please test and close the issue.

> Upgrade to dojo 0.4.3 (security fixes!)
> ---
>
> Key: COCOON-2073
> URL: https://issues.apache.org/jira/browse/COCOON-2073
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Ajax
>Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
>Reporter: Alexander Klimetschek
>Assignee: Grzegorz Kossakowski
>
> Current ajax block includes dojo 0.4.1. The current release of dojo is 0.4.3 
> - in 0.4.2 minor improvements were made but 0.4.3 includes security fixes for 
> cross-site scripting attacks and the guys at dojo strongly recommend 
> upgrading. As far as I can see, there should be no compatibility issues with 
> Cocoon's dojo widgets. 
> http://dojotoolkit.org/releaseNotes/0.4.3

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Discussion about Maven

Vadim Gritsenko pisze:

I wanted to know what are our rules. Do we:
- want to have such a internal releases

I'd avoid using word "release" for this as it has some legal
implications and we would get chewed up for using it :)

Ah, I'm young committer so forgive me that I omit legal implications and use inappropriate words. I'm really hard working to improve my
English. :-)

I agree it should not be called release.

Yes I think you can do such builds and place them on your private space
at people.apache.org or on cocoon zones, and call it "nightly" or
"build" or some such, but not a "milestone *release*".

And it is a good idea to do such builds as long as it helps to further
development of Cocoon.

IMHO, for milestone *release*, I'd bundle all necessary unreleased
dependencies and upload to www.apache.org/dist. I'm not sure if there
are any legal gotchas with this approach, but it worked for us in the
past, for 2.1 milestones.

It will not work with Maven and it can't be called "release" I think. My personal opinion is that release (after changing wording) should be
something that we can officially ship using our infrastructure. Part of our infrastructure is Maven now but in order to upload to its
central server we can't have snapshot dependencies as pointed out earlier.
The only solution I can think of is that we stay longer in "nighly build" mode and we can switch to milestone mode as soon as all of our
dependencies are released ones.
I think that it will work well only if we successfully "push" projects we depend on to follow "release early, release often" practice so we
will not bed forced to stay in "nighly build" phase too long.

I'm not so much experienced with Open Source to have a strong opinion on this. Do you
think that we effectively "push" other project?

-1. I'd prefer to have a (semi) regular milestone releases, even if it
is harder to do with Maven...

I don't think it's harder with Maven. Maven was important factor when it comes to ability to have independent release cycles. We just need
to clearly define terms (like release) we use and get used to the thought that we should tend to depend on released versions and talk more
with other projects about releasing their goodies.

WDYT?

--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

Re: Discussion about Maven


Grzegorz Kossakowski wrote:

Vadim Gritsenko pisze:

Grzegorz Kossakowski wrote:
On the other hand, milestones are just our internal releases and I 
think we can live with these gaps.


No, they are not internal:
  http://cocoon.apache.org/2.1/changes.html
  http://archive.apache.org/dist/cocoon/SOURCES/
  http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-core/2.2.0-M3/


Examples you provided do not apply to the situation I want to discuss. 
In 2.1 times we were shipping all dependencies ourselves so there is no 
problem of dependency resolution.


I hope it is still an option.


I was talking about the situation when we want to release some early 
alpha that has _snapshot_ dependencies that (obviously) are _not_ 
available at central server. If we want to make such a release it has to 
be "internal" because we cannot ship it or upload at central.


Ok, I understand.



I wanted to know what are our rules. Do we:
- want to have such a internal releases


I'd avoid using word "release" for this as it has some legal implications and we 
would get chewed up for using it :)


Yes I think you can do such builds and place them on your private space at 
people.apache.org or on cocoon zones, and call it "nightly" or "build" or some 
such, but not a "milestone *release*".


And it is a good idea to do such builds as long as it helps to further 
development of Cocoon.




OR
- we really think that world is perfect and we'll always depend on 
released artifacts even in early stages of development


IMHO, for milestone *release*, I'd bundle all necessary unreleased dependencies 
and upload to www.apache.org/dist. I'm not sure if there are any legal gotchas 
with this approach, but it worked for us in the past, for 2.1 milestones.




OR
- we do not make any early (alpha) releases at all (what about release 
early, release often, then?)


-1. I'd prefer to have a (semi) regular milestone releases, even if it is harder 
to do with Maven...


Vadim



I would really want to know your view on this issue.

[jira] Updated: (COCOON-2073) Upgrade to dojo 0.4.3 (security fixes!)

2007-06-05 Thread Grzegorz Kossakowski (JIRA)


 [ 
https://issues.apache.org/jira/browse/COCOON-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Grzegorz Kossakowski updated COCOON-2073:
-

   Assignee: Grzegorz Kossakowski
Description: 
Current ajax block includes dojo 0.4.1. The current release of dojo is 0.4.3 - 
in 0.4.2 minor improvements were made but 0.4.3 includes security fixes for 
cross-site scripting attacks and the guys at dojo strongly recommend upgrading. 
As far as I can see, there should be no compatibility issues with Cocoon's dojo 
widgets. 

http://dojotoolkit.org/releaseNotes/0.4.3

  was:
Current ajax block includes dojo 0.4.1. The current release of dojo is 0.4.3 - 
in 0.4.2 minor improvements were made but 0.4.3 includes security fixes for 
cross-site scripting attacks and the guys at dojo strongly recommend upgrading. 
As far as I can see, there should be no compatibility issues with Cocoon's dojo 
widgets.

http://dojotoolkit.org/releaseNotes/0.4.3


> Upgrade to dojo 0.4.3 (security fixes!)
> ---
>
> Key: COCOON-2073
> URL: https://issues.apache.org/jira/browse/COCOON-2073
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Ajax
>Affects Versions: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
>Reporter: Alexander Klimetschek
>Assignee: Grzegorz Kossakowski
>
> Current ajax block includes dojo 0.4.1. The current release of dojo is 0.4.3 
> - in 0.4.2 minor improvements were made but 0.4.3 includes security fixes for 
> cross-site scripting attacks and the guys at dojo strongly recommend 
> upgrading. As far as I can see, there should be no compatibility issues with 
> Cocoon's dojo widgets. 
> http://dojotoolkit.org/releaseNotes/0.4.3

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: svn commit: r544460 - in /cocoon/trunk/core/cocoon-servlet-service: cocoon-servlet-service-components/src/main/java/org/apache/cocoon/servletservice/components/ cocoon-servlet-service-impl/src/mai


[EMAIL PROTECTED] pisze:

Author: giacomo
Date: Tue Jun  5 05:04:42 2007
New Revision: 544460

URL: http://svn.apache.org/viewvc?view=rev&rev=544460
Log:
attempt to fix wrong prefix for servlet-services


Hi Giacomo, thanks for taking care of it. However I would be grateful if you mention in log message the issue you are trying to fix 
(COCOON-2066) and generally it would be good that you assign the issue to yourself because it's sign for the others that you are willing to 
fix it.


Commenting the fix itself, I really hope that you consider it as temporary solution, do you? I talked with Daniel some time ago and he told 
me that we was going to be busy these days with his scientific work but he should be free soon. I really hope that he will help us to make a 
real fix - passing original request object to the BlockCallHttpServletRequest as it's only one reasonable option that covers also other 
issues: http://article.gmane.org/gmane.text.xml.cocoon.user/61154


--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

Re: Discussion about Maven


Vadim Gritsenko pisze:

Grzegorz Kossakowski wrote:
On the other hand, milestones are just our internal releases and I 
think we can live with these gaps.


No, they are not internal:
  http://cocoon.apache.org/2.1/changes.html
  http://archive.apache.org/dist/cocoon/SOURCES/
  http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-core/2.2.0-M3/


Examples you provided do not apply to the situation I want to discuss. In 2.1 times we were shipping all dependencies ourselves so there is 
no problem of dependency resolution.


I was talking about the situation when we want to release some early alpha that has _snapshot_ dependencies that (obviously) are _not_ 
available at central server. If we want to make such a release it has to be "internal" because we cannot ship it or upload at central. I 
wanted to know what are our rules. Do we:

- want to have such a internal releases
OR
- we really think that world is perfect and we'll always depend on released 
artifacts even in early stages of development
OR
- we do not make any early (alpha) releases at all (what about release early, 
release often, then?)

I would really want to know your view on this issue.

--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

Website: Outdated info: How to get listed in live sites link

2007-06-05 Thread Antonio Gallardo


Hi,

The follow instructions still points to the our old bugzilla tracking 
system:


http://cocoon.apache.org/link/livesites-2.1.html#How+to+get+listed

Best Regards,

Antonio Gallardo.

Re: xslt 2.0 with cocoon 2.2?


[EMAIL PROTECTED] wrote:

Vadim Gritsenko <[EMAIL PROTECTED]> writes:

Thanks!
I got it going, but I needed to change a file within one of the jar
files:

META-INF/cocoon/avalon/cocoon-core-xslt-saxon.xconf
in
/maven-temp-repository/org/apache/cocoon/cocoon-pipeline-components/1.0.0-RC1/cocoon-pipeline-components-1.0.0-RC1.jar

to activate saxon. This seems kind of awkward!


You probably are using default (built-in) config files. You can override all of 
them and use your own by adding location attribute on  tag.


Vadim

Re: xslt 2.0 with cocoon 2.2?

2007-06-05 Thread joakim

Vadim Gritsenko <[EMAIL PROTECTED]> writes:

Thanks!
I got it going, but I needed to change a file within one of the jar
files:

META-INF/cocoon/avalon/cocoon-core-xslt-saxon.xconf
in
/maven-temp-repository/org/apache/cocoon/cocoon-pipeline-components/1.0.0-RC1/cocoon-pipeline-components-1.0.0-RC1.jar

to activate saxon. This seems kind of awkward!

> [EMAIL PROTECTED] wrote:
>> This recipy was used for cocoon 2.1:
>> http://wiki.apache.org/cocoon/Saxon>
>> Does it still apply?
>
> The page is incorrect in suggesting that there is a need to modify
> Saxon jar, see [1]. But other than that, Cocoon 2.2 is mostly backward
> compatible with Cocoon 2.1, and we are using it, with Saxon 8.
>
> Vadim
>
> [1] http://blog.reverycodes.com/archives/34.html

-- 
Joakim Verona

Re: xslt 2.0 with cocoon 2.2?


[EMAIL PROTECTED] wrote:

This recipy was used for cocoon 2.1:
http://wiki.apache.org/cocoon/Saxon

Does it still apply?


The page is incorrect in suggesting that there is a need to modify Saxon jar, 
see [1]. But other than that, Cocoon 2.2 is mostly backward compatible with 
Cocoon 2.1, and we are using it, with Saxon 8.


Vadim

[1] http://blog.reverycodes.com/archives/34.html

xslt 2.0 with cocoon 2.2?

2007-06-05 Thread joakim

This recipy was used for cocoon 2.1:
http://wiki.apache.org/cocoon/Saxon

Does it still apply?
-- 
Joakim Verona

Re: Discussion about Maven


Grzegorz Kossakowski wrote:
On the other hand, milestones are just 
our internal releases and I think we can live with these gaps.


No, they are not internal:
  http://cocoon.apache.org/2.1/changes.html
  http://archive.apache.org/dist/cocoon/SOURCES/
  http://repo1.maven.org/maven2/org/apache/cocoon/cocoon-core/2.2.0-M3/


Vadim

[jira] Closed: (COCOON-1941) Upgrade DOJO to 0.4

2007-06-05 Thread Lars Trieloff (JIRA)


 [ 
https://issues.apache.org/jira/browse/COCOON-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lars Trieloff closed COCOON-1941.
-

   Resolution: Fixed
Fix Version/s: 2.2-dev (Current SVN)
   2.1.11-dev (Current SVN)

> Upgrade DOJO to 0.4
> ---
>
> Key: COCOON-1941
> URL: https://issues.apache.org/jira/browse/COCOON-1941
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Ajax
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Lars Trieloff
> Fix For: 2.1.11-dev (Current SVN), 2.2-dev (Current SVN)
>
>
> The Dojo Foundation has released version 0.4 of the Dojo toolkit yesterday. 
> Cocoon should use this version of Dojo.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Presumed bug in Dojo/Cocoon integration

2007-06-05 Thread Ellis Pritchard



On 25 May 2007, at 16:07, Grzegorz Kossakowski wrote:

As for serializing to XHTML. First of all you must be aware that  
browsers will not treat XHTML as XHTML pages because of content  
type set to "text/html" instead of "text/xhtml". It is done so  
because IE (sigh) does not understand "text/xhtml". Given that,  
browsers interpret XHTML as HTML code and it usually works but not  
for empty elements because in html there was no such a construct



We are finally near to the problem, AJAX does not work because js- 
libraries are not being loaded correctly because script tag is not  
parsed correctly. As a workaround, you can add comment/dummmy  
character inside all empty elements in resulting XHTML. It's really  
basic tip.


There were lots of discussions related to this issue so maybe you  
can find some neat solution in archives. Some pointers:

http://thread.gmane.org/gmane.text.xml.cocoon.user/58517
http://thread.gmane.org/gmane.text.xml.cocoon.user/34237

And this especially interesting for you:
http://thread.gmane.org/gmane.text.xml.cocoon.user/60301



See also: http://www.hixie.ch/advocacy/xhtml - Sending XHTML as text/ 
html Considered Harmful


Ellis.

[jira] Updated: (COCOON-1941) Upgrade DOJO to 0.4


 [ 
https://issues.apache.org/jira/browse/COCOON-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Klimetschek updated COCOON-1941:
--

Status: On Hold  (was: Continued)

Ok, an endless loop of feedback ;-) Here is the opportunity for someone to 
close a 8-month old issue!

> Upgrade DOJO to 0.4
> ---
>
> Key: COCOON-1941
> URL: https://issues.apache.org/jira/browse/COCOON-1941
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Ajax
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Lars Trieloff
>
> The Dojo Foundation has released version 0.4 of the Dojo toolkit yesterday. 
> Cocoon should use this version of Dojo.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (COCOON-1941) Upgrade DOJO to 0.4


 [ 
https://issues.apache.org/jira/browse/COCOON-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Klimetschek updated COCOON-1941:
--

Status: Continued  (was: On Hold)

Hmm, let's look what happens after the feedback received workflow action...

> Upgrade DOJO to 0.4
> ---
>
> Key: COCOON-1941
> URL: https://issues.apache.org/jira/browse/COCOON-1941
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Ajax
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Lars Trieloff
>
> The Dojo Foundation has released version 0.4 of the Dojo toolkit yesterday. 
> Cocoon should use this version of Dojo.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (COCOON-1941) Upgrade DOJO to 0.4


 [ 
https://issues.apache.org/jira/browse/COCOON-1941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Klimetschek updated COCOON-1941:
--

Status: On Hold  (was: Open)

This issues is already done, but I have no Jira karma to close it.

> Upgrade DOJO to 0.4
> ---
>
> Key: COCOON-1941
> URL: https://issues.apache.org/jira/browse/COCOON-1941
> Project: Cocoon
>  Issue Type: Improvement
>  Components: Blocks: Ajax
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Lars Trieloff
>
> The Dojo Foundation has released version 0.4 of the Dojo toolkit yesterday. 
> Cocoon should use this version of Dojo.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (COCOON-2073) Upgrade to dojo 0.4.3 (security fixes!)