on.
Granted, these aren't necessarily the best channels of communication,
but they do exist.
Sander sent out a (somewhat late, but definitely in time) email to
committers@ that informed folks of the outage. Did you not get it?
Upayavira
in mind?
Upayavira
Peter Hunsberger wrote:
On 7/12/06, David Crossley [EMAIL PROTECTED] wrote:
Joerg Heinicke wrote:
Upayavira wrote:
Jim last recorded a batch on 2006-07-07. Peter this sounds
strange. Fax it again. If it is back-to-front or unreadable
then nothing that Jim can do.
Our Fax machine
don't know SMPP, I'm now lloking for info about it on the
Internet... I'll tell you if I could use it. Do you suggest me to use
it?
I use aql.com. they have http and smpp interfaces, and reasonable prices
for small scale operations.
Upayavira
Omar Adobati wrote:
On 7/17/06, Upayavira [EMAIL PROTECTED] wrote:
Omar Adobati wrote:
My idea was to connect something like a cellphone (or maybe a real
cellphone) and use the AT instruction to send the SMS. Isn't a ggod
idea?
For low volumes, that can be done. You'd just use a serial
an account for you. That
is the point that you choose/get your apache ID.
Your name isn't showing in the ICLA file, so sounds like your first task
is to ensure that a signed one is received.
Regards, Upayavira
should have an ACL (as the page on
the general wiki).
Add an ACL yourself. Just make sure that there are some users in the
relevant group who can edit it.
Regards, Upayavira
Carsten Ziegeler wrote:
Upayavira wrote:
Do note that the CocoonTask is nothing but a wrapper around the
CocoonBean, much as is the CLI (org.apache.cocoon.Main). Were you to get
the CocoonBean working without changing its interfaces, the CocoonTask
would start working again. Once someone has
is prepared to update it, then it would be better
removed. And I'm not going to be in a position to update it myself.
Regards, Upayavira
it. There is forrest
anyway.
Carsten
This is a quick vote. Only vote, if you're against it. The vote is
open for 48 hours.
Are you against deprecating the CocoonTask in 2.1 and removing it in 2.2?
-1 Until we've had more discussion.
Upayavira
Reinhard Poetz wrote:
Upayavira wrote:
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
I was going through the list of dependencies because I was wondering
why we have Ant artifacts in our web applications. I found the cause
which is the CocoonTask and the question is, what we want to do
.
Yes, sounds reasonable to me. Also helps us to keep the code we are
keeping cleaner.
Upayavira
Hi,
Due to pressures of work, I need to relinquish my moderation role on
dev/users/cvs/[EMAIL PROTECTED]
Are the existing additional moderators happy to continue the job without
me, or do we require additional volunteers?
Regards, Upayavira
pipeline as its generator.
So there are ways you could achieve what you are after with the current
setup.
Regards, Upayavira
more
accessible to folks that have been exposed to such approaches, which is
an increasing number of people. That's how I read it.
Regards, Upayavira
, is just going to have to be fine.
But then, surely all of the above is obvious, no?
Regards, Upayavira
, or a javascript servlet? Or a
proposal for a pull pipeline servlet? Or some other block deployer code
or something?
Thoughts?
Regards, Upayavira
Upayavira wrote:
Bertrand Delacretaz wrote:
Most of you have probably seen it already, Google has officially
announced Summer Of Code 2006: http://code.google.com/soc/
I'll probably suggest a project to expand the scope of automated testing
of our 2.1.x workhorse branch.
That would
, the download page should allow
you to change the mirror site you are using.
Regards, Upayavira
Thorsten Scherler wrote:
El lun, 03-04-2006 a las 12:34 +0100, Upayavira escribió:
Thorsten Scherler wrote:
El lun, 03-04-2006 a las 09:00 +0100, Upayavira escribió:
David Crossley wrote:
Upayavira wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Hmm
David Crossley wrote:
Upayavira wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Hmm... the current CLI uses Cocoon's links view to crawl the website. So
although the new crawler can be based on servlets, it will assume these
servlets to answer to a ?cocoon-view
svn:externals in trunk; I removed the
svn:externals link to gump.xml.
Well that is going to break things. That SVN external was to allow Gump
people write access to our gump descriptor. How come you removed it? It
was placed there in discussion with this list and with the Gump peeps.
Regards, Upayavira
Reinhard Poetz wrote:
Upayavira wrote:
Reinhard Poetz wrote:
Bertrand Delacretaz wrote:
Le 3 avr. 06 à 09:08, Gump a écrit :
... -DEBUG- Sole output [chaperon-20040205.jar] identifier set to
project name
-INFO- Failed with reason missing build outputs
-ERROR- Missing Output: /usr/local
), it would be:
a) Check that's okay with the Gump community
b) Commit the 2.1.X gump.xml on top of the existing one in the gump SVN
c) Create an SVN external in 2.1.X SVN to the gump SVN
Upayavira
Thorsten Scherler wrote:
El lun, 03-04-2006 a las 09:00 +0100, Upayavira escribió:
David Crossley wrote:
Upayavira wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Hmm... the current CLI uses Cocoon's links view to crawl the website. So
although the new crawler
dependencies,
and their dependencies, etc, all built too, which as I understand it
doesn't happen that often :-)
So, yes, it is a valuable resource, but on a broader scale than just our
own project.
Regards, Upayavira
the pages to generate.
Thus, Forrest would transform its site.xml file into this list of pages,
and drive the CLI via that.
Whilst gathering links from within pipelines is clever, it always struck
me as awkward at the same time.
Regards, Upayavira
Carsten Ziegeler wrote:
Upayavira wrote:
David Crossley wrote:
Carsten Ziegeler wrote:
I can't speak for Daniel, but my idea/suggestion was to forget about the
different environments and let Cocoon always run in a servlet container.
The CLI would then be kind of a http client which starts up
.
Regards, Upayavira
proposed
implementing it.
Upayavira
with that.
Regards, Upayavira
Antonio Gallardo wrote:
Dear infra,
Is posible to close bugzilla for cocoon? We now use JIRA.
Apparently not. It would have been otherwise.
Upayavira
]
Or, for cocoon:deploy it said:
[INFO] The plugin 'org.apache.maven.plugins:maven-cocoo-plugin' does not
exist or no valid version could be found
What's up?
Upayavira
Daniel Fagerstrom wrote:
Niclas Hedhman has been elected as a Cocoon committer with 21 1+ and no
other votes. Welcome Niclas!
He has an account (user name: niclas, I think) since before, so just
commit access is needed. Can someone with power take care about that
(Upayavira)?
Done
Bertrand Delacretaz wrote:
Le 27 mars 06 à 20:44, Upayavira a écrit :
...Then ran mvn cocoo:deploy and mvn cocoon:deploy..
AFAIK It's
cocoon:deploy, not
cocoo:deploy
Tried both. No luck with either.
Upayavira
Antonio Gallardo wrote:
Upayavira escribió:
Tried both. No luck with either.
Are you using maven 2.0.2?
$ mvn -version
Maven version: 2.0.2
Upayavira
Reinhard Poetz wrote:
Upayavira wrote:
[INFO] The plugin 'org.apache.maven.plugins:maven-cocoo-plugin' does not
exist or no valid version could be found
What's up?
You have to run it from cocoon/trunk/cocoon-webapp.
Ah, yes. That did it.
Now, being stupid, are we supposed to see
and more to discussions. It's time for him to be able to commit his
patches himself!
Please cast your votes.
+1
Regards, Upayavira
to
the board in a quarterly board report.
There you go. That's the Bureaucracy of it.
Regards, Upayavira
.
Regards, Upayavira
at the attached poms?
I'll try to extend the script to generate the parent and sample poms
automatically and adjust the impl pom (based on the old block pom).
Create a jira issue and attach any files relating to this work to that
issue.
You're doing good work.
Regards, Upayavira
Daniel Fagerstrom wrote:
Upayavira skrev:
My own reflections on this is whether or not this is still Cocoon.
It seems to me that you are creating a framework for managing web
applications based upon servlets, OSGi and the URLConnections. This
doesn't seem all that specific to Cocoon
Reinhard Poetz wrote:
Upayavira wrote:
Carsten has offered a suggestion that _he_ is prepared to implement. I
would like to hear other proposals from people of things that _they_ are
prepared to implement. Only that way will we move beyond this impass.
There are many documents
Peter Hunsberger wrote:
On 3/16/06, Upayavira [EMAIL PROTECTED] wrote:
snip/
Thus, we have 'one way' of doing it, that people don't want to follow,
for their own reasons, and because of this, nothing at all happens, and
our community gets weaker by the day.
Oh, come on. There's no real
.
Is that a volunteer? ;-)
Regards, Upayavira
generally useful too.
Cocoon's contribution would be its SitemapServlet, and other such elements.
So, my question: Is this still cocoon, or is it becoming something more
general than that (e.g. that could become a Felix sub-project) - thus
gaining a far wider adoption?
Regards, Upayavira
waiting' is dangerous, as each moment some of our valuable
resource wanders away.
Upayavira
Peter Hunsberger wrote:
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote:
Personally, the long waiting for this blocks system is having very
unfortunate effects on our community. We need to change that. Take the
development of blocks off the front stage, and let it happen quietly
somewhere until
container.
Exactly the sort of thing I'm talking about. Both streams keep innovating.
Regards, Upayavira
Peter Hunsberger wrote:
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote:
Peter Hunsberger wrote:
Do that, and nothing other than 2.1 will ever happen. Getting real
blocks is a big thing. It looks like a lot of work, everyone has
always known that. Now that there is a little bit of momentum
Reinhard Poetz wrote:
Upayavira wrote:
Bertrand Delacretaz wrote:
Le 15 mars 06 à 16:04, Carsten Ziegeler a écrit :
...I personally would love to have the new configuration features of
2.2 in
2.1.x,
like the includes for xconf and properties. This alone is a big step
forward
Peter Hunsberger wrote:
On 3/15/06, Upayavira [EMAIL PROTECTED] wrote:
snip/
I would like to see blocks and Cocoon 2.1.X move along in parallel, and
as soon as blocks are sufficiently mature and stable, they merge. The
current state of affairs with a tiny minority working on blocks (however
make a patch? That could make it happen.
Upayavira
to the
documentation I'd be happy to add it if you can provide a sensible
description of the isGlobal parameter (i.e. something more sensible than
global redirect).
IIRC a global redirect is one that returns all the way to the browser,
even from within internal requests.
Regards, Upayavira
Jason Johnston wrote:
On Thu, 2006-03-09 at 21:10 +, Upayavira wrote:
Jason Johnston wrote:
On Thu, 2006-03-09 at 08:46 -0800, Ralph Goers wrote:
Bruno Dumon wrote:
On Thu, 2006-03-09 at 06:35 -0800, Ralph Goers wrote:
Hi. Its me again.
Seriously, are we there yet?
I guess
hoped it had been fixed.
Upayavira
is that, if we ship Jackrabbit, we don't need
the JCR jar, as Jackrabbit provides its own impl. Does it still work if
you just remove the JCR jar? Or did I misunderstand something?
Upayavira
I just received this message from Richard Hall. Seems like Felix just go
that bit closer to meeting our needs, which is great. Is there anything
else we specifically need in order to use Felix instead of Eclipse?
Upayavira
Original Message
Subject: Cocoon and Felix
Date: Sun
Thanks for this Daniel - Richard copied in so he sees your reply.
Regards, Upayavira
Daniel Fagerstrom wrote:
We also need the ability to use unpacked bundles for fast prototyping
(available in Equinox). We need the possibility to embed the OSGi
framework in a servlet container
(http
/
map:transform src=stylesheets/user.xsl/
map:serialize type=fo2pdf/
/map:match
I think that is enough. Try it.
Upayavira
Peter Hunsberger wrote:
On 2/15/06, Upayavira [EMAIL PROTECTED] wrote:
Peter Neu wrote:
Hello Bertrand,
I managed to send my xml in a post request to cocoon and retrieve the ouput
back in pdf. But one thing I couldn't figure out so far is how to actually
read the xml from the post request
problems
with classloading (afair) and noone is using jdk14 logging
+1 for log4j
+1 too.
Upayavira
requirements, keeps
things simple. And simple is something that Cocoon seriously needs to be
moving towards. We've been there and done that in relation to lots of
dependencies.
Regards, Upayavira
to change?
My impression is that this is a proposed layout, we're waiting to see
how the few converted classes work out before converting any of the rest.
How are we getting on with tat evaluation?
Are we ready for volunteers to convert the rest?
Upayavira
[
http://issues.apache.org/jira/browse/COCOON-1771?page=comments#action_12365560
]
Upayavira commented on COCOON-1771:
---
This patch came in as anonymous, therefore we cannot accept it, as its
provenance cannot be proven. Please resubmit it while logged
Reinhard Poetz wrote:
Upayavira (JIRA) wrote:
[
http://issues.apache.org/jira/browse/COCOON-1771?page=comments#action_12365560
]
Upayavira commented on COCOON-1771:
---
This patch came in as anonymous, therefore we cannot accept it, as
its provenance
[
http://issues.apache.org/jira/browse/COCOON-1771?page=comments#action_12365587
]
Upayavira commented on COCOON-1771:
---
No need. Just make sure that the one you use was uploaded by a known individual
who clicked the grant license button
optional
flow block?
Your feedback will be appreciated.
Just add servlet.jar to the CLI's classpath. It won't be soon that it
gets the attention it needs to make sure it can work without
servlet.jar, and it will make life easy for a lot of CLI users.
Upayavira
environment api extend the http servlet api
now, (which should be back compatible).
As I say, I feel much happier about this now, after seeing some of the
changes that have taken place since our last discussion.
Regards, Upayavira
of the
ImageReader class as you suggest.
Have I understood your question?
Regards, Upayavira
Daniel Fagerstrom wrote:
Upayavira wrote:
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
...
First, I'm still not sure if this should go into the current 2.2 code
base, but apart from that I now think we should even be more radical in
this area and remove the whole
Tim Williams wrote:
On 1/30/06, Upayavira [EMAIL PROTECTED] wrote:
Tim Williams wrote:
I want the image reader to accept a variant name (e.g. thumb,
small) and then write the newly created image variant to disk before
sending the output. In other words, so that a given image
IMG001.jpg might
Jean-Baptiste Quenot wrote:
* Upayavira:
Jean-Baptiste Quenot wrote:
Any hint on how to add this location to the loader classpath?
The loader source is in tools/src/loader/Loader.java. It seems
that the loader doesn't load class directories. However, a brief
look at the code suggests
as little substantial change as
possible.
Regards, Upayavira
activates in web.xml the optional component
(it's a SessionListener).
Servlet 2.3 will *not* be required to run Cocoon.
A mock sounds like a _much_ better way!
Regards, Upayavira
Sylvain Wallez wrote:
Upayavira wrote:
Jean-Baptiste Quenot wrote:
* Carsten Ziegeler:
Sylvain Wallez schrieb:
Jean-Baptiste can elaborate on this, but AFAIU this is because
an interesting XSP patch requires a servlet listener, which is
something that was added
?
A simple solution is to package the classes of blocks samples as
jars.
The loader source is in tools/src/loader/Loader.java. It seems that the
loader doesn't load class directories. However, a brief look at the code
suggests to me that it wouldn't be too hard to add.
Regards, Upayavira
friendly, IMO.
Does this make sense?
Regards, Upayavira
Reinhard Poetz wrote:
Giacomo Pati wrote:
On Wed, 18 Jan 2006, Reinhard Poetz wrote:
Of course it's possible to edit the wiring.xml but I would (will)
recommend
Editing wiring.xml? I may now be totally wrong but I've understud
replied saying no, but I think that unlikely.
I'd suggest you try another, this time inconsequential commit (add a
space to a file or something) so we can moderate you through properly
this time!
Regards, Upayavira
.
And the short answer is yes, Cocoon can help with that.
Regards,
Upayavira
If you're logging in as yourself first. Then you can try:
passwd maven
Now when Upayavira first created the maven account i tried putting my
ssh key in .ssh/authorized_keys2 but for some reason it doesn't like it
during authentication. I have the exact same setup for my user jheymans
on the zone
not stable, because...
+1
Upayavira
Jean-Baptiste Quenot wrote:
* Ralph Goers:
I don't see a corresponding email for trunk. Was this also
applied there?
Not yet. Is it urgently needed in 2.2?
No, but if you don't do it now, likely it will be forgotten.
Regards, Upayavira
on with prototyping a
new implementation of Cocoon. If/when that new implementation comes
along, we can see if it can be redone as a refactoring rather than a
rewrite. Until then, let's move on on all fronts. We stand a better
chance of winning that way.
Regards,
Upayavira, who's been away for a few days
from that, I think I just trust
your decision which of the two is better suited for us.
So, big +1 for adding JMX support to 2.2 :)
So long as the new dependency isn't one for the core, but can be
contained in a block.
Upayavira
used
and well known blocks and let the users voice their concern about those
blocks we aren't taking forward. If enough noise, we can then still
decide to support these blocks ourselves again or even offer it to
dedicated users to maintain themselves.
See separate mail.
Upayavira
.
Regards, Upayavira
push it out a bit.
no, it wouldn't.
The servlet api is itself an abstraction. So what we have is an
abstraction of an abstraction. The suggestion is to scrap this double
abstraction. We could easily have our own CLI implementation of
javax.servlet.*
That is the suggestion.
Regards, Upayavira
-repository that didn't exist.
Any ideas? Does it work for other people?
Regards, Upayavira
be able to stop us!
Discussing the plan via various email-threads doesn't seem to me to be
that effective - at this initial stage - and could eventually lead to
everyone giving up in frustration.
But at the same time we don't want to leave out thase that are not there.
Upayavira
.
And, the existing Cocoon carries on as long as people want and need it.
Maybe 3.0 could still be the OSGi version. It may well still bring huge
benefits to those using the current generation of Cocoon.
Thoughts? (Other than oh no, not another naming discussion!)
Regards, Upayavira
(P.S. If people do
to be in on it too.
Upayavira
, and
thank you to Sylvain for restarting the discussion.
Regards, Upayavira
Berin Loritsch wrote:
Upayavira wrote:
So, 2.2 = important, and 3.0 = important. Both.
We need to avoid discussions, implications, emotions, etc that suggest
otherwise.
Right. If any of that has gone on, I'm sure its unintentional. If
memory serves me correctly, Cocoon 2
hepabolu wrote:
Berin Loritsch wrote:
Upayavira wrote:
So, 2.2 = important, and 3.0 = important. Both.
We need to avoid discussions, implications, emotions, etc that suggest
otherwise.
Right. If any of that has gone on, I'm sure its unintentional. If
memory serves me correctly
Sylvain Wallez wrote:
knock knock...
Apache Mail servers are struggling at the moment.
Folks are working hard to sort it out.
Upayavira
, and do crontab -e, and edit a
cron entry for the maven user.
Regards, Upayavira
the contribution in Jira.
I don't understand how this should work.
Well, we can use Jira to note contributions, and then manually copy them
into our contribution records. I imagine that is what Pier means.
Regards, Upayavira
Jorg Heymans wrote:
Upayavira wrote:
Alternatively, su to the maven account, and do crontab -e, and edit a
cron entry for the maven user.
-bash-3.00$ whoami
maven
-bash-3.00$ crontab -e
crontab: you are not authorized to use cron. Sorry.
Oh well, another Linux/Solaris difference
Bertrand Delacretaz wrote:
Le 25 nov. 05, à 17:15, Upayavira a écrit :
...Oh well, another Linux/Solaris difference. Provide me with a crontab
line and I'll add it to the root one...
Why not allow user maven to use crontab?
It's certainly safer than running things as root.
I have
1 - 100 of 893 matches
Mail list logo
