[vote] build systems

[Torsten Curdt <tc...@dff.st>]

guys I'd like to have some backup before I change what I have in mind....

1. add a "status=stable/unstable" attribute to the projects in module.xml

2. add per project jar and class dependencies to the module.xml

4. all blocks start with cocoon- (for besser visibility in gump)

5. move the scratchpad stuff into a scratchpad block. the scratchpad libs will 
go into the lib/optional dir. they will be copied into the webapp only if 
necessary

6. I'd like to move also the documentation into a block (same or separate 
block for javadocs?)

7. I'm not quite sure about this one: what about also having a 
cocoon-core-block.jar instead of handling it specially

8. the roles should go into a separate roles.jar since this needs to include 
the roles from the different blocks.

...hope everything will work as I have in mind ;-)

cheers
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: [vote] build systems

[Carsten Ziegeler <cz...@s-und-n.de>]

Torsten Curdt wrote:
> 
> Carsten, could you please try to reproduce the following:
> 
> build clean
> 
> build
> 
> check the cocoon.roles from the jar -> roles from blocks are not there
> 
> build
> 
> check the cocoon.roles from the jar -> roles from blocks are there
> 
> Sorry - I don't think it's fixed yet :-(

Ok ok, you're right (this time I double checked before I confirm it :) ).

Now, I added a fix to this to the build.xml which simply rebuilds
the cocoon.jar after the blocks are build. It's a hack, but it works.
As I fear for months, sooner or later we have to redesign the build
system, because build.xml got way too complicated and big.

Carsten

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [vote] build systems

[Torsten Curdt <tc...@dff.st>]

Carsten, could you please try to reproduce the following:

build clean

build

check the cocoon.roles from the jar -> roles from blocks are not there

build

check the cocoon.roles from the jar -> roles from blocks are there

Sorry - I don't think it's fixed yet :-(
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [vote] build systems

[Torsten Curdt <tc...@dff.st>]

On Tuesday 29 October 2002 14:41, Carsten Ziegeler wrote:
> Torsten Curdt wrote:
> > > Argh, but it did work, because when I created the portal block
> > > I took care of the build system and changed it for that.
> > >
> > > Yes I confirm now it doesn't work anymore, so we should fix it.
> >
> > yepp!
> >
> > the cocoon.jar is build first and then the roles get applied...
> > so in the build dir there is the correct cocoon.roles in the end :-/
>
> Ok, I just rechecked everything and I must say no: "It works." Forget
> my confirmation from above :) Have a look at the portal block.
> The roles declared in that block appear later on in the cocoon.jar

at least *now* I can confirm it works... no matter how ;-)

> > BTW: I just found doing a plain "build" gives me the same esql
> > problem you
> > just reported while "build installwar" works just fine *sigh*
>
> Yeah, but it's fixed now :)

excellent!
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: [vote] build systems

[Carsten Ziegeler <cz...@s-und-n.de>]

Torsten Curdt wrote:
> 
> > Argh, but it did work, because when I created the portal block
> > I took care of the build system and changed it for that.
> >
> > Yes I confirm now it doesn't work anymore, so we should fix it.
> 
> yepp!
> 
> the cocoon.jar is build first and then the roles get applied...
> so in the build dir there is the correct cocoon.roles in the end :-/
> 
Ok, I just rechecked everything and I must say no: "It works." Forget
my confirmation from above :) Have a look at the portal block.
The roles declared in that block appear later on in the cocoon.jar


> BTW: I just found doing a plain "build" gives me the same esql 
> problem you 
> just reported while "build installwar" works just fine *sigh*
> 
Yeah, but it's fixed now :)

Carsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [vote] build systems

[Torsten Curdt <tc...@dff.st>]

> Argh, but it did work, because when I created the portal block
> I took care of the build system and changed it for that.
>
> Yes I confirm now it doesn't work anymore, so we should fix it.

yepp!

the cocoon.jar is build first and then the roles get applied...
so in the build dir there is the correct cocoon.roles in the end :-/

BTW: I just found doing a plain "build" gives me the same esql problem you 
just reported while "build installwar" works just fine *sigh*

> > If you just want to add a new block - you wouldn't have to
> > rebuild the core
> > but compile that block which will produce the block and update
> > the roles.jar.
>
> I feared that you would say this, but this reminds me of a poor-mans
> concept of blocks.

thankyou! *moping*

...at least it will work - the roles is a plague anyway.

> > then let's at least polish the current build system a little...
>
> Yupp!

That's all I wanted. But once you set ball rolling... ;-)
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: [vote] build systems

[Carsten Ziegeler <cz...@s-und-n.de>]

Torsten Curdt wrote:
> 
> AFAICS it doesn't... the cocoon.jar is build before the blocks 
> are build so it 
> cannot work. I just moved precept into a block and noticed the 
> xroles does 
> not get included.
> 
Argh, but it did work, because when I created the portal block
I took care of the build system and changed it for that.

Yes I confirm now it doesn't work anymore, so we should fix it.

> If you just want to add a new block - you wouldn't have to 
> rebuild the core 
> but compile that block which will produce the block and update 
> the roles.jar.
> 
I feared that you would say this, but this reminds me of a poor-mans
concept of blocks.

> > Please, (this is not targeted at you Torsten, it's just an information)
> > let's avoid trying to implement the great block concept proposed by
> > Stefano and Giacomo silently by adding here something and fixing there
> > something. We agreed to move it to 2.2.
> 
> believe me I didn't wanted to did it right now ;-) but while moving the 
> precept stuff I found it's really not in good shape right now.
> 
> IMHO not even good enough for a 2.1 release...
> 
> > I talked with Stefano the last two days about blocks (and more),
> > and guess what, he convinced me that blocks are really cool. We
> > refined the design he already proposed and cleaned out the wrinkles.
> 
> curious to hear more!
> 
> > We will start implementing blocks as soon as 2.1 is *out*. But not
> > any sooner.
> > We both agreed on that.
> 
> then let's at least polish the current build system a little...
Yupp!

Carsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [vote] build systems

[Torsten Curdt <tc...@dff.st>]

On Tuesday 29 October 2002 12:58, Carsten Ziegeler wrote:
> Torsten Curdt wrote:
> > guys I'd like to have some backup before I change what I have in mind....
> >
> > 1. add a "status=stable/unstable" attribute to the projects in module.xml
>
> ok
>
> > 2. add per project jar and class dependencies to the module.xml
>
> ok
>
> > 4. all blocks start with cocoon- (for besser visibility in gump)
>
> ok
>
> > 5. move the scratchpad stuff into a scratchpad block. the
> > scratchpad libs will
> > go into the lib/optional dir. they will be copied into the webapp only if
> > necessary
>
> ok
>
> > 6. I'd like to move also the documentation into a block (same or separate
> > block for javadocs?)
>
> What? Do you mean all documentation into one block? Or do you mean a per
> block documentation? We discussed this several times and it was always
> voted against it - and I think we shouldn't touch the documentation
> system right now because of the current discussion about using forrest
> or not.

must have missed that one... ok

> > 7. I'm not quite sure about this one: what about also having a
> > cocoon-core-block.jar instead of handling it specially
>
> The core is not a block, so we should not call it a block.

wasn't quite sure about this, too

> > 8. the roles should go into a separate roles.jar since this needs
> > to include
> > the roles from the different blocks.
>
> Why this? Adding roles from within a block during build already works
> and putting it into a separate roles.jar doesn't help.

AFAICS it doesn't... the cocoon.jar is build before the blocks are build so it 
cannot work. I just moved precept into a block and noticed the xroles does 
not get included.

If you just want to add a new block - you wouldn't have to rebuild the core 
but compile that block which will produce the block and update the roles.jar.

> Please, (this is not targeted at you Torsten, it's just an information)
> let's avoid trying to implement the great block concept proposed by
> Stefano and Giacomo silently by adding here something and fixing there
> something. We agreed to move it to 2.2.

believe me I didn't wanted to did it right now ;-) but while moving the 
precept stuff I found it's really not in good shape right now.

IMHO not even good enough for a 2.1 release...

> I talked with Stefano the last two days about blocks (and more),
> and guess what, he convinced me that blocks are really cool. We
> refined the design he already proposed and cleaned out the wrinkles.

curious to hear more!

> We will start implementing blocks as soon as 2.1 is *out*. But not
> any sooner.
> We both agreed on that.

then let's at least polish the current build system a little...
--
Torsten

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

RE: [vote] build systems

[Carsten Ziegeler <cz...@s-und-n.de>]

Torsten Curdt wrote:
>
> guys I'd like to have some backup before I change what I have in mind....
>
> 1. add a "status=stable/unstable" attribute to the projects in module.xml
ok
>
> 2. add per project jar and class dependencies to the module.xml
ok
>
> 4. all blocks start with cocoon- (for besser visibility in gump)
ok
>
> 5. move the scratchpad stuff into a scratchpad block. the
> scratchpad libs will
> go into the lib/optional dir. they will be copied into the webapp only if
> necessary
ok
>
> 6. I'd like to move also the documentation into a block (same or separate
> block for javadocs?)
What? Do you mean all documentation into one block? Or do you mean a per
block documentation? We discussed this several times and it was always
voted against it - and I think we shouldn't touch the documentation
system right now because of the current discussion about using forrest
or not.

>
> 7. I'm not quite sure about this one: what about also having a
> cocoon-core-block.jar instead of handling it specially
>
The core is not a block, so we should not call it a block.

> 8. the roles should go into a separate roles.jar since this needs
> to include
> the roles from the different blocks.
>
Why this? Adding roles from within a block during build already works
and putting it into a separate roles.jar doesn't help.

Please, (this is not targeted at you Torsten, it's just an information)
let's avoid trying to implement the great block concept proposed by
Stefano and Giacomo silently by adding here something and fixing there
something. We agreed to move it to 2.2.

I talked with Stefano the last two days about blocks (and more),
and guess what, he convinced me that blocks are really cool. We
refined the design he already proposed and cleaned out the wrinkles.
We will start implementing blocks as soon as 2.1 is *out*. But not
any sooner.
We both agreed on that.

Carsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org