Wow, you propose using maven?
apparently ;-)
Ok.
hehe ...here we go again :o)
cheers
--
Torsten
On Fri, 22 Oct 2004, Stefano Mazzocchi wrote:
Giacomo Pati wrote:
The simplest possible thing would be to have a block descriptor extend
a maven POM and use maven to build them.
Wow, you propose using maven?
apparently ;-)
Ok.
blocks are very simple things and don't require special treatment so
t
Giacomo Pati wrote:
The simplest possible thing would be to have a block descriptor extend
a maven POM and use maven to build them.
Wow, you propose using maven?
apparently ;-)
blocks are very simple things and don't require special treatment so
they could be built with maven easily. As for the w
Unico Hommes wrote:
Vadim Gritsenko wrote:
I don't like renaming jars... Can we just extend gump.xml with the
info we need? In this case, for a block, we need a list of jar files
it requires from lib/optional.
The way I have it now is that for each I add an to the . We could add a library
at
Vadim Gritsenko wrote:
Unico Hommes wrote:
Vadim Gritsenko wrote:
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
Unico Hommes wrote:
Vadim Gritsenko wrote:
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
Vadim Gritsenko wrote:
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
On Thu, 21 Oct 2004, Stefano Mazzocchi wrote:
Carsten Ziegeler wrote:
Nicola Ken Barozzi wrote:
Why? It is easier to write and maintain single ant script
than 55! (we
have 55 blocks right now)
Let me answer for Reinhard :-)
If every local buildfile has
then there is not really more to maintain,
Carsten Ziegeler wrote:
Nicola Ken Barozzi wrote:
Why? It is easier to write and maintain single ant script
than 55! (we
have 55 blocks right now)
Let me answer for Reinhard :-)
If every local buildfile has
then there is not really more to maintain, but you gain in
being able to customize th
Carsten Ziegeler wrote:
Nicola Ken Barozzi wrote:
Why? It is easier to write and maintain single ant script
than 55! (we
have 55 blocks right now)
Let me answer for Reinhard :-)
If every local buildfile has
then there is not really more to maintain, but you gain in
being able to customize th
Unico Hommes wrote:
Having said that, there's no reason why we couldn't have:
trunk/blocks/.project
trunk/blocks/forms/.project
trunk/blocks/databases/.project
etc
That way, you can do it which ever way suits you.
But the core project descriptor currently is trunk/.project that
should become trun
Nicola Ken Barozzi wrote:
>
> >
> > Why? It is easier to write and maintain single ant script
> than 55! (we
> > have 55 blocks right now)
>
> Let me answer for Reinhard :-)
>
> If every local buildfile has
>
>
>
> then there is not really more to maintain, but you gain in
> being able
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 bl
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 /r
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 answe
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 /r
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 /repos/asf/cocoon/t
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 the
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
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
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 t
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 indivi
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:
>
>
> Ok ok, I get the hint ;-)
Oh, that wasn't targetted at you, Unico, but if you have time... :)
> But before I decide to do any work
> there is another issue with the blocks build system I'm dying
> to resolve. What about having only one repository location
> for bloc
Reinhard Poetz wrote:
Unico Hommes wrote:
Carsten Ziegeler wrote:
2. Move blocks to one location. /repos/asf/cocoon/trunk/blocks?
yes
3. Separate blocks build system from core build system and let one
drive the other.
Comments?
Some thoughts I want to share:
goal: move towards real blocks - do
Unico Hommes wrote:
Carsten Ziegeler wrote:
2. Move blocks to one location. /repos/asf/cocoon/trunk/blocks?
yes
3. Separate blocks build system from core build system and let one drive
the other.
Comments?
Some thoughts I want to share:
goal: move towards real blocks - do as much work that can b
Unico Hommes wrote:
What
about having only one repository location for blocks? I am so tired of
all the duplicate effort we have to do for each and every change to
blocks. It shouldn't be neccessary.
There probably isn't a small amount of work involved to get it working
Me thinks it is enough
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Just an idea; can we move ALL libraries to lib/optional, and
copy them into the WEB-INF/lib on as-needed basis, i.e. if
block included which needs a library, only then librariy is
copied over? This should be possible using the info from gump.xml.
Vadim Gritsenko wrote:
>
> Just an idea; can we move ALL libraries to lib/optional, and
> copy them into the WEB-INF/lib on as-needed basis, i.e. if
> block included which needs a library, only then librariy is
> copied over? This should be possible using the info from gump.xml...
>
> This w
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 o
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 o
31 matches
Mail list logo
