Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
Can you give a concrete example? E.g. the DirectoryGenerator which has
already been springfied only exisits as a Spring bean, at least AFAICS.
The DirectoryGenerator is still an Avalon component besides being a
Spring bean. Take a look in its
Leszek Gawron wrote:
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
Can you give a concrete example? E.g. the DirectoryGenerator which
has already been springfied only exisits as a Spring bean, at least
AFAICS.
The DirectoryGenerator is still an Avalon component
Vadim Gritsenko wrote:
Leszek Gawron wrote:
Grzegorz Kossakowski wrote:
Leszek Gawron pisze:
SimpleFormInstanceExtractionTransformer.java and
SimpleFormTransformer.java are probably better placed in
cocoon-pipeline-components than cocoon-core. Can I move them ?
What's their use?
At
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Leszek Gawron wrote:
Grzegorz Kossakowski wrote:
Leszek Gawron pisze:
SimpleFormInstanceExtractionTransformer.java and
SimpleFormTransformer.java are probably better placed in
cocoon-pipeline-components than cocoon-core
Leszek Gawron wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Leszek Gawron wrote:
Grzegorz Kossakowski wrote:
Leszek Gawron pisze:
SimpleFormInstanceExtractionTransformer.java and
SimpleFormTransformer.java are probably better placed in
cocoon-pipeline-components than cocoon-core. Can
Leszek Gawron wrote:
Reinhard Poetz wrote:
It's Vadim who's worried about more modules. I'm just trying to find
alternatives ...
In my opinion that's the way to go but there is still the problem:
What can you do if you only need one of these components?
As you say, the expected behaviour
Joerg Heinicke wrote:
On 09.10.2007 9:44 Uhr, Reinhard Poetz wrote:
At CocoonGT we had some sort of agreement to create optional modules
Please, no more modules. It is bad already as it is - adding *more*
modules only makes it worse. What's wrong with simply deprecating
them, with placing
Vadim Gritsenko wrote:
Grzegorz Kossakowski wrote:
After taking quick look on this problem I saw that JXTemplateGenerator
is broken by the fact that it
implements (indirectly, by extending AbstractXMLProducer) Recycable
interface. Implementing this
interface makes JXTemplateGenerator handled
Ross Gardler wrote:
On 08/10/2007, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Automated build for cocoon-docs FAILED
Am I correct in thinking Cocoon does not use the Forrest built docs anymore?
Can we (Forrest) remove this automated build or do we need to fix this?
(Note the fix is easy, I
Grzegorz Kossakowski wrote:
Leszek Gawron pisze:
Caused by: org.apache.cocoon.CascadingIOException: If you see this
exception you probably called
Source.getInputStream even though the source reported proper validity.
The only way to solve this
is to implement a resource heavy version of
Leszek Gawron wrote:
Grzegorz Kossakowski wrote:
Leszek Gawron pisze:
SimpleFormInstanceExtractionTransformer.java and
SimpleFormTransformer.java are probably better placed in
cocoon-pipeline-components than cocoon-core. Can I move them ?
What's their use?
At CocoonGT we had some sort of
Daniel Fagerstrom wrote:
Leszek Gawron skrev:
There is a lot of .xconf files in core. I would like to start
converting them into spring beans
Great!
but question is: do we want that for 2.2?
Yes.
It is a huge job to convert everything, so the only realistic option is
to do it
Lars Huttar wrote:
On 9/28/2007 9:26 AM, Reinhard Poetz wrote:
While I was creating all the release artifacts of Cocoon 2.2RC2 I also
published our 2.2 docs. See http://cocoon.apache.org/2.2/
I have to say that I'm really proud of seeing this long-term effort
finally materializing
hepabolu wrote:
On all of them. I just tested the main page, the one with the picture of
the graphic of the architecture (Spring framework) and some others I
can't remember.
I added the missing .htaccess file (though I still find it strange that it
worked for me yesterday ...)
Thanks for
Carsten Ziegeler wrote:
I think we should move the root.pom into a sub directory like parent
or pom. This will make updates and releases of the root pom easier as
for these opperations only a single directory with a single file needs
to be checked out.
If noone objects, I'll change this.
+1
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
publish new 'pmc site'
Added:
cocoon/site/site/1164_1_1.html (with props)
cocoon/site/site/1178_1_1.html (with props)
...
Just wondering - do we have any of old URLs preserved? Or htaccess
redirects for old URLs?
no, unfortunatly
Carsten Ziegeler wrote:
Anyone arriving tomorrow in the moring at Fiumicino?
I will be arriving at 8:20 am.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software
hepabolu wrote:
Reinhard Poetz said the following on 28/9/07 16:26:
While I was creating all the release artifacts of Cocoon 2.2RC2 I also
published our 2.2 docs. See http://cocoon.apache.org/2.2/
I have to say that I'm really proud of seeing this long-term effort
finally materializing
Lars Huttar wrote:
On 9/28/2007 10:41 AM, Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
While I was creating all the release artifacts of Cocoon 2.2RC2 I
also published our 2.2 docs. See http://cocoon.apache.org/2.2/
I have to say that I'm really proud of seeing
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
If you want to test it, change the stylesheet, then install the Daisy
export plugin into your local Maven repository by running 'mvn install',
Hmm this step failed with
[INFO
Grzegorz Kossakowski wrote:
Grzegorz Kossakowski pisze:
Hi,
You have probably noticed that I'm doing some documentation work. I wanted to
have better
(meaningful) URLs for documents I create and recalled that Daisy has support
for this. Then I found
that we use BookDefinition instead of
While I was creating all the release artifacts of Cocoon 2.2RC2 I also published
our 2.2 docs. See http://cocoon.apache.org/2.2/
I have to say that I'm really proud of seeing this long-term effort finally
materializing :-) Thanks to all the involved helping hands!
The only missing part is
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
While I was creating all the release artifacts of Cocoon 2.2RC2 I also
published our 2.2 docs. See http://cocoon.apache.org/2.2/
I have to say that I'm really proud of seeing this long-term effort
finally materializing :-) Thanks to all
Grzegorz Kossakowski wrote:
[EMAIL PROTECTED] pisze:
Author: giacomo
Date: Fri Sep 28 04:13:23 2007
New Revision: 580303
URL: http://svn.apache.org/viewvc?rev=580303view=rev
Log:
branch Avalon based CForm blocks
Added:
cocoon/branches/cocoon-2.2/cocoon-forms-avalon-based/
- copied
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
All release artifacts and their docs have been created. This means that
the code freeze is over and our SVN is happily awaiting your commits again!
Currently trunk doesn't build because the parent pom references are not
set correctly. I
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Thanks Reinhard for taking care!
It's nice that we will be able to start creating buzz about Cocoon 2.2
shortly! :-)
;-)
btw, I've forgotten to mention that I'm waiting for the solution(s
Vadim Gritsenko wrote:
I'm getting same exception on trunk (but in 39 seconds! wooo-hooo!) - is
it expected? Should I just wait for end of release process?
yes, please. By the end of the day (MET) everything should be fixed again.
--
Reinhard Pötz Independent Consultant, Trainer
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Grzegorz Kossakowski wrote:
[EMAIL PROTECTED] pisze:
The formatting of a nice message for this event hasn't been
implemented yet, so I'll just put an XML dump of the event here.
ns:collectionCreated xmlns:ns=http://outerx.org/daisy/1.0
As nobody commented on this I'll going to branch cocoon-form before I commit
the sprinified CForms,
as soon as Reinhard has finished releasing. Do I have to branch each block
(cocoon-forms-impl and
cocoon-forms-sample) individually or is branching their upper directory
(cocoon-forms) enough?
Giacomo Pati wrote:
Giacomo Pati wrote:
Giacomo Pati wrote:
Hi all
If there is nobody working on the subject I'll spend a few hours on doing that.
I'm done with it :-) but need an advice on a special case:
There are some special 'custom' stuff which had been referenced in form
Giacomo Pati wrote:
Reinhard Poetz wrote:
As nobody commented on this I'll going to branch cocoon-form before I
commit the sprinified CForms,
as soon as Reinhard has finished releasing. Do I have to branch each
block (cocoon-forms-impl and
cocoon-forms-sample) individually or is branching
Felix Knecht wrote:
Do you know why we have these extra directories at all instead of flat
block directory?
Just my 2 cents
Why do some blocks have 'super' poms including api/impl/sample and
others don't?
I've removed those extra POM level from all blocks that I have to release
because
All release artifacts and their docs have been created. This means that the code
freeze is over and our SVN is happily awaiting your commits again!
Currently trunk doesn't build because the parent pom references are not set
correctly. I will take care for this tommorrow morning if nobody
Reinhard Poetz wrote:
All release artifacts and their docs have been created. This means that
the code freeze is over and our SVN is happily awaiting your commits again!
Currently trunk doesn't build because the parent pom references are not
set correctly. I will take care
Reinhard Poetz wrote:
Reinhard Poetz wrote:
All release artifacts and their docs have been created. This means
that the code freeze is over and our SVN is happily awaiting your
commits again!
Currently trunk doesn't build because the parent pom references are
not set correctly. I
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Could somebody help me with an additional script which recursivly
scans for the download scripts, sets the x attribute on the file
and executes it then?
Sure; what's the script name / name pattern
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
thanks. The command seems to work but I have a problem to execute the
script because David is the owner and neither chown nor chmod are
permitted using my account:
/x1/www/cocoon.apache.org/2.2/core-modules/pipeline-api/1.0/apidocs
ls -lsa
total
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
But now I run into another problem: When I use the find/xargs command,
the working directory is the directory where I entered this command
and not the directory where the create-apidocs.sh script is located.
Is there a way to set the working
Joerg Heinicke wrote:
On 25.09.2007 15:45 Uhr, Vadim Gritsenko wrote:
Our problem is not minimum Java requirement for Cocoon 2.2. The
problem is release time lines. [..] Java requirements? Nah, that's
peanuts...
Thanks, you hit the nail. When was the vote? 1 year ago?
Despite being still
Grzegorz Kossakowski wrote:
[EMAIL PROTECTED] pisze:
The formatting of a nice message for this event hasn't been implemented yet, so
I'll just put an XML dump of the event here.
ns:collectionCreated xmlns:ns=http://outerx.org/daisy/1.0;
ns:newCollection
ns:collection
Giacomo Pati wrote:
Grzegorz Kossakowski wrote:
Any chance to reproduce this behaviour with my little sample? I tried to modify
it so empty List is
passed but everything works fine. Is your list a standard Java implementation
like ArrayList?
Isolating the problem that anyone can test on its
Grzegorz Kossakowski wrote:
Hi,
Any idea why there is no link to databases block on this[1] page?
[1] http://cocoon.zones.apache.org/dev-docs/2.2/blocks/
I guess that there is no particular reason, just an oversight.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Grzegorz Kossakowski wrote:
Hi,
Any idea why there is no link to databases block on this[1] page?
[1] http://cocoon.zones.apache.org/dev-docs/2.2/blocks/
I guess that there is no particular reason, just an oversight.
So how this can
Reinhard Poetz wrote:
Reinhard Poetz wrote:
Reinhard Poetz wrote:
As you probably have noticed, I've started with the release of the
POM modules. So far this shouldn't have affected you except a short
period when trunk didn't build.
I'm going to continue with the jar modules in core
As you probably have noticed, I've started with the release of the POM modules.
So far this shouldn't have affected you except a short period when trunk didn't
build.
I'm going to continue with the jar modules in core and blocks which means that I
ask you not to commit to any of the affected
I also use this release to publish our docs. I wonder now whether I should add
the Javadocs to our docs or not. For the spring-configurator and and
configuration-api I've added them because they are subprojects but I'm not sure
if it is the best idea to add the javadocs of our core modules
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
I also use this release to publish our docs. I wonder now whether I
should add the Javadocs to our docs or not. For the
spring-configurator and and configuration-api I've added them because
they are subprojects but I'm not sure if it is the best
Reinhard Poetz wrote:
Reinhard Poetz wrote:
As you probably have noticed, I've started with the release of the POM
modules. So far this shouldn't have affected you except a short period
when trunk didn't build.
I'm going to continue with the jar modules in core and blocks which
means that I
Reinhard Poetz wrote:
As you probably have noticed, I've started with the release of the POM
modules. So far this shouldn't have affected you except a short period
when trunk didn't build.
I'm going to continue with the jar modules in core and blocks which
means that I ask you not to commit
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Could somebody help me with an additional script which recursivly
scans for the download scripts, sets the x attribute on the file and
executes it then?
Sure; what's the script name / name pattern?
It will be located in apidocs/create-apidocs.sh
Carsten Ziegeler wrote:
Hmm, I'm still not sure what is wrong: the sourceresolver impl or this
test? After the disaster of the 2.2.2 release breaking this stuff, I
tested the 2.2.3 release on both windows and macos x and it did work for
me. I also tested Cocoon 2.1.x and trunk with it and it
Felix Knecht wrote:
4. If ever I'd rather consider the 'pipelineComponent Scope troubles' as
a problem than the zipper stuff.
agreed, but after some thinking about it I came to the conclusion that I can
create the release artifacts anyway. I will only have to wait with starting the
voting
Grzegorz Kossakowski wrote:
Hi,
I forgot that Reinhard asked us for code freeze from 18 to 21 of September
and checked few things in.
Reinhard, could you confirm that you are going to make a release so we will
know that committs are rather not allowed these days?
Yes, I can do it but
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Can anybody confirm this or is it a problem with my environment
(although I deleted my local repo, then entered svn up, mvn clean install)?
Reinhard, I tried to build Cocoon with empty Maven local repo and results are
the same: everything
Grzegorz Kossakowski wrote:
Felix Knecht pisze:
Can anybody confirm this or is it a problem with my environment
(although I deleted my local repo, then entered svn up, mvn clean
install)?
Works for me under linux, using sun-jdk-1.6 and sun-jdk-1.5
Same here so it's again OS-specific issue. I
Giacomo Pati wrote:
Grzegorz Kossakowski wrote:
Giacomo Pati pisze:
Yes, clean my M2 repo.
of problematic behaviour in order to help anyhow.
Still have the problems. With scpre=request I got the stack trace after the
first request found
at
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Giacomo Pati wrote:
Grzegorz Kossakowski wrote:
To be honest, I get almost the same stack trace with your little sample.
Just to make sure: you have configured OM to be in request scope instead of
pipelineComponent scope? I ask because my
Daniel Fagerstrom wrote:
Grzegorz Kossakowski skrev:
I see. Last question is about multiple bean declarations in one xml
file. Do we think it's good or
bad practise?
No strong opinion about that. If a couple of beans works togther or are
of the same kind it seem natural to put them together
Giacomo Pati wrote:
Daniel Fagerstrom wrote:
Giacomo Pati skrev:
Daniel Fagerstrom wrote:
Giacomo Pati skrev:
Again, how should deprecation be implemented:
a) use deprecation logger but keep current implementation
b) throw an exception and remove current implementation
a) is probably
Grzegorz Kossakowski wrote:
Path to dependency: 1)
org.apache.cocoon:cocoon-spring-configurator:jar:1.0.1-SNAPSHOT
2) log4j:log4j:jar:1.2.15
3) javax.jms:jms:jar:1.1
Does anyone know why log4j has this dependencies introduced in minor version
increase?
a quick guess: they
Grzegorz Kossakowski wrote:
Grzegorz Kossakowski pisze:
Hello,
This is a second attempt to resolve problem with inaccurate version information
in JIRA which I
described here[1]. The first one was to split up our COCOON project into
several smaller ones[2].
Unfortunately, this option had
Martijn C. Vos wrote:
Jean-Baptiste Quenot [mailto:[EMAIL PROTECTED] wrote:
* Grzegorz Kossakowski:
What I would like to add is that our users already
tried[1] to do so.
[1] http://article.gmane.org/gmane.text.xml.cocoon.user/61153
Thanks for mentioning this. I remember now
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
I've started to look into Wicket because I'm not satisfied with what I've
used so far (cForms, JSF, Tapestry 4, Struts) when it comes to the
development of *rich client apps* in XHTML/CSS/JS. From what I've seen I'm
impressed but not fully
Olivier Billard wrote:
Hi all,
Still annoyed with that problem.
Can anyone confirm or not ? Should I feed JIRA ?
Yes, please do so. I'm sorry, but I can't help with the problem till the end of
September when I'm back from my vacations.
--
Reinhard Pötz Independent Consultant,
[
https://issues.apache.org/jira/browse/COCOON-2128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reinhard Poetz closed COCOON-2128.
--
Resolution: Fixed
fixed in SVN by additional CSS style for code inside li and td elements
Carsten Ziegeler wrote:
I'm wondering what the opinion about the future of our cron block is? Do
we need such a thing at all? Could we just use the quartz support of Spring?
If we keep it, should we refactor it?
Now, I'm asking this because currently I need a scheduling service in a
non Cocoon
Grzegorz Kossakowski wrote:
Hi,
I wanted let you know that I have created Daisy site for
cocoon-expression-language module. It was very easy because everything is
explained here: http://cocoon.zones.apache.org/daisy/cdocs/g3/1223.html
I must visit our Daisy more often; our documentation system
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Carsten Ziegeler wrote:
I'm wondering what the opinion about the future of our cron block is? Do
we need such a thing at all? Could we just use the quartz support of
Spring?
If we keep it, should we refactor it?
Now, I'm asking this because
I plan to release Cocoon 2.2RC2 between Sept 19th and Sept 21st, provided that I
have enough time to publish our new documentation before because it doesn't
help much if we release things without telling anybody about it ;-)
Does anybody have problems with a code freeze from 18th to 21st of
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
thanks Grek for taking care for documentation too!
No problem. If we are serious about switching to the unified expressions
documentation is a must.
I'm happy that the refered documentation about our documentation was good
enough for you
Olivier Billard wrote:
Hi all,
The Cocoon Maven plug-in can be configured given a
useShieldingRepository configuration parameter. The effect is that all
JARs / classes are moved from WEB-INF/lib and WEB-INF/classes
respectively to WEB-INF/shielded/lib and WEB-INF/shielded/classes.
The
The GT website doesn't have much to say about recommended hotels yet
(http://www.cocoongt.org/Venue.html). Will there be some updates by the end of
the weekend? (I will be offline afterwards and would like to have a reservation
before my holidays.)
Thanks!
--
Reinhard Pötz
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
* I will change my opinion if cocoon-core doesn't contain Java code
anymore and everything is at its right place ...
I've taking a look on this issue when working on GSoC and moving stuff around.
Basically we have:
* code that can be moved
Bruno Dumon wrote:
On Thu, 2007-08-23 at 10:06 +0200, Bruno Dumon wrote:
On Thu, 2007-08-23 at 09:27 +0200, Reinhard Poetz wrote:
Grzegorz Kossakowski wrote:
I must missed it because there was no notification about this document
on our docs list thus commenting now.
Does anybody know why we
Olivier Billard wrote:
Hi Jean-Baptiste !
Thank you for your quick reply.
Didn't you mention the 2.1 part of the SVN repo ? Maybe was it not clear
in my post, but I am talking about Cocoon 2.2 :).
Searching a bit, I found some information about the shielding servlet
service, that seems to do
Grzegorz Kossakowski wrote:
I must missed it because there was no notification about this document
on our docs list thus commenting now.
Does anybody know why we don't receive any notification mails from Daisy? I've
checked the dsy_list_listener user and it is configured correctly.
--
Gianugo Rabellino wrote:
During the traditional Hackathon, developers and users will team up to
discuss the Cocoon internals and work side by side on current Cocoon
issues.
I've created a wiki page to collect relevant information (ideas, who will come,
etc.) about the Hackaton. See
Jean-Baptiste Quenot wrote:
* Reinhard Poetz:
Gianugo Rabellino wrote:
During the traditional Hackathon, developers and users will
team up to discuss the Cocoon internals and work side by side
on current Cocoon issues.
I've created a wiki page to collect relevant information (ideas,
who
Jeroen Reijn wrote:
This seems like a very interesting topic. I'm currently looking into Wicket
to get to know the framework a bit better. Reinhard if you are going to work
on this at the GT I would like to team up with you and see how this can be
made possible. :-)
Sure, you're welcome! I
Vadim Gritsenko wrote:
Grzegorz Kossakowski wrote:
Hi Nils,
Nils Kaiser pisze:
Well, there is even a nicer way to do this. Depending on which
edition of JIRA Apache has, you could add a Custom field Fix Version
(Component) and Affects Version (Component). You should be able to
do searches
Daniel Fagerstrom wrote:
You have done an excellent work Grzegorz.
+1
snip/
While I have lot of expeience in teaching, coaching and mentoring IRL,
this is the first time I have mentored someone that I never have met
IRL, over email. I'm supprised that it has worked so well. An important
Ralph Goers wrote:
I don't want to see Cocoon portal under COCOON_BLOCKS only to have it
changed later.
I also don't understand the last sentence in Reinhard's email, IMO we
should either create them all or don't change anything because I don't
understand what the benefit of having multiple
Carsten Ziegeler wrote:
/META-INF/cocoon/spring when using Cocoon Spring configurator independently from
Cocoon. It's probably not that hard to change but we should do it before
propagating it :)
There are constants defined in
org.apache.cocoon.spring.configurator.impl.Constants.
So changing
Grzegorz Kossakowski wrote:
Hi,
With help of Brett Porter I'm just in process of creating new Continuum
setup for Cocoon at a new Continuum instance[1]. Brett told me that old
one when we used to have Cocoon built is going to be shut down soon.
Grek and Brett, many thanks for making this
Grzegorz Kossakowski wrote:
Grzegorz Kossakowski pisze:
As for now, do you want me to change our setup?
After another batch e-mails I decided to remove all projects except
Apache Cocoon that builds whole Cocoon recursively.
Thanks :-)
--
Reinhard Pötz Independent Consultant,
Joerg Heinicke wrote:
hmmm, the main benefit of having seperate Jira projects is that we
can have seperate version numbering schemes for each project.
I think it makes sense to not introduce a separate Jira project for
EVERY project that might have (or already has) a different version
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
hmmm, the main benefit of having seperate Jira projects is that we can
have seperate version numbering schemes for each project. But looking
at e.g. COCOONM2 I don't see how this can be achieved because all
modules that it contains already
Nils Kaiser wrote:
By following the discussion I had a look wether JIRA people are planning
to add some support in that direction and in fact there are some issues
related to this:
http://jira.atlassian.com/browse/JRA-12241 - Support for Product Suites
/ Sub-Projects (22 votes)
Reinhard Poetz wrote:
Nils Kaiser wrote:
By following the discussion I had a look wether JIRA people are
planning to add some support in that direction and in fact there are
some issues related to this:
http://jira.atlassian.com/browse/JRA-12241 - Support for Product
Suites / Sub-Projects
Grzegorz Kossakowski wrote:
Hi,
We have discussed JIRA split up several times now, the last time in this
thread[1]. Since infra team raised concerns on proposed JIRA project
identifier we agreed on adding COCOON prefix to every identifier. I
posted updated proposal with topic Division of
Daniel Fagerstrom wrote:
I saw that trunk/commons/status.xml hasn't been touched for nearly a
year. Should I document the change there or do we have some new place
for documenting changes in the trunk?
There is a changes.xml file for each module. For such general changes I suggest
using
Felix Knecht wrote:
I would like to deprecated HTMLArea as WYSIWYG HTML editor, because
it's no longer developed and maintained [1].
As replacement different solutions exists (e.g. Xinha, dojo's Editor2).
Please cast your vote!
+1
--
Reinhard Pötz Independent Consultant, Trainer
Felix Knecht wrote:
Joerg Heinicke schrieb:
On 14.08.2007 3:01 Uhr, Felix Knecht wrote:
I would like to deprecated HTMLArea as WYSIWYG HTML editor, because
it's no longer developed and maintained [1].
+1 if that means 2.2 (= remove in 2.3)
That's what I mean ;-)
actually it means that it
Daniel Fagerstrom wrote:
Daniel Fagerstrom skrev:
I would like o.a.c.environment.[Request|Response|Session] to extend
javax.servlet.http.Http[ServletRequest|ServletResponse|Session]
respectively.
...
I don't want this to collide with releasing 2.2, so I'll wait with
introducing the changes
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
If we follow our release policies, we wouldn't be allowed to introduce
this change for any 2.2.x release and 2.3 is far away I'd guess. But
since we have released the first series of RC1 without having
announced them so far, my vote is +1
Daniel Fagerstrom wrote:
I would like o.a.c.environment.[Request|Response|Session] to extend
javax.servlet.http.Http[ServletRequest|ServletResponse|Session]
respectively.
The gain of doing so is that it will be easier to reuse Cocoon
components outside Cocoon and that it will be simpler to
Bertrand Delacretaz wrote:
On 7/30/07, Reinhard Poetz [EMAIL PROTECTED] wrote:
...While following the infrastructure@ mailing list I get the impression that
all
projects that use Confluence (+ Pier's autoexport plugin) as CMS, don't put the
docs into SVN
It would be interesting
Daniel Fagerstrom wrote:
If
you feel that you can spend some time on the 2.2 release without
endangering your GSoC task, feel free to do that. If not, focus on your
GSoC task.
Although I think that a C22 release would be more than necessary, I have to
agree with Daniel. It's not only you
Felix Knecht wrote:
To that I would add a release plan:
RC2 - in a week, this time with an anouncement (given that we have a
willing release manager)
Unfortunatly most likely I won't have time for a further release until the mid
of September. I hope to find the time to publish the website
While following the infrastructure@ mailing list I get the impression that all
projects that use Confluence (+ Pier's autoexport plugin) as CMS, don't put the
docs into SVN.
AFAIU it is still an ASF rule (at least I haven't heard something different) but
OTOH it prevents us from
401 - 500 of 2579 matches
Mail list logo
