Stefano Mazzocchi wrote:
Carsten Ziegeler wrote:
Although the vote is over, just my 2 cents:
Maven is a really useful tool *if* you know how to use it! I think
most projects that tried to use Maven and failed did not
use it in the
right way. Just look at the mess Avalon tried
Sylvain Wallez wrote:
Spotted the problems, which are actually twofold in the TreeProcessor:
- sitemap modification date is checked to be before or equal
to the date when the treeprocessor was built, meaning
continuous rebuild if the sitemap date is in the future
- treeprocessor disposal
Carsten Ziegeler wrote:
...
3. The biggest advantage imho (and again this is my personal opinion -
others
might differ of course) are the different reports you get for free
Sorry Carsten, but this is a bit ridiculous, given all the lines of code
you pour into Cocoon. You know how many lines of
Ugo Cei wrote:
Carsten Ziegeler wrote:
I think we have the second problem in Cocoon since our
first version
:( I always thought about adding a counter for the
concurrent requests
in a tree processor, but always forget about it :( Regarding
performance: is this a problem as the
Nicola Ken Barozzi wrote:
Carsten Ziegeler wrote:
...
3. The biggest advantage imho (and again this is my
personal opinion -
others might differ of course) are the different reports
you get for
free
Sorry Carsten, but this is a bit ridiculous, given all the
lines of code you
Nicola Ken Barozzi wrote:
So, let's all cut a deal: we move to SVN, and then I will
rework the build on a branch. If someone else wants to, he
can do the same with Maven or whatever on another branch.
After this is done, we can have a vote and decide which
buildsystem to adopt for
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Spotted the problems, which are actually twofold in the TreeProcessor:
- sitemap modification date is checked to be before or equal
to the date when the treeprocessor was built, meaning
continuous rebuild if the sitemap date is in the future
-
Carsten Ziegeler wrote:
Nicola Ken Barozzi wrote:
So, let's all cut a deal: we move to SVN, and then I will
rework the build on a branch. If someone else wants to, he
can do the same with Maven or whatever on another branch.
After this is done, we can have a vote and decide which
buildsystem
Nicola Ken Barozzi wrote:
Ok, so I'm really getting fed up with these build discussions, and if
we don't give it a break they will continue to grow.
Some people here are not satisfied with our build system, and advocate
Maven. I definately agree with the first part, and am, for technical
but
On 26 May 2004, at 10:15, Nicola Ken Barozzi wrote:
Some people here are not satisfied with our build system, and advocate
Maven. I definately agree with the first part, and am, for technical
but also for historical reasons, very much adverse to the second one.
Apart from the human factor, about
Nicola Ken Barozzi wrote:
Ok, I'll ask infrastructure.
Guys/Gals, start installing SVN!
http://subversion.tigris.org/project_packages.html
And read about it:
http://svnbook.red-bean.com/
Do we a need a cvs freeze for the move?
And what will be the name of the repository
Steven Noels wrote:
About the emerging SVN move: it would be good to start moving
the blocks inside their own source repositories at that time,
and think seriously about separated release schedules for
blocks core. But we knew that already, of course.
:)
I think we don't have to do
Sylvain Wallez wrote:
I was just looking in the VM spec if a increment operation on an integer
is atomic or not. My opinion it has to be in the case of class members
as the increment is surrounded by getfield/putfield instructions.
Accessing an int is atomic. Accessing a long is not. This is all
On 26.05.2004 10:56, Ugo Cei wrote:
Sylvain Wallez wrote:
I was just looking in the VM spec if a increment operation on an
integer is atomic or not. My opinion it has to be in the case of class
members as the increment is surrounded by getfield/putfield instructions.
Accessing an int is atomic.
The Cocoon project has decided to move to subversion, so we need your
help, along with an indication about when it can be done. TIA
quick-summary
We need to export
cocoon-2.1
cocoon-2.2
cocoon-site
to SVN and then lock these CVS modules.
The resulting repo we need is:
/cocoon/
/trunk/
Now as we have 2.1.5 out, I think we should talk about the future
a little bit - we already have discussed several things in the
past and I want to try to summarize things.
First, I heard in the past complains from users at conferences where
I presented Cocoon, that it's not identifiable what
Ok, so I'm really getting fed up with these build discussions, and if we
don't give it a break they will continue to grow.
Some people here are not satisfied with our build system, and advocate
Maven. I definately agree with the first part, and am, for technical but
also for historical
Ugo Cei wrote:
Sylvain Wallez wrote:
I was just looking in the VM spec if a increment operation on an
integer is atomic or not. My opinion it has to be in the case of
class members as the increment is surrounded by getfield/putfield
instructions.
Accessing an int is atomic. Accessing a long is
Alex Romayev wrote:
Ok, I'm a bit confused and not sure where to start.
This is what I'm trying to achieve. I'd like to replace
portal login form with CForm (using actions, not flow), to
use its validation. So the most interesting use case is:
1. User does not enter
On 25 May 2004, at 19:05, [EMAIL PROTECTED] wrote:
Hi,
I'm very impressed by the site. I think it's great ammunition against
the
sceptics. Reading that the actual building took about 3 weeks I wonder
how
many people were in the team?
Not that many... 3 on the graphics side of things (HTMLers),
Carsten Ziegeler wrote:
Some things that come to my mind for 2.2:
- first finished version of CForms.
- deprecate XSP (and provide a viable alternative)
- cleaning up the caching/store mess
- remove deprecated blocks etc.
All request's named how should I implement that? finish at use flow +
forms
Hi, your both
thanks. acturally i forgot to declare that.
Cecilia
htmldiv@_@/div/html
_
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
Ugo Cei wrote:
I don't think it is necessary, and could hurt performance, but before I
try to dig up some other reference, I'd like to know if we're talking
about the same scenario.
OK, turns out my memory is getting worse each day. I was wrong,
incrementing an int is most certainly *NOT* an
Sylvain Wallez wrote:
Agree for *variables*. Here, we have a class member, which has to be
loaded, then incremented, then stored.
So as Bertrand, I stay on the safe side and synchronize.
Just to be clear, what you're suggesting is to do:
public class MyClass {
private int counter;
public
Carsten Ziegeler dijo:
Antonio Gallardo wrote:
Carsten Ziegeler dijo:
Hi Antonio,
yes, I wasn't sure what to do yesterday: wait for emails
working again
or simply take the risk and release. Now I took the second
option :) I
noticed your commit during the release process and started
Hello,
to authenticate the user in the portal I use cforms in a coplet! The
portle/cform get all login-information from a rmi-object and if the user
submit all nessecary information I generate the authentication-xml, add
it to the session and the flowscript redirect to the authentication
On 26 May 2004, at 11:12, Nicola Ken Barozzi wrote:
Steven Noels wrote:
On 26 May 2004, at 10:15, Nicola Ken Barozzi wrote:
Some people here are not satisfied with our build system, and
advocate Maven. I definately agree with the first part, and am, for
technical but also for historical reasons,
Ugo Cei wrote:
Sylvain Wallez wrote:
Agree for *variables*. Here, we have a class member, which has to be
loaded, then incremented, then stored.
So as Bertrand, I stay on the safe side and synchronize.
Just to be clear, what you're suggesting is to do:
public class MyClass {
private int
Great!
As our head contains 2.2-dev already, I guess we should start thinking
about branching for 2.1.6, right?
Carsten
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 26, 2004 1:56 PM
To: [EMAIL PROTECTED]
Subject: [status update] Re: VERY
Joerg Heinicke wrote:
On 26.05.2004 10:56, Ugo Cei wrote:
Sylvain Wallez wrote:
I was just looking in the VM spec if a increment operation on an
integer is atomic or not. My opinion it has to be in the case of
class members as the increment is surrounded by getfield/putfield
instructions.
FYI
I just happened to stumble (again) onto Struts Flow, which will be
added to the Struts TLP as a subproject in due time:
http://struts.sourceforge.net/struts-flow/index.html
It happens to contain a copy of our beloved Rhino fork as well:
Carsten Ziegeler wrote:
Great!
As our head contains 2.2-dev already, I guess we should start thinking
about branching for 2.1.6, right?
Yep. Can you create a branch?
Vadim
-Original Message-
From: Vadim Gritsenko [mailto:[EMAIL PROTECTED]
Sent: Wednesday, May 26, 2004 2:30 PM
To: [EMAIL PROTECTED]
Subject: Start 2.1.6, Re: [status update] Re: VERY odd exceptions...
Carsten Ziegeler wrote:
Great!
As our head contains 2.2-dev already, I guess
Perez Carmona, David wrote:
This is the first time I write to this mailing-list, some time must be
the first time ;-)
I've created a new transformer that can perform validation in any step
of a XML pipeline. It is described in
http://wiki.cocoondev.org/Wiki.jsp?page=ValidationTransformer
Sylvain Wallez wrote:
Agree for *variables*. Here, we have a class member, which has to be
loaded, then incremented, then stored.
So as Bertrand, I stay on the safe side and synchronize.
Sylvain
I understand the desire for more metrics and instrumenting Cocoon so
that you can get the
On Wed, 26 May 2004 09:24:50 -0400, Berin Loritsch
[EMAIL PROTECTED] wrote:
The more correct version would be:
public class MyClass {
private volatile int counter; //atomic
public someMethod() {
++counter;
}
}
Only longs on up should be actually synchronized.
No,
Berin Loritsch wrote:
Ugo Cei wrote:
Sylvain Wallez wrote:
Agree for *variables*. Here, we have a class member, which
has to be
loaded, then incremented, then stored.
So as Bertrand, I stay on the safe side and synchronize.
Just to be clear, what you're suggesting is
Nicola Ken Barozzi wrote:
Bertrand Delacretaz wrote:
I know the vote is canceled, but maybe we can talk about the problems
before looking at a solution?
+1
Good idea. If we don't learn from the past then we will have
a shiny new build system with a different set of problems.
IMHO
Carsten Ziegeler wrote:
Yes and I think we already went through this hell as we introduced
the concurrent request counter in Cocoon.java which is now only
enabled if debug logging is enabled.
In our case this counter is used for disposing a sitemap that has
been changed. Now we could argue that
On Wed, 2004-05-26 at 04:04, Nicola Ken Barozzi wrote:
The Cocoon project has decided to move to subversion, so we need your
help, along with an indication about when it can be done. TIA
quick-summary
We need to export
cocoon-2.1
cocoon-2.2
cocoon-site
Nicola,
Thanks for the
I do believe that both current build system and maven build system
with only a minor changes.
Is a fact that maven requires a standard directory ( which is not too
diferent from the one adopted for cocoon build system) but with a minor
change it can be done!
Don't forget that the maven build
http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=107831750602134w=2
src/java/org/apache/cocoon/matching/MountTableMatcher.java
Log: Add an ending slash to the prefix
I just realized this change caused a loss of functionality that I
was planning to use. A mount-table is a pass-through construct:
Nicola Ken Barozzi wrote:
Ok, so I'm really getting fed up with these build discussions, and if we
don't give it a break they will continue to grow.
Some people here are not satisfied with our build system, and advocate
Maven. I definately agree with the first part, and am, for technical but
Steven Noels wrote:
it does not work with Gump
That's a burden indeed.
I consider this a roadblock for maven adoption.
--
Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
Sorry if you misunderstood my opinion on this matter. i only stand an
opinion that both methods may coexist peacefully on the same level.
you can eater build with ant or with maven. the only thing to take in
account is that with maven you don't need to worry with the libraries
which are kept in a
Stefano Mazzocchi wrote:
Reinhard Poetz wrote:
- WYSIWIG publishing not possible
(or only with some limitations)
I think that for Tapestry you have to change the plus and minus
signs. JSF tools probably need some time (years?) to become as mature
as HTML-WYSIWIG tools like Dreamweaver.
After
Carsten Ziegeler wrote:
Great!
As our head contains 2.2-dev already, I guess we should start thinking
about branching for 2.1.6, right?
Doh! I certainly missed something (was really busy when the move to SVN
was discussed and skipped that thread). Is the cocoon-2.1 repository
holding the
Carsten Ziegeler wrote:
I think the published-api-html task is missing?
No, there is only a published-api target. It generates the html as
well. However the output dirs are mostly empty as there are no
@cocoon.usage tags, yet.
Does anyone (besides me) think the distinction between published and
On 26 May 2004, at 17:44, Stefano Mazzocchi wrote:
Steven Noels wrote:
it does not work with Gump
That's a burden indeed.
I consider this a roadblock for maven adoption.
Clever but expected snip/ :-)
Care to comment about the other points? I cannot help myself thinking
that Cocoon's adoption of
Il giorno 26/mag/04, alle 11:17, Carsten Ziegeler ha scritto:
Some things that come to my mind for 2.2:
- first finished version of CForms.
- deprecate XSP (and provide a viable alternative)
- cleaning up the caching/store mess
- remove deprecated blocks etc.
- Differentiate between blocks that
On Wed, May 26, 2004 at 09:02:51PM +0200, Steven Noels wrote:
Funny thought: Given the fact that Cocoon is already #1 on
http://lsd.student.utwente.nl/gump/gump_stats/module_dependencies.html,
one could assume that Cocoon == Gump. :-)
Hmm, 220 dependencies. That is the reason we need to be
Tim Larson wrote:
http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=107831750602134w=2
src/java/org/apache/cocoon/matching/MountTableMatcher.java
Log: Add an ending slash to the prefix
I just realized this change caused a loss of functionality that I
was planning to use. A mount-table is a
Steven Noels wrote:
Care to comment about the other points? I cannot help myself thinking
that Cocoon's adoption of Depot is more important for them than for us.
I share that perception.
But I think you understand that unlike Nicola, I'm not against Maven for
personal reasons.
Of course Gump is
-scratchpad/rss.xml
Atom: http://brutus.apache.org:8080/gump/cocoon-2.1/cocoon-block-scratchpad/atom.xml
--
Produced by Gump 2.0.3-alpha-0002.
[Run (20040526 09:00:06, brutus:brutus-public:20040526 09:00:06)]
http://brutus.apache.org:8080/gump/index.html
http://brutus.apache.org:8080/gump
Time to scratch the how best to optimize Cocoon caching with respect to
continuations itch once more...
I've posted previously about how we ended up creating a continuations
manager that manages a hash map of continuations in session for each
user. This works fine, except for two things:
1) you
Stefano Mazzocchi dijo:
I say that nicola works on his version and if somebody wants (antonio?)
they can work on the maven version and then we decide.
Sorry. I have no time now to do that. :-(
I thought to concentrate on the Rhino merging, when I found free time.
Steven already triggered an
Hmm, I'm seeing an odd error message in 2.1-HEAD.
http://localhost:/xx
No pipeline matched request: nullxx
Running Jetty from CVS HEAD, java version 1.4.2_04, Win2k, etc...
Anyone else seeing this extra null?
Tony
57 matches
Mail list logo
