Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Vadim Gritsenko wrote: Daniel Fagerstrom wrote: Vadim Gritsenko wrote: Sylvain Wallez wrote: Daniel Fagerstrom wrote: The idea for blocks is that blocks that contain public URLs are mounted at deploy time at a some root URL, then the URL revriting transformer translates internal use of symbolic block names to the public exported ones. Why would anyone internally use any block: URIs? This should be totally unnecessary: you can either use relative URIs, You need to use block:foo: URIs to access resources in other blocks, block: URIs to use URIs that you want polymorphic behaviour on, and block:super: for geting an URI from the block that you extend. See http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111791016006393w=2 for more details. or construct absolute by passing sitemap prefix into the xslt - same as we do in existing samples. Using the LinkRewritingTransformer together with the block-path module will be so much more convenient (see the cited mail above). Hm, I found no sample where linkrewriter is necessary [1]. LinkRewritingTransformer isn't part of core so I couldn't use it in the tests for core. Take a look at the examples in src/webapp, start with src/webapp/wiring.xml. In the block sample there is a use of link rewriting which at least demonstrates the mechanism although it doesn't motivate its existence. In the simple-samples2html.xsl I use block:/styles/main.css and block:/images/cocoon.gif for loading some resources that are made available through the sitemap of the block. If I had redefined /images/cocoon.gif and /styles/main.css in the sitemap of the block mysample that extends sample (which I didn't), the LinkRewritingTransformer together with the block-path module would have constructed the right absolute path. You can achive this kind of behaviour without using the LinkRewritingTransformer. We use some sitemap design patterns for achieving block like sitemap inhertitance, at the company I work at. But the XSLT and sitemap prefixed based link construction becomes really complicated and is one of the main sources of error when we try to refactor something. So at least from my experiences the block aware link rewriting is a must to keep your applications managable. Stefano obviously felt the same as he made such a thing an integral part of his original design. All I saw is usage of block: protocol from the sitemap, which I understand. I just don't see there are many (any?) usecases for the block: URIs in the pipelines. Either way I'm thinking it will be relatively obsure usecase anyway. See the example above. If you create a webapp that is polymorphically extensible or that use (sitemap) resources from other blocks, the use of the block: protocol within your xslt, xhtml, jxtg, xml etc files will be a must to keep the complexity managable. /Daniel
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Niclas Hedhman wrote: On Thursday 18 August 2005 05:08, Daniel Fagerstrom wrote: Is there more to it?? That an OSGi framework need to have a protocol like the bundle protocol as part of its implementation to be able to implement Bundle.getResource as motivated in my example above. I guess it is not important, but I am not sure I follow what you mean. For the subject it is rather OT, but the discussion have clarified some technical details about OSGi for me at least. What I meant will hiopefully be clearer later in this mail. If you use URL getResource(String) at the Bundle object of the A bundle the resulting URL must contain a reference to the A bundle to not confuse it with foo.xml from the B bundle. Why can't it return jar:file:///home/niclas/.oscar/cocoon/bundle4/version0.0/bundle.jar!/foo.xml ?? It can if the installed bundles happen to be deployed in such a form. In Knopflerfish bundles can either be deployed in memory or at the file system, which mean that it must contain a protocol that know about the local bundle instalation structure. AFAICT, the specification (R3) does not require the returned URL to be globally resolvable, If you mean globally resolvable within the current OSGi instance I interpret 4.23.3.11 in the spec as that the returned URL should be resolvable in any bundle that has the right AdminPermission. and bundle://4/foo.xml is also only resolvable in the current OSGi instance, not even the within the same JVM. Probably, although the URL registration mechanism in Java is rather hacky and have some register only once semantics that might make the bundle protocol more global than one want to. --- o0o --- Anyway, Sylvain's original proposal will solve the problem he want to solve and will probably be possble to get to work under OSGi in 2.2. And that proposal will use the classloader of the calling object rather than the more flexible Bundle.getResource mechanism. Which makes our current discussion somewhat OT. /Daniel
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
On Thursday 18 August 2005 19:19, Daniel Fagerstrom wrote: AFAICT, the specification (R3) does not require the returned URL to be globally resolvable, If you mean globally resolvable within the current OSGi instance I interpret 4.23.3.11 in the spec as that the returned URL should be resolvable in any bundle that has the right AdminPermission. I mean Globally as serialize the URL to a String, send it by mail to another OSGi instance on the other side of the planet to an OSGi instance (which have the protocol(s) installed) and open the stream. I don't think that is required, which means that a jar:file:/// URL could be returned by the framework. Note that Oscar doesn't have the org.osgi.service.url installed by default, so it does not use bundle: AFAICT. OT -- Hopefully improve our (esp your) understanding, which somewhere down the line probably pays off in better stuff in Cocoon :o). Cheers Niclas
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Niclas Hedhman wrote: On Thursday 18 August 2005 19:19, Daniel Fagerstrom wrote: AFAICT, the specification (R3) does not require the returned URL to be globally resolvable, If you mean globally resolvable within the current OSGi instance I interpret 4.23.3.11 in the spec as that the returned URL should be resolvable in any bundle that has the right AdminPermission. I mean Globally as serialize the URL to a String, send it by mail to another OSGi instance on the other side of the planet to an OSGi instance (which have the protocol(s) installed) and open the stream. Ok, it is certainly not global in that sense. I don't think that is required, which means that a jar:file:/// URL could be returned by the framework. Sure Note that Oscar doesn't have the org.osgi.service.url installed by default, so it does not use bundle: AFAICT. bundle: seem to be Knopflerfish specific. The conclusion is that as long as the instalation repository, not is standardized in OSGi one have to be careful while handling URLs from the different resource resolvers in OSGi. OT -- Hopefully improve our (esp your) understanding, which somewhere down the line probably pays off in better stuff in Cocoon :o). If we succeed to remember this discussion ;) it will save us some time when we migrate from Knopflerfish to Oscar. /Daniel
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Niclas Hedhman wrote: On Thursday 18 August 2005 19:19, Daniel Fagerstrom wrote: AFAICT, the specification (R3) does not require the returned URL to be globally resolvable, If you mean globally resolvable within the current OSGi instance I interpret 4.23.3.11 in the spec as that the returned URL should be resolvable in any bundle that has the right AdminPermission. I mean Globally as serialize the URL to a String, send it by mail to another OSGi instance on the other side of the planet to an OSGi instance (which have the protocol(s) installed) and open the stream. I don't think that is required, which means that a jar:file:/// URL could be returned by the framework. Note that Oscar doesn't have the org.osgi.service.url installed by default, so it does not use bundle: AFAICT. Yes it does. Now that may just be because of a cross-pollination between Felix (formerly known as Oscar) and KF. And Felix also defines a module protocol which gives access to resources within the current bundle (AFAIU, a module in Felix is a bundle instance). OT -- Hopefully improve our (esp your) understanding, which somewhere down the line probably pays off in better stuff in Cocoon :o). Yup! For my particular case, it required me to dig in the spec and cross check my understanding in implementations! Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [Proposal] Switch to Maven NOW
Carsten Ziegeler wrote: Actually I'm a little bit tired of the ongoing Maven discussion. Why can't we just switch the trunk to Maven NOW? Who really cares if trunk is not buildable/working for the next days until the switch is finished? So I propose to: - Completly remove the lib directory - Create a sub project core in the trunk directory I think we will use several (sub) projects, one for the core, one for the webapp etc. and use Mavens multiproject feature. - Move src/java to core/src/java - Create a Maven project description with all dependencies for core Et voila, we will get a cocoon.jar hopefully. Then we create a webapp subproject, move the webapp there and build a webapp with just the core. And then we continue from there, moving test, moving samples etc. On thing at a time. And we can always ask the maven guys for assistence and hints. Ah, and finally, I think we should start right away with m2. How does this relate to/integrate with the OSGi stuff? If it helps us in the right direction there too, then I'm +1. Regards, Upayavira
Re: [Proposal] Switch to Maven NOW
Upayavira wrote: How does this relate to/integrate with the OSGi stuff? If it helps us in the right direction there too, then I'm +1. I honestly don't know. I think it will help us as we can simply splitt the core into smaller parts, like the real core :), osgi stuff, basic components, servlet env, cli env etc. And I hope there will be support for building osgi bundles over time as well. We can use Ant inside Maven anyways, so imho we don't loose anything, but gain some of the Maven advantages. So, I have the hope that Maven helps us with OSGi, but if not it won't be harder than without Maven. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [Proposal] Switch to Maven NOW
Carsten Ziegeler wrote: Actually I'm a little bit tired of the ongoing Maven discussion. Why can't we just switch the trunk to Maven NOW? Who really cares if trunk is not buildable/working for the next days until the switch is finished? So I propose to: - Completly remove the lib directory - Create a sub project core in the trunk directory I think we will use several (sub) projects, one for the core, one for the webapp etc. and use Mavens multiproject feature. - Move src/java to core/src/java - Create a Maven project description with all dependencies for core +1 Et voila, we will get a cocoon.jar hopefully. Then we create a webapp subproject, move the webapp there and build a webapp with just the core. And then we continue from there, moving test, moving samples etc. On thing at a time. And we can always ask the maven guys for assistence and hints. Ah, and finally, I think we should start right away with m2. +1 Several things that should be taken into account IMO: I am not following OSGi threads lately (total lack of time) so I do not know the final block packaging format but I'd love to see it as single artifact. I have already tried to use maven for my cocoon based project mainly because of the fact that currently even the simplest block is: - a jar file - xconf files - xlog files So you cannot just put the block binaries into maven repository. other example that I posted some time ago: if every cocoon uses error2html.xsl by default (along with some other default resources) they should be also packed into jars. Next one: we should resign from using xpatch (apart from web.xml maybe). With single cocoon.xconf it was bearable. With current functionality that allows xconfs to span accros multiple files it just got harder. Try to keep your xconf files intact and add some definitions at build time for: - cron triggers - cforms definitions you'll know what I mean. -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [Proposal] Switch to Maven NOW
Carsten Ziegeler wrote: Actually I'm a little bit tired of the ongoing Maven discussion. Why can't we just switch the trunk to Maven NOW? Who really cares if trunk is not buildable/working for the next days until the switch is finished? So I propose to: - Completly remove the lib directory I assume you want to download everything dynamically from some offiicial Maven repository. Sometimes we need to use date-versions of jars, are we going to have an own Maven repository for such things? - Create a sub project core in the trunk directory I think we will use several (sub) projects, one for the core, one for the webapp etc. and use Mavens multiproject feature. For the current OSGi stuff we have separate bundles for core (src/java), webapp, test, osgi-servlet and we will have at least one bundle for each current block in src/blocks. We should have one Maven project for each bundle/block. - Move src/java to core/src/java - Create a Maven project description with all dependencies for core +1 Et voila, we will get a cocoon.jar hopefully. Then we create a webapp subproject, move the webapp there and build a webapp with just the core. And then we continue from there, moving test, moving samples etc. On thing at a time. And we can always ask the maven guys for assistence and hints. Ah, and finally, I think we should start right away with m2. +1 I've got the impression that both Brett Porter and Jason van Zyl are commited to m2 support for OSGi. /Daniel
Re: [Proposal] Switch to Maven NOW
Daniel Fagerstrom wrote: I assume you want to download everything dynamically from some offiicial Maven repository. Sometimes we need to use date-versions of jars, are we going to have an own Maven repository for such things? We have several repositories here at Apache (used by other projects like Geronimo for example). We can put those jars there (if they have the appropriate license of course). For the current OSGi stuff we have separate bundles for core (src/java), webapp, test, osgi-servlet and we will have at least one bundle for each current block in src/blocks. We should have one Maven project for each bundle/block. Yes. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [Proposal] Switch to Maven NOW
Jorg Heymans wrote: remarks: - Will 2.1.x branch also be moved to m2 or is this for trunk only ? I think 2.1.x will stay as is. If we have switched trunk we can think about porting back to 2.1.x, but I don't think that this makes much sense. - We will need to synchronize all libs and poms currently not present to the maven2 repository (http://www.ibiblio.org/maven2/) Yepp and we can use the Apache repositories therefore as well. I'ld be happy to give you a hand on this one Carsten. Hopefully my account gets activated the next couple of days so I can be of more direct use. Great!! Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [Proposal] Switch to Maven NOW
Jorg Heymans wrote: remarks: - Will 2.1.x branch also be moved to m2 or is this for trunk only ? - We will need to synchronize all libs and poms currently not present to the maven2 repository (http://www.ibiblio.org/maven2/) Or create our own maven2 repo. We often depend on particular snapshot releases so our own repo would simplify thigs (at last start). -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Leszek Gawron wrote:
other example that I posted some time ago: if every cocoon uses
error2html.xsl by default (along with some other default resources)
they should be also packed into jars.
Aha! This is something I wanted to talk about when working on Cocoon
stacktraces: standardizing the fact that some blocks provide resources
and include them in jars.
The first block to do this is CForms, which provides a lot of runtime
resources in org/apache/cocoon/forms/resources: XSLs, js, css, etc. We
also have a few items for the core block in webapp/stylesheets/system
and webapp/resources (js and css). What we see here is that these are
runtime resources targeted both at the server side (XSLs) and the client
side (js, css and also XSLs for xsl-aware browsers).
What I propose is that we define a standard layout for resources
provided by blocks: they should be stored in
resource://org/apache/cocoon/{block-name}/resources/
Additionally, we should have a system-defined URI which allows clients
to fetch these resources, implemented in the root sitemap:
map:match pattern=_cocoon_/*/**
map:read src=resource://org/apache/cocoon/{1}/resources/{2}/
/map:match
By standardizing this URI pattern, we can easily solve cross-referencing
problems among resources, e.g. CForms XSLs having to produce script
src=.../ to load the JS files, etc.
This URI pattern could even be written **_cocoon_/*/** to be
location-independent so that we don't have to mess around with
{request:contextPath}.
WDYT?
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: [Proposal] Switch to Maven NOW
Carsten Ziegeler wrote: Actually I'm a little bit tired of the ongoing Maven discussion. Why can't we just switch the trunk to Maven NOW? +1. Who really cares if trunk is not buildable/working for the next days until the switch is finished? Hmm... it would be good to keep build.xml until the maven switch is up and running. So I propose to: - Completly remove the lib directory ... once the maven build works (see above). - Create a sub project core in the trunk directory I think we will use several (sub) projects, one for the core, one for the webapp etc. and use Mavens multiproject feature. - Move src/java to core/src/java - Create a Maven project description with all dependencies for core By this you mean separating the core classes source code and tests from the other stuff in src/ (webapp, docs, etc)? Then +1. Et voila, we will get a cocoon.jar hopefully. Then we create a webapp subproject, move the webapp there and build a webapp with just the core. Sounds good. And then we continue from there, moving test, moving samples etc. On thing at a time. And we can always ask the maven guys for assistence and hints. Ah, and finally, I think we should start right away with m2. If it's stable enough then +1 for Maven2. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Sylvain Wallez wrote:
Leszek Gawron wrote:
other example that I posted some time ago: if every cocoon uses
error2html.xsl by default (along with some other default resources)
they should be also packed into jars.
Aha! This is something I wanted to talk about when working on Cocoon
stacktraces: standardizing the fact that some blocks provide resources
and include them in jars.
The first block to do this is CForms, which provides a lot of runtime
resources in org/apache/cocoon/forms/resources: XSLs, js, css, etc. We
also have a few items for the core block in webapp/stylesheets/system
and webapp/resources (js and css). What we see here is that these are
runtime resources targeted both at the server side (XSLs) and the client
side (js, css and also XSLs for xsl-aware browsers).
What I propose is that we define a standard layout for resources
provided by blocks: they should be stored in
resource://org/apache/cocoon/{block-name}/resources/
Additionally, we should have a system-defined URI which allows clients
to fetch these resources, implemented in the root sitemap:
map:match pattern=_cocoon_/*/**
map:read src=resource://org/apache/cocoon/{1}/resources/{2}/
/map:match
By standardizing this URI pattern, we can easily solve cross-referencing
problems among resources, e.g. CForms XSLs having to produce script
src=.../ to load the JS files, etc.
This URI pattern could even be written **_cocoon_/*/** to be
location-independent so that we don't have to mess around with
{request:contextPath}.
This is a good idea with one small but: map:match
pattern=_cocoon_/*/** should be the last pipeline definition to make
overriding in subsitemaps as easy as possible.
--
Leszek Gawron [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Sylvain Wallez wrote:
Leszek Gawron wrote:
other example that I posted some time ago: if every cocoon uses
error2html.xsl by default (along with some other default resources)
they should be also packed into jars.
Aha! This is something I wanted to talk about when working on Cocoon
stacktraces: standardizing the fact that some blocks provide resources
and include them in jars.
The first block to do this is CForms, which provides a lot of runtime
resources in org/apache/cocoon/forms/resources: XSLs, js, css, etc. We
also have a few items for the core block in webapp/stylesheets/system
and webapp/resources (js and css). What we see here is that these are
runtime resources targeted both at the server side (XSLs) and the
client side (js, css and also XSLs for xsl-aware browsers).
What I propose is that we define a standard layout for resources
provided by blocks: they should be stored in
resource://org/apache/cocoon/{block-name}/resources/
The nice thing with this propsal is that it is back compatible and
follow current (emerging) conventions. OTH with the blocks architecture,
using the resource protocol is not such a good idea. In OSGi resources
have URLs like bundle://3/org.apache.cocoon.foo e.g. where 3 is the
number of the bundle and is deployment order dependent and is therefore
not usable in sitemaps. In OSGi one typically puts the resources at the
top level of the jar or in directories at top level. There is normally
not that much reason for puting resources in the Java package structure,
as the bundle poften is an apropriate level of granularity anyway.
We also have the block protocol that allows you to define what block the
resource is taken from: block:foo:/bar.xsl. Now the block protocol
assumes that everything is exported through the sitemap wich might be
appropriate (but maybe inconvenient) for the use cases you have in mind.
Maybe we could have an own bundle protocol (through the source
mechanism), that works like the OSGi bundle protocol but have symbolic
block names instead of bundle numbers.
Additionally, we should have a system-defined URI which allows clients
to fetch these resources, implemented in the root sitemap:
map:match pattern=_cocoon_/*/**
map:read src=resource://org/apache/cocoon/{1}/resources/{2}/
/map:match
By standardizing this URI pattern, we can easily solve
cross-referencing problems among resources, e.g. CForms XSLs having to
produce script src=.../ to load the JS files, etc.
This URI pattern could even be written **_cocoon_/*/** to be
location-independent so that we don't have to mess around with
{request:contextPath}.
All this is allready solved within the (sitemap) block architecture and
there is an implementation of it in trunk. block URIs are used for
accessing things and a special URL rewriting transformer absolutizes the
block URLs.
WDYT?
Your proposal makes sense and we should make something about the issues
you describe. What you describe will not be particulary future proof though.
/Daniel
Re: [Proposal] Switch to Maven NOW
Sylvain Wallez schrieb: Hmm... it would be good to keep build.xml until the maven switch is up and running. Ok, we can try it, it should work - if for any reason we can't keep it running, would this be a real problem? I think we can do the switch - at least for the core - very quick (some days or so). So I propose to: - Completly remove the lib directory ... once the maven build works (see above). Ok. By this you mean separating the core classes source code and tests from the other stuff in src/ (webapp, docs, etc)? Then +1. Yepp. If it's stable enough then +1 for Maven2. Yes, it is (according to the Maven guys, I did some tests myself and it worked). Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Leszek Gawron wrote:
Sylvain Wallez wrote:
snip/
Additionally, we should have a system-defined URI which allows
clients to fetch these resources, implemented in the root sitemap:
map:match pattern=_cocoon_/*/**
map:read src=resource://org/apache/cocoon/{1}/resources/{2}/
/map:match
By standardizing this URI pattern, we can easily solve
cross-referencing problems among resources, e.g. CForms XSLs having
to produce script src=.../ to load the JS files, etc.
This URI pattern could even be written **_cocoon_/*/** to be
location-independent so that we don't have to mess around with
{request:contextPath}.
This is a good idea with one small but: map:match
pattern=_cocoon_/*/** should be the last pipeline definition to
make overriding in subsitemaps as easy as possible.
Yep. In which case **_cocoon_/*/** (location-independent) may be better
to allow local overrides in some subsitemaps or sub-applications. The
standard implementation of this URI could also be written:
map:match pattern=**_cocoon_/*/**
map:act type=resource-exists src=context://resources/{2}/{3}
!-- resource overriden by the application --
map:read src=context://resources/{2}/{3}/
/map:act
map:read src=resource://org/apache/cocoon/{2}/resources/{3}/
/map:match
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Sylvain Wallez wrote:
Leszek Gawron wrote:
Sylvain Wallez wrote:
snip/
Additionally, we should have a system-defined URI which allows
clients to fetch these resources, implemented in the root sitemap:
map:match pattern=_cocoon_/*/**
map:read src=resource://org/apache/cocoon/{1}/resources/{2}/
/map:match
By standardizing this URI pattern, we can easily solve
cross-referencing problems among resources, e.g. CForms XSLs having
to produce script src=.../ to load the JS files, etc.
This URI pattern could even be written **_cocoon_/*/** to be
location-independent so that we don't have to mess around with
{request:contextPath}.
This is a good idea with one small but: map:match
pattern=_cocoon_/*/** should be the last pipeline definition to
make overriding in subsitemaps as easy as possible.
Yep. In which case **_cocoon_/*/** (location-independent) may be better
to allow local overrides in some subsitemaps or sub-applications. The
standard implementation of this URI could also be written:
map:match pattern=**_cocoon_/*/**
map:act type=resource-exists src=context://resources/{2}/{3}
!-- resource overriden by the application --
map:read src=context://resources/{2}/{3}/
/map:act
map:read src=resource://org/apache/cocoon/{2}/resources/{3}/
/map:match
This is not block friendly IMO. Imagine you have 2 cforms applications
in one cocoon every one having different forms.css
it is easier then to implement own overrides and fallback to default
ones for ones developer does not care:
subsitemap:
map:match pattern=cforms/css/**
map:read src=cocoon:/skin-resource/styles/{1}/
/map:match
parent sitemap:
map:match pattern=cforms/**
map:read src=resource://org/apache/cocoon/forms/resources/{1}/
/map:match
--
Leszek Gawron [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Leszek Gawron wrote:
other example that I posted some time ago: if every cocoon uses
error2html.xsl by default (along with some other default resources)
they should be also packed into jars.
Aha! This is something I wanted to talk about when working on Cocoon
stacktraces: standardizing the fact that some blocks provide resources
and include them in jars.
The first block to do this is CForms, which provides a lot of runtime
resources in org/apache/cocoon/forms/resources: XSLs, js, css, etc. We
also have a few items for the core block in webapp/stylesheets/system
and webapp/resources (js and css). What we see here is that these are
runtime resources targeted both at the server side (XSLs) and the
client side (js, css and also XSLs for xsl-aware browsers).
What I propose is that we define a standard layout for resources
provided by blocks: they should be stored in
resource://org/apache/cocoon/{block-name}/resources/
The nice thing with this propsal is that it is back compatible and
follow current (emerging) conventions. OTH with the blocks architecture,
using the resource protocol is not such a good idea. In OSGi resources
have URLs like bundle://3/org.apache.cocoon.foo e.g. where 3 is the
number of the bundle and is deployment order dependent and is therefore
not usable in sitemaps. In OSGi one typically puts the resources at the
top level of the jar or in directories at top level. There is normally
not that much reason for puting resources in the Java package structure,
as the bundle poften is an apropriate level of granularity anyway.
Look at cforms resources. flattening this structure will give you
maintenance headache.
Your proposal makes sense and we should make something about the issues
you describe. What you describe will not be particulary future proof
though.
It will help at least for now and is applicable also for 2.1.x.
--
Leszek Gawron [EMAIL PROTECTED]
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Leszek Gawron wrote:
other example that I posted some time ago: if every cocoon uses
error2html.xsl by default (along with some other default resources)
they should be also packed into jars.
Aha! This is something I wanted to talk about when working on Cocoon
stacktraces: standardizing the fact that some blocks provide
resources and include them in jars.
The first block to do this is CForms, which provides a lot of runtime
resources in org/apache/cocoon/forms/resources: XSLs, js, css, etc.
We also have a few items for the core block in
webapp/stylesheets/system and webapp/resources (js and css). What we
see here is that these are runtime resources targeted both at the
server side (XSLs) and the client side (js, css and also XSLs for
xsl-aware browsers).
What I propose is that we define a standard layout for resources
provided by blocks: they should be stored in
resource://org/apache/cocoon/{block-name}/resources/
The nice thing with this propsal is that it is back compatible and
follow current (emerging) conventions. OTH with the blocks
architecture, using the resource protocol is not such a good idea. In
OSGi resources have URLs like bundle://3/org.apache.cocoon.foo e.g.
where 3 is the number of the bundle and is deployment order
dependent and is therefore not usable in sitemaps. In OSGi one
typically puts the resources at the top level of the jar or in
directories at top level. There is normally not that much reason for
puting resources in the Java package structure, as the bundle poften
is an apropriate level of granularity anyway.
Hmm... as I understand it, the bundle: protocol is similar to what is
returned by ClassLoader.getResource(), and is abstracted by the
resource: protocol implementation (it can actually be a jar: or a file:
or something else that we never see).
And BTW, unless I missed something I haven't seen an explicit reference
to the bundle: protocol in the OSGi specs, at least in R3.
We also have the block protocol that allows you to define what block
the resource is taken from: block:foo:/bar.xsl. Now the block protocol
assumes that everything is exported through the sitemap wich might be
appropriate (but maybe inconvenient) for the use cases you have in
mind. Maybe we could have an own bundle protocol (through the source
mechanism), that works like the OSGi bundle protocol but have symbolic
block names instead of bundle numbers.
Something like block-resource://org.apache.cocoon.forms/... ?
This can be implemented today in 2.1.x by having this protocol
delegating to resource:
Additionally, we should have a system-defined URI which allows
clients to fetch these resources, implemented in the root sitemap:
map:match pattern=_cocoon_/*/**
map:read src=resource://org/apache/cocoon/{1}/resources/{2}/
/map:match
By standardizing this URI pattern, we can easily solve
cross-referencing problems among resources, e.g. CForms XSLs having
to produce script src=.../ to load the JS files, etc.
This URI pattern could even be written **_cocoon_/*/** to be
location-independent so that we don't have to mess around with
{request:contextPath}.
All this is allready solved within the (sitemap) block architecture
and there is an implementation of it in trunk. block URIs are used for
accessing things and a special URL rewriting transformer absolutizes
the block URLs.
I'm proposing here a public URL pattern that can be accessed by
browsers. Block URIs are an internal thing and this pattern must be
implemented somewhere, no?
WDYT?
Your proposal makes sense and we should make something about the
issues you describe. What you describe will not be particulary future
proof though.
So how do we make it future proof yet possible in 2.1.x? Can we have a
single naming scheme (with a new protocol) implemented differently or
pointing to different locations (the 'resources' dir can be located at
the top-level of a bundle)?
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: [Proposal] Switch to Maven NOW
Wow. It is always a surprise when I wake up in the morning! I'm +5 to this. Carsten Ziegeler wrote: Actually I'm a little bit tired of the ongoing Maven discussion. Why can't we just switch the trunk to Maven NOW? Who really cares if trunk is not buildable/working for the next days until the switch is finished? So I propose to: - Completly remove the lib directory - Create a sub project core in the trunk directory I think we will use several (sub) projects, one for the core, one for the webapp etc. and use Mavens multiproject feature. - Move src/java to core/src/java - Create a Maven project description with all dependencies for core Et voila, we will get a cocoon.jar hopefully. Then we create a webapp subproject, move the webapp there and build a webapp with just the core. And then we continue from there, moving test, moving samples etc. On thing at a time. And we can always ask the maven guys for assistence and hints. Ah, and finally, I think we should start right away with m2. Carsten
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Leszek Gawron wrote:
snip/
This is not block friendly IMO. Imagine you have 2 cforms
applications in one cocoon every one having different forms.css
it is easier then to implement own overrides and fallback to default
ones for ones developer does not care:
subsitemap:
map:match pattern=cforms/css/**
map:read src=cocoon:/skin-resource/styles/{1}/
/map:match
parent sitemap:
map:match pattern=cforms/**
map:read src=resource://org/apache/cocoon/forms/resources/{1}/
/map:match
My example shows how to allow a simple override in a one-application
cocoon, and is meant as a cut/paste example in the root sitemap. Now you
can override it as you want using your favorite patterns and protocols ;-)
Sylvain
--
Sylvain WallezAnyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research Technology Director
Re: [Proposal] Switch to Maven NOW
Jorg Heymans wrote: remarks: - Will 2.1.x branch also be moved to m2 or is this for trunk only ? I would wait and see what it takes to convert trunk. As much as I would like to switch I would wait and see what the impact will be. However, it might be much easier to convert 2.1.x once plugins, etc. are created for trunk.
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Leszek Gawron wrote: Daniel Fagerstrom wrote: snip/ The nice thing with this propsal is that it is back compatible and follow current (emerging) conventions. OTH with the blocks architecture, using the resource protocol is not such a good idea. In OSGi resources have URLs like bundle://3/org.apache.cocoon.foo e.g. where 3 is the number of the bundle and is deployment order dependent and is therefore not usable in sitemaps. In OSGi one typically puts the resources at the top level of the jar or in directories at top level. There is normally not that much reason for puting resources in the Java package structure, as the bundle poften is an apropriate level of granularity anyway. Look at cforms resources. flattening this structure will give you maintenance headache. I'm not talking about flattening the structure just about not having the prefix org/apache/cocoon/cforms as this allready is taken care about by the symbolic block name. Your proposal makes sense and we should make something about the issues you describe. What you describe will not be particulary future proof though. It will help at least for now and is applicable also for 2.1.x. Sure it will, but if we want to introduce a new standard way of doing things it would be better if we find something that will work well with blocks. /Daniel
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Leszek Gawron wrote:
other example that I posted some time ago: if every cocoon uses
error2html.xsl by default (along with some other default resources)
they should be also packed into jars.
Aha! This is something I wanted to talk about when working on Cocoon
stacktraces: standardizing the fact that some blocks provide
resources and include them in jars.
The first block to do this is CForms, which provides a lot of
runtime resources in org/apache/cocoon/forms/resources: XSLs, js,
css, etc. We also have a few items for the core block in
webapp/stylesheets/system and webapp/resources (js and css). What we
see here is that these are runtime resources targeted both at the
server side (XSLs) and the client side (js, css and also XSLs for
xsl-aware browsers).
What I propose is that we define a standard layout for resources
provided by blocks: they should be stored in
resource://org/apache/cocoon/{block-name}/resources/
The nice thing with this propsal is that it is back compatible and
follow current (emerging) conventions. OTH with the blocks
architecture, using the resource protocol is not such a good idea. In
OSGi resources have URLs like bundle://3/org.apache.cocoon.foo e.g.
where 3 is the number of the bundle and is deployment order
dependent and is therefore not usable in sitemaps. In OSGi one
typically puts the resources at the top level of the jar or in
directories at top level. There is normally not that much reason for
puting resources in the Java package structure, as the bundle poften
is an apropriate level of granularity anyway.
Hmm... as I understand it, the bundle: protocol is similar to what is
returned by ClassLoader.getResource(),
It will be returned by getResource() in Knopflerfish.
and is abstracted by the resource: protocol implementation (it can
actually be a jar: or a file: or something else that we never see).
Yes.
And BTW, unless I missed something I haven't seen an explicit
reference to the bundle: protocol in the OSGi specs, at least in R3.
Didn't found it either, maybe it is Knopflerfish specific. But even if
it is, the OSGi api have no direct ways for accessing a resource from
any bundle, you must specify from what bundle you want to read a
resource. Maybe there is a way to do it in some more indirect way.
We also have the block protocol that allows you to define what block
the resource is taken from: block:foo:/bar.xsl. Now the block
protocol assumes that everything is exported through the sitemap wich
might be appropriate (but maybe inconvenient) for the use cases you
have in mind. Maybe we could have an own bundle protocol (through the
source mechanism), that works like the OSGi bundle protocol but have
symbolic block names instead of bundle numbers.
Something like block-resource://org.apache.cocoon.forms/... ?
This can be implemented today in 2.1.x by having this protocol
delegating to resource:
That would be one possibility, question is if we want direct access to
blocks. Part of the idea with blocks is to have symbiolic names for the
blocks so that one can chnage implementation. OTH a package name could
be seen as a symbolic name as well, so it might be good enough.
Additionally, we should have a system-defined URI which allows
clients to fetch these resources, implemented in the root sitemap:
map:match pattern=_cocoon_/*/**
map:read src=resource://org/apache/cocoon/{1}/resources/{2}/
/map:match
By standardizing this URI pattern, we can easily solve
cross-referencing problems among resources, e.g. CForms XSLs having
to produce script src=.../ to load the JS files, etc.
This URI pattern could even be written **_cocoon_/*/** to be
location-independent so that we don't have to mess around with
{request:contextPath}.
All this is allready solved within the (sitemap) block architecture
and there is an implementation of it in trunk. block URIs are used
for accessing things and a special URL rewriting transformer
absolutizes the block URLs.
I'm proposing here a public URL pattern that can be accessed by
browsers. Block URIs are an internal thing and this pattern must be
implemented somewhere, no?
The idea for blocks is that blocks that contain public URLs are mounted
at deploy time at a some root URL, then the URL revriting transformer
translates internal use of symbolic block names to the public exported ones.
WDYT?
Your proposal makes sense and we should make something about the
issues you describe. What you describe will not be particulary future
proof though.
So how do we make it future proof yet possible in 2.1.x? Can we have a
single naming scheme (with a new protocol) implemented differently or
pointing to different locations (the 'resources' dir can be located at
the top-level of a bundle)?
Something like the block-resource: protocol could work. As said above
the question is if we want direct
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
On Wednesday 17 August 2005 22:09, Daniel Fagerstrom wrote: And BTW, unless I missed something I haven't seen an explicit reference to the bundle: protocol in the OSGi specs, at least in R3. Didn't found it either, maybe it is Knopflerfish specific. But even if it is, the OSGi api have no direct ways for accessing a resource from any bundle, you must specify from what bundle you want to read a resource. Maybe there is a way to do it in some more indirect way. It is probably a protocol available to be 'installed' at your own leisure (i.e. the core beauty of OSGi). I have not bothered with it. Since a protocol is a Service, I assume that the ServiceFactory mechanism would also work, in which case a protocol could extract context information from the requesting bundle and use that to tailor the resulting connection, including retrieving resources from with that client bundle. I have not tested this for URLs but using something along those line in a Log4J bundle, where the default config for a bundle is retrieved from the requesting bundle. I think quite a fair bit in Cocoon should use URLs and custom protocols, and implement those through the OSGi URL service mechanism. Cheers Niclas
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Daniel Fagerstrom wrote: Sylvain Wallez wrote: Hmm... as I understand it, the bundle: protocol is similar to what is returned by ClassLoader.getResource(), It will be returned by getResource() in Knopflerfish. What getResource()? There are plenty of them ;-) I guess it's Bundle.getResource() and is abstracted by the resource: protocol implementation (it can actually be a jar: or a file: or something else that we never see). Yes. And BTW, unless I missed something I haven't seen an explicit reference to the bundle: protocol in the OSGi specs, at least in R3. Didn't found it either, maybe it is Knopflerfish specific. But even if it is, the OSGi api have no direct ways for accessing a resource from any bundle, you must specify from what bundle you want to read a resource. Maybe there is a way to do it in some more indirect way. Yes, they do have access to resources in a bundle *if* these resources are packaged in the bundle's classpath and declared in the exported packages. Loading resources in jars follows the exact same path as loading classes (that what I understood from the spec and verified in the Oscar/Felix implementation). So the resource: protocol will behave with OSGi just as it behaves otherwise, with the restriction that the search path is restricted to the bundle's dependencies. We also have the block protocol that allows you to define what block the resource is taken from: block:foo:/bar.xsl. Now the block protocol assumes that everything is exported through the sitemap wich might be appropriate (but maybe inconvenient) for the use cases you have in mind. Maybe we could have an own bundle protocol (through the source mechanism), that works like the OSGi bundle protocol but have symbolic block names instead of bundle numbers. Something like block-resource://org.apache.cocoon.forms/... ? This can be implemented today in 2.1.x by having this protocol delegating to resource: That would be one possibility, question is if we want direct access to blocks. Part of the idea with blocks is to have symbiolic names for the blocks so that one can chnage implementation. OTH a package name could be seen as a symbolic name as well, so it might be good enough. Right. In this case, I consider these resources as well-known things and placing them in jars is a way to allow them to have well-known names and avoid to copy them around each time we start a project. In this regard, the resource name is similar to a class name: classes don't move around ;-) So this is really about accessing a resource more than a service, which is what block bring us. Sure, the distinction is somewhat subtle. We may want in the future to implement access to these resources as block services, the Forms block implementing this service as an access to the resource. In the meantime, we can consider the access through resource: as an transition step between copy/paste in each application and block-powered services. snip/ All this is allready solved within the (sitemap) block architecture and there is an implementation of it in trunk. block URIs are used for accessing things and a special URL rewriting transformer absolutizes the block URLs. I'm proposing here a public URL pattern that can be accessed by browsers. Block URIs are an internal thing and this pattern must be implemented somewhere, no? The idea for blocks is that blocks that contain public URLs are mounted at deploy time at a some root URL, then the URL revriting transformer translates internal use of symbolic block names to the public exported ones. Ah yes. So for now in 2.1.x, that rewriting stuff would be the little sitemap snippet I proposed. snip/ So how do we make it future proof yet possible in 2.1.x? Can we have a single naming scheme (with a new protocol) implemented differently or pointing to different locations (the 'resources' dir can be located at the top-level of a bundle)? Something like the block-resource: protocol could work. As said above the question is if we want direct block references, the block architecture only allow direct block refernces in the deploy descriptor and use symbolic names everywhere else. For where to put the resouces, we could put them in a resources directory at top level and then let the build process put it at the place appropriate for 2.1.x and OSGi based blocks repsectively. Another question is of course if we really should back port everything to 2.1.x. For now I'm concentrating on a 2.1.x issue, which of course should work on 2.2 even if 2.2 provides more advanced and powerful features. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Sylvain Wallez wrote: Daniel Fagerstrom wrote: Sylvain Wallez wrote: snip/ So the resource: protocol will behave with OSGi just as it behaves otherwise, with the restriction that the search path is restricted to the bundle's dependencies. Totally makes sense (*). Maybe we could have an own bundle protocol (through the source mechanism), that works like the OSGi bundle protocol but have symbolic block names instead of bundle numbers. Something like block-resource://org.apache.cocoon.forms/... ? First problem: block name is missing. You probably meant: block:myforms:resource://org.apache.cocoon.forms/ (resolve resource: in the context of the block). But... This can be implemented today in 2.1.x by having this protocol delegating to resource: That would be one possibility, question is if we want direct access to blocks. Probably not. Above can be achieved using regualar block protocol, and an entry in the block's sitemap to export resources: block:myforms:resources/css/forms.css Whereas myforms' sitemap will have match for resources/**/*.css But... snip/ In the meantime, we can consider the access through resource: as an transition step between copy/paste in each application and block-powered services. Given the fact that resource: protocol still works as expected with 'real blocks' (See (*) above), conclusion is that simple sitemap snippet: map:read src=resource://org/apache/cocoon/forms/resources/css/forms.css/ is enough, and no 'fancy' block protocol is necessary. snip/ The idea for blocks is that blocks that contain public URLs are mounted at deploy time at a some root URL, then the URL revriting transformer translates internal use of symbolic block names to the public exported ones. Why would anyone internally use any block: URIs? This should be totally unnecessary: you can either use relative URIs, or construct absolute by passing sitemap prefix into the xslt - same as we do in existing samples. Vadim
Re: [Proposal] Switch to Maven NOW
Carsten Ziegeler wrote: Actually I'm a little bit tired of the ongoing Maven discussion. Why can't we just switch the trunk to Maven NOW? Who really cares if trunk is not buildable/working for the next days until the switch is finished? So I propose to: - Completly remove the lib directory - Create a sub project core in the trunk directory I think we will use several (sub) projects, one for the core, one for the webapp etc. and use Mavens multiproject feature. - Move src/java to core/src/java - Create a Maven project description with all dependencies for core Et voila, we will get a cocoon.jar hopefully. Then we create a webapp subproject, move the webapp there and build a webapp with just the core. And then we continue from there, moving test, moving samples etc. On thing at a time. And we can always ask the maven guys for assistence and hints. Ah, and finally, I think we should start right away with m2. Go for it. -- Stefano.
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Niclas Hedhman wrote: On Wednesday 17 August 2005 22:09, Daniel Fagerstrom wrote: And BTW, unless I missed something I haven't seen an explicit reference to the bundle: protocol in the OSGi specs, at least in R3. Didn't found it either, maybe it is Knopflerfish specific. But even if it is, the OSGi api have no direct ways for accessing a resource from any bundle, you must specify from what bundle you want to read a resource. Maybe there is a way to do it in some more indirect way. It is probably a protocol available to be 'installed' at your own leisure (i.e. the core beauty of OSGi). I have not bothered with it. Don't know, but I would assume that all OSGi implementation would need something like the bundle: protocol (although the name and syntax might not be standardized). Say that you have two bundles A and B that both contain the resource foo.xml. If you use URL getResource(String) at the Bundle object of the A bundle the resulting URL must contain a reference to the A bundle to not confuse it with foo.xml from the B bundle. Since a protocol is a Service, I assume that the ServiceFactory mechanism would also work, in which case a protocol could extract context information from the requesting bundle and use that to tailor the resulting connection, including retrieving resources from with that client bundle. I have not tested this for URLs but using something along those line in a Log4J bundle, where the default config for a bundle is retrieved from the requesting bundle. Ok. I think quite a fair bit in Cocoon should use URLs and custom protocols, and implement those through the OSGi URL service mechanism. Yes, that would remove the need to depend on the Source interface in blocks and make it possible to use external libraries that requires java.net.URL. /Daniel
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Vadim Gritsenko wrote: Sylvain Wallez wrote: Daniel Fagerstrom wrote: Sylvain Wallez wrote: snip/ So the resource: protocol will behave with OSGi just as it behaves otherwise, with the restriction that the search path is restricted to the bundle's dependencies. Totally makes sense (*). Yes, gave some more details about in my answer to Sylvain. Maybe we could have an own bundle protocol (through the source mechanism), that works like the OSGi bundle protocol but have symbolic block names instead of bundle numbers. Something like block-resource://org.apache.cocoon.forms/... ? First problem: block name is missing. You probably meant: block:myforms:resource://org.apache.cocoon.forms/ No, it was a try to find something that could work in both 2.2 and 2.1.x without needing to back port to much of the blocks architecture from 2.2. But it probably becomes complicated without giving that much so we should use the resource: solution instead. (resolve resource: in the context of the block). But... This can be implemented today in 2.1.x by having this protocol delegating to resource: That would be one possibility, question is if we want direct access to blocks. Probably not. Above can be achieved using regualar block protocol, and an entry in the block's sitemap to export resources: block:myforms:resources/css/forms.css Whereas myforms' sitemap will have match for resources/**/*.css But... snip/ In the meantime, we can consider the access through resource: as an transition step between copy/paste in each application and block-powered services. Given the fact that resource: protocol still works as expected with 'real blocks' (See (*) above), conclusion is that simple sitemap snippet: map:read src=resource://org/apache/cocoon/forms/resources/css/forms.css/ is enough, and no 'fancy' block protocol is necessary. Exactly. snip/ The idea for blocks is that blocks that contain public URLs are mounted at deploy time at a some root URL, then the URL revriting transformer translates internal use of symbolic block names to the public exported ones. Why would anyone internally use any block: URIs? This should be totally unnecessary: you can either use relative URIs, You need to use block:foo: URIs to access resources in other blocks, block: URIs to use URIs that you want polymorphic behaviour on, and block:super: for geting an URI from the block that you extend. See http://marc.theaimsgroup.com/?l=xml-cocoon-devm=111791016006393w=2 for more details. or construct absolute by passing sitemap prefix into the xslt - same as we do in existing samples. Using the LinkRewritingTransformer together with the block-path module will be so much more convenient (see the cited mail above). /Daniel
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Niclas Hedhman wrote: On Thursday 18 August 2005 03:36, Daniel Fagerstrom wrote: Don't know, but I would assume that all OSGi implementation would need something like the bundle: protocol (although the name and syntax might not be standardized). Say that you have two bundles A and B that both contain the resource foo.xml. If you use URL getResource(String) at the Bundle object of the A bundle the resulting URL must contain a reference to the A bundle to not confuse it with foo.xml from the B bundle. Are we talking; bundle://4/foo.xml ? Then my implementation is; URL resource = anyBundleContext.getBundle( 4 ).getResource( foo.xml ); Sure. Is there more to it?? That an OSGi framework need to have a protocol like the bundle protocol as part of its implementation to be able to implement Bundle.getResource as motivated in my example above. Meaning it is dirt simple to make the bundle protocol (as described here (I have not seen it in action anywhere)) as a protocol according to the spec, and does not need any support from the OSGi implementation itself. Not to implement it but as motivated above it must AFAICS allready be part of the implementation. One can also support fancy search algorithms for the Bundle... I'm not certain about what you refer to but in R3 you can just access resources that you allready have the path for not list the content of a resource directory or something like that. In R4 you can though. That is one of the reasons that we need R4 for Cocoon, the others are better version handling and ASF compliant license. /Daniel
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Daniel Fagerstrom wrote: Niclas Hedhman wrote: On Wednesday 17 August 2005 22:09, Daniel Fagerstrom wrote: And BTW, unless I missed something I haven't seen an explicit reference to the bundle: protocol in the OSGi specs, at least in R3. Didn't found it either, maybe it is Knopflerfish specific. But even if it is, the OSGi api have no direct ways for accessing a resource from any bundle, you must specify from what bundle you want to read a resource. Maybe there is a way to do it in some more indirect way. It is probably a protocol available to be 'installed' at your own leisure (i.e. the core beauty of OSGi). I have not bothered with it. Don't know, but I would assume that all OSGi implementation would need something like the bundle: protocol (although the name and syntax might not be standardized). Say that you have two bundles A and B that both contain the resource foo.xml. If you use URL getResource(String) at the Bundle object of the A bundle the resulting URL must contain a reference to the A bundle to not confuse it with foo.xml from the B bundle. Sure, but that's for the Bundle.getResource() method. What we're talking about here is ClassLoader.getResource() which follows a different resolution scheme and returns an URL that is resolved through the bundle's classpath and points to the actual resource in a jar file or class directory in the target bundle, e.g. jar://file://path/to/bundle-repo/foo-bundle/lib.jar!/path/to/resource. I think quite a fair bit in Cocoon should use URLs and custom protocols, and implement those through the OSGi URL service mechanism. Yes, that would remove the need to depend on the Source interface in blocks and make it possible to use external libraries that requires java.net.URL. Yup. Being able to use the standard java.net.URL class instead of the SourceResolver will be a very nice thing. The only problem is the infiamous SourceResolver.resolve() that has no equivalent on URLConnection and which is needed for only one protocol, but an important one which is cocoon:... Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
On Thursday 18 August 2005 05:08, Daniel Fagerstrom wrote: Is there more to it?? That an OSGi framework need to have a protocol like the bundle protocol as part of its implementation to be able to implement Bundle.getResource as motivated in my example above. I guess it is not important, but I am not sure I follow what you mean. If you use URL getResource(String) at the Bundle object of the A bundle the resulting URL must contain a reference to the A bundle to not confuse it with foo.xml from the B bundle. Why can't it return jar:file:///home/niclas/.oscar/cocoon/bundle4/version0.0/bundle.jar!/foo.xml ?? AFAICT, the specification (R3) does not require the returned URL to be globally resolvable, and bundle://4/foo.xml is also only resolvable in the current OSGi instance, not even the within the same JVM. Have I understood you right? Cheers Niclas
