You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2003/02/28 09:29:13 UTC
[New build system] Status of samples
Hi,
is anybody working on getting the samples working again with
the new build system?
What is missing? I can help, if required.
(PS: I really need the samples working again soon)
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
Re: [New build system] Status of samples
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 28/02/2003 11.50:
> Carsten Ziegeler wrote:
...
> > 1) Refactor the project-info.xml to split in several files contained >
> > in the blocks themselves.
> > Just like Eclipse plugin.xml files in their plugins, a plugin is
> > installed by just dropping it in the plugins dir. Usecase: This will
> > make it easy for me to maintain my JavadocSource block (or any
> > (external) block for that matter), now I need to sync each time when
> > project-info.xml changes ;-)
>
> This is called for, I totally agree. I was going to tackle that problem
> today, anybody against this?
>
> is anything using that project-info.xml file or is just a left-over from
> the old build system?
It's the Gump descriptor.
Before, Gump used that directly to run, but then Sam wanted to tackle
the compilation problems himself (thanks Sam :-) and copied it over to
the Gump repo.
To keep the two in synch IMHO it should be only one, so I'd like to see
ours being used for both Gump, the build, and jar check-update.
...
> Refactoring the project-info.xml file requires a special block ant task,
> I'll try to make it more usable than the current (admittedly somewhat
> hacky) property-based solution.
Can you please expand on this?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [New build system] Status of samples
Posted by Bart Guijt <b....@chello.nl>.
From: "Stefano Mazzocchi" <st...@apache.org>
> Samples are 'integration oriented' while blocks are 'separation oriented'.
Yes indeed they are.
> Get the 'hello-world' sample directory: this depends on many different
> blocks (fop,batik and so on). Refactoring this into pieces and XconfTool
> patches is a major pain in the ass.
>
> Even more: some samples require code to be compiled. In some senses,
> each of these sample folder (for example, flow or xmlform) looks like a
> microblock on its own.... but making each sample folder as a block is
> clearly overwelming and would ruin the concept.
Why would making each sample a block ruin the concept? (...am I ignorant?
;-)
Clearly there must be some separation between 'sample' blocks and
'component' blocks, but this
should be no more than a subdirectory separation IMHO.
> But having just *one* sample block is useless since we are back on the
> hello-world iper-dependent problem.
>
> Finally, I think the Cocoon build should also allow you to build your
> own cocoon web site. In this case, your stuff should becomes nothing
> different from a microblock. (please, don't start using this
> terminology, it sucks, it's just to give you the idea)
I would definitely love this: just drop-in your block and hit build!
> I spent last night looking at how very complex java software is built
> (netbeans for example) and it seems that we are unique in such a highly
> fragmented yet dependency-intensive behavior.
>
> So I'm definately stuck.
>
> Bart Guijt wrote:
>
> > 2) Have each sample have its own block, which depends on the block(s)
> > declaring the components they need.
> > IIRC the infrastructure to support this is already there. Usecase: The
> > XMLForm sample(s) use the databases block, XMLForm block and the Mail
> > block. Having the XMLForm block depend on the Mail block is silly, of
> > course.
>
> So, what do you propose for those samples that depend on many different
> blocks?
If you refer to the hello-world like samples, I think there are two issues
here:
1) Perhaps the samples should be 'rotated' 90 degrees, e.g. having a
(collection of) samples per
block instead of having a 'subject' of samples (e.g. 'hello world') over
many blocks;
2) What is the dependency direction? i.e. are (parts of) the samples built
when its dependend
blocks are included, or are the blocks built if either it is included
directly (-Dinclude...) or
another block/sample depends on it (like Ant target dependencies)?
Other than that, what is wrong with a sample(block) depending on as many
other blocks necessary?
This is the perfect way to find out what blocks are needed to implement an
application which
resembles the sample (e.g., XMLForm). To build Cocoon with a sample, just
specify the include
parameter at buildtime and Cocoon builds with all dependend blocks included.
> > 3) Instead of exclude-block-xxx properties, use the include-block-xxx
> > properties in file blocks.properties (or accept both - just like Ant's
> > <fileset> include/exclude attributes).
> > Let the build process figure out what the dependencies between blocks
> > are. Usecase: If I need to test a certain block, I don't want to set
> > each exclude-property to true, while hoping not to forget anything.
>
> Refactoring the project-info.xml file requires a special block ant task,
> I'll try to make it more usable than the current (admittedly somewhat
> hacky) property-based solution.
>
> Suggestions on how to do this are welcome.
>
> > Again, I don't want to interfere with your own ideas, I just thought
> > this proposal would do it because it is simple, most necessary
> > infrastructure is already there and I'd like to build my JavadocSource
> > stuff again ;-)
>
> Thansk, your suggestions are precious and resonate with my planned line
> of action.
Thanks for your appreciation.
Ciao,
Bart Guijt
Re: [New build system] Status of samples
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Friday, February 28, 2003, at 02:44 PM, Stefano Mazzocchi wrote:
> Jeremy Quinn wrote:
>> On Friday, February 28, 2003, at 10:50 AM, Stefano Mazzocchi wrote:
>>> Finally, I think the Cocoon build should also allow you to build
>>> your own cocoon web site. In this case, your stuff should becomes
>>> nothing different from a microblock. (please, don't start using this
>>> terminology, it sucks, it's just to give you the idea)
>>>
>> I completely agree. (but I have no suggestions for a solution, sorry)
>
> don't worry, we'll come up with a solution collaboratively.
I am confidant of that too ;)
>
>> One of the trickiest things to do with Cocoon is to update an
>> existing webapp with a new version of the code and configs.
>
> Yep!
>
>> The configs pose the largest problem. 1) they change often, 2) you
>> often have to modify them with your own datasources (etc.).
>
> A solution for this is already designed into the COB concept since
> each COB (the real cocoon blocks, not the static poor-man version we
> have today) will have their own sitemap, configurations and roles.
>
> And they will be exposed to those blocks that depend on these
> transparently.
>
> But we need a much better avalon container to be able to support this
> concept.
I remember the discussions.
>
>> While it is important to have a simple build, so you can see it works
>> out of the box (as we have now), I am looking at the scenario whereby
>> a user wants to update an existing cocoon installation with a fresh
>> update from CVS, first for testing, then for production. Or wants to
>> build an installation of samples.
>> so I see 4 common scenarios :
>> 1) a 'test' build and run (we have that and it's great!)
>
> yes, I wanted to reach this point first and I think I did.
agreed :)
>
>> 2) a 'samples' build and run
>
> This is the next thing to tackle.
There are lots of people on Users, wondering where the samples are.
I know you want to find the right way of doing it, and I applaud your
efforts, but it is not going to happen overnight.
I don't know if it possible to make the samples work at all ATM. But if
there is a way, it would be good to make a note about it in the
install.txt file, as a short-term work around.
>
>> 3) an 'update' build and run (on an internal testing port)
>> 4) an 'update' build and run (on a production port)
>
> Without a complete redesign of the way Cocoon handles components and
> internal dependencies this is going to be tricky to say the least.
> Hacky for sure.
>
Yeah, I can only think of the hacks ATM ;)
All this work will pay off in many ways.
> During the last few months I thought about forking Cocoon and work on
> my own tree until a new architecture for block loading was in place,
> but I feared that this move would have created too much social
> friction (been there, done that), so I'm choosing an evolutionary path
> which might be rather annoying for those working on the tree (Carsten
> already expressed his feelings about this) but keeps the community
> together.
>
I am sure we are all glad you did not do that =:-O
> This evolutionary path goes thru creating a cleaner build system and
> really factors things out on a dependency base.
>
The evolutionary path is good it is pragmatic.
I guessed some frustration on your part, was the trigger for you to
tackle this. But then, that is how this community works ;)
> I do have an architectural solution that will solve *all* your
> usability problems and I outlined it in my COB proposal.
+1
> But I want to release Cocoon 2.1 before even attempting to do such a
> major refactor.
So we need a temporary solution for various things.
> At that point, 2.1.x will solidify while the brave men between us will
> tear everything apart and start over with Cocoon 2.2 on a new CVS
> module.
>
> When I say "tear everythign apart" I don't want you to worry: cocoon
> is so well architected internally that we can redesign everything
> inside without having to touch *ANY* of the contracts with the > outside.
>
> This is why I see this as Cocoon 2.2 instead of 3.0: there will be
> complete component-level back compatibility and your webapps will work
> just fine.
>
> But this is the future.
Sounds good to me.
> For now, what we can do is to refactor things so they are cleaner.
Well, I'll keep on testing ;)
> For the 'update' scenario, we'll do some hacks for now while we work
> on a serious solution for the next generation.
>
>> I am sorry I do not actually have any solutions, I am just thinking
>> about what I reckon people want to be able to do easily.
>
> The solutions are already there, Jeremy, trust me.
I do ;)
regards Jeremy
Re: [New build system] Status of samples
Posted by Stefano Mazzocchi <st...@apache.org>.
Jeremy Quinn wrote:
>
> On Friday, February 28, 2003, at 10:50 AM, Stefano Mazzocchi wrote:
>
>> Finally, I think the Cocoon build should also allow you to build your
>> own cocoon web site. In this case, your stuff should becomes nothing
>> different from a microblock. (please, don't start using this
>> terminology, it sucks, it's just to give you the idea)
>>
>
> I completely agree. (but I have no suggestions for a solution, sorry)
don't worry, we'll come up with a solution collaboratively.
> One of the trickiest things to do with Cocoon is to update an existing
> webapp with a new version of the code and configs.
Yep!
> The configs pose the largest problem. 1) they change often, 2) you often have to modify them
> with your own datasources (etc.).
A solution for this is already designed into the COB concept since each
COB (the real cocoon blocks, not the static poor-man version we have
today) will have their own sitemap, configurations and roles.
And they will be exposed to those blocks that depend on these transparently.
But we need a much better avalon container to be able to support this
concept.
> While it is important to have a simple build, so you can see it works
> out of the box (as we have now), I am looking at the scenario whereby a
> user wants to update an existing cocoon installation with a fresh update
> from CVS, first for testing, then for production. Or wants to build an
> installation of samples.
>
> so I see 4 common scenarios :
>
> 1) a 'test' build and run (we have that and it's great!)
yes, I wanted to reach this point first and I think I did.
> 2) a 'samples' build and run
This is the next thing to tackle.
> 3) an 'update' build and run (on an internal testing port)
> 4) an 'update' build and run (on a production port)
Without a complete redesign of the way Cocoon handles components and
internal dependencies this is going to be tricky to say the least. Hacky
for sure.
During the last few months I thought about forking Cocoon and work on my
own tree until a new architecture for block loading was in place, but I
feared that this move would have created too much social friction (been
there, done that), so I'm choosing an evolutionary path which might be
rather annoying for those working on the tree (Carsten already expressed
his feelings about this) but keeps the community together.
This evolutionary path goes thru creating a cleaner build system and
really factors things out on a dependency base.
I do have an architectural solution that will solve *all* your usability
problems and I outlined it in my COB proposal.
But I want to release Cocoon 2.1 before even attempting to do such a
major refactor. At that point, 2.1.x will solidify while the brave men
between us will tear everything apart and start over with Cocoon 2.2 on
a new CVS module.
When I say "tear everythign apart" I don't want you to worry: cocoon is
so well architected internally that we can redesign everything inside
without having to touch *ANY* of the contracts with the outside.
This is why I see this as Cocoon 2.2 instead of 3.0: there will be
complete component-level back compatibility and your webapps will work
just fine.
But this is the future.
For now, what we can do is to refactor things so they are cleaner.
For the 'update' scenario, we'll do some hacks for now while we work on
a serious solution for the next generation.
> I am sorry I do not actually have any solutions, I am just thinking
> about what I reckon people want to be able to do easily.
The solutions are already there, Jeremy, trust me.
> Thanks for all the hard work you are putting in.
You're welcome.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: [New build system] Status of samples
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
On Friday, February 28, 2003, at 10:50 AM, Stefano Mazzocchi wrote:
> Finally, I think the Cocoon build should also allow you to build your
> own cocoon web site. In this case, your stuff should becomes nothing
> different from a microblock. (please, don't start using this
> terminology, it sucks, it's just to give you the idea)
>
I completely agree. (but I have no suggestions for a solution, sorry)
One of the trickiest things to do with Cocoon is to update an existing
webapp with a new version of the code and configs. The configs pose the
largest problem. 1) they change often, 2) you often have to modify them
with your own datasources (etc.).
While it is important to have a simple build, so you can see it works
out of the box (as we have now), I am looking at the scenario whereby a
user wants to update an existing cocoon installation with a fresh
update from CVS, first for testing, then for production. Or wants to
build an installation of samples.
so I see 4 common scenarios :
1) a 'test' build and run (we have that and it's great!)
2) a 'samples' build and run
3) an 'update' build and run (on an internal testing port)
4) an 'update' build and run (on a production port)
Where the 'update' build will build _into_ an existing webapp, or for
testing, build _using_ an existing webapp. (Where 'webapp' obviously
means the set of sitemaps/xslt/xml etc.)
I am sorry I do not actually have any solutions, I am just thinking
about what I reckon people want to be able to do easily.
Thanks for all the hard work you are putting in.
regards Jeremy
Re: Gump Integration
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 28/02/2003 17.41:
...
>
>
> Cocoon will (sooner or later) move to an indirect dependency graph. This
> will require a special build system, probably with special ant tasks. I
> think we'll make an effort to make these tasks bootstrappable with basic
> Ant and JAXP dependencies. This will keep everybody happy and will make
> developing the ant tasks easier.
>
> How can this be reflected in gump? It is algorithmically possible to
> generate a directed dependency graph from an indirected dependency one.
> So it will be possible to generate a gump-digestible project descriptor,
> but only dynamically: doing it by hand will be a horrible task.
Well, Jenny takes all the descriptors and merges them... se below...
> So, I believe that the best thing we can do is to expose two different
> projects to gump:
>
> - cocoon core
> - cocoon blocks
+1
Each Gump module is a coherent set of <project>s
> the first will be a normal project, with the usual direct dependencies.
>
> the second will be a different type of project, where the project
> descriptor will have to be dynamically generated by the analysis of the
> indirect dependency graph of the cocoon blocks.
>
> The last alternative is to include indirect dependencies on gump itself,
> but i don't think this is worth the effort.
Gump builds *defined* projects, not "generic" ones. Direct dependencies
are good, because they are an *explicit* contract. IMHO making the gump
descriptor generated from our descriptors, is a good KISS solution.
"Indirect" dependencies are done in Java via interfaces. I don't see how
it can be a problem, as long as we have blocks depend on "interface"
blocks.
No?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Gump Integration
Posted by Stefano Mazzocchi <st...@apache.org>.
Sam Ruby wrote:
> Stefano Mazzocchi wrote:
>
>>
>>> - apart from that, I don't think so. Isn't this a gump descriptor?
>>
>>
>> I just made it became so. Previously it was just a copy and the real
>> descriptor was in the jakarta-gump repository. Now, Gump picks it up
>> from here so this means we have to keep it updated.
>
>
> My two cents: what you just did was significantly reduce the number of
> people who can keep this updated. My experience in the past has been
> that this always is a bad thing, but perhaps Cocoon will prove me wrong.
I'm aware of the fact that it significantly reduced the number of
people, but I believe that keeping project descriptors in gump is
against the concept of continous integration itself.
Gump nags if there is a failed build, but doesn't nag if dependencies
are broken. Fair enough.
The problem is that Gump was designed to expect *all* projects to be
equally generated from source. I think this is a mistake.
Gump should nag if a dependend library is not found because that's a
problem with the project build and it's the project's concern to keep it
up-to-date.
in the past, several non-cocoon people and a few cocoon developers cared
about gump descriptors, I want that reversed: all cocoon developers care
and a few non-cocoon developers nag us if there is something wrong.
we need more continous integration and this is done only if more people
*here* care about the process, not on gump-land.
>>> For me it looks totally confusing anyway.
>>
>>
>> I totally agree, even if the choice of separating blocks into their
>> own gump projects makes it easier to obtain a clean cocoon run in Gump
>> by lowering the dependency needs for the core (Sam, did we ever get a
>> clean Cocoon2 gump build?)
>
>
> We have gotten close, but we have never to my knowledge gotten a clean
> gump build of cocoon.
which shows pretty evidently we have a problem.
>>> So I'm +1 on removing it and
>>> replacing it with per block-versions that use a better XML syntax.
>>> For pluggable blocks we need this anyway.
>>
>>
>> Yes, completely.
>>
>> Sam, is it possible to have Gump obtain a dynamically generated
>> project descriptor? what would allow us to keep our block descriptors
>> as we like and generate a gump descriptor dynamically.
>>
>> Yes, I know that it doesn't change that often and that we could file
>> it into the jakarta-gump repository at need, but I'm sure that people
>> will forget to do it, or, even worse, update it by hand.
>
>
> There are a number of answers to this question, each of them fairly
> lengthy. I'll give short answers and will expand on each if there is
> interest.
ok
> First, my feeling is that if there is a better syntax, I would like to
> simply adopt it. I don't care what the definition of better is:
> technical, community, whatever.
It's not a matter of syntax, Sam. It's a matter of concepts.
Gump has no notion of polymorphic behaviors, nor I think it should.
Here is a potential descriptor for our blocks
<block xmlns="http://apache.org/cocoon/block">
<name>My Stuff</name>
<identifier>http://myblock.com/block/mystuff</identifier>
<version>2.3</version>
<creator>
<author name="Alice" email="alice@myblock.com"/>
<author name="Bob" email="bob@myblock.com"/>
<affiliation>MyBlock Corp.</affiliation>
</creator>
<description>This is my stuff</description>
<location url="http://myblock.com/block/mystuff-2.3.cob"
latest="http://myblock.com/block/mystuff.cob"/>
<license url="http://myblock.com/legal/license"/>
<roles>
<implements uri="http://apache.org/cocoon/block/whatever"/>
</roles>
<dependencies>
<requires uri="http://apache.org/cocoon/block/something"/>
<requires uri="http://apache.org/cocoon/block/and-something-else"/>
</dependencies>
<extends uri="http://http://myblock.com/block/myolderstuff"
version="2.x+"/>
</block>
as you can see, there is no information included in this descriptor
about "what" implementation of the required dependencies this block will
use.
The information can be inferred *only* after crawling all block
descriptors and creating a topological map of the dependencies.
While Gump has a much simpler 'direct' concept of dependency, Cocoon
COBs will have an indirect dependency concept, as for Component-Oriented
Programming polymorphic practices.
Gump does
xml-forrest -> xml-cocoon2
while Cocoon will need
block1 -(requires behavior)-> behavior <-(implements behavior)- block2
thus
block1 -(in this particular setup depends on)-> block2
It's a two step process.
There are multiple and extremely important reasons for this additional
complexity but I don't think Gump will ever benefit from this since
projects are generally directly dependant.
On the other hand, it doesn't surprise me that the projects that are
most difficult to automate with Gump are Cocoon Blocks and Avalon
Excalibur, both containers of COP-oriented components.
> Second, I care very deeply that the process is bootstrapable.
Fair enough.
> I don't want the dynamic generation of a descriptor to depend on the
> building of
> a generator which is described by a descriptor which is generated
> dynamically by that generator...
There are two solutions on the table:
1) Cocoon exposes itself and its blocks as Gump projects
2) Cocoon exposes its entire self as one project to Gump
In the past we had 2), then we moved to 1)... despite polluting the gump
result table with *-block projects who don't really indicate they belong
to cocoon (unless one looks at the dependencies), they provide the
advantage of reducing the dependencies needed by the cocoon core to be
built.
the fact that even with 1) cocoon never got to compile indicates the
point is pretty moot anyway. the problem might well reside on how
excalibur works with gump.
Cocoon will (sooner or later) move to an indirect dependency graph. This
will require a special build system, probably with special ant tasks. I
think we'll make an effort to make these tasks bootstrappable with basic
Ant and JAXP dependencies. This will keep everybody happy and will make
developing the ant tasks easier.
How can this be reflected in gump? It is algorithmically possible to
generate a directed dependency graph from an indirected dependency one.
So it will be possible to generate a gump-digestible project descriptor,
but only dynamically: doing it by hand will be a horrible task.
So, I believe that the best thing we can do is to expose two different
projects to gump:
- cocoon core
- cocoon blocks
the first will be a normal project, with the usual direct dependencies.
the second will be a different type of project, where the project
descriptor will have to be dynamically generated by the analysis of the
indirect dependency graph of the cocoon blocks.
The last alternative is to include indirect dependencies on gump itself,
but i don't think this is worth the effort.
Comments?
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
Re: [New build system] Status of samples
Posted by Sam Ruby <ru...@apache.org>.
Nick Chalko wrote:
> Sam Ruby wrote:
>
>> Carsten Ziegeler wrote:
>> >> First, my feeling is that if there is a better syntax, I would like
>> >> to simply adopt it. I don't care what the definition of better is:
>> >> technical, community, whatever.
>> >>
>> > So where is the right place to discuss the syntax? In short: Cocoon
>> > has many dependencies but the description for the dependencies is a
>> > little bit confusing (at least for me), and has some shortcommings.
>> > There is for example no common naming scheme for dependencies, so you
>> > can for example call fop either fop, or xml-fop or whatever you want.
>>
>> I'd recommend the gump@jakarta.apache.org mailing list. But I am
>> willing to discuss it anywhere. At the moment, the following is
>> effectively the equivalent of an alias:
>>
>> <project name="jakarta-ant">
>> <depend project="ant" inherit="jars"/>
>> </project>
>>
>> We could make this simpler with a new <alias/> tag that has the same
>> effect. Thoughts?
>
> I don't follow the coocon list, please describe the <alias?> tag.
You've seen the same problem with the names that Maven and the names
that Gump uses for a given project not matching.
The example above uses "fop" and "xml-fop". The question is how to make
these two be synonyms. When Stephen renamed jakarta-ant to ant, he left
behind a project by the old name that depends on the project with the
new name and exports the same jars.
Effectively, an alias.
- Sam Ruby
Re: [New build system] Status of samples
Posted by Nick Chalko <ni...@chalko.com>.
Sam Ruby wrote:
> Carsten Ziegeler wrote:
> >> First, my feeling is that if there is a better syntax, I would like
> >> to simply adopt it. I don't care what the definition of better is:
> >> technical, community, whatever.
> >>
> > So where is the right place to discuss the syntax? In short: Cocoon
> > has many dependencies but the description for the dependencies is a
> > little bit confusing (at least for me), and has some shortcommings.
> > There is for example no common naming scheme for dependencies, so you
> > can for example call fop either fop, or xml-fop or whatever you want.
>
> I'd recommend the gump@jakarta.apache.org mailing list. But I am
> willing to discuss it anywhere. At the moment, the following is
> effectively the equivalent of an alias:
>
> <project name="jakarta-ant">
> <depend project="ant" inherit="jars"/>
> </project>
>
> We could make this simpler with a new <alias/> tag that has the same
> effect. Thoughts?
I don't follow the coocon list, please describe the <alias?> tag.
>
> - Sam Ruby
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gump-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: gump-help@jakarta.apache.org
--
Nick Chalko Show me the code.
Centipede
Ant + autodownloadable build plugins + needed jars autodownload.
http://krysalis.org/centipede
---------------------------------------------------------------------
RE: [New build system] Status of samples
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> -----Original Message-----
> From: Sam Ruby [mailto:rubys@apache.org]
> Sent: Friday, February 28, 2003 5:36 PM
> To: cocoon-dev@xml.apache.org
> Cc: gump@jakarta.apache.org
> Subject: Re: [New build system] Status of samples
>
>
> Carsten Ziegeler wrote:
> >> First, my feeling is that if there is a better syntax, I would like
> >> to simply adopt it. I don't care what the definition of better is:
> >> technical, community, whatever.
> >>
> > So where is the right place to discuss the syntax? In short: Cocoon
> > has many dependencies but the description for the dependencies is a
> > little bit confusing (at least for me), and has some shortcommings.
> > There is for example no common naming scheme for dependencies, so you
> > can for example call fop either fop, or xml-fop or whatever you want.
>
> I'd recommend the gump@jakarta.apache.org mailing list. But I am
> willing to discuss it anywhere. At the moment, the following is
> effectively the equivalent of an alias:
>
> <project name="jakarta-ant">
> <depend project="ant" inherit="jars"/>
> </project>
>
> We could make this simpler with a new <alias/> tag that has the same
> effect. Thoughts?
>
I'm not sure if this helps, this ends up in many aliases. Looking at
the current thread about a apache jar repository, I think we have the
same problem here: useful names.
I think, for each project there should only be one definite name
which is the project name. So, for fop I guess the project name is rather
xml-fop (as the cvs) than fop - so in the gump descriptors only xml-fop
should be used and nothing else.
And this leads to the names of the jars for those projects, which means
the jar should be named "xml-fop-VERSION.jar".
For example, you can simply test for the availability of a library by
searching for a jar name "PROJECT-ANY_VERSION.jar" or "PROJECT-*.jar".
So, at the end, this has not so much to do with gump, but with a common
naming scheme for asf projects.
Carsten
Re: [New build system] Status of samples
Posted by Sam Ruby <ru...@apache.org>.
Carsten Ziegeler wrote:
>> First, my feeling is that if there is a better syntax, I would like
>> to simply adopt it. I don't care what the definition of better is:
>> technical, community, whatever.
>>
> So where is the right place to discuss the syntax? In short: Cocoon
> has many dependencies but the description for the dependencies is a
> little bit confusing (at least for me), and has some shortcommings.
> There is for example no common naming scheme for dependencies, so you
> can for example call fop either fop, or xml-fop or whatever you want.
I'd recommend the gump@jakarta.apache.org mailing list. But I am
willing to discuss it anywhere. At the moment, the following is
effectively the equivalent of an alias:
<project name="jakarta-ant">
<depend project="ant" inherit="jars"/>
</project>
We could make this simpler with a new <alias/> tag that has the same
effect. Thoughts?
- Sam Ruby
Re: [New build system] Status of samples
Posted by Sam Ruby <ru...@apache.org>.
Carsten Ziegeler wrote:
>> First, my feeling is that if there is a better syntax, I would like
>> to simply adopt it. I don't care what the definition of better is:
>> technical, community, whatever.
>>
> So where is the right place to discuss the syntax? In short: Cocoon
> has many dependencies but the description for the dependencies is a
> little bit confusing (at least for me), and has some shortcommings.
> There is for example no common naming scheme for dependencies, so you
> can for example call fop either fop, or xml-fop or whatever you want.
I'd recommend the gump@jakarta.apache.org mailing list. But I am
willing to discuss it anywhere. At the moment, the following is
effectively the equivalent of an alias:
<project name="jakarta-ant">
<depend project="ant" inherit="jars"/>
</project>
We could make this simpler with a new <alias/> tag that has the same
effect. Thoughts?
- Sam Ruby
RE: [New build system] Status of samples
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sam Ruby wrote:
> > I totally agree, even if the choice of separating blocks into their own
> > gump projects makes it easier to obtain a clean cocoon run in Gump by
> > lowering the dependency needs for the core (Sam, did we ever
> get a clean
> > Cocoon2 gump build?)
>
> We have gotten close, but we have never to my knowledge gotten a clean
> gump build of cocoon.
>
Not exactly, months ago gump was happy, and then to many changes appeared
in dependent projects, so...but that's the use case for gump, right. So,
now we know that we (or others) have to change something.
> First, my feeling is that if there is a better syntax, I would like to
> simply adopt it. I don't care what the definition of better is:
> technical, community, whatever.
>
So where is the right place to discuss the syntax?
In short: Cocoon has many dependencies but the description for the
dependencies
is a little bit confusing (at least for me), and has some shortcommings.
There
is for example no common naming scheme for dependencies, so you can for
example
call fop either fop, or xml-fop or whatever you want.
Carsten
Re: [New build system] Status of samples
Posted by Sam Ruby <ru...@apache.org>.
Stefano Mazzocchi wrote:
>
>> - apart from that, I don't think so. Isn't this a gump descriptor?
>
> I just made it became so. Previously it was just a copy and the real
> descriptor was in the jakarta-gump repository. Now, Gump picks it up
> from here so this means we have to keep it updated.
My two cents: what you just did was significantly reduce the number of
people who can keep this updated. My experience in the past has been
that this always is a bad thing, but perhaps Cocoon will prove me wrong.
>> For me it looks totally confusing anyway.
>
> I totally agree, even if the choice of separating blocks into their own
> gump projects makes it easier to obtain a clean cocoon run in Gump by
> lowering the dependency needs for the core (Sam, did we ever get a clean
> Cocoon2 gump build?)
We have gotten close, but we have never to my knowledge gotten a clean
gump build of cocoon.
>> So I'm +1 on removing it and
>> replacing it with per block-versions that use a better XML syntax.
>> For pluggable blocks we need this anyway.
>
> Yes, completely.
>
> Sam, is it possible to have Gump obtain a dynamically generated project
> descriptor? what would allow us to keep our block descriptors as we like
> and generate a gump descriptor dynamically.
>
> Yes, I know that it doesn't change that often and that we could file it
> into the jakarta-gump repository at need, but I'm sure that people will
> forget to do it, or, even worse, update it by hand.
There are a number of answers to this question, each of them fairly
lengthy. I'll give short answers and will expand on each if there is
interest.
First, my feeling is that if there is a better syntax, I would like to
simply adopt it. I don't care what the definition of better is:
technical, community, whatever.
Second, I care very deeply that the process is bootstrapable. I don't
want the dynamic generation of a descriptor to depend on the building of
a generator which is described by a descriptor which is generated
dynamically by that generator...
> Suggestions?
Let's jointly work to improve the syntax and ensure that the descriptors
can still be updated by the people who have been maintaining it to date:
http://cvs.apache.org/viewcvs/jakarta-gump/project/Attic/xml-cocoon2.xml
- Sam Ruby
Re: [New build system] Status of samples
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stefano Mazzocchi wrote, On 28/02/2003 15.19:
...
> Sam, is it possible to have Gump obtain a dynamically generated project
> descriptor? what would allow us to keep our block descriptors as we like
> and generate a gump descriptor dynamically.
We can make a Gump descriptor for each project, but it won't help the
build. I kept it together to make it easier to make a single buildfile
manage it. If we start splitting it, it will be a pain to manage. Take
for example (again) Avalon Excalibur.
I've played with these permutations quite a lot, and I've come to the
conclusion that each CVS module must have one descriptor.
When the blocks will be indipendent, and that means have their own set
of committers, life, releases, etc, then we can make a separate descriptor.
If you build all together, keep a single descriptor. If you build based
on released versions, you can split.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: [New build system] Status of samples
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> Stefano Mazzocchi wrote:
>
>> >
>> > 1) Refactor the project-info.xml to split in several files contained >
>> > in the blocks themselves.
>> > Just like Eclipse plugin.xml files in their plugins, a plugin is
>> > installed by just dropping it in the plugins dir. Usecase: This will
>> > make it easy for me to maintain my JavadocSource block (or any
>> > (external) block for that matter), now I need to sync each time when
>> > project-info.xml changes ;-)
>>
>>This is called for, I totally agree. I was going to tackle that problem
>>today, anybody against this?
>>
>>is anything using that project-info.xml file or is just a left-over from
>>the old build system?
>>
>
> The build mechanism uses it to generate the build file; but I guess you
> know this
yes :)
> - apart from that, I don't think so. Isn't this a gump descriptor?
I just made it became so. Previously it was just a copy and the real
descriptor was in the jakarta-gump repository. Now, Gump picks it up
from here so this means we have to keep it updated.
> For me it looks totally confusing anyway.
I totally agree, even if the choice of separating blocks into their own
gump projects makes it easier to obtain a clean cocoon run in Gump by
lowering the dependency needs for the core (Sam, did we ever get a clean
Cocoon2 gump build?)
> So I'm +1 on removing it and
> replacing it with per block-versions that use a better XML syntax.
> For pluggable blocks we need this anyway.
Yes, completely.
Sam, is it possible to have Gump obtain a dynamically generated project
descriptor? what would allow us to keep our block descriptors as we like
and generate a gump descriptor dynamically.
Yes, I know that it doesn't change that often and that we could file it
into the jakarta-gump repository at need, but I'm sure that people will
forget to do it, or, even worse, update it by hand.
Suggestions?
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
RE: [New build system] Status of samples
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
> >
> > 1) Refactor the project-info.xml to split in several files contained >
> > in the blocks themselves.
> > Just like Eclipse plugin.xml files in their plugins, a plugin is
> > installed by just dropping it in the plugins dir. Usecase: This will
> > make it easy for me to maintain my JavadocSource block (or any
> > (external) block for that matter), now I need to sync each time when
> > project-info.xml changes ;-)
>
> This is called for, I totally agree. I was going to tackle that problem
> today, anybody against this?
>
> is anything using that project-info.xml file or is just a left-over from
> the old build system?
>
The build mechanism uses it to generate the build file; but I guess you
know this - apart from that, I don't think so. Isn't this a gump descriptor?
For me it looks totally confusing anyway. So I'm +1 on removing it and
replacing it with per block-versions that use a better XML syntax.
For pluggable blocks we need this anyway.
Carsten
Re: [New build system] Status of samples
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> Hi,
>
> is anybody working on getting the samples working again with
> the new build system?
I am, but it's such a pain in the ass :(
> What is missing? I can help, if required.
The problem is simple, the solution complex.
Samples are 'integration oriented' while blocks are 'separation oriented'.
Get the 'hello-world' sample directory: this depends on many different
blocks (fop,batik and so on). Refactoring this into pieces and XconfTool
patches is a major pain in the ass.
Even more: some samples require code to be compiled. In some senses,
each of these sample folder (for example, flow or xmlform) looks like a
microblock on its own.... but making each sample folder as a block is
clearly overwelming and would ruin the concept.
But having just *one* sample block is useless since we are back on the
hello-world iper-dependent problem.
Finally, I think the Cocoon build should also allow you to build your
own cocoon web site. In this case, your stuff should becomes nothing
different from a microblock. (please, don't start using this
terminology, it sucks, it's just to give you the idea)
I spent last night looking at how very complex java software is built
(netbeans for example) and it seems that we are unique in such a highly
fragmented yet dependency-intensive behavior.
So I'm definately stuck.
Bart Guijt wrote:
> I hope this doen't interfere your ideas, so if you don't mind I'd
> like to propose the following:
Ok, let's see.
>
> 1) Refactor the project-info.xml to split in several files contained >
> in the blocks themselves.
> Just like Eclipse plugin.xml files in their plugins, a plugin is
> installed by just dropping it in the plugins dir. Usecase: This will
> make it easy for me to maintain my JavadocSource block (or any
> (external) block for that matter), now I need to sync each time when
> project-info.xml changes ;-)
This is called for, I totally agree. I was going to tackle that problem
today, anybody against this?
is anything using that project-info.xml file or is just a left-over from
the old build system?
> 2) Have each sample have its own block, which depends on the block(s)
> declaring the components they need.
> IIRC the infrastructure to support this is already there. Usecase: The
> XMLForm sample(s) use the databases block, XMLForm block and the Mail
> block. Having the XMLForm block depend on the Mail block is silly, of
> course.
So, what do you propose for those samples that depend on many different
blocks?
> 3) Instead of exclude-block-xxx properties, use the include-block-xxx
> properties in file blocks.properties (or accept both - just like Ant's
> <fileset> include/exclude attributes).
> Let the build process figure out what the dependencies between blocks
> are. Usecase: If I need to test a certain block, I don't want to set
> each exclude-property to true, while hoping not to forget anything.
Refactoring the project-info.xml file requires a special block ant task,
I'll try to make it more usable than the current (admittedly somewhat
hacky) property-based solution.
Suggestions on how to do this are welcome.
> Again, I don't want to interfere with your own ideas, I just thought
> this proposal would do it because it is simple, most necessary
> infrastructure is already there and I'd like to build my JavadocSource
> stuff again ;-)
Thansk, your suggestions are precious and resonate with my planned line
of action.
Anybody has other comments on this?
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------