Re: Roadmap for Cocoon Blocks
Jorg Heymans wrote: Vadim Gritsenko wrote: * Copy over blocks to WEB-INF/blocks or simialr :-) by default, all included blocks are copied to WEB-INF/lib when using the war:war task. But we can have them anywhere we want really. Yep they should be elsewhere, and definitely not in the lib! :) * Prepare a source release there is the source:jar task [1], we could use it for first milestones while we spec out how the source release should look like [*] As long as we have all contents which we have now, I'm ok... What this task produces? Now I think we essentially ship zip of checkout from svn... * Prepare a binary release would you initially be happy with a deployable war file containing all blocks? Then its doable already (war:war on the webapp module), otherwise we should spec out how exactly the binary release should look like [*] Well it should be zip file containing * Javadocs * Daisy/Forrest Docs (whatever docs we end up with after exporting from daisy) * Webapp * Jetty * Scripts Not sure I want to see war file: not all of Cocoon samples are working from inside the war. * Build subset of blocks (using properties file?) First thought: this could be done by writing a plugin that reads local.blocks.props, generates a project definition from it and executes a build using this pom. Ok I think above is a complete list of what is needed from it... Did I miss anything? What is not implemented yet? this covers most initial thoughts yes. I'll see about adding them to the [M10N] roadmap. Great. Vadim Regards Jorg [1] http://maven.apache.org/maven2/plugins/maven-source-plugin/ [*] if this has been decided allready, apologies - just point me to the thread and i'll add it to bugzilla M10N roadmap.
Re: Roadmap for Cocoon Blocks
Vadim Gritsenko wrote: > * Build Cocoon done > * Build all blocks done (samples not excluded) > * Copy over blocks to WEB-INF/blocks or simialr :-) by default, all included blocks are copied to WEB-INF/lib when using the war:war task. But we can have them anywhere we want really. > * Patch wiring.xml (as soon as we start using it) yes, this will be part of the deployment plugin. > * Prepare a source release there is the source:jar task [1], we could use it for first milestones while we spec out how the source release should look like [*] > * Prepare a binary release would you initially be happy with a deployable war file containing all blocks? Then its doable already (war:war on the webapp module), otherwise we should spec out how exactly the binary release should look like [*] > * Build subset of blocks (using properties file?) First thought: this could be done by writing a plugin that reads local.blocks.props, generates a project definition from it and executes a build using this pom. > * Prepare a source release with subset of blocks (is it needed?) use the generated pom from above > * Prepare a binary release with subset of blocks use the generated pom from above. > I think above is a complete list of what is needed from it... Did I miss > anything? What is not implemented yet? this covers most initial thoughts yes. I'll see about adding them to the [M10N] roadmap. Regards Jorg [1] http://maven.apache.org/maven2/plugins/maven-source-plugin/ [*] if this has been decided allready, apologies - just point me to the thread and i'll add it to bugzilla M10N roadmap.
Re: Roadmap for Cocoon Blocks
Pier Fumagalli wrote: On 12 Oct 2005, at 15:21, Daniel Fagerstrom wrote: ... An advantage of using OSGi instead of a home brewn solution is that we don't have to solve all these complexity issues ourselves. As an example there actually allready was an Eclipse plugin editor there that helped you. On that I agree wholeheartedly, mate... Don't get me wrong. I'm just seeing my OSGI Eclipse plugin on one side, and the last slide Arje posted during the wrap-up of the GetTogether "SIMPLICITY" :-) Somehow, I can't feel OSGI is moving us towards that direction... You know mate, simplicity is my main concern and driving force. Now it doesn't get simpler in the first step as we have to let the new stuff live side by side with the old stuff. But as soon as we have got the things working we can start to split Cocoon in small blocks with well defined concern areas. I'm very motivated to get there so I guess I can ask you to trust that we are getting there or better help getting there ;) Also bring something else that I guess that you have to work with it for some time to really appriciate. It is like a small operating system with a console where you can start and stop blocks, ask about theire state and meta data, check the state of the services etc. It is really neat. ... Yep... I feel your pain... But thinking about it for a little bit, I'm starting to wonder if there is another way... There is still a big nag in my mind, related to what Leo posted a while ago, and outlined here: http://www.betaversion.org/~pier/ 2005/07/dependancies-through-import-statements.html I like the simplicity that Leo outlined... I also find it cool. And it would be fun to work on. But for the moment I feel more entusiastic about getting something working in realistic time and about the possibility to cooperate with other communities than about doing container research. ... Dude, your pain is _my_ pain on this topic... Unfortunately my current job doesn't allow me to spend much time on Cocoon itself and related projects (or even on my wife, for that matters!!!). Seriously speaking, I wish I could dedicate more time onto this, but for now, I'm tied into writing XSLT and maintaining a huge lump of PERL code, and I can tell you, it's not fun... Yes I understod that. And after having worked on some other somewhat complicated stuff like templates, VPCs, the sitemap parts my experience was that even if people was interested, it was next to impossible to get much feedback on technical questions. So my conclusion was that even if we have many talented people in the community, the fact is that they are not interested enough in deep infrastructure stuff to actually spend the time in designing and building a container suitable for blocks. So the realistic choices was to either use something that existed or don't bother about blocks anymore. You know how I am :-) I don't like hacks, or one-fits-all things... I just wish I had more time! :-P We all do ;) /Daniel
Re: Roadmap for Cocoon Blocks
On Thursday 13 October 2005 01:19, Torsten Curdt wrote: > > I hope the Cocooners can work all of this out, as the motivation > > for me to use > > Cocoon diminishes by the days, as it gets easier and easier to do > > stuff in > > competing platforms that only made sense in Cocoon previously. > > ...like? > > Just curious... I hope I am not getting in to trouble for trying out other stuff ;o) A few weeks ago we started on a new internal back-burner project, and needed some forms, user auhorization, multiple L&F depending on user, and PDF reports from JDO-backed database. A few months ago, I would not even think before throwing Cocoon at the problem. Due to need to learn Wicket for another external upcoming project, we gave it a go. It was scarily simple, and considering their use of plain and pure HTML as templating, typesafety all over the place, 1:1 checks for components in code vs components on page, no XML and easy to programmatically hook JasperReports straight into the reponse stream, I was indeed impressed. And that was from starting from scratch. Does it really scale upwards? How about endless support of UserAgents?? Performance under heavy load? Sorry - I don't know. Just saying the answers are no longer given, even if you know Cocoon pretty well. I am a Java programmer, and it is faster for me to hack up 100 lines of code than it is to get a combo of XML and JavaScripts operational. I love the compiler :o) Now, compare that with Cocoon anno 2001. Far ahead of its time. The orthogonality of concerns were remarkable for its time. The competition was essentially CGI, SSI, JSP and hard coded servlets. Cocoon rose with the external dependencies of Batik, FOP and many others over time, which made Cocoon a unique center-piece in content aggregation. Cheers Niclas
Re: Roadmap for Cocoon Blocks
I hope the Cocooners can work all of this out, as the motivation for me to use Cocoon diminishes by the days, as it gets easier and easier to do stuff in competing platforms that only made sense in Cocoon previously. ...like? Just curious... cheers -- Torsten PGP.sig Description: This is a digitally signed message part
Re: Roadmap for Cocoon Blocks
On Wednesday 12 October 2005 22:21, Daniel Fagerstrom wrote: > Also Niclas Hedman have moved his post Merlin/Metro work to use context > dependency injection and it is built uppon OSGi, maybe he can comment on > it. Not much to report in this ContextIoC [1] area. I have been busy porting Merlin/Metro to a OSGi bundle, where the Merlin/Metro services are seen by other bundles, and the Merlin/Metro services can use the OSGi services. And some stuff around all to make this work. All needed as migration path for the project I am involved. Other than that, most important observation in the OSGi adventure is probably that bundles becomes "just nice size" (or maybe it is just my preference). Not too large that 100s of classes needs to interact with each other with heaps of GoF patterns required to hold everything together, and essentially I don't feel I need any "component framework" at all. A dozen or two classes is typical bundle size for me, and all bundles that provides a service generates two Jars, one with the API and one for the impl, so the API can be placed in dependent bundles, as originally intended. That allows me to "fabricate" the needed components or their factories in the Activator, pass it down the line with constructor injection, and pretty set to go. I.e. I am on the same page as Pier when it comes to "I don't like complex solutions", and to me Spring is complex, Pico is complex, yes Merlin/Metro is complex. One gets sucked in slowly into these platforms, but end up fighting different kind of battles (XML hell) instead of coding Java. Anyway... With the "Feature" feature in OSGi R4, where sets of bundles are treated as mega-bundles, I think my "small bundle approach" makes very good sense, and a component-like organization is emerging. I still think that OSGi needs better implementations of many presecribed services, i.e Config, Prefs, Meta, User, Permission and so on services. I was hoping that Felix would become the place where those implementations flourished and could be shared across half a dozen projects at ASF alone. As for Cocoon to use OSGi, I am not familiar enough with the inner workings of Cocoon of today to have any clue of how hard that would be to remain compatible with previous versions. I guess that 100% compatibility is impossible, by the fact that there are no well-defined contracts, and any user could be using any internal bits that it happens to reach one way or the other. I hope the Cocooners can work all of this out, as the motivation for me to use Cocoon diminishes by the days, as it gets easier and easier to do stuff in competing platforms that only made sense in Cocoon previously. Cheers Niclas [1] http://www.theserverside.com/articles/article.tss?l=IOCandEJB
Re: Roadmap for Cocoon Blocks
Upayavira wrote: Stefano Mazzocchi wrote: Daniel Fagerstrom wrote: Pier Fumagalli wrote: On 11 Oct 2005, at 20:16, Bertrand Delacretaz wrote: Le 11 oct. 05, à 07:31, Reinhard Poetz a écrit : ...- Cocoon 2.2 will not use OSGi but will support blocks as far as possible:... ...- Cocoon 3.0 will use OSGi --> shielding classloader and hot plugablillity... ...WDOT? +1 to the plan. Just one small nitpicking comment, we should say "3.0 will *most probably* use OSGI" - as you said, it's a nice goal to have but I don't think we're 100% positive on that yet, there are still a few unknowns. I agree wholeheartedly... I am not 100% sure that OSGI is the perfect solution. AFAICS it's a little bit too cumbersome for my brain. And I know a lot of others share my concerns (from discussions at the GT). Pier Any specific concerns about OSGi? For me, licensing. As for technical matters, I stopped caring when we killed Avalon. We can't ship until a OSGi R4 implementation is available, which means probably waiting for Felix to finish the implementation *and* exit incubation. That might take some time. Or use Eclipse, which is R4 already, and then switch to Felix when it matures sufficiently. Ah! didn't know that. Good, I'm happy then. -- Stefano.
Re: Roadmap for Cocoon Blocks
Stefano Mazzocchi wrote:
Any specific concerns about OSGi?
For me, licensing. As for technical matters, I stopped caring when we
killed Avalon.
We can't ship until a OSGi R4 implementation is available, which means
probably waiting for Felix to finish the implementation *and* exit
incubation. That might take some time.
Fortunatly we don't have to wait that long:
http://www.eclipse.org/osgi/
Eclipse 3.1.1 supports the final OSGi spec. Citing Jeff McAffer:
[...] In any
event, it is complete and R4. As soon as the TCK is avalialbe it will be
officially compliant. [...]
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Roadmap for Cocoon Blocks
Stefano Mazzocchi wrote: Daniel Fagerstrom wrote: Pier Fumagalli wrote: On 11 Oct 2005, at 20:16, Bertrand Delacretaz wrote: Le 11 oct. 05, à 07:31, Reinhard Poetz a écrit : ...- Cocoon 2.2 will not use OSGi but will support blocks as far as possible:... ...- Cocoon 3.0 will use OSGi --> shielding classloader and hot plugablillity... ...WDOT? +1 to the plan. Just one small nitpicking comment, we should say "3.0 will *most probably* use OSGI" - as you said, it's a nice goal to have but I don't think we're 100% positive on that yet, there are still a few unknowns. I agree wholeheartedly... I am not 100% sure that OSGI is the perfect solution. AFAICS it's a little bit too cumbersome for my brain. And I know a lot of others share my concerns (from discussions at the GT). Pier Any specific concerns about OSGi? For me, licensing. As for technical matters, I stopped caring when we killed Avalon. We can't ship until a OSGi R4 implementation is available, which means probably waiting for Felix to finish the implementation *and* exit incubation. That might take some time. Or use Eclipse, which is R4 already, and then switch to Felix when it matures sufficiently. Upayavira
Re: Roadmap for Cocoon Blocks
Daniel Fagerstrom wrote: Pier Fumagalli wrote: On 11 Oct 2005, at 20:16, Bertrand Delacretaz wrote: Le 11 oct. 05, à 07:31, Reinhard Poetz a écrit : ...- Cocoon 2.2 will not use OSGi but will support blocks as far as possible:... ...- Cocoon 3.0 will use OSGi --> shielding classloader and hot plugablillity... ...WDOT? +1 to the plan. Just one small nitpicking comment, we should say "3.0 will *most probably* use OSGI" - as you said, it's a nice goal to have but I don't think we're 100% positive on that yet, there are still a few unknowns. I agree wholeheartedly... I am not 100% sure that OSGI is the perfect solution. AFAICS it's a little bit too cumbersome for my brain. And I know a lot of others share my concerns (from discussions at the GT). Pier Any specific concerns about OSGi? For me, licensing. As for technical matters, I stopped caring when we killed Avalon. We can't ship until a OSGi R4 implementation is available, which means probably waiting for Felix to finish the implementation *and* exit incubation. That might take some time. -- Stefano.
Re: Roadmap for Cocoon Blocks
On 12 Oct 2005, at 15:21, Daniel Fagerstrom wrote: Pier Fumagalli wrote: On 12 Oct 2005, at 12:40, Daniel Fagerstrom wrote: Pier Fumagalli wrote: On 11 Oct 2005, at 20:16, Bertrand Delacretaz wrote: Just one small nitpicking comment, we should say "3.0 will *most probably* use OSGI" - as you said, it's a nice goal to have but I don't think we're 100% positive on that yet, there are still a few unknowns. I agree wholeheartedly... I am not 100% sure that OSGI is the perfect solution. AFAICS it's a little bit too cumbersome for my brain. And I know a lot of others share my concerns (from discussions at the GT). Any specific concerns about OSGi? Personally, it looks "cumbersome" to me... Heck, I'm writing an Eclipse plugin at the moment, and if it wasn't for the Eclipse Plugin editor and stuff, I'd be totally lost. OSGi gives us classloader isolation and the possibility of hot plugabillity. Both are rather complex areas, and things that we require from the real block system, so some extra complexity is hard to avoid. Classloader isolation is quite neat, I have to admit that, but it's not a major difficulty to implement on top of existing frameworks... An advantage of using OSGi instead of a home brewn solution is that we don't have to solve all these complexity issues ourselves. As an example there actually allready was an Eclipse plugin editor there that helped you. On that I agree wholeheartedly, mate... Don't get me wrong. I'm just seeing my OSGI Eclipse plugin on one side, and the last slide Arje posted during the wrap-up of the GetTogether "SIMPLICITY" :-) Somehow, I can't feel OSGI is moving us towards that direction... But that's a feeling, I'm far from saying "No, let's use something else", don't get me wrong... Since the flow came along, I got quite lazy (weakly typed languages rule) and the complexity of writing (and maintaining) a set of metadata files related to each individual block, on top of sitemaps, wirings, xconfs, source Java files and so on is definitely not appealing to me. For the Manifest.mf, the only complexity I have experienced is maintaining the export and import of packages. There are several things to say about that: First there are tool support to help you, Eclipse e.g. There is also a tool for calculating dependencies between the bundles: http://oscar-osgi.sourceforge.net/mangen/, that we maybe could use in our build process. You can also simplify export and import rules by using wildcards. But IMO there is a more important aspect of imports and exports: they declare what your bundle export and import and if they are complicated, that often mean that your bundle doesn't have a focused concern area and that its interface to the rest of the world is fat. This leads to rigid systems that are hard to reuse. So it is true that the current "bundleization" of Cocoon have complicated export and import section. I don't see that as a problem with OSGi, but rather as a consequnce of what we all allready know: Cocoon is monolothic, have far to much inter dependencies and fat interfaces and it is not that well defined what sub parts there are. Yep... I feel your pain... But thinking about it for a little bit, I'm starting to wonder if there is another way... There is still a big nag in my mind, related to what Leo posted a while ago, and outlined here: http://www.betaversion.org/~pier/ 2005/07/dependancies-through-import-statements.html I like the simplicity that Leo outlined... As soon as the basic mechanisms are in place I and hopefully others will focus on geting the contracts leaner. Yep... We need to see what the future holds... I'm wondering if there isn't an easier (simpler) way to approach the problem. Sure, don't we all ;) We can of course wait for ever on the perfect approach for real block. But after having waited for the for 3+ years, I and some others wanted something good enough now rather than something perfect in the future. For your core, you might remeber that I supported that we should use it and wanted to start working on it, but you never found time to answer my qustions about some of the concepts in it or commit the much improved version of it that you said that you had. Dude, your pain is _my_ pain on this topic... Unfortunately my current job doesn't allow me to spend much time on Cocoon itself and related projects (or even on my wife, for that matters!!!). Seriously speaking, I wish I could dedicate more time onto this, but for now, I'm tied into writing XSLT and maintaining a huge lump of PERL code, and I can tell you, it's not fun... That's why I'm not saying "let's move away from OSGI", but just outlining the fact that I personally find it quite cumbersome, and that what I like most is simplicity... If we go down the OSGI route, I'll code for OSGI, not for some pseudo-ad
Re: Roadmap for Cocoon Blocks
Ralph Goers wrote: hepabolu wrote: If the ideas of keeping track of changes in a changes.xml per block are going to be implemented, there should be a proper configuration of the site generating aspects, i.e. m2 site:site should result in a smallish site that includes basic info with a link to the Daisy books (included in the release) and formatted pages for all changes.xml of all blocks. WDYT? Bye, Helma I think our site will end up bearing a resemblance to maven's. They have the core documentation and in that is the plug-in section where each plugin is documented separately. Yes, but I want to keep the "mavenized" part as small as possible, otherwise we're going back to hacking xdocs. So in my view it's just the relative static info like "about", "svn address", "mailing lists" and "changes" and maybe "developer team". The "about" part can refer to a link to the Daisy books. All this (except for "changes") is generated from top level pom.xml. Bye, Helma
Re: Roadmap for Cocoon Blocks
Pier Fumagalli wrote: On 12 Oct 2005, at 12:40, Daniel Fagerstrom wrote: Pier Fumagalli wrote: On 11 Oct 2005, at 20:16, Bertrand Delacretaz wrote: Just one small nitpicking comment, we should say "3.0 will *most probably* use OSGI" - as you said, it's a nice goal to have but I don't think we're 100% positive on that yet, there are still a few unknowns. I agree wholeheartedly... I am not 100% sure that OSGI is the perfect solution. AFAICS it's a little bit too cumbersome for my brain. And I know a lot of others share my concerns (from discussions at the GT). Any specific concerns about OSGi? Personally, it looks "cumbersome" to me... Heck, I'm writing an Eclipse plugin at the moment, and if it wasn't for the Eclipse Plugin editor and stuff, I'd be totally lost. OSGi gives us classloader isolation and the possibility of hot plugabillity. Both are rather complex areas, and things that we require from the real block system, so some extra complexity is hard to avoid. An advantage of using OSGi instead of a home brewn solution is that we don't have to solve all these complexity issues ourselves. As an example there actually allready was an Eclipse plugin editor there that helped you. Since the flow came along, I got quite lazy (weakly typed languages rule) and the complexity of writing (and maintaining) a set of metadata files related to each individual block, on top of sitemaps, wirings, xconfs, source Java files and so on is definitely not appealing to me. For the Manifest.mf, the only complexity I have experienced is maintaining the export and import of packages. There are several things to say about that: First there are tool support to help you, Eclipse e.g. There is also a tool for calculating dependencies between the bundles: http://oscar-osgi.sourceforge.net/mangen/, that we maybe could use in our build process. You can also simplify export and import rules by using wildcards. But IMO there is a more important aspect of imports and exports: they declare what your bundle export and import and if they are complicated, that often mean that your bundle doesn't have a focused concern area and that its interface to the rest of the world is fat. This leads to rigid systems that are hard to reuse. So it is true that the current "bundleization" of Cocoon have complicated export and import section. I don't see that as a problem with OSGi, but rather as a consequnce of what we all allready know: Cocoon is monolothic, have far to much inter dependencies and fat interfaces and it is not that well defined what sub parts there are. As soon as the basic mechanisms are in place I and hopefully others will focus on geting the contracts leaner. I'm wondering if there isn't an easier (simpler) way to approach the problem. Sure, don't we all ;) We can of course wait for ever on the perfect approach for real block. But after having waited for the for 3+ years, I and some others wanted something good enough now rather than something perfect in the future. For your core, you might remeber that I supported that we should use it and wanted to start working on it, but you never found time to answer my qustions about some of the concepts in it or commit the much improved version of it that you said that you had. I really liked the idea of POJOs, and now OSGI forces me back to re-use service factories again (so, what's the difference from Avalon???), and on top of what Avalon does, it introduces all those manifests and stuff... At the CocoonGT one year ago the concensus was to use two level of containers for blocks one, intra block container like ECM++ or Spring that keeps back compability and give convenient component handling and one inter block container taking care of class loader isolation and hot plugabillity. OSGi have what is needed for the second part, but is as you notice not as convenient as e.g. Spring for the internal component management. The style of OSGi is rather similar to Avalon but as allready said it have classloader isolation and hot plugability support and above that it is standardized. So we can be rather confident that there is not going to be any Avalon community kind of things. Oh, and please don't tell me that I can still use Avalon, Spring or whatever in the new thing. Why shouldn't I? That was a major design criteria that we should keep back compability. If we go down the OSGI route, I'll code for OSGI, not for some pseudo-adapter of some sort... I'm not one to take shortcuts. I can agree with that attitude, even if I think most users will be quite happy to be able to use their favorit component container. OSGi is rather low level for component management, only the basic mechanisms are there (+ classloader isolation and hot plugabillity support, which is what makes it unique), but no one stops you from building more convenient abstractions above that. In R4 there is a de
Re: Roadmap for Cocoon Blocks
hepabolu wrote: If the ideas of keeping track of changes in a changes.xml per block are going to be implemented, there should be a proper configuration of the site generating aspects, i.e. m2 site:site should result in a smallish site that includes basic info with a link to the Daisy books (included in the release) and formatted pages for all changes.xml of all blocks. WDYT? Bye, Helma I think our site will end up bearing a resemblance to maven's. They have the core documentation and in that is the plug-in section where each plugin is documented separately. Ralph
Re: Roadmap for Cocoon Blocks
On 12.10.2005 15:24, Bertrand Delacretaz wrote: IIUC we're currently talking of a "first milestone" release of 2.2, not a "release candidate". So the current ant build could be good enough for that until the m2 stuff matures, if this allows the milestone to be out earlier. +1 Jörg
Re: Roadmap for Cocoon Blocks
Le 12 oct. 05, à 14:33, Reinhard Poetz a écrit : ...I think a build/deployment system is a must as soon as we reach the "release candidate" phase of 2.2. Currently the best bet is M2. Do you see any alternatives that could be implemented faster?... IIUC we're currently talking of a "first milestone" release of 2.2, not a "release candidate". So the current ant build could be good enough for that until the m2 stuff matures, if this allows the milestone to be out earlier. -Bertrand
Re: Roadmap for Cocoon Blocks
Vadim Gritsenko wrote: Well, I think m2 should be able to: * Build Cocoon * Build all blocks * Copy over blocks to WEB-INF/blocks or simialr :-) * Patch wiring.xml (as soon as we start using it) * Prepare a source release * Prepare a binary release * Build subset of blocks (using properties file?) * Prepare a source release with subset of blocks (is it needed?) * Prepare a binary release with subset of blocks I think above is a complete list of what is needed from it... Did I miss anything? What is not implemented yet? If the ideas of keeping track of changes in a changes.xml per block are going to be implemented, there should be a proper configuration of the site generating aspects, i.e. m2 site:site should result in a smallish site that includes basic info with a link to the Daisy books (included in the release) and formatted pages for all changes.xml of all blocks. WDYT? Bye, Helma
Re: Roadmap for Cocoon Blocks
Reinhard Poetz wrote: Vadim Gritsenko wrote: Reinhard Poetz wrote: I think a build/deployment system is a must as soon as we reach the "release candidate" phase of 2.2. Currently the best bet is M2. Do you see any alternatives that could be implemented faster? 2.1 is using Ant build for years now; I don't see a problem using it a bit longer if it means release sooner. ok, I think we're talking about differnt things. Anyway - the only missing thing so that the M2 build is equivalent to the Ant build is the include/exclude mechanism, isn't it? Well, I think m2 should be able to: * Build Cocoon * Build all blocks * Copy over blocks to WEB-INF/blocks or simialr :-) * Patch wiring.xml (as soon as we start using it) * Prepare a source release * Prepare a binary release * Build subset of blocks (using properties file?) * Prepare a source release with subset of blocks (is it needed?) * Prepare a binary release with subset of blocks I think above is a complete list of what is needed from it... Did I miss anything? What is not implemented yet? Vadim
Re: Roadmap for Cocoon Blocks
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
I don't recall that m2 will be ready when 2.2 is out. If m2 is not
ready, it should not delay the release. So, I suggest slight change
of plan:
According to the m2 dev list, there will be a m2 final next week (if
I'm
not mistaken). But of course a final version might not mean that
everything works the way we want it :)
Bad choice of words from me :-) I rather meant, our next build system
which is based on m2 could be not ready for 2.2 release.
IIRC, 2.2m1 is due in 1 week or so :-) and m2 build is far from being
implemented. My point is, delays in m2 build system implementation
should not affect 2.2 releases, and if necessary, it can be easily
done as part of 2.3.
I think a build/deployment system is a must as soon as we reach the
"release candidate" phase of 2.2. Currently the best bet is M2. Do you
see any alternatives that could be implemented faster?
2.1 is using Ant build for years now; I don't see a problem using it a
bit longer if it means release sooner.
ok, I think we're talking about differnt things. Anyway - the only missing thing
so that the M2 build is equivalent to the Ant build is the include/exclude
mechanism, isn't it?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Roadmap for Cocoon Blocks
On 12 Oct 2005, at 12:40, Daniel Fagerstrom wrote: Pier Fumagalli wrote: On 11 Oct 2005, at 20:16, Bertrand Delacretaz wrote: Just one small nitpicking comment, we should say "3.0 will *most probably* use OSGI" - as you said, it's a nice goal to have but I don't think we're 100% positive on that yet, there are still a few unknowns. I agree wholeheartedly... I am not 100% sure that OSGI is the perfect solution. AFAICS it's a little bit too cumbersome for my brain. And I know a lot of others share my concerns (from discussions at the GT). Any specific concerns about OSGi? Personally, it looks "cumbersome" to me... Heck, I'm writing an Eclipse plugin at the moment, and if it wasn't for the Eclipse Plugin editor and stuff, I'd be totally lost. Since the flow came along, I got quite lazy (weakly typed languages rule) and the complexity of writing (and maintaining) a set of metadata files related to each individual block, on top of sitemaps, wirings, xconfs, source Java files and so on is definitely not appealing to me. I'm wondering if there isn't an easier (simpler) way to approach the problem. I really liked the idea of POJOs, and now OSGI forces me back to re-use service factories again (so, what's the difference from Avalon???), and on top of what Avalon does, it introduces all those manifests and stuff... Oh, and please don't tell me that I can still use Avalon, Spring or whatever in the new thing. If we go down the OSGI route, I'll code for OSGI, not for some pseudo-adapter of some sort... I'm not one to take shortcuts. Pier smime.p7s Description: S/MIME cryptographic signature
Re: Roadmap for Cocoon Blocks
Reinhard Poetz wrote: Vadim Gritsenko wrote: Carsten Ziegeler wrote: Vadim Gritsenko wrote: I don't recall that m2 will be ready when 2.2 is out. If m2 is not ready, it should not delay the release. So, I suggest slight change of plan: According to the m2 dev list, there will be a m2 final next week (if I'm not mistaken). But of course a final version might not mean that everything works the way we want it :) Bad choice of words from me :-) I rather meant, our next build system which is based on m2 could be not ready for 2.2 release. IIRC, 2.2m1 is due in 1 week or so :-) and m2 build is far from being implemented. My point is, delays in m2 build system implementation should not affect 2.2 releases, and if necessary, it can be easily done as part of 2.3. I think a build/deployment system is a must as soon as we reach the "release candidate" phase of 2.2. Currently the best bet is M2. Do you see any alternatives that could be implemented faster? 2.1 is using Ant build for years now; I don't see a problem using it a bit longer if it means release sooner. Vadim
Re: Roadmap for Cocoon Blocks
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
I don't recall that m2 will be ready when 2.2 is out. If m2 is not
ready, it should not delay the release. So, I suggest slight change
of plan:
According to the m2 dev list, there will be a m2 final next week (if I'm
not mistaken). But of course a final version might not mean that
everything works the way we want it :)
Bad choice of words from me :-) I rather meant, our next build system
which is based on m2 could be not ready for 2.2 release.
IIRC, 2.2m1 is due in 1 week or so :-) and m2 build is far from being
implemented. My point is, delays in m2 build system implementation
should not affect 2.2 releases, and if necessary, it can be easily done
as part of 2.3.
I think a build/deployment system is a must as soon as we reach the "release
candidate" phase of 2.2. Currently the best bet is M2. Do you see any
alternatives that could be implemented faster?
For the first we will start with handcrafted wiring.xml and copying blocks
manually into the right directories. Do you think that this is enough for a release?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Roadmap for Cocoon Blocks
Carsten Ziegeler wrote: Vadim Gritsenko wrote: I don't recall that m2 will be ready when 2.2 is out. If m2 is not ready, it should not delay the release. So, I suggest slight change of plan: According to the m2 dev list, there will be a m2 final next week (if I'm not mistaken). But of course a final version might not mean that everything works the way we want it :) Bad choice of words from me :-) I rather meant, our next build system which is based on m2 could be not ready for 2.2 release. IIRC, 2.2m1 is due in 1 week or so :-) and m2 build is far from being implemented. My point is, delays in m2 build system implementation should not affect 2.2 releases, and if necessary, it can be easily done as part of 2.3. Vadim
Re: Roadmap for Cocoon Blocks
Pier Fumagalli wrote: On 11 Oct 2005, at 20:16, Bertrand Delacretaz wrote: Le 11 oct. 05, à 07:31, Reinhard Poetz a écrit : ...- Cocoon 2.2 will not use OSGi but will support blocks as far as possible:... ...- Cocoon 3.0 will use OSGi --> shielding classloader and hot plugablillity... ...WDOT? +1 to the plan. Just one small nitpicking comment, we should say "3.0 will *most probably* use OSGI" - as you said, it's a nice goal to have but I don't think we're 100% positive on that yet, there are still a few unknowns. I agree wholeheartedly... I am not 100% sure that OSGI is the perfect solution. AFAICS it's a little bit too cumbersome for my brain. And I know a lot of others share my concerns (from discussions at the GT). Pier Any specific concerns about OSGi? /Daniel
Re: Roadmap for Cocoon Blocks
Vadim Gritsenko wrote: > > I don't recall that m2 will be ready when 2.2 is out. If m2 is not ready, it > should not delay the release. So, I suggest slight change of plan: > According to the m2 dev list, there will be a m2 final next week (if I'm not mistaken). But of course a final version might not mean that everything works the way we want it :) Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Roadmap for Cocoon Blocks
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
So here is the roadmap and let's discuss it "officially" on the
mailing list:
I don't recall that m2 will be ready when 2.2 is out. If m2 is not
ready, it should not delay the release. So, I suggest slight change of
plan:
- Cocoon 2.2 will not use OSGi but will support blocks as far as
possible:
- blocks protocol (= sitemap blocks)
- a block gets its own component manager that contains all local
components
and gets the block component managers of all wired blocks as parent.
- blocks are distributed as binaries
- blocks are *not* spread over different directories during deployment
- a block can contain classes in [block]/BLOCK-INF/classes that are
added
to the context classloader
--> this means that everything, that real blocks promise, works
except the
shielding of Java classes.
- Cocoon 2.3
- we use M2 as build and deployment tool (needs some special M2
plug-ins
for the deployment part)
I understand that you don't want to base Cocoon on an unstable M2 release, but
what's the alternative for 2.2? Ant? Maven 1?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Roadmap for Cocoon Blocks
Reinhard Poetz wrote: So here is the roadmap and let's discuss it "officially" on the mailing list: I don't recall that m2 will be ready when 2.2 is out. If m2 is not ready, it should not delay the release. So, I suggest slight change of plan: - Cocoon 2.2 will not use OSGi but will support blocks as far as possible: - blocks protocol (= sitemap blocks) - a block gets its own component manager that contains all local components and gets the block component managers of all wired blocks as parent. - blocks are distributed as binaries - blocks are *not* spread over different directories during deployment - a block can contain classes in [block]/BLOCK-INF/classes that are added to the context classloader --> this means that everything, that real blocks promise, works except the shielding of Java classes. - Cocoon 2.3 - we use M2 as build and deployment tool (needs some special M2 plug-ins for the deployment part) - Cocoon 3.0 will use OSGi --> shielding classloader and hot plugablillity Although Daniel has emphasized this many times I want to repeat it: We don't need to branch trunk for this roadmap. OSGi development can be done in parallel and we can avoid the unsatisfying situation of maintaining two branches. Yep. Of course future development can show that this or that is not possible or should be done differently (who knows now, if OSGi will really make it) but IMO it's nice to have a goal and something that we can communicate to other projects that depend on Cocoon so that they have enough time to adapt their design decisions. WDOT? Sounds good. Vadim
Re: Roadmap for Cocoon Blocks
On 11 Oct 2005, at 20:16, Bertrand Delacretaz wrote: Le 11 oct. 05, à 07:31, Reinhard Poetz a écrit : ...- Cocoon 2.2 will not use OSGi but will support blocks as far as possible:... ...- Cocoon 3.0 will use OSGi --> shielding classloader and hot plugablillity... ...WDOT? +1 to the plan. Just one small nitpicking comment, we should say "3.0 will *most probably* use OSGI" - as you said, it's a nice goal to have but I don't think we're 100% positive on that yet, there are still a few unknowns. I agree wholeheartedly... I am not 100% sure that OSGI is the perfect solution. AFAICS it's a little bit too cumbersome for my brain. And I know a lot of others share my concerns (from discussions at the GT). Pier smime.p7s Description: S/MIME cryptographic signature
Re: Roadmap for Cocoon Blocks
Le 11 oct. 05, à 07:31, Reinhard Poetz a écrit : ...- Cocoon 2.2 will not use OSGi but will support blocks as far as possible:... ...- Cocoon 3.0 will use OSGi --> shielding classloader and hot plugablillity... ...WDOT? +1 to the plan. Just one small nitpicking comment, we should say "3.0 will *most probably* use OSGI" - as you said, it's a nice goal to have but I don't think we're 100% positive on that yet, there are still a few unknowns. -Bertrand
Re: Roadmap for Cocoon Blocks
Stefano Mazzocchi wrote: ... One thing, though, remember to also have a LinkRewritingTransformer that is block aware so that we can do and this gets translated in the right URL We allready have, see http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/webapp/WEB-INF/blocks/sample/sitemap.xmap?view=markup for configuration of the LinkRewriteTransformer and the link element in the begining of http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/webapp/WEB-INF/blocks/sample/simple-samples2html.xsl?view=markup for a (rather crappy) example of using it. (hopefully relative, so that we don't have issues with webapp proxying, or, if absolute, we need a way to configure where is the cocoon mountpoint as seen from the proxy side) It is absolute right now, but if it is more convenient to have it relative, we can make it relative. It seem a little bit complicated though. We could start with absolutizing the URL of the page that is link rewrited and then absolitize a link and from that calculate the relative path of the link relative to the page. Would that be enough or is there more to it? I'm currently doing http://simile.mit.edu/repository/linotype/trunk/stylesheets/absolutize.xslt with my latest linotype and I can't wait to get rid of all these hacks :-) I have some own applications with such hacks and neither can I wait to get rid of them ;) /Daniel
Re: Roadmap for Cocoon Blocks
Jorg Heymans wrote: ... 3.0 is a different beast alltogether. Likely we will need an m2 plugin that can compile one block against other blocks using osgi dependency rules (ie using the manifest information). The same goes for dependency resolution, as it needs to be made osgi aware (right Daniel?). So unless he knows a lot about osgi, a block developer will have to use our m2 deployment framework to target 3.0. Or am I seeing this m2-osgi build and deploy time integration too complicated for what it really is ? As long as the build of a bundle only depends on explicit jars and not on other bundles, the build is rather simple. This will be the case in our initial work with OSGi as we work more on bundelizing the existing Cocoon than integrating with external bundles. And for our own blocks we need to take care of the dependendency on libraries anyway. As soon as we want to have the build dependent on other bundles it becomes a little bit more complicated as the build system must be OSGi aware to know what packages in a bundle that will be available for another bundle. Now, even if this happen to be somewhat complex, it probably doesn't need to be a problem for us. Eclipse have allready solved this in theire build system and created external APIs for handling dependency information. I have discussed this question a little bit at the Felix list, and some of the main developers of the Eclipse kernel suggested to use the Eclipse mechanism and seemed to be willing to help making it work. So for the nearest future it will be enough with a rather simple system, like the M2 OSGi plugin at Felix. And when we require a more sophisticated solution, we have a quite clear idea about how to solve that. /Daniel
Re: Roadmap for Cocoon Blocks
Stefano Mazzocchi wrote:
One thing, though, remember to also have a LinkRewritingTransformer that
is block aware so that we can do
and this gets translated in the right URL (hopefully relative, so that
we don't have issues with webapp proxying, or, if absolute, we need a
way to configure where is the cocoon mountpoint as seen from the proxy
side)
I'm currently doing
http://simile.mit.edu/repository/linotype/trunk/stylesheets/absolutize.xslt
with my latest linotype and I can't wait to get rid of all these hacks :-)
I haven't checked it but I think the LinkRewritingTransformer in the
link-rewriting block is already block aware and does what you want. Of course it
needs to be moved to core.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Roadmap for Cocoon Blocks
Reinhard Poetz wrote: > Currently these dependendencies are declared in the Maven project > descriptor. Personally I don't have a problem with it as the alternative > is having our own mechanism. Shipping M2 with Cocoon 2.2 will be much > simpler. Agreed, but don't you mean "requiring" rather than "shipping" ? Jorg
Re: Roadmap for Cocoon Blocks
Reinhard Poetz wrote: Jorg Heymans wrote: Ralph Goers wrote: I hadn't thought of this before, but I suppose this means that end user applications using Cocoon will need to be built with Maven 2? I'ld say they can but don't have to. Right, if the user makes sure himself that the dependencies are resolved correctly because a 2.2 block will not include the JARs it depends on but they are copied into WEB-INF/lib at deploy time. M2 will make sure that only one version of one JAR type is deployed. Currently these dependendencies are declared in the Maven project descriptor. Personally I don't have a problem with it as the alternative is having our own mechanism. Shipping M2 with Cocoon 2.2 will be much simpler. I don't have a problem with that. I really am not crazy about implementing our own alternative. But it is just one more thing that needs to be made clear in the doc. Ralph
Re: Roadmap for Cocoon Blocks
Reinhard Poetz wrote: In Amsterdam at the GT Daniel gave a presentation (http://cocoongt.hippo12.castaserver.com/cocoongt/daniel-fagerstrom-blocks-2.pdf) about Cocoon blocks and one of his slides contained a roadmap for Cocoon blocks. This roadmap was discussed in the breaks and AFAICT is was widely accepted. Of course this doesn't mean that this is community consensus as not all have had the chance to comment on this yet. So here is the roadmap and let's discuss it "officially" on the mailing list: - Cocoon 2.2 will not use OSGi but will support blocks as far as possible: - blocks protocol (= sitemap blocks) - a block gets its own component manager that contains all local components and gets the block component managers of all wired blocks as parent. - we use M2 as build and deployment tool (needs some special M2 plug-ins for the deployment part) - blocks are distributed as binaries - blocks are *not* spread over different directories during deployment - a block can contain classes in [block]/BLOCK-INF/classes that are added to the context classloader --> this means that everything, that real blocks promise, works except the shielding of Java classes. - Cocoon 3.0 will use OSGi --> shielding classloader and hot plugablillity Although Daniel has emphasized this many times I want to repeat it: We don't need to branch trunk for this roadmap. OSGi development can be done in parallel and we can avoid the unsatisfying situation of maintaining two branches. Of course future development can show that this or that is not possible or should be done differently (who knows now, if OSGi will really make it) but IMO it's nice to have a goal and something that we can communicate to other projects that depend on Cocoon so that they have enough time to adapt their design decisions. I'm +1 One thing, though, remember to also have a LinkRewritingTransformer that is block aware so that we can do and this gets translated in the right URL (hopefully relative, so that we don't have issues with webapp proxying, or, if absolute, we need a way to configure where is the cocoon mountpoint as seen from the proxy side) I'm currently doing http://simile.mit.edu/repository/linotype/trunk/stylesheets/absolutize.xslt with my latest linotype and I can't wait to get rid of all these hacks :-) -- Stefano.
Re: Roadmap for Cocoon Blocks
Jorg Heymans wrote:
Ralph Goers wrote:
I hadn't thought of this before, but I suppose this means that end user
applications using Cocoon will need to be built with Maven 2?
I'ld say they can but don't have to.
Right, if the user makes sure himself that the dependencies are resolved
correctly because a 2.2 block will not include the JARs it depends on but they
are copied into WEB-INF/lib at deploy time. M2 will make sure that only one
version of one JAR type is deployed.
Currently these dependendencies are declared in the Maven project descriptor.
Personally I don't have a problem with it as the alternative is having our own
mechanism. Shipping M2 with Cocoon 2.2 will be much simpler.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Roadmap for Cocoon Blocks
Ralph Goers wrote: > I hadn't thought of this before, but I suppose this means that end user > applications using Cocoon will need to be built with Maven 2? I'ld say they can but don't have to. We will distribute the 2.2 core and block releases via the m2 repository, so m2 based projects can easily upgrade this way. The full binary build will still contain "everything" in one package, this can be used to build your app in any other way you like. Now we might provide a recommended way of building and structuring cocoon applications using m2 archetypes and our own plugins, but it will only be a recommendation and not a requirement. 3.0 is a different beast alltogether. Likely we will need an m2 plugin that can compile one block against other blocks using osgi dependency rules (ie using the manifest information). The same goes for dependency resolution, as it needs to be made osgi aware (right Daniel?). So unless he knows a lot about osgi, a block developer will have to use our m2 deployment framework to target 3.0. Or am I seeing this m2-osgi build and deploy time integration too complicated for what it really is ? Jorg
Re: Roadmap for Cocoon Blocks
I hadn't thought of this before, but I suppose this means that end user applications using Cocoon will need to be built with Maven 2? Ralph Reinhard Poetz wrote: In Amsterdam at the GT Daniel gave a presentation (http://cocoongt.hippo12.castaserver.com/cocoongt/daniel-fagerstrom-blocks-2.pdf) about Cocoon blocks and one of his slides contained a roadmap for Cocoon blocks. This roadmap was discussed in the breaks and AFAICT is was widely accepted. Of course this doesn't mean that this is community consensus as not all have had the chance to comment on this yet. So here is the roadmap and let's discuss it "officially" on the mailing list: - Cocoon 2.2 will not use OSGi but will support blocks as far as possible: - blocks protocol (= sitemap blocks) - a block gets its own component manager that contains all local components and gets the block component managers of all wired blocks as parent. - we use M2 as build and deployment tool (needs some special M2 plug-ins for the deployment part) - blocks are distributed as binaries - blocks are *not* spread over different directories during deployment - a block can contain classes in [block]/BLOCK-INF/classes that are added to the context classloader --> this means that everything, that real blocks promise, works except the shielding of Java classes. - Cocoon 3.0 will use OSGi --> shielding classloader and hot plugablillity Although Daniel has emphasized this many times I want to repeat it: We don't need to branch trunk for this roadmap. OSGi development can be done in parallel and we can avoid the unsatisfying situation of maintaining two branches. Of course future development can show that this or that is not possible or should be done differently (who knows now, if OSGi will really make it) but IMO it's nice to have a goal and something that we can communicate to other projects that depend on Cocoon so that they have enough time to adapt their design decisions. WDOT?
