headers
Grzegorz Kossakowski (JIRA | 1 Jul 2007 01:05
Picon
Favicon

[jira] Created: (COCOON-2082) Get rid of Avalon dependencies in cocoon-expression-language code

Get rid of Avalon dependencies in cocoon-expression-language code
-----------------------------------------------------------------

                 Key: COCOON-2082
                 URL: https://issues.apache.org/jira/browse/COCOON-2082
             Project: Cocoon
          Issue Type: Task
          Components: * Cocoon Core, - Components: Avalon, Blocks: Templating
    Affects Versions: 2.2-dev (Current SVN)
            Reporter: Grzegorz Kossakowski
            Assignee: Grzegorz Kossakowski
             Fix For: 2.2-dev (Current SVN)

The task consists of making DefaultExpressionFactory a Spring bean and minor tweaking in rest of classes.

Block cocoon-template must be updated accordingly.

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Permalink | Reply | 1 comment |
headers
Grzegorz Kossakowski | 1 Jul 2007 15:46
Favicon
Gravatar

Versioning XML Schemas

Hi,

I would like to add some more documentation to cocoon-configurator-1.0.1.xsd[1] but I'm not sure what is
our policy for versioning XML 
schemas. AFAIK, 1.0.1 version has not been released yet so I can modify it freely, right? When it will be
officially released? When 
cocoon-spring-configurator is released?

What is more confusing we already have schema published at [2] without any mark that this is a snapshot
version that is likely to be changed.

Do we have any policy on versioning xml schemas? Shouldn't we have a
cocoon-configurator-1.0.1-SNAPSHOT.xsd published and rename it just 
before we release cocoon-spring-cofigurator? This way we would always know when the version is locked down.

[1] 
http://svn.apache.org/viewvc/cocoon/trunk/core/cocoon-configuration/cocoon-spring-configurator/src/main/resources/org/apache/cocoon/spring/configurator/schema/cocoon-configurator-1.0.1.xsd?view=markup
[2] http://cocoon.apache.org/schema/configurator/cocoon-configurator-1.0.1.xsd

--

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Permalink | Reply | 7 comments |
headers
Joerg Heinicke | 1 Jul 2007 16:37
Picon
Picon

Re: Versioning XML Schemas

On 01.07.2007 15:46, Grzegorz Kossakowski wrote:

> I would like to add some more documentation to 
> cocoon-configurator-1.0.1.xsd[1] but I'm not sure what is our policy for 
> versioning XML schemas. AFAIK, 1.0.1 version has not been released yet 
> so I can modify it freely, right? When it will be officially released? 
> When cocoon-spring-configurator is released?

Yes, I think it should be released with the block it contains it. I 
don't know if its versioning needs to follow its containing block 
though. Not every release of the block makes changes in the schema 
necessary. Despite steps in the versioning it will probably be easier 
though to follow the block's versioning.

> What is more confusing we already have schema published at [2] without 
> any mark that this is a snapshot version that is likely to be changed.

IMO that's no problem. See below ...

> Do we have any policy on versioning xml schemas? Shouldn't we have a 
> cocoon-configurator-1.0.1-SNAPSHOT.xsd published and rename it just 
> before we release cocoon-spring-cofigurator? This way we would always 
> know when the version is locked down.

I'm against the SNAPSHOT suffix. A DTD or schema should never be 
retrieved from remote, but always from a local version (via xml 
catalogue or whatever). For somebody doing the latter it should be 
obvious whether it's released or not since he works with the released or 
the snapshot block. IMO it's just too much work to change all the 
references from the snapshot version to the release version if they
(Continue reading)

Permalink | Reply | 6 comments |
headers
xweber | 1 Jul 2007 17:02

cocoon 2.2 - some more questions


hi,

actually i'm trying to get a 2.2 based thingy up and running. Based on the
existing daisy docs there are some questions "open" for me. Current
questions:

1.) the demo-application-context.xml file
what about that filename - must it reflect the package name? Or must there
only be a file ending with ..-application-context.xml. Is there only one of
this files for all packages in that block?

2.) as in the tutorials i have two or more blocks and one webapp type
folders. I fire up the webapp part with mvn jetty:run inside it.
Unfortuanatly the rcl (reloading on change) stuff did not work. Is there a
way to get it also up when started via webapp part?

Alex
--

-- 
View this message in context: http://www.nabble.com/cocoon-2.2---some-more-questions-tf4008051.html#a11382520
Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Permalink | Reply | 14 comments |
headers
Grzegorz Kossakowski | 1 Jul 2007 17:18
Picon
Favicon

Re: Versioning XML Schemas

Joerg Heinicke pisze:
> Yes, I think it should be released with the block it contains it. I 
> don't know if its versioning needs to follow its containing block 
> though. Not every release of the block makes changes in the schema 
> necessary. Despite steps in the versioning it will probably be easier 
> though to follow the block's versioning.

Agreed.

> I'm against the SNAPSHOT suffix. A DTD or schema should never be 
> retrieved from remote, but always from a local version (via xml 
> catalogue or whatever). For somebody doing the latter it should be 
> obvious whether it's released or not since he works with the released or 
> the snapshot block. IMO it's just too much work to change all the 
> references from the snapshot version to the release version if they 
> differ in name.

I agree that renaming would involve too much tinkering but I don't get XML catalog solution fully. Do you
want to say that publishing schema 
is useless because we should always use XML catalogs for receiving schemas?

> Spring handles it the same way [1]. They did not even increase the 
> version number on changes [2]. Important is probably the backwards 
> compatibility. In that particular case: An XML written against Spring 
> 2.0.2's AOP schema works in 2.0.3 as well despite the additional 
> attribute. No idea yet when it is better to force the user to update his 
> references.

I really don't like such a solution. I really like to know that something released as x.y.z is never going to
change. Otherwise, whole
(Continue reading)

Permalink | Reply | 5 comments |
headers
Grzegorz Kossakowski | 1 Jul 2007 17:26
Picon
Favicon

Re: cocoon 2.2 - some more questions

xweber pisze:
> hi,
> 
> actually i'm trying to get a 2.2 based thingy up and running. Based on the
> existing daisy docs there are some questions "open" for me. Current
> questions:
> 
> 1.) the demo-application-context.xml file
> what about that filename - must it reflect the package name? Or must there
> only be a file ending with ..-application-context.xml. Is there only one of
> this files for all packages in that block?

You can choose filename whatever you like. The only requirement is its location, it must be located at
MEA-INF/cocoon/spring since all 
Spring configuration is read from there by default.

> 2.) as in the tutorials i have two or more blocks and one webapp type
> folders. I fire up the webapp part with mvn jetty:run inside it.
> Unfortuanatly the rcl (reloading on change) stuff did not work. Is there a
> way to get it also up when started via webapp part?

No. Webapp (create from webapp archetype) is useful when you want to create a package of your application
(e.g. a WAR file that can be 
dropped in Tomcat's working directory). Of course, you can use it also for starting your application but
since we have a RCL plug-in it is 
not advised to use webapp for development.

If you follow tutorials really carefully RCL plug-in must work for you, it has been tested rather thoroughly.

--

--
(Continue reading)

Permalink | Reply | 8 comments |
headers
xweber | 1 Jul 2007 17:51

Re: cocoon 2.2 - some more questions


> If you follow tutorials really carefully RCL plug-in must work for you, it
> has been tested rather thoroughly.
> 

Yes for Block(s) the RCL is working. Seems I am still struggeling how to pu
the parts together :-)

archetype webapp is the last part in development. I thought I could use it
as a kind of "config" holder for my other blocks (e.g. property files for
other blocks)- which should be tied together for a plugin like structure. So
for me it seems I am in the need to have this config-part to be a block
archetype - because I can use the RCL feature of it for development.

Alex
--

-- 
View this message in context: http://www.nabble.com/cocoon-2.2---some-more-questions-tf4008051.html#a11382998
Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Permalink | Reply | 6 comments |
headers
Grzegorz Kossakowski | 1 Jul 2007 18:09
Picon
Favicon

Re: cocoon 2.2 - some more questions

xweber pisze:
> 
> 
>> If you follow tutorials really carefully RCL plug-in must work for you, it
>> has been tested rather thoroughly.
>>
> 
> Yes for Block(s) the RCL is working. Seems I am still struggeling how to pu
> the parts together :-)
> 
> archetype webapp is the last part in development. I thought I could use it
> as a kind of "config" holder for my other blocks (e.g. property files for
> other blocks)- which should be tied together for a plugin like structure. So
> for me it seems I am in the need to have this config-part to be a block
> archetype - because I can use the RCL feature of it for development.

What kind of configuration do have in mind? If it's an application-specific configuration (properties)
the idea to tweak them in webapp is 
quite reasonable. Still I don't understand why do you want to start whole application from webapp, you can
develop particular blocks with 
any properties you like to test.

If you provide more detailed description of what you really want to achieve it will be easier to help you.

--

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Permalink | Reply | 5 comments |
headers
xweber | 1 Jul 2007 18:39

Re: cocoon 2.2 - some more questions


well i am thinking of a portal. So there will be a core block (to manage the
main sitemap), one or more skin blocks for final layout, some lib-blocks for
extending the core with e.g. database, mail and that kind of functionality.
And modules like blocks for features to the portal (the ones who will
provide the content). That as a generic portal (combination). Now you want
to have a concrete portal with that parts. Instead of modifying settings in
core (and database) for the concrete informations, and what modules to use
(maybe you do not want to have the module-tictactoe in your portal) all you
need to do is not to set the dependency to that module in the "webapp"
pom.xml. So that is the kind of configurations-block i had in mind.

I know there is a portal in Cocoon 2.1 and there will be one in 2.2 (at
least i think so). Maybe that approach i have in mind is a bit more spring
like to set the parts together. I dont even know if it possible.

Alex
--

-- 
View this message in context: http://www.nabble.com/cocoon-2.2---some-more-questions-tf4008051.html#a11383411
Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Permalink | Reply | 4 comments |
headers
Grzegorz Kossakowski | 1 Jul 2007 19:31
Picon
Favicon

Re: cocoon 2.2 - some more questions

xweber pisze:
> well i am thinking of a portal. So there will be a core block (to manage the
> main sitemap), one or more skin blocks for final layout, some lib-blocks for
> extending the core with e.g. database, mail and that kind of functionality.
> And modules like blocks for features to the portal (the ones who will
> provide the content). That as a generic portal (combination). Now you want
> to have a concrete portal with that parts. Instead of modifying settings in
> core (and database) for the concrete informations, and what modules to use
> (maybe you do not want to have the module-tictactoe in your portal) all you
> need to do is not to set the dependency to that module in the "webapp"
> pom.xml. So that is the kind of configurations-block i had in mind.

I see. I think you have described the use case for C2.2 architecture. It's basically what blocks has been
designed for (but not only for 
such situations). Most of the infrastructure is already there (especially configuration, building and
packaging parts). The only part still 
under development is wiring (servlet-service-fw). With blocks polymorphism (see COCOON-2038 issue)
and postable source (see COCOON-2046) you 
will get all needed tools to handle even more sophisticated set-ups.

I plan to write docs for servlet-service-fw tomorrow and explain the big picture so everyone will know what
incredible functionality it 
already offers (or will offer soon) and what help is needed. The plan may change a little because my top
priority is GSoC-related development.

If you have concrete question (how to achieve x) feel free to ask, I'll be happy to answer them only if I can help.

> I know there is a portal in Cocoon 2.1 and there will be one in 2.2 (at
> least i think so). Maybe that approach i have in mind is a bit more spring
> like to set the parts together. I dont even know if it possible.
(Continue reading)

Permalink | Reply | 3 comments |

Gmane