Jean-Baptiste Quenot wrote:
* Vadim Gritsenko:
http://marc.theaimsgroup.com/?l=xml-cocoon-devw=2r=1s=Cocoon-2.1.X+Tests+Failureq=b
So IIUC you setup automated tests that were stopped since more
than one year? I don't remember the decision to stop them.
Since it generated no interest there
Niclas Hedhman wrote:
You said; libraries that are currently hosted on cvs.a.o, meaning they
exist
on cvs.a.o, and can't you just tell Maven in your pom to use that repository
as well??
I meant :
libraries that are currently hosted on cvs.a.o AND that are not hosted
on ibiblio AND that
Gianugo Rabellino wrote:
http://tinyurl.com/s66vt
Just change to suspend=n and you should be ready to go!
Yes, that works great - thanks!
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Carsten Ziegeler wrote:
Ok, you're right (of course): the hierarchy of bean factories is
correctly initialized, including for example the jx generator. For some
strange reason, the tree processor of a sub sitemap is creating the
correct bean factory but using the root bean factory. Therefore
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
Didn't work for me. I copied configuration files and samples as
described in
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2 and
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114085759822501w=2
and still gets the same
On 3/21/06, Carsten Ziegeler [EMAIL PROTECTED] wrote:
Daniel Fagerstrom wrote:
Didn't work for me. I copied configuration files and samples as
described in
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2 and
* Vadim Gritsenko:
Carsten Ziegeler wrote:
Reinhard Poetz schrieb:
If a testcase gets broken *locally* by a developer, the
developer should discuss the change on [EMAIL PROTECTED] and then
people can decide together how to proceed. That should be
the standard procedure
Niclas Hedhman wrote:
What is being suggested is not that we mirror the whole of ibiblio, we
would only mirror the libraries that are currently hosted on cvs.a.o.
... You can point your pom to use the cvs.a.o directly.
What do you mean here?
- the dependency is not available on the
Pier Fumagalli wrote:
On 20 Mar 2006, at 09:19, Andrew Savory wrote:
Hi,
Jorg Heymans wrote:
If someone can offer the bandwidth and server, i'm willing to
migrate us
away from cvs.a.o. and setup a decent m2 repo where only *we* control
the poms.
Any offers? I've got some time to kill
Niclas Hedhman wrote:
If SNAPSHOTs are totally unavoidable, consider putting these in the Svn
alongside the source code. Inability to build from today's source in the
future is a serious flaw in chosen strategy.
This is exactly what we do internally. ;-)
Best Regards,
Antonio Gallardo.
On Wednesday 22 March 2006 01:00, Jorg Heymans wrote:
Niclas Hedhman wrote:
What is being suggested is not that we mirror the whole of ibiblio, we
would only mirror the libraries that are currently hosted on cvs.a.o.
... You can point your pom to use the cvs.a.o directly.
What do you
Niclas Hedhman wrote:
You said; libraries that are currently hosted on cvs.a.o, meaning
they exist
on cvs.a.o, and can't you just tell Maven in your pom to use that repository
as well??
From what I can see the build is set up to do that. The builds fail
because apparently that repository
Hi,
Jorg Heymans wrote:
If someone can offer the bandwidth and server, i'm willing to migrate us
away from cvs.a.o. and setup a decent m2 repo where only *we* control
the poms.
Any offers? I've got some time to kill this weekend ;)
We (Luminas/SourceSense) are offering. Do you know what
On 20 Mar 2006, at 09:19, Andrew Savory wrote:
Hi,
Jorg Heymans wrote:
If someone can offer the bandwidth and server, i'm willing to
migrate us
away from cvs.a.o. and setup a decent m2 repo where only *we* control
the poms.
Any offers? I've got some time to kill this weekend ;)
We
Hi,
Pier Fumagalli wrote:
Excuse me, but can someone refresh my memory on why we went down the
Maven way? I thought it was to get rid of maintaining all those lib in
our SVN, and now someone is telling me that we actually should maintain
a full maven mirror, but tweaked because we don't like
Andrew Savory wrote:
We (Luminas/SourceSense) are offering. Do you know what sort of
requirements in terms of bandwidth and server space? We have capacity
to spare, and are happy to donate it.
Thanks, see below.
Pier Fumagalli wrote:
Excuse me, but can someone refresh my memory on why we
Andrew Savory wrote:
infrastructure problems are resolved. Actually, in hindsight, it makes
more sense to see what can be done to fix maven's repo infrastructure -
but I know nothing about ibiblio etc. and don't have time to investigate
This is being worked on by maven and infra, but it's a
On Tuesday 21 March 2006 02:32, Jorg Heymans wrote:
What is being suggested is not that we mirror the whole of ibiblio, we
would only mirror the libraries that are currently hosted on cvs.a.o.
This sounds like a really odd idea. You can point your pom to use the cvs.a.o
directly.
- the
Daniel Fagerstrom wrote:
Didn't work for me. I copied configuration files and samples as
described in
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2 and
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114085759822501w=2
and still gets the same problem as Ben reports
Carsten Ziegeler skrev:
Daniel Fagerstrom schrieb:
Carsten Ziegeler skrev:
I'm sorry if I broke something in trunk with the move to Spring or the
refactoring; I'm currently not aware of a problem as trunk is working
for me here on my machine. So if someone can come up with a bug
description or
Carsten Ziegeler skrev:
I'm sorry if I broke something in trunk with the move to Spring or the
refactoring; I'm currently not aware of a problem as trunk is working
for me here on my machine. So if someone can come up with a bug
description or stack trace I can try to fix that (if time permits).
Upayavira schrieb:
Andreas Hochsteger wrote:
I successfully built cocoon-linkrewriter using 'mvn package' with the
converted directory structure using the conversion script and 2 new and
one adopted pom file.
I wanted to attach them, but for some reasons my SMTP server rejected
them as SPAM.
Andrew Savory wrote:
Is there any way we can set up a Cocoon mirror for the time being, until
the repository problems are resolved? I'm sure several of us here can
set up a repo, and it could be the default used by Cocoon.
If someone can offer the bandwidth and server, i'm willing to migrate
Daniel Fagerstrom wrote:
It would also be very valuable if someone with Cocoon zones competence
could get the snapshot build running again
(http://svn.apache.org/maven-snapshot-repository/org/apache/cocoon/).
With the snapshots working one just need to check out the blocks that
one
Daniel Fagerstrom schrieb:
Carsten Ziegeler skrev:
I'm sorry if I broke something in trunk with the move to Spring or the
refactoring; I'm currently not aware of a problem as trunk is working
for me here on my machine. So if someone can come up with a bug
description or stack trace I can try
I'm sorry if I broke something in trunk with the move to Spring or the
refactoring; I'm currently not aware of a problem as trunk is working
for me here on my machine. So if someone can come up with a bug
description or stack trace I can try to fix that (if time permits).
Apart from that, I'll
Daniel Fagerstrom wrote:
Ralph Goers skrev:
Andrew Savory wrote:
Hi,
Ralph Goers wrote:
1. I'm pretty sure all the blocks have not been mavenized.
Is there a list of blocks to mavenise anywhere, with instructions of
how to do it? I don't mind helping with this.
The easy way to tell I
Andreas Hochsteger wrote:
Daniel Fagerstrom wrote:
Ralph Goers skrev:
Andrew Savory wrote:
Hi,
Ralph Goers wrote:
1. I'm pretty sure all the blocks have not been mavenized.
Is there a list of blocks to mavenise anywhere, with instructions of
how to do it? I don't mind helping with
Upayavira schrieb:
Andreas Hochsteger wrote:
Daniel Fagerstrom wrote:
Ralph Goers skrev:
Andrew Savory wrote:
Hi,
Ralph Goers wrote:
1. I'm pretty sure all the blocks have not been mavenized.
Is there a list of blocks to mavenise anywhere, with instructions of
how to do it? I don't mind
Andreas Hochsteger wrote:
Upayavira schrieb:
Andreas Hochsteger wrote:
Daniel Fagerstrom wrote:
Ralph Goers skrev:
Andrew Savory wrote:
Hi,
Ralph Goers wrote:
1. I'm pretty sure all the blocks have not been mavenized.
Is there a list of blocks to mavenise anywhere, with
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
I mocked-up a shell script which converts the directories from the
old blocks to the structure used by the new mavenized ones.
Don't expect too much, since there is still some more manual work to
do, but at least some easy parts can be
Carsten Ziegeler wrote:
Reinhard Poetz schrieb:
If a testcase gets broken *locally* by a developer, the developer should discuss
the change on [EMAIL PROTECTED] and then people can decide together how to proceed.
That should be the standard procedure in every development project, may it be
Andreas Hochsteger wrote:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
I mocked-up a shell script which converts the directories from the
old blocks to the structure used by the new mavenized ones.
Don't expect too much, since there is still some more manual work to
do, but at least
Vadim Gritsenko wrote:
http://marc.theaimsgroup.com/?l=xml-cocoon-devw=2r=1s=Cocoon-2.1.X+Tests+Failureq=b
Nice statistics :) I was talking about the tests in trunk.
Carsten
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
http://marc.theaimsgroup.com/?l=xml-cocoon-devw=2r=1s=Cocoon-2.1.X+Tests+Failureq=b
Nice statistics :) I was talking about the tests in trunk.
Well if tests are/were ignored in stable branch, why trunk would be any better?
Vadim
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
I mocked-up a shell script which converts the directories from the
old blocks to the structure used by the new mavenized ones.
Don't expect too much, since there is still some more manual
Andreas Hochsteger schrieb:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
I mocked-up a shell script which converts the directories from the
old blocks to the structure used by the new mavenized ones.
Don't expect too much, since
Andreas Hochsteger wrote:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
I mocked-up a shell script which converts the directories from the
old blocks to the structure used by the new mavenized ones.
Don't expect too much, since
Andreas Hochsteger wrote:
After analyzing the old blocks in more details I found the following
common directories.
It would be great, if you (or someone else involved in developing the
new blocks) can finish the mapping below ...
ok, forget my last response. I'll change it in some points:
Reinhard Poetz schrieb:
Andreas Hochsteger wrote:
After analyzing the old blocks in more details I found the following
common directories.
It would be great, if you (or someone else involved in developing the
new blocks) can finish the mapping below ...
ok, forget my last response. I'll
I successfully built cocoon-linkrewriter using 'mvn package' with the
converted directory structure using the conversion script and 2 new and
one adopted pom file.
I wanted to attach them, but for some reasons my SMTP server rejected
them as SPAM. :-(
I used the following conventions for the
Andreas Hochsteger wrote:
I successfully built cocoon-linkrewriter using 'mvn package' with the
converted directory structure using the conversion script and 2 new and
one adopted pom file.
I wanted to attach them, but for some reasons my SMTP server rejected
them as SPAM. :-(
I used the
Reinhard Poetz wrote:
I want to add some thoughts to Daniel's idea of writing some Ant script
for the build: trunk has been mavenized and split up into many modules.
The missing thing is some tool that will create a web application out of
a number of blocks. In a world of real blocks that's
Le 16 mars 06 à 08:44, Carsten Ziegeler a écrit :
...Getting a 2.3 out with the proposed plan is doable in the short
term imho...
Would it be possible to prove this without touching the current
trunk, so as not to disturb the work of those working on the blocks
and OSGI stuff? By creating
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 that explain the roadmap Daniel and I
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 that
On 3/16/06, Upayavira [EMAIL PROTECTED] wrote:
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
Reinhard Poetz schrieb:
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 that
Hi,
Tim Williams wrote:
On 3/16/06, Upayavira [EMAIL PROTECTED] wrote:
The overhead for people to work on trunk is that trunk is largely
unknown. It is my perception that many people have little confidence
that trunk actually works. Fear that it will change frequently, and that
they will
* Reinhard Poetz:
If somebody has the need of writing some deployment tool without having to
understand blocks-fw, he could write an
Ant script or an M2 Mojo that get some kind of configuration which blocks
should be installed:
configuration
blocks
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 evidence for this being true.
Carsten Ziegeler wrote:
Trunk is not working out of the box; testing the samples is really a
pain; for example I can't test the new portal version as this would
require porting all missing blocks to the new structure, getting them
compiled and more important its a rather huge effort to build
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
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
Daniel Fagerstrom wrote:
The blocks FUD
==
I'd like to remind once again that the blocks work doesn't destabilize
the traditional use of Cocoon the slightest, see
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2.
It just cannot affect that as there are no
* Sylvain Wallez:
Daniel says that classical Cocoon code doesn't depend on the
infrastructure that's being built for real blocks and OSGi. And
we seem pretty close to a full M10N. AFAIU, what's needed to
finish it is mainly the equivalent of build webapp.
Exactly!
If the above
Jean-Baptiste Quenot wrote:
* Sylvain Wallez:
Daniel says that classical Cocoon code doesn't depend on the
infrastructure that's being built for real blocks and OSGi. And
we seem pretty close to a full M10N. AFAIU, what's needed to
finish it is mainly the equivalent of build webapp.
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
BTW, I'm quite surprised that you want to go back to the messy Ant
build from 2.1.x after having argued for building Cocoon with Maven
for years. Have you lost your faith in Maven?
Same feeling here.
I honestly admit being rather clueless
Hi,
Ralph Goers wrote:
1. I'm pretty sure all the blocks have not been mavenized.
Is there a list of blocks to mavenise anywhere, with instructions of how
to do it? I don't mind helping with this.
(I could be
wrong, but I don't seem to be able to check out trunk as there is an
external
Andrew Savory wrote:
Hi,
Ralph Goers wrote:
1. I'm pretty sure all the blocks have not been mavenized.
Is there a list of blocks to mavenise anywhere, with instructions of
how to do it? I don't mind helping with this.
The easy way to tell I suppose is to check out trunk. There are a
Hi,
Ralph Goers wrote:
I first tried it at ApacheCon in early December. As I recall it was in a
whiteboard at the time. I've tried it several times since then. I've
never been able to get a Cocoon up where I could test the code I wanted
to modify. I haven't tried it since the email you
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
SNIP/
Not surprisingly I'm -1 on your points 2 and 3. If you want to continue
in that direction which IMO represents a huge step back. I insist on
that you prove that it work and that you actually have the persistence
to carry it through, on
We are really innovating, as the cited article just contains some parts
of the blocks idea. But the rest of the world is definitely catching up.
If we focus on self doubt instead of development, we will be overrunned
in this area as well.
On the more positive side it is an advantage that the
Ralph Goers skrev:
Andrew Savory wrote:
Hi,
Ralph Goers wrote:
1. I'm pretty sure all the blocks have not been mavenized.
Is there a list of blocks to mavenise anywhere, with instructions of
how to do it? I don't mind helping with this.
The easy way to tell I suppose is to check out
Reinhard Poetz wrote:
Daniel Fagerstrom wrote:
The blocks FUD
==
I'd like to remind once again that the blocks work doesn't
destabilize the traditional use of Cocoon the slightest, see
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2.
It just cannot affect
Carsten Ziegeler said the following on 15-03-2006 17:00:
At the same time the blocks stuff can continue and we are not blocking
any development.
WDYT?
+1
Bye, Helma
Il giorno 15/mar/06, alle ore 17:00, Carsten Ziegeler ha scritto:
Ok, here is a simple plan to continue.
snip/
WDYT?
I like it. I share Upayavira's and others' frustration at not
understanding (our fault entirely) what is going on in trunk and
being able to help.
Ugo
--
Ugo
Carsten Ziegeler wrote:
Ok, here is a simple plan to continue.
Please note, that the current trunk has several new things: a new core
which can be seen as a follow-up to 2.1.x, the blocks stuff and the
maven build. We can use trunk as a direct follow-up to 2.1.x without blocks!
As Bertrand
Le 15 mars 06 à 17:00, Carsten Ziegeler a écrit :
...At the same time the blocks stuff can continue and we are not
blocking
any development...
+1 on your plan!
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
The blocks FUD
==
I'd like to remind once again that the blocks work doesn't destabilize
the traditional use of Cocoon the slightest, see
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2. It
just cannot affect that as there are no dependencies from the
Daniel Fagerstrom wrote:
The blocks FUD
==
I'd like to remind once again that the blocks work doesn't destabilize
the traditional use of Cocoon the slightest, see
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=114073731515724w=2. It
just cannot affect that as there are no
71 matches
Mail list logo
