Re: Looking for help in upcoming release
On 12/13/06, Alfred Nathaniel <[EMAIL PROTECTED]> wrote: ...Shall we say that 2.1.10 is the last 1.3 compatible release? Or even that 2.1.9 is already the last one?... If no one's willing to fix 2.1.10 for JDK 1.3, I agree to stop supporting 1.3 officially. But IIRC we've been saying for a long time that not all blocks run under 1.3. -Bertrand
Re: [vote] Releasing from trunk (cocoon-core-2.2.0-M2 and others)
Reinhard Poetz wrote: > > Please cast your votes, whether we want to publish these artifacts to the > official Maven repository and make the release official. The vote is open > for 72 hours. -1 I tried to raise these issues when Reinhard proposed the release plan. The procedure is not being followed. We need to vote on sources, not binaries. We also need to publish those sources as the release. We also need to know which SVN revision corresponds to the release. See the last paragraph of http://www.apache.org/dev/release.html#what I am not just being a stickler for procedure, rather that the PMC has responsibilities. Perhaps follow the release procedure that Carsten already has been using, of course with the additional maven bits. Why is there an "-M2" in the artefact names? If it is a "release" and not a "milestone" then it should be named "2.2.0". -David
Re: [vote] Releasing from trunk (cocoon-core-2.2.0-M2 and others)
On Wed, 13 Dec 2006, Simone Gianni wrote: Date: Wed, 13 Dec 2006 01:32:24 +0100 From: Simone Gianni <[EMAIL PROTECTED]> Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [vote] Releasing from trunk (cocoon-core-2.2.0-M2 and others) Reinhard Poetz wrote: Giacomo Pati wrote: One little fix I have encountered yesterday and fixed it this morning. The deployer-plugin was not applying xpatches in case of war (I thought this was not intended, right?). The deployer plugin hasn't been released this time. I want to work on a second part of release artifacts (deployer, forms, apples, mail) before Xmas, but can't promise it. Hi Reinhard, maybe I can help with the deployer plugin. What should it do now with the current structure? I manage to build 2.2 WARs with my blocks inside without the need of the deployer. IIUC it is still needed when reloading classloader comes in play, but for doing what? It is also able to patch various files in a webapp/block. Ciao -- Otego AG Tel: +41 (0)1 240 00 55 Giacomo Pati, CTO Mobile:+41 (0)79 262 21 04 Apache Software Foundation Member Mailto:[EMAIL PROTECTED] Hohlstrasse 216 Mailto:[EMAIL PROTECTED] CH-8004 Zürichhttp://www.otego.com
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter Max Upload Size
Luca Morandini wrote: So, the chain you propose is (sorted by order of loading): 1) WEB-INF/classes/META-INF/cocoon/properties (block-wide stuff). 2) WEB-INF/classes/cocoon/properties (project-wide stuf). In truth, I don't find the use of "classes" for configuration stuff done outside JARs particularly intuitive... I'd rather stick with WEB-INF/cocoon/properties. One more level is needed which is already in the 2.1 branch (and I thought 2.2). The system property org.apache.cocoon.settings points to the directory where properties can be found. In our environment we never touch stuff inside war or ear files, especially since they might not be exploded.
Re: [vote] Releasing from trunk (cocoon-core-2.2.0-M2 and others)
Reinhard Poetz wrote: > Giacomo Pati wrote: > >> One little fix I have encountered yesterday and fixed it this >> morning. The deployer-plugin was not >> applying xpatches in case of war (I thought >> this was not intended, right?). > > The deployer plugin hasn't been released this time. I want to work on > a second part of release artifacts (deployer, forms, apples, mail) > before Xmas, but can't promise it. > Hi Reinhard, maybe I can help with the deployer plugin. What should it do now with the current structure? I manage to build 2.2 WARs with my blocks inside without the need of the deployer. IIUC it is still needed when reloading classloader comes in play, but for doing what? Simone
Re: Looking for help in upcoming release
On Mon, 2006-12-11 at 14:55 +0100, Carsten Ziegeler wrote: > 7. Make sure you describe your test environment: Platform and JVM, > including version numbers. The following blocks do not compile with Sun JDK 1.3.1_19: -- databases: import javax.sql cannot be resolved -- imageop: import javax.imageio cannot be resolved -- portal: constructor RuntimeException(String, ServiceException) is undefined (twice in StandardPortalApplication.java) NB this is only compilation in Eclipse using the 1.3 rt.jar. I failed to get the 1.3 JVM running on my Ubuntu Dapper Drake due a missing shared library. Is anyone of the committers really still using JDK1.3? If not, shouldn't promise support for something nobody is using. Shall we say that 2.1.10 is the last 1.3 compatible release? Or even that 2.1.9 is already the last one? Cheers, Alfred.
Re: Releasing to http://www.apache.org/dist/cocoon
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Reinhard Poetz wrote:
On a separate issue, as David pointed out some time ago, we have to
make the files available at http://www.apache.org/dist/cocoon/ too.
I'd say the jar files (cocoon-core, cocoon-template-impl,
cocoon-flowscript-impl, cocoon-blocks-fw-impl) only. The pom artifacts
and the archetypes are pretty useless without Maven so I don't think
it makes much sense to put them there.
What's the point of uploading jars to mirrors if nothing usefule can be
done with it?
Right, a Maven 2 user wouldn't need them but for those that use an alternative
build tool, it is the default place where Apache projects put there released
artifacts and where people look for them.
Also, reading http://www.apache.org/dev/release.html, I understand that we have
to put our releases there, haven't we?
It should at least be accompanied with a webapp archive.
would be great
And source code archives.
right, forgot about the source artifacts.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter Max Upload Size
Mark Lundquist wrote: On Dec 12, 2006, at 7:33 AM, Luca Morandini wrote: In truth, I don't find the use of "classes" for configuration stuff done outside JARs particularly intuitive... +1 Vadim
Re: Crowded cocoon/tags directory
Marc Portier wrote: Reinhard Poetz wrote: Since we are releasing artifacts separatly, the cocoon/tags directory in our SVN gets crowded and I guess that in a couple of months we will have hundrets of subdirectories there. We should find some way to reduce this number. My first idea was using the year and the quarter as subdirectories: cocoon/tags/2006-Q1 cocoon/tags/2006-Q2 etc. This way the number of subdirectories should grow in smaller pace. WDOT? in my experience people don't know/remember the date/quarter of a certain release, so would be hindered in finding back what they are looking for the subdir hierarchy should be build up of stuff they can be normally expected to know, eg 1- major/minor/patch 2- or the various artifact-names (given those are causing this, I'ld go for option 2) +1 to option 2. Vadim
Re: Releasing to http://www.apache.org/dist/cocoon
Reinhard Poetz wrote: Reinhard Poetz wrote: On a separate issue, as David pointed out some time ago, we have to make the files available at http://www.apache.org/dist/cocoon/ too. I'd say the jar files (cocoon-core, cocoon-template-impl, cocoon-flowscript-impl, cocoon-blocks-fw-impl) only. The pom artifacts and the archetypes are pretty useless without Maven so I don't think it makes much sense to put them there. What's the point of uploading jars to mirrors if nothing usefule can be done with it? It should at least be accompanied with a webapp archive. And source code archives. Vadim
Re: [RT] Accessing environment information in 2.2
Hi Carsten, maybe I'm missing something, but isn't there a ProcessInfoProvider, with which you can access request, response, servlet context and object model (and from there all the rest)? It ends in a thread local anyway, since uses the environment stack Daniel told about. If this is not the right class, then maybe we should revise the javadocs, since the ContextHelper (which was used in 2.1 to access all other stuff from a Contextualizable component) is deprecated and the ProcessInfoProvider is suggested instead. Simone Carsten Ziegeler wrote: > During development you sometimes face the problem that you need access > to specific information, like the current request object (or its > parameters), the Spring application context, the servlet context etc. > > In an ideal world where everything is a component, this is no issue as > the container provides a way for this. But as we all know, the world is > not ideal and this means, you sometimes need access to those objects > when you don't have anything else to use. > > So, I think we need a way to provide those information. The best choice > seems to be to use thread local variables. > I think we need a way to access the servlet context, the original http > request/response object and the current application context. (If you > have access to the current request object, you can get the application > context from the request). > > The provide access to those things from everywhere the best way is to > have a general servlet filter putting the information into thread local > variables and cleaning them after the request is finished. > > This approach has the drawback that users have to put this filter into > their web.xml. So I think we should make this a little bit more user > friendly and add the logic/code of this filter to all servlets we > provide by default (which means the servlet performs the code). So as > long as users are using our servlets, they get the information "for > free". In addition, we provide the servlet filter for users who might > want to use different servlets but need the same information. > > WDYT? >
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter Max Upload Size
On Dec 12, 2006, at 7:33 AM, Luca Morandini wrote: In truth, I don't find the use of "classes" for configuration stuff done outside JARs particularly intuitive... +1 —ml—
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter Max Upload Size
Carsten Ziegeler wrote: Luca Morandini schrieb: Carsten Ziegeler wrote: Luca Morandini wrote: This was neatly solved by the use of WEB-INF/cocoon/properties, since it was loaded after the "classpath:*" chain. Yes, you're right. Hmm, perhaps we should load properties from WEB-INF/classes last. I'll have a look at that as well. Last ? Hmm... I'm not sure I got you point. Yepp, the properties system works in the way that the last definition wins. And this means that project-wide stuff has to be loaded last. So, the chain you propose is (sorted by order of loading): 1) WEB-INF/classes/META-INF/cocoon/properties (block-wide stuff). 2) WEB-INF/classes/cocoon/properties (project-wide stuf). In truth, I don't find the use of "classes" for configuration stuff done outside JARs particularly intuitive... I'd rather stick with WEB-INF/cocoon/properties. Regards, Luca Morandini www.lucamorandini.it
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter Max Upload Size
Giacomo Pati wrote: Carsten Ziegeler wrote: Luca Morandini wrote: This was neatly solved by the use of WEB-INF/cocoon/properties, since it was loaded after the "classpath:*" chain. Yes, you're right. Hmm, perhaps we should load properties from WEB-INF/classes last. I'll have a look at that as well. Luca is absolutely right! WEB-INF/classes should be the last resort where one ultimatively can overwrite properties (same should be true for WEB-INF/classes/META-INF/cocoon/spring/.) Just to be absolutely clear: In my eyes WEB-INF/classes/META-INF/cocoon/properties should be used for block-wide property or cocoon defaults, and WEB-INF/cocoon/properties for project-wide properties. I suppose most users would just put their properties under WEB-INF/cocoon and update the *.properties under WEB-INF/classes/META-INF only at their peril (a block update, or the adding of a block that happens to have a properties file starting with a greater letter of the alphabet may ruin their day). By the way, let's suppose I use block fooblock, which has a nice META-INF/cocoon/properties/fooblock.properties file tucked under its JAR: is fooblock.properties unzipped by default under WEB-INF/classes/META-INF so I can modify its properties ? If so, what happens when there is another version of fooblock ? Is the properties file overwritten at installation (deploy) time ? Sorry if the last questions seem so silly, but... "better safe than sorry" ;) Regards, Luca Morandini www.lucamorandini.it
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter Max Upload Size
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carsten Ziegeler wrote: > Luca Morandini wrote: >> Remember to update the comments in the source code of >> SettingsBeanFactoryPostProcessor.java then, because they still state >> that WEB-INF/cocoon/properties is supported in the fall-back chain of >> properties loading. >> > Yepp, thanks for the info - I'll take care of it in the next days. > > >> One issue, though: since the property loading mechanism uses >> "classpath:°" protocol, property files are read in alphabetical order, >> which means I might have my per-project properties ruined by the >> addition of a block, unless I call them .properties. >> >> This was neatly solved by the use of WEB-INF/cocoon/properties, since it >> was loaded after the "classpath:*" chain. >> > Yes, you're right. Hmm, perhaps we should load properties from > WEB-INF/classes last. I'll have a look at that as well. Luca is absolutely right! WEB-INF/classes should be the last resort where one ultimatively can overwrite properties (same should be true for WEB-INF/classes/META-INF/cocoon/spring/.) Ciao - -- Otego AG Tel: +41 (0)1 240 00 55 Giacomo Pati, CTO Mobile:+41 (0)79 262 21 04 Apache Software Foundation Member Mailto:[EMAIL PROTECTED] Hohlstrasse 216 Mailto:[EMAIL PROTECTED] CH-8004 Zuerich http://www.otego.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFfsUNLNdJvZjjVZARAnF3AJ9dTgMEHqAYmj6vICLU0Q2b+ZfzVACfZvXH pgNnuygo9oDrThYvuF7GYPg= =Qdgc -END PGP SIGNATURE-
Re: Crowded cocoon/tags directory
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Reinhard Poetz wrote:
> Giacomo Pati wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>>
>>
>> Marc Portier wrote:
>>> Reinhard Poetz wrote:
Since we are releasing artifacts separatly, the cocoon/tags
directory in
our SVN gets crowded and I guess that in a couple of months we will
have
hundrets of subdirectories there. We should find some way to reduce
this
number.
My first idea was using the year and the quarter as subdirectories:
cocoon/tags/2006-Q1
cocoon/tags/2006-Q2
etc.
This way the number of subdirectories should grow in smaller pace.
WDOT?
>>> in my experience people don't know/remember the date/quarter of a
>>> certain release, so would be hindered in finding back what they are
>>> looking for
>>>
>>> the subdir hierarchy should be build up of stuff they can be normally
>>> expected to know, eg
>>> 1- major/minor/patch
>>> 2- or the various artifact-names
>>>
>>> (given those are causing this, I'ld go for option 2)
>>
>> Me too. Kinda Maven repository structure?
>>
>> artifactId/version/ ?
>
> The problem with it is, that we have to configure it in pom.xml for each
> module, the date solution would have worked for all.
>
> Maybe something like this
>
>
> maven-release-plugin
> 2.0-beta-4
>
>
> https://svn.apache.org/repos/asf/cocoon/tags/${project.artifactId}
If this works (and I cannot see why it shouldn't) even
https://svn.apache.org/repos/asf/cocoon/tags/${project.artifactId}/${project.version}
should work.
>
>
>
>
> is resolved correctly and automatically creates missing directories. I
> will give it a try next time.
>
- --
Otego AG Tel: +41 (0)1 240 00 55
Giacomo Pati, CTO Mobile:+41 (0)79 262 21 04
Apache Software Foundation Member Mailto:[EMAIL PROTECTED]
Hohlstrasse 216 Mailto:[EMAIL PROTECTED]
CH-8004 Zuerich http://www.otego.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFFfsSsLNdJvZjjVZARAm4EAJsGm0ShMcVgO3ajhAx4LFRZdxqFYwCdFEkR
+zjuVTFXofnm03UnkBjbJBM=
=re/4
-END PGP SIGNATURE-
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter Max Upload Size
Luca Morandini schrieb: > Carsten Ziegeler wrote: >> Luca Morandini wrote: >> >>> One issue, though: since the property loading mechanism uses >>> "classpath:°" protocol, property files are read in alphabetical order, >>> which means I might have my per-project properties ruined by the >>> addition of a block, unless I call them .properties. >>> >>> This was neatly solved by the use of WEB-INF/cocoon/properties, since it >>> was loaded after the "classpath:*" chain. >>> >> Yes, you're right. Hmm, perhaps we should load properties from >> WEB-INF/classes last. I'll have a look at that as well. > > Last ? Hmm... I'm not sure I got you point. > Anyway, what I meant is that I'd like to have a way to load project-wide > properties that cannot be overridden by block-wide ones. > Yepp, the properties system works in the way that the last definition wins. And this means that project-wide stuff has to be loaded last. Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter Max Upload Size
Carsten Ziegeler wrote: Luca Morandini wrote: One issue, though: since the property loading mechanism uses "classpath:°" protocol, property files are read in alphabetical order, which means I might have my per-project properties ruined by the addition of a block, unless I call them .properties. This was neatly solved by the use of WEB-INF/cocoon/properties, since it was loaded after the "classpath:*" chain. Yes, you're right. Hmm, perhaps we should load properties from WEB-INF/classes last. I'll have a look at that as well. Last ? Hmm... I'm not sure I got you point. Anyway, what I meant is that I'd like to have a way to load project-wide properties that cannot be overridden by block-wide ones. Regards, Luca Morandini www.lucamorandini.it
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter Max Upload Size
Luca Morandini wrote: > > Remember to update the comments in the source code of > SettingsBeanFactoryPostProcessor.java then, because they still state > that WEB-INF/cocoon/properties is supported in the fall-back chain of > properties loading. > Yepp, thanks for the info - I'll take care of it in the next days. > One issue, though: since the property loading mechanism uses > "classpath:°" protocol, property files are read in alphabetical order, > which means I might have my per-project properties ruined by the > addition of a block, unless I call them .properties. > > This was neatly solved by the use of WEB-INF/cocoon/properties, since it > was loaded after the "classpath:*" chain. > Yes, you're right. Hmm, perhaps we should load properties from WEB-INF/classes last. I'll have a look at that as well. Thanks Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[jira] Commented: (COCOON-1437) Htmlarea lost contents
[
http://issues.apache.org/jira/browse/COCOON-1437?page=comments#action_12457683
]
Jeroen Reijn commented on COCOON-1437:
--
This seems to be fixed cocoon 2.1.10. I've tried it with a small webapp and it
seems to work.
> Htmlarea lost contents
> --
>
> Key: COCOON-1437
> URL: http://issues.apache.org/jira/browse/COCOON-1437
> Project: Cocoon
> Issue Type: Bug
> Components: Blocks: Forms
>Affects Versions: 2.2-dev (Current SVN)
> Environment: Operating System: All
> Platform: All
>Reporter: Gioni Gennai
> Assigned To: Cocoon Developers Team
>
> In my project I use htmlarea with cform. I customize the html area calling a
> js
> function with onload event
>
> function initHtmlArea(elementId) {
>// inititalize editor
>editor = new HTMLArea(elementId);
>// retrive the config object
>var config = editor.config;
>// do custom configuration
>config.toolbar = [
>[
>"bold", "italic", "underline", "separator",
>"undo", "redo", "separator",
> "justifyleft", "justifycenter", "justifyright", "separator",
> "insertorderedlist", "insertunorderedlist", "outdent",
> "indent"
>]
>]; HTMLArea.replace(elementId, config);
> }
> Where descrizione is the htmlarea's id
>
>
>
> All seems to work, I have my htmlarea show in the form.
> The problem is that in the form I have a selection list, with the
> submit-on-change="true"/>, that I use to populate another selection list on
> the
> form. When i change the selection, in the first selection list, the second is
> populate as I expect, but the text present in the htmlarea is lost.
--
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: Crowded cocoon/tags directory
Giacomo Pati wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marc Portier wrote:
Reinhard Poetz wrote:
Since we are releasing artifacts separatly, the cocoon/tags directory in
our SVN gets crowded and I guess that in a couple of months we will have
hundrets of subdirectories there. We should find some way to reduce this
number.
My first idea was using the year and the quarter as subdirectories:
cocoon/tags/2006-Q1
cocoon/tags/2006-Q2
etc.
This way the number of subdirectories should grow in smaller pace. WDOT?
in my experience people don't know/remember the date/quarter of a
certain release, so would be hindered in finding back what they are
looking for
the subdir hierarchy should be build up of stuff they can be normally
expected to know, eg
1- major/minor/patch
2- or the various artifact-names
(given those are causing this, I'ld go for option 2)
Me too. Kinda Maven repository structure?
artifactId/version/ ?
The problem with it is, that we have to configure it in pom.xml for each module,
the date solution would have worked for all.
Maybe something like this
maven-release-plugin
2.0-beta-4
https://svn.apache.org/repos/asf/cocoon/tags/${project.artifactId}
is resolved correctly and automatically creates missing directories. I will give
it a try next time.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: [vote] Releasing from trunk (cocoon-core-2.2.0-M2 and others)
Giacomo Pati wrote:
One little fix I have encountered yesterday and fixed it this morning. The
deployer-plugin was not
applying xpatches in case of war (I thought this was
not intended, right?).
The deployer plugin hasn't been released this time. I want to work on a second
part of release artifacts (deployer, forms, apples, mail) before Xmas, but can't
promise it.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter Max Upload Size
Carsten Ziegeler wrote: Giacomo Pati wrote: This raises the question if we need this? I think we should readd the support for reading properties from WEB-INF/cocoon/properties. IIRC we mentioned putting those into WEB-INF/classes/META-INF/cocoon/properties Yes, you're absolutely right! This brings back my memory :) So, there is no need for WEB-INF/cocoon/properties. Remember to update the comments in the source code of SettingsBeanFactoryPostProcessor.java then, because they still state that WEB-INF/cocoon/properties is supported in the fall-back chain of properties loading. One issue, though: since the property loading mechanism uses "classpath:°" protocol, property files are read in alphabetical order, which means I might have my per-project properties ruined by the addition of a block, unless I call them .properties. This was neatly solved by the use of WEB-INF/cocoon/properties, since it was loaded after the "classpath:*" chain. Regards, Luca Morandini www.lucamorandini.it
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter Max Upload Size
Giacomo Pati wrote: > >> This raises the question if we need this? I think we should readd the >> support for reading properties from WEB-INF/cocoon/properties. > > IIRC we mentioned putting those into > > WEB-INF/classes/META-INF/cocoon/properties > Yes, you're absolutely right! This brings back my memory :) So, there is no need for WEB-INF/cocoon/properties. Thanks! Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Crowded cocoon/tags directory
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marc Portier wrote: > > Reinhard Poetz wrote: >> Since we are releasing artifacts separatly, the cocoon/tags directory in >> our SVN gets crowded and I guess that in a couple of months we will have >> hundrets of subdirectories there. We should find some way to reduce this >> number. >> >> My first idea was using the year and the quarter as subdirectories: >> >> cocoon/tags/2006-Q1 >> cocoon/tags/2006-Q2 >> etc. >> >> This way the number of subdirectories should grow in smaller pace. WDOT? >> > > in my experience people don't know/remember the date/quarter of a > certain release, so would be hindered in finding back what they are > looking for > > the subdir hierarchy should be build up of stuff they can be normally > expected to know, eg > 1- major/minor/patch > 2- or the various artifact-names > > (given those are causing this, I'ld go for option 2) Me too. Kinda Maven repository structure? artifactId/version/ ? Ciao - -- Otego AG Tel: +41 (0)1 240 00 55 Giacomo Pati, CTO Mobile:+41 (0)79 262 21 04 Apache Software Foundation Member Mailto:[EMAIL PROTECTED] Hohlstrasse 216 Mailto:[EMAIL PROTECTED] CH-8004 Zuerich http://www.otego.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFfoK3LNdJvZjjVZARAtZ/AJ9+OP/sENibrWBfENuBBEsOECIItgCcCxML trVw8OaDMcIi6qUEVIt1p18= =olUt -END PGP SIGNATURE-
Re: Cocoon Properties, Re: Cocoon 2.2 Samples Setting MultipartFilter Max Upload Size
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carsten Ziegeler wrote: > Vadim Gritsenko wrote: >> Carsten Ziegeler wrote: >>> Have a look at the core.properties file in the cocoon-core module. Just >>> put a properties file with the appropriate configuration into >>> WEB-INF/cocoon/properties. This should work. >> Carsten, >> >> Regarding loading of properties from WEB-INF - can you point out where this >> is >> done? In the code I can only see loading from META-INF; and I can not >> confirm >> that loading from WEB-INF is working. >> > You're right - it's gone :( > > This raises the question if we need this? I think we should readd the > support for reading properties from WEB-INF/cocoon/properties. IIRC we mentioned putting those into WEB-INF/classes/META-INF/cocoon/properties Ciao - -- Otego AG Tel: +41 (0)1 240 00 55 Giacomo Pati, CTO Mobile:+41 (0)79 262 21 04 Apache Software Foundation Member Mailto:[EMAIL PROTECTED] Hohlstrasse 216 Mailto:[EMAIL PROTECTED] CH-8004 Zuerich http://www.otego.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFfoHlLNdJvZjjVZARAjBzAKDR7gLtREAykC1UfdCEDCkzsQjqTgCeLw++ SrMExCpuPx1fpUGTejD9yhY= =C7y3 -END PGP SIGNATURE-
Re: [vote] Releasing from trunk (cocoon-core-2.2.0-M2 and others)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhard Poetz wrote: > > I have compiled a release of following artifacts > > - org.apache.cocoon:cocoon:2 > - org.apache.cocoon:cocoon-core-modules:2 > - org.apache.cocoon:cocoon-core:1.0.0-M2 > - org.apache.cocoon:cocoon-blocks-modules:2 > - org.apache.cocoon:cocoon-template:2 > - org.apache.cocoon:cocoon-flowscript:1 > - org.apache.cocoon:cocoon-template-impl:1.0.0-M2 > - org.apache.cocoon:cocoon-flowscript-impl:1.0.0-M1 > - org.apache.cocoon:cocoon-blocks-fw:1 > - org.apache.cocoon:cocoon-blocks-fw-impl:1.0.0-M1 > - org.apache.cocoon:cocoon-tools-modules:2 > - org.apache.cocoon:cocoon-archetypes:2 > - org.apache.cocoon:cocoon-22-archetype-block:1.0.0-M4 > - org.apache.cocoon:cocoon-22-archetype-webapp:1.0.0-M1 I couldn't test the specific releases but most of the modules above are in use by me for the current project (and if I would have found an issue I'd have fixed it right away). One little fix I have encountered yesterday and fixed it this morning. The deployer-plugin was not applying xpatches in case of war (I thought this was not intended, right?). Ciao - -- Otego AG Tel: +41 (0)1 240 00 55 Giacomo Pati, CTO Mobile:+41 (0)79 262 21 04 Apache Software Foundation Member Mailto:[EMAIL PROTECTED] Hohlstrasse 216 Mailto:[EMAIL PROTECTED] CH-8004 Zuerich http://www.otego.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFfoGfLNdJvZjjVZARAjdUAKCV26m7v+I5cFOC0ErdaP4EBLQppACfQVDL IVsMpSGHa7di5UgP9ZLfLDk= =/Qxq -END PGP SIGNATURE-
Re: Crowded cocoon/tags directory
Reinhard Poetz wrote: > > Since we are releasing artifacts separatly, the cocoon/tags directory in > our SVN gets crowded and I guess that in a couple of months we will have > hundrets of subdirectories there. We should find some way to reduce this > number. > > My first idea was using the year and the quarter as subdirectories: > > cocoon/tags/2006-Q1 > cocoon/tags/2006-Q2 > etc. > > This way the number of subdirectories should grow in smaller pace. WDOT? > in my experience people don't know/remember the date/quarter of a certain release, so would be hindered in finding back what they are looking for the subdir hierarchy should be build up of stuff they can be normally expected to know, eg 1- major/minor/patch 2- or the various artifact-names (given those are causing this, I'ld go for option 2) regards, -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Releasing to http://www.apache.org/dist/cocoon
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Reinhard Poetz wrote:
On a separate issue, as David pointed out some time ago, we have to make
the files available at http://www.apache.org/dist/cocoon/ too. This also
requires signing the files with PGP. Can somebody take care of this please?
Any volunteers for this? IIUC, it shouldn't be difficult for somebody who has a
signed PGP key and it is only 4 files that need to be released.
I can take care of this - which files need to be released there?
thanks :-)
I'd say the jar files (cocoon-core, cocoon-template-impl,
cocoon-flowscript-impl, cocoon-blocks-fw-impl) only. The pom artifacts and the
archetypes are pretty useless without Maven so I don't think it makes much sense
to put them there.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
