[
http://issues.apache.org/jira/browse/COCOON-1961?page=comments#action_12455239
]
Reinhard Poetz commented on COCOON-1961:
We have to discuss on [EMAIL PROTECTED] what use cases the deployer plugin has
to cover at all. Since the latest
[
http://issues.apache.org/jira/browse/COCOON-1961?page=comments#action_12455233
]
Simone Gianni commented on COCOON-1961:
---
Uops, forgot the NPE stacktrace :
java.lang.NullPointerException
at
org.apache.maven.plugin.war.AbstractW
[
http://issues.apache.org/jira/browse/COCOON-1961?page=comments#action_12455232
]
Simone Gianni commented on COCOON-1961:
---
I submitted a patch for http://jira.codehaus.org/browse/MWAR-86 and tested it
locally with a plugin that, as the c
Cocoon deployer plugin given null pointer cause of maven limitations on
subclassing
---
Key: COCOON-1961
URL: http://issues.apache.org/jira/browse/COCOON-1961
Project: Co
On Monday 04 December 2006 06:02, Mark Lundquist wrote:
> I see that this would have to wait 'til C3, according to
> http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g2/1181.html
And in a future C3, could it be possible that the entire sitemap is abstracted
out,
a. into a standalone compo
I see that this would have to wait 'til C3, according to
http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g2/1181.html
—ml—
[
http://issues.apache.org/jira/browse/COCOON-1945?page=comments#action_12455214
]
Simone Gianni commented on COCOON-1945:
---
Also, connected to this one, there is the way the ConcreteTreeProcessor checks
which processor should execute a ce
Hi gang,
OK, here is a proposal for a way to reformulate matching and selecting
so that they can be expressed in a more concise and powerful way. It
would (a) make sitemaps cleaner and easier to understand and write, (b)
lower the learning curve for new users, and (c) can be implemented with
Carsten Ziegeler wrote:
Unfortunatly we have one showstopper: the dependency of cocoon-core on
commons-jci. The problem is that there is no release available and we can't
release something if it has a dependency on a snapshot releases.
For the time being I only see two options:
a) we get a
Carsten Ziegeler wrote:
Let's comment this stuff out, I think we should move this into a
separate module anyway and keep the core as small as possible.
+1
Jorg
Reinhard Poetz wrote:
Currently we have following configuration in our root POM:
cocoon-staging-repo
staging release repository
scpexe://people.apache.org/home/jheymans/public_html/cocoon-staging-repository
I guess that it isn't the best idea to use Jorg's home directory as
stagi
On Dec 3, 2006, at 4:50 AM, Gabriele Columbro wrote:
Hi Mark (Maurizio is here on my side not answering due to annoying
mail server issues)
bummer :-/
and we're working on reloading classloader configuration.
You're right, the TreeProcessor already behaves like this, by checking
the value
Reinhard Poetz schrieb:
> Reinhard Poetz wrote:
>> I think it's time to release the next milestone of some of our modules:
>>
>> - org.apache.cocoon:cocoon(pom)
>> - org.apache.cocoon:cocoon-core-modules (pom)
>> - org.apache.cocoon:cocoon-core (jar)
>> -
On 12/3/06, Reinhard Poetz <[EMAIL PROTECTED]> wrote:
...Some time ago somebody mentioned that the mv command is atomic. Is this
information correct?...
on a Linux or unixish system, mv uses the rename() system call which
is atomic (i.e. intermediate states are not visible), so
mv somefile n
Reinhard Poetz wrote:
I think it's time to release the next milestone of some of our modules:
- org.apache.cocoon:cocoon(pom)
- org.apache.cocoon:cocoon-core-modules (pom)
- org.apache.cocoon:cocoon-core (jar)
- org.apache.cocoon:cocoon-blocks-modules
Hi Mark (Maurizio is here on my side not answering due to annoying mail
server issues) and we're working on reloading classloader configuration.
You're right, the TreeProcessor already behaves like this, by checking the
value of
org.apache.cocoon.reloading=[yes,no]
used also to control sitemap r
[ http://issues.apache.org/jira/browse/COCOON-1946?page=all ]
Maurizio Pillitu updated COCOON-1946:
-
Attachment: cocoon-javaflow-r481762.diff
> [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and
> showing cform templates
> -
[
http://issues.apache.org/jira/browse/COCOON-1946?page=comments#action_12455166
]
Maurizio Pillitu commented on COCOON-1946:
--
Still some changes of the cocoon-javaflow-r470120.diff patch are missing; I'm
providing a new patch based on
As releasing POM artifacts is a real PITA because of the snowball effect on many
other POMs, we should take care that all settings in our root POM are correct
this time.
Currently we have following configuration in our root POM:
cocoon-staging-repo
staging release repository
scpexe:/
I think it's time to release the next milestone of some of our modules:
- org.apache.cocoon:cocoon(pom)
- org.apache.cocoon:cocoon-core-modules (pom)
- org.apache.cocoon:cocoon-core (jar)
- org.apache.cocoon:cocoon-blocks-modules (pom)
- org.apach
20 matches
Mail list logo
