Reinhard Poetz wrote:
Some thoughts I want to share:
goal: move towards real blocks - do as much work that can be reused later
- each block has its own build system
Why? It is easier to write and maintain single ant script than 55! (we have 55
blocks right now)
Vadim
Unico Hommes wrote:
Reinhard Poetz wrote:
Unico Hommes wrote:
Some thoughts I want to share:
goal: move towards real blocks - do as much work that can be reused later
- each block has its own build system
IIRC, Nicola already started an effort for an updated build system that
features an
Carsten Ziegeler wrote:
Unico Hommes wrote:
Ok ok, I get the hint ;-)
Oh, that wasn't targetted at you, Unico, but if you have time... :)
I didn't really feel that it was. It just seems opportune that I take up
the issue since I raised it. I'll see what I can do.
But before I decide
Carsten Ziegeler wrote:
then do a painless 2.1.6 release and then spend energy on
this issue. I personally don't want to delay a 2.1.6 release
just because of a broken build system etc.
I agree, first the release (and sync) and then the change in the build system.
--
Reinhard
Unico Hommes wrote:
That is true. Is there anything holding back a 2.1.6 release btw?
Apart from the syncing there is only one test that fails according to Vadim.
So, as soon as we have synced we can release.
Carsten
Reinhard Poetz wrote:
Unico Hommes wrote:
[snip]
For splitting the eclipse project there is an additional requirement
that blocks and core directory don't overlap. Eclipse cannot deal
with overlapping projects. So that would mean that the 2.2 core move
to /repos/asf/cocoon/trunk/core .
IMO
Unico Hommes wrote:
Reinhard Poetz wrote:
Unico Hommes wrote:
[snip]
For splitting the eclipse project there is an additional requirement
that blocks and core directory don't overlap. Eclipse cannot deal
with overlapping projects. So that would mean that the 2.2 core move
to
Upayavira wrote:
Unico Hommes wrote:
Reinhard Poetz wrote:
Unico Hommes wrote:
[snip]
For splitting the eclipse project there is an additional
requirement that blocks and core directory don't overlap. Eclipse
cannot deal with overlapping projects. So that would mean that the
2.2 core move to
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Some thoughts I want to share:
goal: move towards real blocks - do as much work that can be reused later
- each block has its own build system
Why? It is easier to write and maintain single ant script than 55! (we
have 55 blocks right now)
Let me
Upayavira wrote:
Unico Hommes wrote:
Reinhard Poetz wrote:
Unico Hommes wrote:
[snip]
For splitting the eclipse project there is an additional requirement
that blocks and core directory don't overlap. Eclipse cannot deal
with overlapping projects. So that would mean that the 2.2 core move
to
Nicola Ken Barozzi wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Some thoughts I want to share:
goal: move towards real blocks - do as much work that can be reused
later
- each block has its own build system
Why? It is easier to write and maintain single ant script than 55! (we
have 55
are not experiencing the avalon build system problem
where each module had his own build file with all this complex
library and dependency handling and the final result was that
noone was able to use the build system for months. Then going
back and force from Ant to Maven etc. which in the end didn't
really
are not experiencing the avalon build system problem
where each module had his own build file with all this complex
library and dependency handling and the final result was that
noone was able to use the build system for months. Then going
back and force from Ant to Maven etc. which in the end didn't
really help
are not experiencing the avalon build system problem
where each module had his own build file with all this complex
library and dependency handling and the final result was that
noone was able to use the build system for months. Then going
back and force from Ant to Maven etc. which in the end didn't
really help
I'd like to add the ability to use an excalibur DataSourceComponent as
the ConnectionProvider for the QuartzJobScheduler's JobStore. However
the solution I had in mind results in an additional dependency on the
cocoon databases block. Not because of a compilation dependency on the
source code
Unico Hommes wrote:
I'd like to add the ability to use an excalibur DataSourceComponent as
the ConnectionProvider for the QuartzJobScheduler's JobStore. However
the solution I had in mind results in an additional dependency on the
cocoon databases block. Not because of a compilation dependency
Hi,
when David changed the descriptor to reflect the avalon restructuring,
one reference to avalon-framework was missed - it was well hidden by
Gump.
Please apply the appended patch to finally get nagged again ;-)
Cheers
Stefan
--
http://stefanbodewig.blogger.de/
Index: gump.xml
Stefan Bodewig wrote:
Hi,
when David changed the descriptor to reflect the avalon restructuring,
one reference to avalon-framework was missed - it was well hidden by
Gump.
Please apply the appended patch to finally get nagged again ;-)
now that we have SVN, could we say that gump.xml in cocoon is
Stefano Mazzocchi dijo:
now that we have SVN, could we say that gump.xml in cocoon is writeable
by all the ASF committers, just like gump? that would allow gumpers to
help out *and* the cocoon build system to still function and being more
actively maintained?
thoughts?
+1
Best Regards,
Good to know thanks !
Jorg
Joerg Heinicke wrote:
Thanks for the hint. Important is adding the dependency in gump.xml.
The blocks.properties is only generated by
build generate-blocks.properties.
Joerg
2004 14:46:23 -
@@ -140,10 +140,11 @@
#include.block.serializers=false
#-[dependency]: slide depends on jms, repository.
#include.block.slide=false
+#-[dependency]: slop is needed by tour.
#include.block.slop=false
#include.block.stx=false
#include.block.taglib=false
Thanks for the hint. Important is adding the dependency in gump.xml.
The blocks.properties is only generated by
build generate-blocks.properties.
Joerg
a dependency on the jms block in gump.xml but that
doesn't seem to work. Should there be a way declare a dependency on
another block so that all of *its* dependencies are traversed and added
to the compilation classpath as well? The other solution is to have a
copy of the same jar in the Slide block too
: dinsdag 13 januari 2004 11:54
To: [EMAIL PROTECTED]
Subject: Slide/jms dependency
I am looking into adding a class to the Slide block that
sends invalidation events over JMS so that the event caching
system can pick them up and do its work accordingly. However,
I am running into the problem
Joerg Heinicke [EMAIL PROTECTED] wrote:
Carsten is in holidays for three weeks, but maybe one of the other SN
people knows (Matthew, Guido)?? Was it planned to replace W3C DOM with
JDOM or the other way around?
I'm not familiar with the portal code and don't know of any planned
refactoring.
I think it is only a documentation fault.
I add the author to CC ([EMAIL PROTECTED])
Volker
Joerg Heinicke [EMAIL PROTECTED] wrote:
Carsten is in holidays for three weeks, but maybe one of the other SN
people knows (Matthew, Guido)?? Was it planned to replace W3C DOM with
JDOM or the
Couple of portal files:
cocoon-2.1\src\blocks\portal\java\org\apache\cocoon\portal\application\PortalApplicationConfig.java
cocoon-2.1\src\blocks\portal\java\org\apache\cocoon\portal\application\PortalApplicationConfigFactory.java
excplicitly mention JDOM in theirs Javadoc. But anywhere in
Carsten is in holidays for three weeks, but maybe one of the other SN
people knows (Matthew, Guido)?? Was it planned to replace W3C DOM with
JDOM or the other way around?
Joerg
Vadim Gritsenko wrote:
Couple of portal files:
201 - 228 of 228 matches
Mail list logo
