ng
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
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?
SMSes.
> I really 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
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-
d be a custom HTTP one, or perhaps an SMPP
one.
Do you have a provider in mind?
Upayavira
ned email now, not sure of the details tho), the ASF
Secretary records the receipt in a file in SVN. When that record is
seen, our PMC Chair (Reinhard now?) can request 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
rs work.
A good idea, but I can't see any way in which infrastructure would allow
this.
That is because it would prevent any useful partitioning of resources.
Maven is likely to become a resource hog, and could easily bring SVN
down to its knees. Much better that it only be the MVN repo that goes
down at such a time, and not our SVN repo too.
Upayavira
keyword before posting. I also alerted
> infra about this. In short this page 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
>> woul
d can decide later on what to do with it...
>
> I like the idea.
Yes, sounds reasonable to me. Also helps us to keep the code we are
keeping cleaner.
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 t
gt;>>
>>
>> I guess it's currently not working anyway. Personally I see no real need
>> in a cocoon ant task, so I would vote for removing 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
's a different discussion).
However, moving it into a separate module makes sense, as both CLI and
Ant are definitely not the main use-cases for Cocoon.
In the end, if no-one 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
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
te a separate user, and tell us its name.
We will then give such rights to that user.
Upayavira
call the sub-pipeline with something
that tells it how to use another pipeline as its generator.
So there are ways you could achieve what you are after with the current
setup.
Regards, Upayavira
stify it, he may help sooner. Otherwise, he'll
just carry on waiting. Either, in the end, is just going to have to be fine.
But then, surely all of the above is obvious, no?
Regards, Upayavira
s the same way as has
become a convention in more recent times? Which makes the code 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
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
&
creation of a sitemap servlet, or a javascript servlet? Or a
proposal for a pull pipeline servlet? Or some other block deployer code
or something?
Thoughts?
Regards, Upayavira
you are unable to access that mirror, 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:
>>>&g
Ralph Goers wrote:
> Upayavira wrote:
>
>> Ralph Goers wrote:
>>
>>
>>> Reinhard Poetz wrote:
>>>
>>>> yes, according to the mails above sometime in the future it will work.
>>>>
>>>>
t for the Gump people, because we have s
many dependencies. If Cocoon builds, that means all of its 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
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:
>>>>&
o have Gump build
2.1.x (which makes some sense to me), 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
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
ak 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
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
CLI, whilst I would support crawling I would mainly
configure the CLI to get the list of pages to visit by calling one or
more URLs. Those URLs would specify 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 conta
ster if the container didn't serve over http, i.e. require an
http client too.
Regards, Upayavira
vironment needed for running a servlet within a block and make it
> possible for it to communicate with other blocks. It is also used for
> the block protocol (the block correspondence to the Cocoon protocol). We
> could reuse part of this for the CLI.
>
> So the current CLI is a minimal command line Processor container, we
> could have a minimal command line Servlet container instead.
This makes complete sense to me and is exactly how I would have proposed
implementing it.
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
ke very long if Maven is used for the
> first them. But then, it should work fine in the future as further
> downloads are the exception and not the rule.
Yes, but here we're talking about downloading stuff needed to build
Cocoon aren't we? So we end up downloading _all_ dependencies. I've no
problem with that particularly. What I want to see is small, snappy
binary distributions. If we still have a large source download, that's
fine with me. And, IIUC, what we're doing is in line with that.
Regards, 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"
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
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
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
>
[INFO] Total time: 1 second
[INFO] Finished at: Mon Mar 27 19:28:09 BST 2006
[INFO] Final Memory: 2M/5M
[INFO]
----
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
his stuff, and is participating
> more and more to discussions. It's time for him to be able to commit his
> patches himself!
>
> Please cast your votes.
+1
Regards, Upayavira
member's votes being the
binding ones. And probably new releases, once done, should be noted to
the board in a quarterly board report.
There you go. That's the Bureaucracy of it.
Regards, Upayavira
l as modules
>
> Could somebody please have a look 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
Welcome
> page - but without samples so far.
The subversion part is the easiest bit. Working out exactly how to make
it work is very useful and doesn't require SVN commit rights. Although,
if you do move directories, try using svn move, as it will likely make
for better svn patch or svn diff output at the end of the process.
Personally, I would say go for it. Anything anyone can do would be
great, and is much needed right now.
Regards, Upayavira
tchpad status.
>
> Keeping M10N and providing a « build webapp » script is definitely
> the way to go.
Is that a volunteer? ;-)
Regards, Upayavira
Peter Hunsberger wrote:
> On 3/16/06, Upayavira <[EMAIL PROTECTED]> wrote:
>
>> 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 we
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.
>
hological
block that I want to find ways to remove. Really, what the technology is
that helps to remove that block, I do not care. I just want to see that
block removed so that the creativity of the many can flow again.
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.
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
>>
Peter Hunsberger wrote:
> On 3/15/06, Upayavira <[EMAIL PROTECTED]> wrote:
>
>
>>>> 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
>>>> curre
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
>>&g
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 k
whatever to avoid confusion.
>
> And that 2.3 release would be a big improvement already, especially
> using Spring as its 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:
>> 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
ds, can't find time to contribute to Cocoon because we
can't justify it - it is just too hard to work out where to contribute.
And 'just waiting' is dangerous, as each moment some of our valuable
resource wanders away.
Upayavira
more 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,
Jason Johnston wrote:
> On Thu, 2006-03-09 at 21:10 +0000, 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,
the browser,
even from within internal requests.
Regards, Upayavira
mentioned every time someone asks about the 2.1.9 release, so to
> keep the pattern going: what about the Template block from trunk? IIRC
> this was discussed and planned for inclusion in 2.1.9.
Could you make a patch? That could make it happen.
Upayavira
g on this
precise problem, and had hoped it had been fixed.
Upayavira
oy 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
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 containe
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
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'
> short code snippet?
>
> The relevant part looks like this:
>
>
> //still a hard coded resource
>
>
>
You need the stream generator:
I think that is enough. Try it.
Upayavira
before. Personally, just using the de-facto
standard of Log4J, if it is capable of meeting our 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
gt; Yes, please :) I would suggest log4j as commons-logging has problems
>> with classloading (afair) and noone is using jdk14 logging
>
>
> +1 for log4j
+1 too.
Upayavira
supposed 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_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&qu
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
[
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 wh
on.xconf by creating a new 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
Jean-Baptiste Quenot wrote:
> * Upayavira:
>
>
>>Ah. And currently the cache doesn't survive restarts in the CLI,
>>which it should. So your approach is now more understandable.
>
>
> AFAICT it does not survive restarts in servlet mode either,
>
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
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,
contents
of buffer to disc, then copy contents of buffer to original output
stream.
I think that would work. And this should work as an extension of the
ImageReader class as you suggest.
Have I understood your question?
Regards, Upayavira
n has been set up by the context listener and is available through
>> the context - similar to what Spring et.all. do).
>
> We should definitively make Cocoon more friendly towards other frameworks.
Yup.
>> So, let's simplify Cocoon and remove this extra abstraction completly.
>
> Would be nice. We will see what others think. For me it is most
> important that we let our 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
Sylvain Wallez wrote:
> Upayavira wrote:
>
>> Jean-Baptiste Quenot wrote:
>>
>>
>>> * Carsten Ziegeler:
>>>
>>>
>>>> Sylvain Wallez schrieb:
>>>>
>>>>
>>>>> Jean-Baptiste can elaborat
XSP. It's only for
> *compilation* that servlet 2.3 is needed, not for runtime, unless
> the user explicitly 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
2.4 with Cocoon 2.2, but
stick as we are in 2.1.x. After all, it is becoming more of a
maintenance release, and should have as little substantial change as
possible.
Regards, Upayavira
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 does
uldn't be too hard to add.
Regards, Upayavira
user 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
>>
>
The only thing that could have happened is another moderator
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
n on the user list. It is a better place for
such a question.
And the short answer is "yes, Cocoon can help with that."
Regards,
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
s as stable, to be included in imminent 2.1.9 release:
>
> [ ] +1, Let's do it!
> [ ] 0, What is CForms?
> [ ] -1, It's not stable, because...
+1
Upayavira
-3.00$ passwd
> passwd: Changing password for jheymans
> Permission denied
>
> No idea what's going on there.
You need to use:
su - maven
If you're logging in as yourself first. Then you can try:
passwd maven
> Now when Upayavira first created the maven account i tried p
opinion is correct. So in my
view, we should be taking multiple paths until one shows up to be the
clear winner. So, I'd say, Carsten, get on with improving 2.2 to address
the issues people have mentioned, and others, get 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 and hasn't read the full thread
and added ECM++ for being able to add JMX
> support somehow. Now, it thing depending on commons-modeler is a little
> bit "easier" as it's an Apache project - if there is something wrong for
> us we can fix it more easily. But apart 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
ther we should consider replacing the serializers in
core with those in the serializer block.
Regards, Upayavira
t 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
n is to scrap this double
abstraction. We could easily have our own CLI implementation of
javax.servlet.*
That is the suggestion.
Regards, Upayavira
/maven-snapshot-repository that didn't exist.
Any ideas? Does it work for other people?
Regards, Upayavira
or example).
I don't think you'll 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
> I'm far over the stage of "remote interest", I can't wait until we have
> switched completely to M2. And Carsten might be interested in discussing
> Maven as well ;)
I plan to be in on it too.
Upayavira
at brought you Apache Cocoon".
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 discu
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.
>>>
>>>
&
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 sur
ter.
Let's get 2.2 out, and let's continue to mull on the nature of 3.0, and
thank you to Sylvain for restarting the discussion.
Regards, Upayavira
1 - 100 of 996 matches
Mail list logo
