You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2005/05/24 20:36:09 UTC
Block builder and deployer
Unico Hommes wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Reinhard Poetz wrote:
>
>>Unico Hommes wrote:
>>
>>Nice to see you back Unico!
>
>
> Thanks Reinhard! Lurker mode is off now, but still have some catching up
> to do. One of the things I'd been meaning to find out is what is the
> status of your blocks builder
the block-builder works as described on the wiki page. It uses the block.xml to
generate an Ant script out of it which builds the block resolving all
dependencies. Currently it requires more knowledge about how blocks will
actually look like. AFAIU only little work is left but this requires more work
on the implementation of real blocks (Daniel's current work on the
Block(s)Manager, the OSGi integration)
> and blocks deployer
Ihe interfaces are pretty stable and the unit tests are already able to deploy a
block. My last commits dealt with updating the wiring.xml but this hasn't been
finished. I guess that it will take about 5 working days to finish the missing
parts and some additional time to adapt it according to the requirements that
will arise with the actual block implementation.
As we currently have the ongoing discussion about OSGi, I agree with Daniel and
Sylvain that we will have to provide our own deployment tools as our needs are
too special. But maybe I 'm (we're) wrong here.
Of course any help is very appreciated!
efforts. Especially,
> is blocks builder the intented build system for 2.2?
hmmm, IMO yes ;-) Some others want to use Maven. As said in some former
discussions, it will not matter which build system will build a COB as long as
it follows the (to be done) COB specification (block.xml, directory structure).
I generated Ant scripts out of block descriptors (block.xml) as I know much more
about Ant than about Maven. Finally, I think we will be able to provide support
for both build systems which isn't a disadvantage IMO.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Block builder and deployer
Posted by Unico Hommes <un...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Reinhard Poetz wrote:
> Nicola Ken Barozzi wrote:
>
>> Unico Hommes wrote:
>> ...
>>
>>> Exactly my thinking. In fact the reason I asked is that I was thinking
>>> of starting a Maven2 plugin for cocoon. I've been looking at the
>>> emerging Maven2 effort that is due to come out this summer and I think
>>> its going to be a killer. IIUC I can just start that in the whiteboard
>>> without a vote right?
>>
>>
>>
>> Yes.
>>
>> Maven2 is very interesting: it seems that most architectural
>> shortcomings of Maven 1 have been fixed.
>>
>> I have written an xsl that converts the gump descriptor in the
>> block.xml files, I just need to test it.
>
>
> :-D
>
>> I also want to use the Maven Ant tasks to download the jars needed, as
>> already voted on this list. For this, and to be able to collaborate on
>> transitive dependencies with the other projects, we will need to
>> create also a pom.xml
>
>
> can we generate this? I want to avoid having more than one descriptor file
Good point, I'll keep that in mind. Though its probably separate from
the core plugin functionality.
>> for each block, which would help also your effort for Maven 2.
>>
>> BTW, the current schema is inadeguate for MAven2:
>>
>> <libraries>
>> <lib id="avalon-framework-api" location="core"/>
>> <lib id="avalon-framework-impl" location="core"/>
>> <lib id="excalibur-xmlutil" location="core"/>
>> <lib id="excalibur-pool" location="core"/>
>> <lib id="excalibur-sourceresolve" location="core"/>
>> </libraries>
>>
>> I'll have to change it to mimic the Maven pom library entries.
>
>
> no problem
>
>> OTOMH, maybe it may also be beneficial to use the Maven2 directory
>> project layout, at least for blocks.
>
>
> no problem
>
> The current block builder makes it possible to work on blocks that have
> a dependency on another *development version* of a block. What I don't
> want is having a build system that requires me to build all dependencies
> manually and put the build JARs into my project. This has to happen
> automatically (as it is done by the current block builder).
M2 does this automatically IIUC.
> The build system must also be able to resolve all the dependencies on
> *development versions* of blocks when it creates IDE descriptor files.
OK, M2 has support for generating eclipse and idea project files but I
don't know if it will take us all the way here.
- --
Unico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFClHOkcuec8tVNKAwRArOgAJ44tBHprAzp/jgZPDND9Eu0vEJ/vACeInpK
0fr8X5fBZ0fvjrHHalrx3vQ=
=TOSu
-----END PGP SIGNATURE-----
Re: Block builder and deployer
Posted by Reinhard Poetz <re...@apache.org>.
Nicola Ken Barozzi wrote:
> Unico Hommes wrote:
> ...
>
>> Exactly my thinking. In fact the reason I asked is that I was thinking
>> of starting a Maven2 plugin for cocoon. I've been looking at the
>> emerging Maven2 effort that is due to come out this summer and I think
>> its going to be a killer. IIUC I can just start that in the whiteboard
>> without a vote right?
>
>
> Yes.
>
> Maven2 is very interesting: it seems that most architectural
> shortcomings of Maven 1 have been fixed.
>
> I have written an xsl that converts the gump descriptor in the block.xml
> files, I just need to test it.
:-D
> I also want to use the Maven Ant tasks to
> download the jars needed, as already voted on this list. For this, and
> to be able to collaborate on transitive dependencies with the other
> projects, we will need to create also a pom.xml
can we generate this? I want to avoid having more than one descriptor file
> for each block, which
> would help also your effort for Maven 2.
>
> BTW, the current schema is inadeguate for MAven2:
>
> <libraries>
> <lib id="avalon-framework-api" location="core"/>
> <lib id="avalon-framework-impl" location="core"/>
> <lib id="excalibur-xmlutil" location="core"/>
> <lib id="excalibur-pool" location="core"/>
> <lib id="excalibur-sourceresolve" location="core"/>
> </libraries>
>
> I'll have to change it to mimic the Maven pom library entries.
no problem
> OTOMH, maybe it may also be beneficial to use the Maven2 directory
> project layout, at least for blocks.
no problem
The current block builder makes it possible to work on blocks that have a
dependency on another *development version* of a block. What I don't want is
having a build system that requires me to build all dependencies manually and
put the build JARs into my project. This has to happen automatically (as it is
done by the current block builder).
The build system must also be able to resolve all the dependencies on
*development versions* of blocks when it creates IDE descriptor files.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Block builder and deployer
Posted by Unico Hommes <un...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Nicola Ken Barozzi wrote:
> Unico Hommes wrote:
> ...
>
>> Exactly my thinking. In fact the reason I asked is that I was thinking
>> of starting a Maven2 plugin for cocoon. I've been looking at the
>> emerging Maven2 effort that is due to come out this summer and I think
>> its going to be a killer. IIUC I can just start that in the whiteboard
>> without a vote right?
>
>
> Yes.
I love that policy.
> Maven2 is very interesting: it seems that most architectural
> shortcomings of Maven 1 have been fixed.
>
> I have written an xsl that converts the gump descriptor in the block.xml
> files, I just need to test it.
If you upload it to subversion I could help you out. :-)
- --
Unico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFClHOycuec8tVNKAwRAksqAJwLGoUtaGAH7+yUZi2AcnUkN7tsCACgr4kF
IqXUh8cLQl5NnVPNj4iGzdQ=
=xqwJ
-----END PGP SIGNATURE-----
Re: Block builder and deployer
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Unico Hommes wrote:
...
> Exactly my thinking. In fact the reason I asked is that I was thinking
> of starting a Maven2 plugin for cocoon. I've been looking at the
> emerging Maven2 effort that is due to come out this summer and I think
> its going to be a killer. IIUC I can just start that in the whiteboard
> without a vote right?
Yes.
Maven2 is very interesting: it seems that most architectural
shortcomings of Maven 1 have been fixed.
I have written an xsl that converts the gump descriptor in the block.xml
files, I just need to test it. I also want to use the Maven Ant tasks to
download the jars needed, as already voted on this list. For this, and
to be able to collaborate on transitive dependencies with the other
projects, we will need to create also a pom.xml for each block, which
would help also your effort for Maven 2.
BTW, the current schema is inadeguate for MAven2:
<libraries>
<lib id="avalon-framework-api" location="core"/>
<lib id="avalon-framework-impl" location="core"/>
<lib id="excalibur-xmlutil" location="core"/>
<lib id="excalibur-pool" location="core"/>
<lib id="excalibur-sourceresolve" location="core"/>
</libraries>
I'll have to change it to mimic the Maven pom library entries.
OTOMH, maybe it may also be beneficial to use the Maven2 directory
project layout, at least for blocks.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: Block builder and deployer
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
David Casal wrote:
> Hi again,
>
> On 25 May 2005, at 10:39, David Casal wrote:
>
>> If you read this far, I owe you a beer. Please get creative with your
>> answers, comic-book style.
>
> *tumbleweed*
>
> Any suggestions as to whether I should post these questions on a new
> thread, or perhaps in cocoon-users, or just not in the cocoon mailing
> lists at all, very welcome.
>
> Hope it didn't bother anyone :-)
There is *really* no need to appologize for asking questions . Most
questions get some kind of answer and questions that someone finds
intersting gets better answers. Your questions are relevant for the list
and IMO interesting. It takes some time to answer such a general
question, and I hadn't that time yesterday, I'll try to give my view on
the topic later.
In general it is better to change subject line if one changes the
subject, it increase the chance to reach the right audience and makes it
easier to search the archive. In this particular case I guess that "the
right audience" follow this thread anyway.
/Daniel
Re: Block builder and deployer
Posted by David Casal <da...@luminas.co.uk>.
Hi again,
On 25 May 2005, at 10:39, David Casal wrote:
> If you read this far, I owe you a beer. Please get creative with your
> answers, comic-book style.
*tumbleweed*
Any suggestions as to whether I should post these questions on a new
thread, or perhaps in cocoon-users, or just not in the cocoon mailing
lists at all, very welcome.
Hope it didn't bother anyone :-)
d
--
David Plans Casal, Director of Research, Luminas Internet Applications
Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135
Web: www.luminas.co.uk Orixo alliance: http://www.orixo.com/
Re: Block builder and deployer
Posted by David Casal <da...@luminas.co.uk>.
On 27 May 2005, at 17:52, Stefano Mazzocchi wrote:
>> That's what I'm after. So you see a roadmap whereby first you work on
>> easy kernel installation -then- play semantics.
>
> Correct. The other way around would make the goal even harder to
> bootstrap. No advancement in an open source software happens if you
> don't capture some development momentum that is greater than just one
> guy wanting it, especially for such deep and complex architectural
> issues.
Understood, of course.
> The issues right now are not with semantics, but with the actual
> operativity of a block design. (see the excellent various RTs on the
> matter)
/me goes read some more.
>> Where do you think the struggle to achieve automatic block deployment
>> resides? (again, please take this question as journalistic vs.
>> informed)
>
> in dependency maintenance. see debian, gentoo, bsd ports... the hard
> thing is to keep up with the dependency graph, but luckily this is a
> very parallizable tasks (in terms of people that can work on it without
> stepping on each other toes)
I see. That of course makes a lot of sense, and it -is- something I can
write about, since my remit is not necessarily to get people's hopes
up, but to try to gauge the state of development and report accurately
on it.
>> My remit for this report is to answer as clearly as I can as to
>> whether
>> that is very far in the future or perhaps not as far as they think.
>
> I honestly doubt something like that can happen out of cocoon in a
> short
> time... because this community is not interested in it and that
> community doesn't have the skills to make it happen technologically (or
> even phrase what they want in a way that developers could understand).
Of course; that's partly why JISC are skeptical of it, at a senior
level.
>> Can you see piggy banks being used by applications other than Firefox?
>> (I assume because it relies on RDF, Firefox is simple the tool you're
>> using for its -present- form, and that anything people write that can
>> speak and interact with RDF stores will be able to talk to it).
>
> Yes, PB is the firefox plugin, but the engine is called Longwell
> (http://simile.mit.edu/longwell/), that's the RDF presentation
> framework
> (you can think of it as a cocoon for RDF) and it's usable (today)
> already
Ahh. The picture clears (I'd forgotten you mentioned Longwell some time
ago.)
>> Its a bit like asking a football manager 'so do you think you'll win
>> the
>> League this year?'.
>
> yeah, that's how it sounded. :-)
Heh. My bad.
> I honestly don't know and it feels to me that the question might be
> bogus already. M$ office contains access and it's very easy to use tool
> to create a personal database. But how many of the milions of office
> users use it? not a lot.
Indeed. And more than likely, it -is- the wrong question to ask.
> Do we want cocoon to become the ultimate RAD tool? a visual basic for
> the web? I don't. It's a lot of pain and no fun at all (content
> management systems show you that pain, just allowing them to write
> content is such a painful environment to be in)
Agree; one of the things JISC is eager to find out is whether their
scepticism about general humanists building webapps outta thin air is
well-founded. Hearing this, I would say so. Perhaps though, this topic
deserves to be clarified, so that the ongoing UK discussion focuses
more on concrete issues (block deployment, etc) and less on pipe
dreams.
>> This isn't a commercial, VC-led, vampiric question, Stefano.
>
> Oh, I know, don't worry.
Huh phew. You never know, these days.
>> I don't
>> have any intention of packaging Cocoon or making nice little shiny
>> toys
>> with it.
>
> And if you did, I wouldn't have a problem with it... because *you* were
> going to pay the price for supporting those users, not us ;-)
ROFL. Quite. Which is why when VCs talk to us, we now say 'Get a real
job'.
>> I'll leave people with more time and money and less worries
>> than me to do that. Its a question from researchers just like you, but
>> from different disciplines (mainly the Humanities), who are hoping the
>> tools you guys build will get easier to use with time, and would love
>> to
>> now when, how, etc.
>
> Take the pain of content management and multiply by a thousand. that's
> what it feels like to me.
Gotcha. And of course, I imagine most people share that sentiment.
> Would we get closer? yes. How? I have no clue. For now, I focus on data
> interoperability and that's a hard enough problem to solve, and we just
> add a little tiny layer of declerative reasoning and it already has
> severe problems.
Excellent point. One that I can use, too. The problem being that
co-operation (The Evolution of Co-Operation, Axelrod, 1980) is possible
because it emerges out of working communities, but the inference behind
declarative reasoning, when attempting to pre-empt that communities
movements, if charged with pre-empting order within chaos, which is
neigh to impossible.
> I told you privately to buy Lego mindstorms. Do it. Then play with it.
> It's probably the simplest to use programming language ever invented
> (and visual!). Do you see a humanity professor using it? I don't.
/me looks at mindstorms kit on amazon and wonders whether his wife will
castrate him for spending £160
hey wait, I have a child on the way, maybe I can justify "i'm just
getting READY for it, alright?"
Thanks for your time, Stefano, it was really helpful.
Cheers,
David
--
David Plans Casal, Director of Research, Luminas Internet Applications
Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135
Web: www.luminas.co.uk Orixo alliance: http://www.orixo.com/
Re: Block builder and deployer
Posted by Stefano Mazzocchi <st...@apache.org>.
David Casal wrote:
> That's what I'm after. So you see a roadmap whereby first you work on
> easy kernel installation -then- play semantics.
Correct. The other way around would make the goal even harder to
bootstrap. No advancement in an open source software happens if you
don't capture some development momentum that is greater than just one
guy wanting it, especially for such deep and complex architectural issues.
The issues right now are not with semantics, but with the actual
operativity of a block design. (see the excellent various RTs on the matter)
>> Your dream are not wild at all, btw, they are actually very moderate,
>> the lego-like approach has been in my vision of cocoon since before
>> cocoon even started (it was the vision behind avalon). As for automatic
>> deployment of blocks, again, this was in our vision for avalon already
>> in 1998, but never managed to get it bootstrapped (and we still struggle
>> with that here for cocoon blocks).
>
> Where do you think the struggle to achieve automatic block deployment
> resides? (again, please take this question as journalistic vs. informed)
in dependency maintenance. see debian, gentoo, bsd ports... the hard
thing is to keep up with the dependency graph, but luckily this is a
very parallizable tasks (in terms of people that can work on it without
stepping on each other toes)
>> What I think it's pure BS is the idea that the general population will
>> use Firefox to build web applications. There is a huge cognitive
>> difference between seeing your client adapt to your needs, and instruct
>> it to do so. The second approach is something only a small percentage of
>> the general population has interest in doing.
>
>
> Ok I getcha. However, the second approach, and its small percentage of
> interested parties is -exactly- the audience of this JISC report. They
> don't necessarily want to know whether they'll be able to build webapps
> through Firefox. They just wonder whether they'll be able to see
> Historians, Musicians, Anthropologists and Librarians build webapps
> without having to understand XML configuration files, or get involved in
> the nature of the framework delivering the components to build those
> webapps.
>
> My remit for this report is to answer as clearly as I can as to whether
> that is very far in the future or perhaps not as far as they think.
I honestly doubt something like that can happen out of cocoon in a short
time... because this community is not interested in it and that
community doesn't have the skills to make it happen technologically (or
even phrase what they want in a way that developers could understand).
>> And the generation of that HTML might be a result (as in piggy-bank) of
>> complex, client side operations on a more sofisticated memory model of
>> the data. In fact, my next task for Piggy-bank is to find a way to allow
>> 'user selectable' views of your data (we call those "lenses"), and there
>> has been a huge discussion about the feasibility of this approach
>> declaratively on the general@simile.mit.edu mailing list about the
>> Fresnel RDF presentation ontology (fresnel, lenses, got it?) (find more
>> at http://simile.mit.edu/fresnel/)
>
> Can you see piggy banks being used by applications other than Firefox?
> (I assume because it relies on RDF, Firefox is simple the tool you're
> using for its -present- form, and that anything people write that can
> speak and interact with RDF stores will be able to talk to it).
Yes, PB is the firefox plugin, but the engine is called Longwell
(http://simile.mit.edu/longwell/), that's the RDF presentation framework
(you can think of it as a cocoon for RDF) and it's usable (today) already
[note it was first written by our friend Mark Butler]
>> Yes, the vision is that the user will get more power having to do less,
>> but this is the vision of pretty much any reasonable technology.
>>
>> Is not the "what" that counts here (that's the easy part), it's the
>> "how". And believe me, nobody really has any clue of what is going to
>> work or what is going to fail miserably (that's why is called 'research')
>
>
> And my commission here is to inform a research agency (JISC) about your
> research and that of everyone involved in Cocoon development. Nothing more.
>
> Sorry if that got your back up.
oh, no problem.
> Its a bit like asking a football manager 'so do you think you'll win the
> League this year?'.
yeah, that's how it sounded. :-)
> In the end, Stefano, it isn't as imbecile a question as you appear to
> think.
>
> Let me put it again in a more straightforward manner : when I introduce
> people to Cocoon in JISC projects, I usually train people who are
> already developers. Their 'project managers' sit back, unaware even of
> the topic, precisely because they've hired programmers to help them
> create whatever webapp/repository/foobarPortal for their research
> discipline. The gap between the two is abismal; Cocoon goes a LONG way
> towards closing that gap already, and everyone hopes it will go further.
> Could you comment on where you'd like make progress to bridge the gap
> between researchers and programmers when building applications for the
> web, and how you think you'll go about it?
I honestly don't know and it feels to me that the question might be
bogus already. M$ office contains access and it's very easy to use tool
to create a personal database. But how many of the milions of office
users use it? not a lot.
Do we want cocoon to become the ultimate RAD tool? a visual basic for
the web? I don't. It's a lot of pain and no fun at all (content
management systems show you that pain, just allowing them to write
content is such a painful environment to be in)
> This isn't a commercial, VC-led, vampiric question, Stefano.
Oh, I know, don't worry.
> I don't
> have any intention of packaging Cocoon or making nice little shiny toys
> with it.
And if you did, I wouldn't have a problem with it... because *you* were
going to pay the price for supporting those users, not us ;-)
> I'll leave people with more time and money and less worries
> than me to do that. Its a question from researchers just like you, but
> from different disciplines (mainly the Humanities), who are hoping the
> tools you guys build will get easier to use with time, and would love to
> now when, how, etc.
Take the pain of content management and multiply by a thousand. that's
what it feels like to me.
Would we get closer? yes. How? I have no clue. For now, I focus on data
interoperability and that's a hard enough problem to solve, and we just
add a little tiny layer of declerative reasoning and it already has
severe problems.
At the end of the day, non-programmers don't program, they don't like
it, or they can't, their minds don't work like that.
I told you privately to buy Lego mindstorms. Do it. Then play with it.
It's probably the simplest to use programming language ever invented
(and visual!). Do you see a humanity professor using it? I don't.
It's the way their brain works. There is *NOTHING* technology can do to
change that. And even if it could, would I? No. I value diversity of
mental processes more than technological innovation.
--
Stefano.
Re: Block builder and deployer
Posted by David Casal <da...@luminas.co.uk>.
Hi
On 26 May 2005, at 14:42, Stefano Mazzocchi wrote:
>> Do you see a point where they'll be
>> able to put together semi-complex webapps in LEGO style?
>
> Dude, can you read?
>
> http://cocoon.apache.org/ [very first paragraph]
Patently I cannot ;-)
> [nobody is responding because that's like asking: do you see a future
> of
> open source for this project? WTF man!?!]
See, actually, my question (which admittedly could be much better put)
is:
What -kind- of a future do you see, in concrete terms, for Cocoon
blocks being deployed for a non-programmer (not even XML confs) user
who has no intention of actually meeting Cocoon at all?
It's not an informed question, its a journalistic question; humble
apologies for not pre-emptying with 'consider first that I don't know
what I'm talking 'bout' ;-)
>> Secondly, if you were to think much further ahead in the future, do
>> you
>> see agent-driven applications calling containers which might or might
>> not call Cocoon components into a user's 'Webapp Building' tool? Does
>> the work Stefano is carrying out at MIT (Simile, PiggyBank) make you
>> think of emergent people processing, whereby people might be able to
>> use
>> Firefox to build web applications, by having the browser enquire RDF
>> repositories for the right components and their dependencies?
>
> Honestly, the whole thing has more the flavor of sci-fi or VC-oriented
> BS than any real technology (see below)
Again, I realise I should have clarified. Imagine a Higher Education
body saying 'Cocoon is -not- as easy to use for HE developers as it
advertises it is. Do you see it becoming easier with time, and how?'.
Those guys want to know more about your thoughts for the future.
At no point does this have anything to do with either VCs, or sci-fi
for that matter. It's simply a report for a publicly-funded research
body, on how the people building frameworks like Cocoon see the future.
Let me very very clear here: *do not* confuse these questions as
anything other than questions related to a JISC report. It has been
commissioned by Lesley Hawkins (JISC executive, l.hawskey@jisc.ac.uk)
and Paul Anderson from Techwatch (p.anderson@intelligentcontent.co.uk),
who works for JISC. They have no intention of this report being used to
do anything but inform their channels (FE and HE developers and senior
decision makers) about available technology.
Of course, when I write about it, it sounds like sci-fi bullshit. It
does so because my questions are naive. But don't let that put you off
answering the question (I see below, it didn't).
> people are talking about agents, but how is an agent different than a
> program? My spam filter saves me hours every single day, it's a very
> complex beast and achieves impressive results (better than me, for
> sure). Is that an agent? In the "it's working for you sense" it is, if
> it's spamassassin, it's also downloading information from the network
> to
> fulfill its task.
Completely agree. My definition of 'agency' (including its component
agents) has nothing to do with AI. Too much heuristic emphasis has been
put on the word agency in the past. I simply mean 'a learning program
which purports to help a human achieve successful completion of a
task'. The only reason I see whereby you would call this program and
'agent', is because like a human helper, it learns overtime. Nothing
more sci-fi than that.
> Agents and web services are fancy names to describe stuff that we have
> been doing since the days the concept of 'client-server' was born. We
> are moving into describing the borders of this concepts in a more
> precise way, mostly by specifying more on the data being transfered and
> the nature of the service interaction, but at the end, it's the same
> architectural concept.
Again, no discussion there.
> Firefox extensions contain RDF that indicates where they come from,
> their version and so on. So, in a sort of way, Firefox is a lego-like
> semantic agent. But again, that's BS, it's just the way they do things,
> not necessarely the only way to achieve the same functionality.
But, a way which is -working- right now. I'm much more interested in
hearing your thoughts on feasibility than whether the wording is
correct. To my mind, a piano has been working as a tool for players for
the last 400 years. The discussion on how to better the tool hasn't
ended. Its become more granular and therefore less visible to
outsiders.
> We could write the cocoon blocks metadata in RDF (I would suggest we do
> so, but not now), but if the cocoon kernel doesn't support easy
> installation, that doesn't buy us anything.
That's what I'm after. So you see a roadmap whereby first you work on
easy kernel installation -then- play semantics.
> Your dream are not wild at all, btw, they are actually very moderate,
> the lego-like approach has been in my vision of cocoon since before
> cocoon even started (it was the vision behind avalon). As for automatic
> deployment of blocks, again, this was in our vision for avalon already
> in 1998, but never managed to get it bootstrapped (and we still
> struggle
> with that here for cocoon blocks).
Where do you think the struggle to achieve automatic block deployment
resides? (again, please take this question as journalistic vs.
informed)
> What I think it's pure BS is the idea that the general population will
> use Firefox to build web applications. There is a huge cognitive
> difference between seeing your client adapt to your needs, and instruct
> it to do so. The second approach is something only a small percentage
> of
> the general population has interest in doing.
Ok I getcha. However, the second approach, and its small percentage of
interested parties is -exactly- the audience of this JISC report. They
don't necessarily want to know whether they'll be able to build webapps
through Firefox. They just wonder whether they'll be able to see
Historians, Musicians, Anthropologists and Librarians build webapps
without having to understand XML configuration files, or get involved
in the nature of the framework delivering the components to build those
webapps.
My remit for this report is to answer as clearly as I can as to whether
that is very far in the future or perhaps not as far as they think.
> And the generation of that HTML might be a result (as in piggy-bank) of
> complex, client side operations on a more sofisticated memory model of
> the data. In fact, my next task for Piggy-bank is to find a way to
> allow
> 'user selectable' views of your data (we call those "lenses"), and
> there
> has been a huge discussion about the feasibility of this approach
> declaratively on the general@simile.mit.edu mailing list about the
> Fresnel RDF presentation ontology (fresnel, lenses, got it?) (find more
> at http://simile.mit.edu/fresnel/)
Can you see piggy banks being used by applications other than Firefox?
(I assume because it relies on RDF, Firefox is simple the tool you're
using for its -present- form, and that anything people write that can
speak and interact with RDF stores will be able to talk to it).
> Yes, the vision is that the user will get more power having to do less,
> but this is the vision of pretty much any reasonable technology.
>
> Is not the "what" that counts here (that's the easy part), it's the
> "how". And believe me, nobody really has any clue of what is going to
> work or what is going to fail miserably (that's why is called
> 'research')
And my commission here is to inform a research agency (JISC) about your
research and that of everyone involved in Cocoon development. Nothing
more.
Sorry if that got your back up.
Its a bit like asking a football manager 'so do you think you'll win
the League this year?'.
In the end, Stefano, it isn't as imbecile a question as you appear to
think.
Let me put it again in a more straightforward manner : when I introduce
people to Cocoon in JISC projects, I usually train people who are
already developers. Their 'project managers' sit back, unaware even of
the topic, precisely because they've hired programmers to help them
create whatever webapp/repository/foobarPortal for their research
discipline. The gap between the two is abismal; Cocoon goes a LONG way
towards closing that gap already, and everyone hopes it will go
further. Could you comment on where you'd like make progress to bridge
the gap between researchers and programmers when building applications
for the web, and how you think you'll go about it?
This isn't a commercial, VC-led, vampiric question, Stefano. I don't
have any intention of packaging Cocoon or making nice little shiny toys
with it. I'll leave people with more time and money and less worries
than me to do that. Its a question from researchers just like you, but
from different disciplines (mainly the Humanities), who are hoping the
tools you guys build will get easier to use with time, and would love
to now when, how, etc.
See?
Thanks for the reply though, goes a long way towards at least letting
me know how you feel about it all.
Ciao,
David
--
David Plans Casal, Director of Research, Luminas Internet Applications
Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135
Web: www.luminas.co.uk Orixo alliance: http://www.orixo.com/
Re: Block builder and deployer
Posted by Stefano Mazzocchi <st...@apache.org>.
David Casal wrote:
> Do you see a point where they'll be
> able to put together semi-complex webapps in LEGO style?
Dude, can you read?
http://cocoon.apache.org/ [very first paragraph]
:-)
[nobody is responding because that's like asking: do you see a future of
open source for this project? WTF man!?!]
> Secondly, if you were to think much further ahead in the future, do you
> see agent-driven applications calling containers which might or might
> not call Cocoon components into a user's 'Webapp Building' tool? Does
> the work Stefano is carrying out at MIT (Simile, PiggyBank) make you
> think of emergent people processing, whereby people might be able to use
> Firefox to build web applications, by having the browser enquire RDF
> repositories for the right components and their dependencies?
Honestly, the whole thing has more the flavor of sci-fi or VC-oriented
BS than any real technology (see below)
> If you read this far, I owe you a beer. Please get creative with your
> answers, comic-book style.
>
> I'd like to have your wildest dreams for cocoon, even if all I get is
> 'I'd like cocoon to run my house' or 'shut the fuck up you piano playing
> barbarian'.
David,
people are talking about agents, but how is an agent different than a
program? My spam filter saves me hours every single day, it's a very
complex beast and achieves impressive results (better than me, for
sure). Is that an agent? In the "it's working for you sense" it is, if
it's spamassassin, it's also downloading information from the network to
fulfill its task.
Agents and web services are fancy names to describe stuff that we have
been doing since the days the concept of 'client-server' was born. We
are moving into describing the borders of this concepts in a more
precise way, mostly by specifying more on the data being transfered and
the nature of the service interaction, but at the end, it's the same
architectural concept.
Firefox extensions contain RDF that indicates where they come from,
their version and so on. So, in a sort of way, Firefox is a lego-like
semantic agent. But again, that's BS, it's just the way they do things,
not necessarely the only way to achieve the same functionality.
We could write the cocoon blocks metadata in RDF (I would suggest we do
so, but not now), but if the cocoon kernel doesn't support easy
installation, that doesn't buy us anything.
Your dream are not wild at all, btw, they are actually very moderate,
the lego-like approach has been in my vision of cocoon since before
cocoon even started (it was the vision behind avalon). As for automatic
deployment of blocks, again, this was in our vision for avalon already
in 1998, but never managed to get it bootstrapped (and we still struggle
with that here for cocoon blocks).
What I think it's pure BS is the idea that the general population will
use Firefox to build web applications. There is a huge cognitive
difference between seeing your client adapt to your needs, and instruct
it to do so. The second approach is something only a small percentage of
the general population has interest in doing.
I *do* see the ability for a client to be able to download pieces of
code that enable more powerful functionality, but this has to be
transparent, unnoticed, seemless and less intrusive as possible. In such
a sense, the <embed>/<object>/<applet> tags in HTML go in that direction
already, as the iframe-based DHTML embedding used by some (ie. google maps).
And the generation of that HTML might be a result (as in piggy-bank) of
complex, client side operations on a more sofisticated memory model of
the data. In fact, my next task for Piggy-bank is to find a way to allow
'user selectable' views of your data (we call those "lenses"), and there
has been a huge discussion about the feasibility of this approach
declaratively on the general@simile.mit.edu mailing list about the
Fresnel RDF presentation ontology (fresnel, lenses, got it?) (find more
at http://simile.mit.edu/fresnel/)
Yes, the vision is that the user will get more power having to do less,
but this is the vision of pretty much any reasonable technology.
Is not the "what" that counts here (that's the easy part), it's the
"how". And believe me, nobody really has any clue of what is going to
work or what is going to fail miserably (that's why is called 'research')
--
Stefano.
Re: [RT] Block usage
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
> Daniel Fagerstrom wrote:
<snip/>
>> A basic scenario
>> ================
>>
>> 1. A soon to become Cocoon user, downloads the "start kit"
>> distribution from our site.
>>
>> It contains the (OSGi) kernel, the Cocoon service block (containing
>> the Cocoon core), a Cocoon servlet block,
>
> ok
>
>> a (light weight) web server block,
>
> you mean a block that contains e.g. Jetty or Tomcat?
Yes, there is a standard http service api in the OSGi spec, and there
are bundles based on both Jetty and Tomcat that implement that api.
> IMO this could only be an option but not a requirement. Cocoon must
> be deployable in a J2EE or servlet container.
As we have discussed before we should support both cases. What I
describe is a "start kit" distribution that helps a new user to get up
to speed. Puting a http service block in the "start kit" distro
coresponds to our current bundling of Jetty. All blocks should be
separately downloadable so that the experienced users can mix and match
as they want to.
>> a block deployer block
>
> Basically the block deployer will be a stand-alone application (Ant
> task, Maven plug-in, Eclipse plug-in, ...). Of course somebody could
> write a web interface for it which could be a cocoon block.
As you can see in my original message I proposed: a block deployer
block, a block depoyer webapp block. Web interface and functinality
should cleary be kept separately.
<snip/>
> called block.xml, no?
>
> (wiring.xml and the Manifest file), a near
Yes, block.xml.
<snip/>
> One thing to add: It must be possible that one block depends on
> another block that is under development. I want my custom projects
> requiring the latest svn version of e.g. the forms block. If the forms
> block changes, this change takes effect immediatly on my project
> without explicit deployment.
Absolutely!
/Daniel
Re: [RT] Block usage
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> David Casal wrote:
> <snip/>
>
>> how do you see the common user approaching the development of new
>> webapp, considering they might not have a senior level of development
>> experience? Could you illustrate your ideal use case scenario?
>
>
> <snip/>
>
> We haven't discussed use case scenarious in a more systematic way for
> quite some time. Bits and pieces have been discussed in technical
> threads although not in any way that have been easy to follow for those
> not involved in the specifics. What's described in
> http://wiki.apache.org/cocoon/BlockIntroduction and
> http://wiki.apache.org/cocoon/BlocksUseCases still holds. But Cocoon has
> changed since then, new technologies have appeared and we have learnt
> more by discussing and trying to implement the blocks so it could be
> worthwhile to discuss the user experience of blocks again.
>
> I'll mix up the use case with some technical details on how it might be
> implemented. The terms block, bundle and plugin are synonymes in this RT.
>
> Ok, here is my current view:
>
> A basic scenario
> ================
>
> 1. A soon to become Cocoon user, downloads the "start kit" distribution
> from our site.
>
> It contains the (OSGi) kernel, the Cocoon service block (containing the
> Cocoon core), a Cocoon servlet block,
ok
> a (light weight) web server block,
you mean a block that contains e.g. Jetty or Tomcat? IMO this could only be an
option but not a requirement. Cocoon must be deployable in a J2EE or servlet
container.
> a block deployer block
Basically the block deployer will be a stand-alone application (Ant task, Maven
plug-in, Eclipse plug-in, ...). Of course somebody could write a web interface
for it which could be a cocoon block.
, a block depoyer webapp block, a "get
> started" tutorial block and some basic blocks (template, cforms, xslt,
> flow, ...) that the previous blocks depends on.
ok
> 2. The user double clicks the distribution and answer where to install
> it and whether the tutorial webapp should be started.
>
> It is not certain that the distribution contains all the above
> physically,
we can have different distributions
> it might download its dependencies during this step. Those
> thinking about using Maven etc can probably give a better view on this.
>
> If the user chose to start the tutorial webapp, the kernel will be
> started and the blocks listed above will be installed into the kernel
> and started. The start page for the tutorial will be mounted at e.g. "/"
> and will be served through the call chain: web server block -> Cocoon
> servlet block -> Cocoon service block -> "Get started" tutorial block.
>
>
> 3. The user points the browser at http://localhost:8888/ and start to
> follow the tutorial.
>
> Here we have IMO a lot to learn from Forrest. When you have dowloaded
> and installed Forrest you directly gets instructions about how to start
> use it.
>
>
> 4. The user can chose between following a number of different wizard
> like tutorials, e.g.: Minimal Cocoon app, documentation site (Forrest),
> portal, CMS site (Lenya or Daisy), Spring based webapp etc.
>
> In this step the needed blocks (including the specific tutorial/wizard)
> will be dowloaded, installed and started. A user block skeleton will be
> created. It should be noted that the created user block is much simpler
> than what is needed today. It is a directory with a description of what
> blocks the block depends on
called block.xml, no?
(wiring.xml and the Manifest file), a near
> to empty sitemap and that is all.
>
>
> 5. The user start to develop the new application from the skeleton one
> and have at all times a working app that can be used from the browser.
>
> I think polymorphic extension will be a key mechanism for making it easy
> for users to develop new apps. Let us say that you want to create a
> documentation site. Then your skeleton block extends the Forrest block,
> which allready contain an example documentation site. By extending the
> Forrest block, your new this far empty, block allready delivers content.
> The Forrest block is designed in such a way that everything that you
> might want to change or extend: content, menues, styling, configuration
> etc is available through the blocks sitemap (some of it only
> internally). By overiding the URLs of these things in your own sitemap
> with own content you can one step at the time adapt the default app to
> your own needs. For some of the inherited resources you just want to
> modify the original content. This can be done by applying a stylesheet
> on "block:super:". Also components from the extended block can be
> overrided.
I remember one or two mails about this some months ago ;-)
>
>
> 6. The new block contain some new and intersting stuff that is not
> available before. After a number of refactorings it consists of a number
> of blocks that are reusable and solves well defined concerns. Now the
> user puts the blocks in a new project in Sourceforge (or cocoondev.org
> etc).
>
> An important aspect of blocks is that they can make Cocoon development
> much more scalable and distributed. To make this possible we must, IMO,
> split the Cocoon core of today in a number of blocks. These blocks
> should have well defined concern areas, and in some cases own release
> cycles. We should also be much more carefull about what is external
> interfaces and classes and what is only for internal use.
>
> Above all we should have a lean, mean and rock stable core, containing
> the basic mechanisms for the sitemap and (possibly) component management
> and the minimal set of core interfaces. This is a must for creating a
> stable fundament that external blocks developers can put their trust in.
ok
> --- o0o ---
>
> I would assume that we will have an Cocoon Eclipse starting kit distro
> as well. With IDE support, the user can get much more support and
> guiding in the above described process. The Lepido crew will hopefully
> give a view on that.
>
> WDYT?
One thing to add: It must be possible that one block depends on another block
that is under development. I want my custom projects requiring the latest svn
version of e.g. the forms block. If the forms block changes, this change takes
effect immediatly on my project without explicit deployment.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de
Re: [RT] Block usage
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
David Casal wrote:
> Hello Daniel,
>
> Thanks for your extremely edifying response. As with Stefano, will it be
> ok to cite some of your comments in this report? I may not cite you
> literally, but I need to credit you if I do. Would that be ok?
Sure.
> The report will be published on Techwatch:
> http://www.jisc.ac.uk/index.cfm?name=techwatch_home
>
> On 26 May 2005, at 13:34, Daniel Fagerstrom wrote:
>
> <snip>
>
>> 4. The user can chose between following a number of different wizard
>> like tutorials, e.g.: Minimal Cocoon app, documentation site
>> (Forrest), portal, CMS site (Lenya or Daisy), Spring based webapp etc.
>>
>> In this step the needed blocks (including the specific
>> tutorial/wizard) will be dowloaded, installed and started. A user
>> block skeleton will be created. It should be noted that the created
>> user block is much simpler than what is needed today. It is a
>> directory with a description of what blocks the block depends on
>> (wiring.xml and the Manifest file), a near to empty sitemap and that
>> is all.
>
> </snip>
>
> As I read from your May 20th OSGi proposal, the core and block jars are
> managed within the OSGi framework, is this correct?
Yes.
> Meaning that the
> directory a potential user is presented with is minimal because of this?
Yes, the blocks the user webapp depends on don't need to be stored
within the users webapp directory anymore.
>> 5. The user start to develop the new application from the skeleton one
>> and have at all times a working app that can be used from the browser.
>>
>> I think polymorphic extension will be a key mechanism for making it
>> easy for users to develop new apps.
>
> <snip>
>
>> Also components from the extended block can be overrided.
>
> Could you explain how?
Say that block E extends block B, block B handle the URLs /foo and /bar
and block E handle /foo. Then a user of block E (through the block:
protocol), will get /foo from E and /bar from B.
Furthermore the inheritance is polymorphic, so if the sitemap rule in B
is defining /bar in terms of (among other things) /foo by using
"block:/foo", the /foo from E will be used if /bar is used from E.
A more technical description of the block: protocol can be found in
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111265006428803&w=2.
The most comprehensive discussion about these concepts with some good
examples can be find in the, not entirelly plessant, threads:
http://marc.theaimsgroup.com/?t=111177260800002&r=1&w=2 and
http://marc.theaimsgroup.com/?t=111211349500004&r=1&w=2.
We haven't discussed component handling in any detail. But the idea is
that component names can be prefixed with the name of the block it
should be taken from. Extension and polymorphism should probably work in
the same way as for sitemap resources.
<snip/>
Reinhard answered the rest of the questions.
/Daniel
Re: [RT] Block usage
Posted by Reinhard Poetz <re...@apache.org>.
David Casal wrote:
>> 6. The new block contain some new and intersting stuff that is not
>> available before. After a number of refactorings it consists of a
>> number of blocks that are reusable and solves well defined concerns.
>> Now the user puts the blocks in a new project in Sourceforge (or
>> cocoondev.org etc).
>
>
> That's a v cool thought. Do you envision that at this point, a user who
> finds the reusable blocks in the Sourceforge project, could download
> them and run them as they are?
yes
> Meaning, would they contain Cocoon's
> core, or as you explain further, would it only contain the parts of the
> Cocoon core it needs?
It doesn't contain any parts of Cocoon core at all. It only has to compile
against Cocoon core's interfaces.
> Might it instead contain only the meta info needed
> to downloaded needed core and non-core components during install?
>
> Are you guys thinking of a central Cocoon OSGi repository all these
> externally developed block-built apps would rely on?
yes, see http://wiki.apache.org/cocoon/BlockImplementation (block deployer)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: [RT] Block usage
Posted by David Casal <da...@luminas.co.uk>.
Hello Daniel,
Thanks for your extremely edifying response. As with Stefano, will it
be ok to cite some of your comments in this report? I may not cite you
literally, but I need to credit you if I do. Would that be ok?
The report will be published on Techwatch:
http://www.jisc.ac.uk/index.cfm?name=techwatch_home
On 26 May 2005, at 13:34, Daniel Fagerstrom wrote:
<snip>
> 4. The user can chose between following a number of different wizard
> like tutorials, e.g.: Minimal Cocoon app, documentation site
> (Forrest), portal, CMS site (Lenya or Daisy), Spring based webapp etc.
>
> In this step the needed blocks (including the specific
> tutorial/wizard) will be dowloaded, installed and started. A user
> block skeleton will be created. It should be noted that the created
> user block is much simpler than what is needed today. It is a
> directory with a description of what blocks the block depends on
> (wiring.xml and the Manifest file), a near to empty sitemap and that
> is all.
</snip>
As I read from your May 20th OSGi proposal, the core and block jars are
managed within the OSGi framework, is this correct? Meaning that the
directory a potential user is presented with is minimal because of
this?
> 5. The user start to develop the new application from the skeleton one
> and have at all times a working app that can be used from the browser.
>
> I think polymorphic extension will be a key mechanism for making it
> easy for users to develop new apps.
<snip>
> Also components from the extended block can be overrided.
Could you explain how?
> 6. The new block contain some new and intersting stuff that is not
> available before. After a number of refactorings it consists of a
> number of blocks that are reusable and solves well defined concerns.
> Now the user puts the blocks in a new project in Sourceforge (or
> cocoondev.org etc).
That's a v cool thought. Do you envision that at this point, a user who
finds the reusable blocks in the Sourceforge project, could download
them and run them as they are? Meaning, would they contain Cocoon's
core, or as you explain further, would it only contain the parts of the
Cocoon core it needs? Might it instead contain only the meta info
needed to downloaded needed core and non-core components during
install?
Are you guys thinking of a central Cocoon OSGi repository all these
externally developed block-built apps would rely on?
> I would assume that we will have an Cocoon Eclipse starting kit distro
> as well. With IDE support, the user can get much more support and
> guiding in the above described process. The Lepido crew will hopefully
> give a view on that.
From http://www.eclipse.org/proposals/eclipse-lepido/ :
"To this effect, there will be a Cocoon project setup wizard, that will
allow the user to choose the blocks that are to be included in the
project, also allowing also further modification of the selected blocks
during the project lifetime."
Do people here think (Sylvain?) that use of the AXE editors for the
conf files might mean, that during the setup process for a typical app
(say a portal), dependency resolutions would get solved (by download)
while the user interacts with the form? As in 'oh I'll need some CMS
functionalitiy, too'?
> WDYT?
I think it sounds great, and I thank you very much for your time.
Cheers,
David
--
David Plans Casal, Director of Research, Luminas Internet Applications
Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135
Web: www.luminas.co.uk Orixo alliance: http://www.orixo.com/
[RT] Block usage
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
David Casal wrote:
<snip/>
> how do you see the common user approaching the development of new
> webapp, considering they might not have a senior level of development
> experience? Could you illustrate your ideal use case scenario?
<snip/>
We haven't discussed use case scenarious in a more systematic way for
quite some time. Bits and pieces have been discussed in technical
threads although not in any way that have been easy to follow for those
not involved in the specifics. What's described in
http://wiki.apache.org/cocoon/BlockIntroduction and
http://wiki.apache.org/cocoon/BlocksUseCases still holds. But Cocoon has
changed since then, new technologies have appeared and we have learnt
more by discussing and trying to implement the blocks so it could be
worthwhile to discuss the user experience of blocks again.
I'll mix up the use case with some technical details on how it might be
implemented. The terms block, bundle and plugin are synonymes in this RT.
Ok, here is my current view:
A basic scenario
================
1. A soon to become Cocoon user, downloads the "start kit" distribution
from our site.
It contains the (OSGi) kernel, the Cocoon service block (containing the
Cocoon core), a Cocoon servlet block, a (light weight) web server
block, a block deployer block, a block depoyer webapp block, a "get
started" tutorial block and some basic blocks (template, cforms, xslt,
flow, ...) that the previous blocks depends on.
2. The user double clicks the distribution and answer where to install
it and whether the tutorial webapp should be started.
It is not certain that the distribution contains all the above
physically, it might download its dependencies during this step. Those
thinking about using Maven etc can probably give a better view on this.
If the user chose to start the tutorial webapp, the kernel will be
started and the blocks listed above will be installed into the kernel
and started. The start page for the tutorial will be mounted at e.g. "/"
and will be served through the call chain: web server block -> Cocoon
servlet block -> Cocoon service block -> "Get started" tutorial block.
3. The user points the browser at http://localhost:8888/ and start to
follow the tutorial.
Here we have IMO a lot to learn from Forrest. When you have dowloaded
and installed Forrest you directly gets instructions about how to start
use it.
4. The user can chose between following a number of different wizard
like tutorials, e.g.: Minimal Cocoon app, documentation site (Forrest),
portal, CMS site (Lenya or Daisy), Spring based webapp etc.
In this step the needed blocks (including the specific tutorial/wizard)
will be dowloaded, installed and started. A user block skeleton will be
created. It should be noted that the created user block is much simpler
than what is needed today. It is a directory with a description of what
blocks the block depends on (wiring.xml and the Manifest file), a near
to empty sitemap and that is all.
5. The user start to develop the new application from the skeleton one
and have at all times a working app that can be used from the browser.
I think polymorphic extension will be a key mechanism for making it easy
for users to develop new apps. Let us say that you want to create a
documentation site. Then your skeleton block extends the Forrest block,
which allready contain an example documentation site. By extending the
Forrest block, your new this far empty, block allready delivers content.
The Forrest block is designed in such a way that everything that you
might want to change or extend: content, menues, styling, configuration
etc is available through the blocks sitemap (some of it only
internally). By overiding the URLs of these things in your own sitemap
with own content you can one step at the time adapt the default app to
your own needs. For some of the inherited resources you just want to
modify the original content. This can be done by applying a stylesheet
on "block:super:". Also components from the extended block can be overrided.
6. The new block contain some new and intersting stuff that is not
available before. After a number of refactorings it consists of a number
of blocks that are reusable and solves well defined concerns. Now the
user puts the blocks in a new project in Sourceforge (or cocoondev.org etc).
An important aspect of blocks is that they can make Cocoon development
much more scalable and distributed. To make this possible we must, IMO,
split the Cocoon core of today in a number of blocks. These blocks
should have well defined concern areas, and in some cases own release
cycles. We should also be much more carefull about what is external
interfaces and classes and what is only for internal use.
Above all we should have a lean, mean and rock stable core, containing
the basic mechanisms for the sitemap and (possibly) component management
and the minimal set of core interfaces. This is a must for creating a
stable fundament that external blocks developers can put their trust in.
--- o0o ---
I would assume that we will have an Cocoon Eclipse starting kit distro
as well. With IDE support, the user can get much more support and
guiding in the above described process. The Lepido crew will hopefully
give a view on that.
WDYT?
/Daniel
Re: Block builder and deployer
Posted by David Casal <da...@luminas.co.uk>.
Hello all,
I apologise in advance for interrupting the thread and introducing
possibly unnecessary noise. Please tell me to go away if you find this
inappropriate.
For those of you who don't know who I am, I was the musician at GT2003.
That doesn't entitle me to pester you like this, but I hope you will
read on anyway.
I have some generic questions with regards to this Blocks/Maven2
thread, because I'm writing a report for JISC (jisc.ac.uk) that should
inform public servants in education about the future of web frameworks
(don't ask me why -I'm- writing it, they just point at random monkeys
and say things like 'go write about the future').
Firstly, I'd like your thoughts on LEGO.
Once you star-studded geniuses (I'm serious!) have figured out
Maven2-Blocks integration, how do you see the common user approaching
the development of new webapp, considering they might not have a senior
level of development experience? Could you illustrate your ideal use
case scenario?
Is it perhaps whereby LowlyDeveloperN00b downloads Cocoon, reads the
docs, gets pointed at 'Your first Webapp Tutorial', dances with Maven2,
and sees the automagic construction of a skeleton webapp which
illustrates best practice? How far do dependency injection issues get
resolved for her? Can you see a relevant RubyOnRails comparison and
might you adopt its practice? How? Do you see a point where they'll be
able to put together semi-complex webapps in LEGO style?
Secondly, if you were to think much further ahead in the future, do you
see agent-driven applications calling containers which might or might
not call Cocoon components into a user's 'Webapp Building' tool? Does
the work Stefano is carrying out at MIT (Simile, PiggyBank) make you
think of emergent people processing, whereby people might be able to
use Firefox to build web applications, by having the browser enquire
RDF repositories for the right components and their dependencies?
If you read this far, I owe you a beer. Please get creative with your
answers, comic-book style.
I'd like to have your wildest dreams for cocoon, even if all I get is
'I'd like cocoon to run my house' or 'shut the fuck up you piano
playing barbarian'.
Yours,
David Casal
--
David Plans Casal, Director of Research, Luminas Internet Applications
Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135
Web: www.luminas.co.uk Orixo alliance: http://www.orixo.com/
Re: Block builder and deployer
Posted by Reinhard Poetz <re...@apache.org>.
Unico Hommes wrote:
> Reinhard Poetz wrote:
>>hmmm, IMO yes ;-) Some others want to use Maven. As said in some former
>>discussions, it will not matter which build system will build a COB as
>>long as it follows the (to be done) COB specification (block.xml,
>>directory structure). I generated Ant scripts out of block descriptors
>>(block.xml) as I know much more about Ant than about Maven. Finally, I
>>think we will be able to provide support for both build systems which
>>isn't a disadvantage IMO.
>
>
> Exactly my thinking. In fact the reason I asked is that I was thinking
> of starting a Maven2 plugin for cocoon. I've been looking at the
> emerging Maven2 effort that is due to come out this summer and I think
> its going to be a killer. IIUC I can just start that in the whiteboard
> without a vote right?
yes
IIUC Maven2 will be based on Ant, right? Could you share your thoughts about a
Maven2 plugin for Cocoon?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Block builder and deployer
Posted by Unico Hommes <un...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Reinhard Poetz wrote:
> Unico Hommes wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Reinhard Poetz wrote:
>>
>>> Unico Hommes wrote:
>>>
>>> Nice to see you back Unico!
>>
>>
>>
>> Thanks Reinhard! Lurker mode is off now, but still have some catching up
>> to do. One of the things I'd been meaning to find out is what is the
>> status of your blocks builder
>
>
> the block-builder works as described on the wiki page. It uses the
> block.xml to generate an Ant script out of it which builds the block
> resolving all dependencies. Currently it requires more knowledge about
> how blocks will actually look like. AFAIU only little work is left but
> this requires more work on the implementation of real blocks (Daniel's
> current work on the Block(s)Manager, the OSGi integration)
>
Ah, ok that explains the rather suspended state of that effort I was
sensing.
>> and blocks deployer
>
>
> Ihe interfaces are pretty stable and the unit tests are already able to
> deploy a block. My last commits dealt with updating the wiring.xml but
> this hasn't been finished. I guess that it will take about 5 working
> days to finish the missing parts and some additional time to adapt it
> according to the requirements that will arise with the actual block
> implementation.
>
> As we currently have the ongoing discussion about OSGi, I agree with
> Daniel and Sylvain that we will have to provide our own deployment tools
> as our needs are too special. But maybe I 'm (we're) wrong here.
>
> Of course any help is very appreciated!
>
> efforts. Especially,
>
>> is blocks builder the intented build system for 2.2?
>
>
> hmmm, IMO yes ;-) Some others want to use Maven. As said in some former
> discussions, it will not matter which build system will build a COB as
> long as it follows the (to be done) COB specification (block.xml,
> directory structure). I generated Ant scripts out of block descriptors
> (block.xml) as I know much more about Ant than about Maven. Finally, I
> think we will be able to provide support for both build systems which
> isn't a disadvantage IMO.
Exactly my thinking. In fact the reason I asked is that I was thinking
of starting a Maven2 plugin for cocoon. I've been looking at the
emerging Maven2 effort that is due to come out this summer and I think
its going to be a killer. IIUC I can just start that in the whiteboard
without a vote right?
- --
Unico
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCk7kVcuec8tVNKAwRAo9HAKCl4Nt/Erzit+xrrA3A/i6YeirfhQCeIRNk
LNlRcS6kqE73NMF6MmbEJ+c=
=Ky+y
-----END PGP SIGNATURE-----