Re: Rhino (once more)
I don't believe it works like that. My understanding is that as long as the flowscript block is an optional part of Cocoon then there is no problem with releasing the flowscript block even if it requires a jar under the NPL. We just have to provide notice and not include the NPL'd jar within our distribution. Ralph David Crossley wrote: Ralph Goers wrote: This may not be too big a deal for Cocoon trunk. So long as flowscript is an optional part of Cocoon I believe we are OK. However, it probably also means that while other blocks can take advantage of flowscript they shouldn't rely on it. I presume that this will put the problem onto the "Flowscript Block" which could not be officially released if Rhino is a mandatory part of that block. -David
Re: [SITE] - Contributions to this relase....
Antonio Gallardo wrote: > > In http://cocoon.apache.org/2.1/changes.html we read for each release: > > > > > Contributors to this release > > We thank the following people for their contributions to this release. > > This is a list of all people who participated as committers: > [Committer's list] > > This is a list of other contributors: > [contributor's list] > > > > I wonder if we can improve the sentence: "This is a list of other > contributors:" In particular I don't like the "other contributor" > concept. Perhaps it is because I am no a native english speaker. > > Perhpas we should review the whole section. > > WDYT? This is generated by the Forrest plugin "projectInfo" from the data in cocoon/site/status.xml It says "other contributors" because "committers" are contributors but these other people are contributors but are not "committers". I had tried my best to get that English correct. If people think that they can do better then please send a patch to the Forrest sources. It is very important to acknowledge everyone who is involved, otherwise a community cannot be built. -David
Re: Rhino (once more)
Ralph Goers wrote: > This may not be too big a deal for Cocoon trunk. So long as flowscript > is an optional part of Cocoon I believe we are OK. However, it probably > also means that while other blocks can take advantage of flowscript they > shouldn't rely on it. I presume that this will put the problem onto the "Flowscript Block" which could not be officially released if Rhino is a mandatory part of that block. -David
[jira] Commented: (COCOON-1946) [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing cform templates
[
http://issues.apache.org/jira/browse/COCOON-1946?page=comments#action_12445686
]
Maurizio Pillitu commented on COCOON-1946:
--
This issue depends on http://issues.apache.org/jira/browse/COCOON-1929
> [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and
> showing cform templates
> ---
>
> Key: COCOON-1946
> URL: http://issues.apache.org/jira/browse/COCOON-1946
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Java Flow
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Maurizio Pillitu
> Attachments: cocoon-javaflow-r469213.diff
>
>
> In order to enable the runtime Javaflow class enhancement, the sitemap must
> provide a map:classloader configuration, defining the class-dir folder to be
> monitored. Since the class-dir may contain also non .class files, the
> BCELTransformer crashes whether the resource to transform is not a .class
> file.
> This patch introduces a JavaflowResourceStore that wraps the Commons
> JavaflowResourceStore and parses the include/exclude elements of the
> map:classloader sitemap configuration.
> Additionally, it fixes some bugs in the sample cforms, related to the
> Continuation references of the form templates:
> the reference #{$continuation/id}.cont must be changed to
> #{$cocoon/continuation/id}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1946) [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing cform templates
[ http://issues.apache.org/jira/browse/COCOON-1946?page=all ]
Maurizio Pillitu updated COCOON-1946:
-
Attachment: cocoon-javaflow-r469213.diff
> [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and
> showing cform templates
> ---
>
> Key: COCOON-1946
> URL: http://issues.apache.org/jira/browse/COCOON-1946
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Java Flow
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Maurizio Pillitu
> Attachments: cocoon-javaflow-r469213.diff
>
>
> In order to enable the runtime Javaflow class enhancement, the sitemap must
> provide a map:classloader configuration, defining the class-dir folder to be
> monitored. Since the class-dir may contain also non .class files, the
> BCELTransformer crashes whether the resource to transform is not a .class
> file.
> This patch introduces a JavaflowResourceStore that wraps the Commons
> JavaflowResourceStore and parses the include/exclude elements of the
> map:classloader sitemap configuration.
> Additionally, it fixes some bugs in the sample cforms, related to the
> Continuation references of the form templates:
> the reference #{$continuation/id}.cont must be changed to
> #{$cocoon/continuation/id}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1946) [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing cform templates
[PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing
cform templates
---
Key: COCOON-1946
URL: http://issues.apache.org/jira/browse/COCOON-1946
Project: Cocoon
Issue Type: Bug
Components: Blocks: Java Flow
Affects Versions: 2.2-dev (Current SVN)
Reporter: Maurizio Pillitu
In order to enable the runtime Javaflow class enhancement, the sitemap must
provide a map:classloader configuration, defining the class-dir folder to be
monitored. Since the class-dir may contain also non .class files, the
BCELTransformer crashes whether the resource to transform is not a .class file.
This patch introduces a JavaflowResourceStore that wraps the Commons
JavaflowResourceStore and parses the include/exclude elements of the
map:classloader sitemap configuration.
Additionally, it fixes some bugs in the sample cforms, related to the
Continuation references of the form templates:
the reference #{$continuation/id}.cont must be changed to
#{$cocoon/continuation/id}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1929) [PATCH] Reloading classloader in Cocoon 2.2
[ http://issues.apache.org/jira/browse/COCOON-1929?page=all ] Maurizio Pillitu updated COCOON-1929: - Attachment: cocoon-core-r469213.diff Last patcheset was missing some files; this is the right one. > [PATCH] Reloading classloader in Cocoon 2.2 > --- > > Key: COCOON-1929 > URL: http://issues.apache.org/jira/browse/COCOON-1929 > Project: Cocoon > Issue Type: Task > Components: * Cocoon Core >Affects Versions: 2.2-dev (Current SVN) >Reporter: Maurizio Pillitu > Attachments: cocoon-core-r469213.diff, cocoon-r469167.diff, > cocoon.diff > > > The attached patch provides a first implementation to enable reloading > classloader configuration into the sitemap, using the sitemap syntax used in > blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resources/COB-INF/sitemap.xmap. > Referring to CocoonGT 2005 Torsten's code, I moved all the JCI listener > configuration into the ReloadingClassLoaderFactory class, that is in charge > to parse the classloader configuration (filled by AvalonUtils class) and > instanciate all the JCI listeners. > The TreeProcessor component is subscribed to the JCI listeners, in order to > reload the component definitions when a file change event is triggered. > The patch provides also a sample : > http://localhost:/blocks/cocoon-core-main-sample/reloading/ > Try to change MyGenerator.java and compile it into > blocks/cocoon-core-sample/cocoon-core-main-sample/target/classes (default > eclipse location); if you need to change the location of the .class folder, > edit the cocoon-core-main-sample sitemap.xmap. > core. > Obviously there are many parts of the code that can be optimized. > The patch has been applied on revision 453682. > NOTE! > 1. I decided to provide the reloading class functionality only for dev mode, > so, in order to get it working, you need to run the cocoon application with > -Dorg.apache.cocoon.mode=dev > 2. The patch depends on a bugfix on Commons JCI > (https://issues.apache.org/jira/browse/SANDBOX-174), so it's necessary to > build jci-core from trunk; the patch will update the cocoon-bootstrap > dependency to jci. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (COCOON-1945) Mounting the same subsitemap multiple time, but with different prefixes, causes an error
Mounting the same subsitemap multiple time, but with different prefixes, causes
an error
Key: COCOON-1945
URL: http://issues.apache.org/jira/browse/COCOON-1945
Project: Cocoon
Issue Type: Bug
Components: * Cocoon Core
Affects Versions: 2.2-dev (Current SVN)
Reporter: Simone Gianni
Suppose I have a subsitemap that generates XML documents, and then i want to
mount it with different prefixes. For example :
The second call with cocoon:// fails with the cause that
"/otherprefix/docs/blabla does not start with /originalprefix/".
This is because in MountNode getProcessor() the TreeProcessors are cached based
on their source (mysubfolder/sitemap.xmap), but not regarding their prefix.
I "solved" this using also the prefix in the cache key :
Index:
src/main/java/org/apache/cocoon/components/treeprocessor/sitemap/MountNode.java
===
---
src/main/java/org/apache/cocoon/components/treeprocessor/sitemap/MountNode.java
(revision 449416)
+++
src/main/java/org/apache/cocoon/components/treeprocessor/sitemap/MountNode.java
(working copy)
@@ -135,13 +135,13 @@
private synchronized TreeProcessor getProcessor(String source, String
prefix)
throws Exception {
-TreeProcessor processor = (TreeProcessor) processors.get(source);
+TreeProcessor processor = (TreeProcessor) processors.get(source + "||"
+ prefix);
if (processor == null) {
processor = this.parentProcessor.createChildProcessor(source,
this.checkReload, prefix);
// Associate to the original source
-processors.put(source, processor);
+processors.put(source + "||" + prefix, processor);
}
return processor;
But this means that two tree processors gets generated to represent the same
sitemap, with only the prefix changing. I'm sure that there is a best way to do
it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Reloading Classloader patch
On 30.10.2006 18:52, Torsten Curdt wrote: > I've already applied it on my machine and can do the commit ...but I > think Maurizio also did another update to it to re-enable the > component reloading as well. Maurizio? > > ...also think it would be really worth having that in ASAP could you apply the patch before we release cocoon-core-2.2M2 - would be great to have it within the release. Trying to get hold of the most recent patch. Could not find it in JIRA. Maurizio, can you send me the link please? I guess it's this one: http://issues.apache.org/jira/browse/COCOON-1929. There was a Jira mail today (including the link ;-) ) as Maurizio updated the patch. Jörg
Re: Reloading Classloader patch
On 10/30/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote: Torsten Curdt wrote: > On 10/15/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote: >> >> Because of a lot of work on our open Jira issues (thanks guys!) you >> might have >> overlooked it: Maurizio provided a patch that enables Torsten's reloading >> classloader in trunk (again)[1]. I think we should apply it so that it >> gets part >> of cocoon-core-2.2M2. I would do it myself but unfortunatly I won't >> have much >> time within the next two weeks. It would be great if someone was >> faster than me >> ... ;-) > > I've already applied it on my machine and can do the commit ...but I > think Maurizio also did another update to it to re-enable the > component reloading as well. Maurizio? > > ...also think it would be really worth having that in ASAP could you apply the patch before we release cocoon-core-2.2M2 - would be great to have it within the release. Trying to get hold of the most recent patch. Could not find it in JIRA. Maurizio, can you send me the link please? cheers -- Torsten
Re: Reloading Classloader patch
Torsten Curdt wrote:
On 10/15/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote:
Because of a lot of work on our open Jira issues (thanks guys!) you
might have
overlooked it: Maurizio provided a patch that enables Torsten's reloading
classloader in trunk (again)[1]. I think we should apply it so that it
gets part
of cocoon-core-2.2M2. I would do it myself but unfortunatly I won't
have much
time within the next two weeks. It would be great if someone was
faster than me
... ;-)
I've already applied it on my machine and can do the commit ...but I
think Maurizio also did another update to it to re-enable the
component reloading as well. Maurizio?
...also think it would be really worth having that in ASAP
could you apply the patch before we release cocoon-core-2.2M2 - would be great
to have it within the release.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [2.2] Deployment and the maven plugin
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
do we establish any contracts? I guess the only thing is the includes in
cocoon.xconf, right?
Yes.
let's implement your solution c). If somebody comes up with something better
before we release the final 2.2, we can change it, otherwise we go the usual
deprecation path.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [GT2006] Missing Presentations
Hi Guys Ross and I managed to update our presentation on the wiki. Enjoy regards Jeremy On 13 Oct 2006, at 14:48, Vadim Gritsenko wrote: Hi, Many presentations are already uploaded to the wiki [1], but some are missing. Any chance of getting them all up? Jeremy, last slide of your presentation on [1] seems to be not finished. Do you have a complete version? :) Gianugo, can you upload your presentation as well? With audio? If not text will do as well :) Thanks, Vadim [1] http://wiki.apache.org/cocoon/GT2006Notes smime.p7s Description: S/MIME cryptographic signature
[jira] Updated: (COCOON-1929) [PATCH] Reloading classloader in Cocoon 2.2
[ http://issues.apache.org/jira/browse/COCOON-1929?page=all ] Maurizio Pillitu updated COCOON-1929: - Attachment: cocoon-r469167.diff Adapted patch after cocoon-core xconf location refactoring Added cocoon-core-sample dependency to cocoon-webapp > [PATCH] Reloading classloader in Cocoon 2.2 > --- > > Key: COCOON-1929 > URL: http://issues.apache.org/jira/browse/COCOON-1929 > Project: Cocoon > Issue Type: Task > Components: * Cocoon Core >Affects Versions: 2.2-dev (Current SVN) >Reporter: Maurizio Pillitu > Attachments: cocoon-r469167.diff, cocoon.diff > > > The attached patch provides a first implementation to enable reloading > classloader configuration into the sitemap, using the sitemap syntax used in > blocks/cocoon-core-sample/cocoon-core-main-sample/src/main/resources/COB-INF/sitemap.xmap. > Referring to CocoonGT 2005 Torsten's code, I moved all the JCI listener > configuration into the ReloadingClassLoaderFactory class, that is in charge > to parse the classloader configuration (filled by AvalonUtils class) and > instanciate all the JCI listeners. > The TreeProcessor component is subscribed to the JCI listeners, in order to > reload the component definitions when a file change event is triggered. > The patch provides also a sample : > http://localhost:/blocks/cocoon-core-main-sample/reloading/ > Try to change MyGenerator.java and compile it into > blocks/cocoon-core-sample/cocoon-core-main-sample/target/classes (default > eclipse location); if you need to change the location of the .class folder, > edit the cocoon-core-main-sample sitemap.xmap. > core. > Obviously there are many parts of the code that can be optimized. > The patch has been applied on revision 453682. > NOTE! > 1. I decided to provide the reloading class functionality only for dev mode, > so, in order to get it working, you need to run the cocoon application with > -Dorg.apache.cocoon.mode=dev > 2. The patch depends on a bugfix on Commons JCI > (https://issues.apache.org/jira/browse/SANDBOX-174), so it's necessary to > build jci-core from trunk; the patch will update the cocoon-bootstrap > dependency to jci. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [SITE] - Contributions to this relase....
Antonio Gallardo said the following on 30/10/06 01:08: Hi folks, In http://cocoon.apache.org/2.1/changes.html we read for each release: Contributors to this release We thank the following people for their contributions to this release. This is a list of all people who participated as committers: [Committer's list] This is a list of other contributors: [contributor's list] I wonder if we can improve the sentence: "This is a list of other contributors:" In particular I don't like the "other contributor" concept. Perhaps it is because I am no a native english speaker. Perhpas we should review the whole section. I really don't care less who contributed what and to which release. IMO we have a (read: ONE) release-independent committer list and, if we so choose, we can have a list of contributors, although we should specify the difference between committers and contributors. Bye, Helma
Re: Cocoon 2.2 build errors for cocoon-dist-samples
Hello Jorg, I'm sorry I did not respond to your question earlier. On Fri, Oct 13, 2006 at 12:42:13PM +0200, Jorg Heymans wrote: > Fred Vos wrote: [...] > > > >[INFO] Generating war > >/path/to/cocoon/trunk/dists/cocoon-dist-samples/target/cocoon-samples.war > >[INFO] > > > >[ERROR] BUILD ERROR > >[INFO] > > > >[INFO] Error assembling WAR > > > >Embedded error: Deployment descriptor: > >/path/to/cocoon/trunk/dists/cocoon-dist-samples/target/cocoon-samples/WEB-INF/web.xml > >does not exist. > > > >This cocoon-dist-samples also couses troubles on another machine where I've > >tried to build cocoon earlier. After an update to the same revision as in > >the > >previous example and a build attempt, I get the following errors: [...] > > I can't reproduce this. What does your maven commandline look like? It was the % mvn -Dmaven.test.skip=true -Dallblocks install command as found in README.txt. After your reply to another mail (see http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=116189430206587&w=2), I tried to build Cocoon again, but had troubles with missing artifacts for some days. Today I did an svn update and built Cocoon 2.2 successfully on both machines. Thank you, Fred
Re: Uploads not working with blocks, proposal for fix
Checking for a class doesn't seem to be a good idea I think we should check for an interface instead. Implemented. Maybe we instead could make the DispatcherServlet less intrusive on the request object by modifying the getServletPath() and getPathInfo () on the incomming request object by a dynamic proxy instead of wrapping it with a request wrapper. Implemented as well. Thank you for the suggestion. Uploads are now working again. Lars -- Lars Trieloff visit http://www.mindquarry.com/
Re: Using Avalon Components in Spring Components
Alexander Klimetschek mindquarry.com> writes: > >> But roles are a different concept than bean-ids > > Why do you think so? > > I am not a Spring expert, but roles have this inheritance concept, and > bean-ids are merely just IDs, aren't they? I might be wrong, but there is no real inheritance concept in the Avalon roles. They just work as IDs. Only with the selector stuff you got some concatenated IDs of type ROLE + "/" + selectionID, but this is no real inheritance. IIRC this was also the reason for refraining from selectors as you can use the concatenated ID as plain ID as well. Jörg
Re: Using Avalon Components in Spring Components
Alexander Klimetschek wrote:
> Carsten Ziegeler schrieb:
>>> But roles are a different concept than bean-ids
>> Why do you think so?
>
> I am not a Spring expert, but roles have this inheritance concept, and
> bean-ids are merely just IDs, aren't they?
>
Ah, yes, the original idea of Avalon included the possibility that there
might be
several implementations for the same role and you can choose at runtime,
like we today have the Generator role with the different available
generator implementations.
Now, the old avalon way to handle this was to lookup a
component(service) selector for the role, and then the real component
from this selector by using a hint(which can be compared to a key).
While this approach is very natural, it has some drawbacks like for
example you have to know whether you're looking up directly a component
or through a component selector etc.
In the end with recent Avalon containers this has been simplified by
either using the role for the component id or, in the case of several
implementations, by using "{role}/{key}" as the component id. And this
is actually how it works today in 2.2 with Spring as well, so you could
connect to the file generator by "o.a.c.g.Generator/file".
HTH
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Using Avalon Components in Spring Components
Carsten Ziegeler schrieb: But roles are a different concept than bean-ids Why do you think so? I am not a Spring expert, but roles have this inheritance concept, and bean-ids are merely just IDs, aren't they? Alex -- Alexander Klimetschek http://www.mindquarry.com
[jira] Commented: (COCOON-1939) Stack overflow when inheriting from block that alread inherits from another one
[ http://issues.apache.org/jira/browse/COCOON-1939?page=comments#action_12445588 ] Alexander Klimetschek commented on COCOON-1939: --- With this fix polymorphic calls no longer work. Eg. (with A <-- super -- B), calling B, then super to A, then calling block:/polymorphic.xml will now call A polymorphic.xml and not the "overridden" one in block B. > Stack overflow when inheriting from block that alread inherits from another > one > --- > > Key: COCOON-1939 > URL: http://issues.apache.org/jira/browse/COCOON-1939 > Project: Cocoon > Issue Type: Bug > Components: - Blocks Framework >Affects Versions: 2.2-dev (Current SVN) >Reporter: Alexander Klimetschek > > There are problems with the following scenario: I have one Block A, another > one B that has A as super-block defined and a third one C that has B as > super-block defined. > The super-relation between B and A works ok, but if you start in C, then > forward to B, which in turn wants to forward to block A (all via the > block:super: protocol), a stack overflow happens. It looks like he always > thinks he is in C, so that block:super: from B will always get to B, thus > creating an endless loop. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: CForms: Upload Repeater
On 26 Oct 2006, at 20:35, Lars Trieloff wrote: But in this case the repeater's add-button should only do an ajax- request and add the new contents behind the already existing repeater-rows. So I think the main problem is making the repeater AJAX-aware. Repeaters are already Ajax-aware. When you click to add a new row, the whole form is submitted, with the repeater's action button id in the hidden 'forms_submit_id' field. AFAICS, currently all form data is sent, but is not validated on the server. Turning on Ajax in the form results in the whole form being submitted via Ajax techniques, a new hidden field 'cocoon- ajax=true' is created, this is detected by the response pipeline to filter and wrap any changes in the BrowserUpdate schema, which is used to inject those changes into the form. This is how it already works. The trouble for my usecase though is that all the form fields are submitted, when not all of it is 'needed' for the event to work properly on the server. I am trying to work out if it is safe to somehow filter out a bunch of fields from this type of submit. Only sending enough data for the action to work. I see no problem with excluding some fields from the submit e.g. for actions or on-value-changed submits, the server just needs to know there are some fields that are not sending data, not sending empty data. Clearly, I can just implement this specially for my one application, but would like to work out if this is something I can safely apply generically to CForms as a whole. Has anyone else got an opinion about this issue ? thanks regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: [2.2] Deployment and the maven plugin
Reinhard Poetz wrote: > > do we establish any contracts? I guess the only thing is the includes in > cocoon.xconf, right? > Yes. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Using Avalon Components in Spring Components
Alexander Klimetschek wrote: > Hi, > > how do you use an Avalon component in a Spring bean? With Spring you are > supposed to inject the dependency via the bean XML config. There you > need a bean-id of the component to inject. What if this component is not > defined as a Spring bean but is an Avalon component? Do I simply use the > role of the component? Yes. > But roles are a different concept than bean-ids Why do you think so? > > In my use case I want to have access to the SourceResolver inside a > Spring bean. Just use the full qualified role (org) Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Deployment and the maven plugin
Carsten Ziegeler wrote: The current version of trunk is feature complete; we only have one item left which we discussed briefly at the GetTogether and a little bit more in the past weeks in this mailing list: removing the need of the maven deploy plugin. There is one major advantage: make the use of maven 2 for building own projects optional. Currently, if you're developing your own Cocoon 2.2 based project, you depend on the specific artifacts (jar files) which you can get from the repository *and* you need the maven 2 deployer plugin to extract specific files from some of the artifacts into some directories in your web application. For example the legacy avalon configuration files and the spring bean configuration files are extracted into the file system. Before discussing a solution for this, let's have a look at what is currently handled by the deploy plugin (please correct me if the information below is wrong): Currently the deployer plugin handles: a) COB-INF/** - these are all application resources of the block like the sitemap, stylesheets etc. b) META-INF/legacy/xconf/** - Block specific avalon config files c) META-INF/legacy/sitemap-additions/** - Block specific avalon config files for sitemap components d) META-INF/spring/** - Block specific spring config files e) META-INF/properties/** - Block specific properties f) META-INF/legacy/cocoon.xconf - The main avalon config file g) WEB-INF/classes/** - Block specific resources for the classpath h) WEB-INF/db/** - Support for the hsqldb block i) META-INF/xpatch/*.xweb - Patches for web.xml I think we can simplify this a little bit: - No block should contain a cocoon.xconf - this file is either created by using an archetype or by directly writing it per hand - so we should drop the support for f) +1 - I see no use for g). We can simply put the resources "directly" into the jar file. +1 - I have no clue for h) and i) right now, but they are not very common use-cases. We had a long discussion about i) at the end of August. Maybe Lezek, who integrated this stuff can give a summary. - The separation between business components and sitemap components in avalon is legacy as well, so I think we can all drop them into "legacy/xconf", but in different configuration files. so you mean dropping META-INF/legacy/sitemap-additions/? No problems with it. - Using "legacy" in the directory structure is fine, but somehow it seems wrong to me that we use "legacy" during development but not in the final web application (there we just use WEB-INF/cocoon/xconf). So we should imho either rename "legacy/xconf" to just "xconf" or put everything in the resulting webapp under "WEB-INF/cocoon/legacy": the avalon configuration files and the initial cocoon.xconf. For the reminder of this mail, I'll use the first solution. This leaves the COB-INF directory and some configuration directories in META-INF. I know that we discussed the directory structure many times but today I think we should put all configuration stuff inside one single directory; I would suggest to put everything in the META-INF/cocoon directory (apart from COB-INF): META-INF/cocoon/xconf/** META-INF/cocoon/spring/** META-INF/cocoon/properties/** Changing this simplifies the deployer as it just has to extract the META-INF/cocoon directory to WEB-INF/cocoon. +1 (maybe somebody can write some script that moves around the directories (again) so that they follow this. So the final part is how to avoid the maven deploy plugin? We recently discussed a possible solution which works using some classloader functionality, some new protocols and so on and does not require any extraction of files during deployment or runtime. Cocoon would be able to serve everything directly from the jar files. While this is a very interesting solution, it has some problems: first and most important: we have to develop it. As we are lacking resources, this might take too much time until we have a final version. So what are our alternatives? I come up with the following three, but perhaps there are more: a) We don't care and require people to use maven2 for their development (or if they don't want to use maven2 they have to figure out how to do it) b) We support other build system, for example by providing an ant task doing the same stuff as the maven deployer c) We implement a simpler solution which works for most people a) is obviously not a good choice; agreed I'm not sure about b) doable but if we rewrite things we can go for a better solution like c) so I personally would focus on c). A solution would be to simply extract the files on startup of Cocoon into the web archive. We already have a place where we can do this (in the setting up of the properties system of Cocoon which is the first activity on startup) and implementing this should be fairly easy. We just have to find a smart way of not extracting everything on
Using Avalon Components in Spring Components
Hi, how do you use an Avalon component in a Spring bean? With Spring you are supposed to inject the dependency via the bean XML config. There you need a bean-id of the component to inject. What if this component is not defined as a Spring bean but is an Avalon component? Do I simply use the role of the component? But roles are a different concept than bean-ids In my use case I want to have access to the SourceResolver inside a Spring bean. Alex -- Alexander Klimetschek http://www.mindquarry.com
Re: [2.2] Deployment and the maven plugin
Joerg Heinicke wrote: > Carsten Ziegeler apache.org> writes: > >> So the final part is how to avoid the maven deploy plugin? We recently >> discussed a possible solution which works using some classloader >> functionality, some new protocols and so on and does not require any >> extraction of files during deployment or runtime. Cocoon would be able >> to serve everything directly from the jar files. >> While this is a very interesting solution, it has some problems: first >> and most important: we have to develop it. As we are lacking resources, >> this might take too much time until we have a final version. > > Was this a discussion on the mailing list? Maybe I just haven't read that > thread > yet. Or was this offline at Cocoon GT or similar? Can you give some links or > summarize it here please? What's needed more than resource:/? > We started the discussion at the GT and then continued/summarized it in this mailing list. I greped some pointers from another discussion on this list: >> >> >> We have some ideas about how to get rid of the need for the deployer >> >> >> in the development cycle. See >> >> >> http://marc.theaimsgroup.com/?t=11601324081&r=1&w=2, >> >> >> http://marc.theaimsgroup.com/?t=11603443062&r=1&w=2 and >> >> >> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=116035392308084&w=2 >> >> >> for that discussion. >> > > >> > > That would indeed be very nice. But how does the reloading work >> then? >> > > Deploy a special jar into cocoon/libs that somehow points to its >> > > original source folders? >> No, we discussed having a configuration file with associations between >> block name and block path, that overrides the blocks in the classpath. >> By using that you can point to your block under development. You need more than the resource procotol as for example you have to scan through the archive for all *.xml files and so on. And the other problem is the "mounting" of the COB-INF directory. Although it's doable (at least currently we think it's doable), it might get a little bit tricky here and there. Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Release roadmap
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Joerg Heinicke wrote:
IMHO this is too fast. We did not receive any feedback on the 2.2 stuff
from any non-committer (only people working with committers). We should
run through some release candidates first, which gives the users the
impression of having something at least testable. If we want to push the
final 2.2 release now and if the current trunk is feature complete, we
should do a RC 1 release (not another milestone) and see how it is
accepted. With M2 soon and final release only one month later I feel
like flying blind ...
+1. let's have some more milestone releases and release candiates before we make
the first official release because all contracts that we establish with an
official release _are_ carved in stone. And as we know it takes a long time to
get rid of badly designed/implemented things again.
Yes, of course I agree with this in general, but personally I doubt that
releasing a 2.2-RCx will give us more feedback (perhaps I'm too
pessimistic on this).
there was at least one user who tried Cocoon 2.2 and asked questions about it on
[EMAIL PROTECTED] Generally I think that documentation will make a big difference,
but well, maybe I'm too optimistic ;-)
And to be honest, my intention of the statement to get 2.2 out this
year, was a try to push things. I guess we all remember that set up a
roadmap for 2.2 some time ago (when was it, at the ApacheCon EU?) to
release milestones of 2.2 every 4 to 6 weeks and the final version in
september/october 2006. So far we managed to release just one milestone...
yes, I know. I planned to push things more in October but some unforseeable
changes in projects forced me to change my schedule. But now, it seems that I
have more time :-)
So, agreeing with your statements from above, let's release a m2 this week.
+1, I can help with the release
(http://cocoon.zones.apache.org/daisy/documentation/g2/1199.html) if you do it
on Thursday and/or Friday. We should also use the new Cocoon staging repository.
Jorg, what's the current status of it?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [2.2] Deployment and the maven plugin
Carsten Ziegeler apache.org> writes: > So the final part is how to avoid the maven deploy plugin? We recently > discussed a possible solution which works using some classloader > functionality, some new protocols and so on and does not require any > extraction of files during deployment or runtime. Cocoon would be able > to serve everything directly from the jar files. > While this is a very interesting solution, it has some problems: first > and most important: we have to develop it. As we are lacking resources, > this might take too much time until we have a final version. Was this a discussion on the mailing list? Maybe I just haven't read that thread yet. Or was this offline at Cocoon GT or similar? Can you give some links or summarize it here please? What's needed more than resource:/? Jörg
[2.2] Deployment and the maven plugin
The current version of trunk is feature complete; we only have one item left which we discussed briefly at the GetTogether and a little bit more in the past weeks in this mailing list: removing the need of the maven deploy plugin. There is one major advantage: make the use of maven 2 for building own projects optional. Currently, if you're developing your own Cocoon 2.2 based project, you depend on the specific artifacts (jar files) which you can get from the repository *and* you need the maven 2 deployer plugin to extract specific files from some of the artifacts into some directories in your web application. For example the legacy avalon configuration files and the spring bean configuration files are extracted into the file system. Before discussing a solution for this, let's have a look at what is currently handled by the deploy plugin (please correct me if the information below is wrong): Currently the deployer plugin handles: a) COB-INF/** - these are all application resources of the block like the sitemap, stylesheets etc. b) META-INF/legacy/xconf/** - Block specific avalon config files c) META-INF/legacy/sitemap-additions/** - Block specific avalon config files for sitemap components d) META-INF/spring/** - Block specific spring config files e) META-INF/properties/** - Block specific properties f) META-INF/legacy/cocoon.xconf - The main avalon config file g) WEB-INF/classes/** - Block specific resources for the classpath h) WEB-INF/db/** - Support for the hsqldb block i) META-INF/xpatch/*.xweb - Patches for web.xml I think we can simplify this a little bit: - No block should contain a cocoon.xconf - this file is either created by using an archetype or by directly writing it per hand - so we should drop the support for f) - I see no use for g). We can simply put the resources "directly" into the jar file. - I have no clue for h) and i) right now, but they are not very common use-cases. - The separation between business components and sitemap components in avalon is legacy as well, so I think we can all drop them into "legacy/xconf", but in different configuration files. - Using "legacy" in the directory structure is fine, but somehow it seems wrong to me that we use "legacy" during development but not in the final web application (there we just use WEB-INF/cocoon/xconf). So we should imho either rename "legacy/xconf" to just "xconf" or put everything in the resulting webapp under "WEB-INF/cocoon/legacy": the avalon configuration files and the initial cocoon.xconf. For the reminder of this mail, I'll use the first solution. This leaves the COB-INF directory and some configuration directories in META-INF. I know that we discussed the directory structure many times but today I think we should put all configuration stuff inside one single directory; I would suggest to put everything in the META-INF/cocoon directory (apart from COB-INF): META-INF/cocoon/xconf/** META-INF/cocoon/spring/** META-INF/cocoon/properties/** Changing this simplifies the deployer as it just has to extract the META-INF/cocoon directory to WEB-INF/cocoon. So the final part is how to avoid the maven deploy plugin? We recently discussed a possible solution which works using some classloader functionality, some new protocols and so on and does not require any extraction of files during deployment or runtime. Cocoon would be able to serve everything directly from the jar files. While this is a very interesting solution, it has some problems: first and most important: we have to develop it. As we are lacking resources, this might take too much time until we have a final version. So what are our alternatives? I come up with the following three, but perhaps there are more: a) We don't care and require people to use maven2 for their development (or if they don't want to use maven2 they have to figure out how to do it) b) We support other build system, for example by providing an ant task doing the same stuff as the maven deployer c) We implement a simpler solution which works for most people a) is obviously not a good choice; I'm not sure about b) so I personally would focus on c). A solution would be to simply extract the files on startup of Cocoon into the web archive. We already have a place where we can do this (in the setting up of the properties system of Cocoon which is the first activity on startup) and implementing this should be fairly easy. We just have to find a smart way of not extracting everything on each startup - but that shouldn't be too hard. The only drawback I see right now is that people that want to run Cocoon unexpanded can't use this approach. But if someone has the opinion to run web apps unexpanded is the better approach, we could *for now* require them to use the maven plugin. We can come up with a better solution with upcomming versions. So, wdyt? -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de htt
