[VOTE] Introduce component/module specific version fields in JIRA
Hello, This is a second attempt to resolve problem with inaccurate version information in JIRA which I described here[1]. The first one was to split up our COCOON project into several smaller ones[2]. Unfortunately, this option had several drawbacks like broken links to the current issues. Unexpectedly, Nils Kaiser has come up with much better and, in general, less intrusive solution. He proposed[3] to introduce custom fields where information about version specific to the *component* would be stored. Thereby, I would like to propose adding two new custom fields in our COCOON project on JIRA: * Affects version (Component) - counterpart of standard Affects version field in JIRA but limited to component the issue is assigned. * Fix version (Component) - counterpart of standard Fix version field in JIRA but limited to component the issue is assigned. It's worth to say that, AFAIK, options in fields cannot be filtered basing on component choice so they will contain all versions of all components. Unfortunately, JIRA is very limited when it comes to handling of multi-module projects where modules are released independently. Please cast your votes! [1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74876 [2] http://article.gmane.org/gmane.text.xml.cocoon.devel/74591 [3] http://article.gmane.org/gmane.text.xml.cocoon.devel/74887 -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/ *** My Internet Service Provider breaks my internet connection *** *** incessantly so I'll not be able to respond to e-mails *** *** regularly and my work will be somehow irregular. *** *** I'm already trying to switch ISP but it will take handful amount of time. ***
Re: svn commit: r569656 - /cocoon/whiteboard/osgi/README.txt
Hi Daniel, [EMAIL PROTECTED] pisze: Author: danielf Date: Sat Aug 25 03:37:44 2007 New Revision: 569656 URL: http://svn.apache.org/viewvc?rev=569656view=rev Log: Actually all samples work. Modified: cocoon/whiteboard/osgi/README.txt I see that you are playing with OSGi in whiteboard and according to svn log messages there is something to try already. However, I lack any experience and knowledge of OSGi and I don't know how Cocoon OSGi integration is supposed to work. Could you give some links to introduction articles and tutorials that is the most relevant to your current effort? Giving some links to the discussion about *current* OSGi integration effort would be helpful. I'm asking for this because I just want only to get familiar with OSGi parts needed in Cocoon. -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
FYI: Expression language Daisy site created
Hi, I wanted let you know that I have created Daisy site for cocoon-expression-language module. It was very easy because everything is explained here: http://cocoon.zones.apache.org/daisy/cdocs/g3/1223.html I must visit our Daisy more often; our documentation system is no less fun than coding. :-) -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
OSGi integration (again)
As some of you might have seen in the SVN logs, I have started to work on making Cocoon work under OSGi again [1]. This will, for the moment, not affect the trunk more than that I might refactor or reorganize some stuff based on needs for the OSGi integration. The main reasons for working on OSGi integration is that OSGi makes it possible to push the modularization of Cocoon a bit further. * Blocks can be dynamically installed, started, stopped and updated while the rest of the webapp continue to run. Take a look at Peter Kriens demo from last year to see how cool this is [2]. * Each block (bundle) has its own classloader and import and export Java packages from other bundles based on OSGi specific info in the metainf.mf. In this way the classloader hell is handled. Several versions of the same jar can be used in the same application. * Each block has its own Spring context and publish and use services (beans) from other blocks based on a special Spring-OSGi configuration [3]. For background on OSGi [4], [5] and [6] might be good. And the specification [7] is fairly readable for being a specification. The work on getting there mainly conisists of: bundelizing the Cocoon jars and all needed jars, make beans OSGi services and creating infrastucture for building, configuring and running Cocoon in OSGi. Bundelizing === To make a jar working in OSGi it must be converted to a bundle. Which means that its Manifest.mf must be extended with some OSGi specific, info about what packages it exports and imports and some other things. Felix contains an excelent Maven plugin that makes this work rather easy [8]. Also the Felix, Spring-OSGi, Eclipse Equinox and OPS4J has already bundelized many popular Java libraries. Services The Spring-OSGi project [9] creates OSGi-Spring integration. There is a custom name space with constructions for publishing beans as OSGi services and for using OSGi services as Spring bean references. The idea is that each bundle (block) has its own Sprin application context, and that it can publish beans and use beans from other bundles through OSGi:s service architecture. There is a Spring OSGi extender bundle that automatically detects bundles with a Spring configurations in the META-INF/spring directory and takes care about its services. Infrastructure == Although the Cocoon OSGi integration should work in any OSGi implementation I use Felix during development. I have set up a Maven assembly that creates a directory structure with all needed jars and configuration files. So that one just can start the Felix OSGi framework with parts of Cocoon inside (see the README [10]). For logging I use OPS4J Pax Logging [11], which makes all major logging frameworks available in an OSGi friendly way. I use an HTTP service from Eclipse Equinox as the Felix one doesn't support Servlet 2.4 only 2.3. An activator [14], [15] has the same role as the DispatcherServlet in the ordinary context. But it is dynamic so it will detect and use servlet services that comes and goes. The servlet protocol is available as a real Java protocol and is available with java.net.URL, using the OSGi URL service. Status == This far some basic examples that use the servlet service fw works. See the README [10] for how to build and test the stuff. I'll continue with bundelizing the Cocoon core. There are a number of open problems: * How to handle configuration * Spring-OSGi doesn't support prototype scope that well * How handle the massive import of services that is needed for a sitemap? We had some partial answers to the above question last time we worked on Cocoon OSGi integration. Hopefully they can be adapted to the Spring OSGi context. An overview of earlier work can be found in [12] and in my presentation [13]. /Daniel [1] http://svn.apache.org/repos/asf/cocoon/whiteboard/osgi/ [2] http://www.aqute.biz/Blog/20070703 [3] http://www.springframework.org/osgi/specification [4] http://www.aqute.biz/OSGi/Tutorial [5] http://felix.apache.org/site/presentations.data/osgi-berlin-20070321.pdf [6] http://www.osgi.org/osgi_technology/index.asp?section=2 [7] http://www2.osgi.org/Download/Release4V401 [8] http://felix.apache.org/site/maven-bundle-plugin-bnd.html [9] http://www.springframework.org/osgi/ [10] http://svn.apache.org/repos/asf/cocoon/whiteboard/osgi/README.txt [11] http://wiki.ops4j.org/confluence/display/ops4j/Pax+Logging [12] http://marc.info/?l=xml-cocoon-devm=114237414521595w=2 [13] http://www.cocoongt.org/archive/2005/Slides-and-recordings.html [14] http://svn.apache.org/repos/asf/cocoon/whiteboard/osgi/core/cocoon-servlet-service/cocoon-servlet-service-impl-osgi/src/main/java/org/apache/cocoon/servletservice/osgi/Activator.java [15] http://svn.apache.org/repos/asf/cocoon/whiteboard/osgi/core/cocoon-servlet-service/cocoon-servlet-service-impl-osgi/src/main/resources/META-INF/spring/servlet-listener.xml
Re: svn commit: r569656 - /cocoon/whiteboard/osgi/README.txt
Grzegorz Kossakowski skrev: Hi Daniel, [EMAIL PROTECTED] pisze: Author: danielf Date: Sat Aug 25 03:37:44 2007 New Revision: 569656 URL: http://svn.apache.org/viewvc?rev=569656view=rev Log: Actually all samples work. Modified: cocoon/whiteboard/osgi/README.txt I see that you are playing with OSGi in whiteboard and according to svn log messages there is something to try already. However, I lack any experience and knowledge of OSGi and I don't know how Cocoon OSGi integration is supposed to work. Try to follow the README and report back if it works (or not). Could you give some links to introduction articles and tutorials that is the most relevant to your current effort? Giving some links to the discussion about *current* OSGi integration effort would be helpful. I'm asking for this because I just want only to get familiar with OSGi parts needed in Cocoon. There are no links about the current effort, but I just wrote a mail about it. /Daniel
Re: [VOTE] Introduce component/module specific version fields in JIRA
Grzegorz Kossakowski wrote: Hello, This is a second attempt to resolve problem with inaccurate version information in JIRA which I described here[1]. The first one was to split up our COCOON project into several smaller ones[2]. Unfortunately, this option had several drawbacks like broken links to the current issues. Unexpectedly, Nils Kaiser has come up with much better and, in general, less intrusive solution. He proposed[3] to introduce custom fields where information about version specific to the *component* would be stored. Thereby, I would like to propose adding two new custom fields in our COCOON project on JIRA: * Affects version (Component) - counterpart of standard Affects version field in JIRA but limited to component the issue is assigned. * Fix version (Component) - counterpart of standard Fix version field in JIRA but limited to component the issue is assigned. It's worth to say that, AFAIK, options in fields cannot be filtered basing on component choice so they will contain all versions of all components. Unfortunately, JIRA is very limited when it comes to handling of multi-module projects where modules are released independently. Please cast your votes! +1 Ralph
Re: cocoon-template incompatible change
Grzegorz Kossakowski wrote:
this one is quite obvious:
markLocalContext() should be executed only if a context object is
explicitly set with jx:import uri=sth context=${contextObject}/
(or should not?)
You are right, the problem is with local contexts. I remember that I didn't
understand what the
context attribute is for. Could you explain what is expected behaviour of
context presence and lack
of it?
to tell you the truth I have never used jx:import with context set, has
anymone?
I thought that context attribute affects imported template (replaces it's
context bean). On the
other hand, current handling of local contexts makes use of jx:set instruction
limited because there
is no option to set value globally.
It works exactly as you've described. But when you import a template
without context object the current one should be used.
Actually, I was going to revise concept of local contexts and its use in
template but forgot about
it in the end. Thanks to your discovery I guess it makes sense to think about
it a little more.
Before we fix anything I would like to see contracts of jx:set instruction
clearly stated. I think
we should answer two questions:
1. What's the scope of variable introduced by jx:set?
you are probably asking the wrong question. jx:set always puts a
variable in current context. The question should be: which
elements/instructions should trigger a new local context.
I think new local context should never be introduced for plain xml
elements (either local or imported, namespaced or not).
jx:if, jx:choose, jx:forEach, etc. should create a new local context.
jx:call (along with alternative macroName/ invocation) should create a
new context that DOES not inherit from parent context (only the
parameters explicitly passed with jx:call macro=macroName
param1=value param2=value/) should be visible.
2. If it's somehow limited should we allow global sets (I'm really reluctant to
that option)?
not needed IMO
Simply removing this instructions is not the best option because there would be
a lot of junk
(namespace declarations) laying in Object Model when, in fact, we would be out
of this namespaces.
I have no experience in xml namespaces area.
Are these valid xml files?:
root
foo:foo xmlns:foo=http://foo.org/1.0;
/foo:foo
!-- different namespace, same prefix --
foo:foo xmlns:foo=http://bar.org/2.0;
/foo:foo
/root
root
foo:foo xmlns:foo=http://foo.org/1.0;
/foo:foo
!-- namespaced element outside namespace declaration --
foo:foo
/foo:foo
/root
If the second one is valid we have to keep all declared namespaces till
the end of xml file (gets worse for xmls with jx:imports). Unnecessary
namespaces are cleared anyway by a filter:
XMLConsumer consumer = new AttributeAwareXMLConsumerImpl(new
RedundantNamespacesFilter(this.xmlConsumer));
2.b. introduce new methods to ObjectModel which
* register namespace local context
* unregister namespace local context without removing variable
declarations
One of my main goals was to have ObjectModel interface as small and clean as
possible. That's why I
moved namespace handling out of Object Model and introduced new namespaces
parameter in
Event#execute() method.
I believe we could sort out current problems without polluting ObjectModel as
soon as we establish
precise contracts for jx:set.
Once again: the contract of jx:set is clear. On the contrary we have
inconsistent context creation contract for all other jx:* instructions.
--
Leszek Gawron http://www.mobilebox.pl/krs.html
CTO at MobileBox Ltd.
Re: cocoon-template incompatible change
Leszek Gawron pisze: 1. What's the scope of variable introduced by jx:set? you are probably asking the wrong question. jx:set always puts a variable in current context. The question should be: which elements/instructions should trigger a new local context. I think new local context should never be introduced for plain xml elements (either local or imported, namespaced or not). Take a look at this code from StartPrefixMapping: namespaces.addDeclaration(getPrefix(), getUri()); objectModel.markLocalContext(); objectModel.put(ObjectModel.NAMESPACE, namespaces); What this code does is putting NamespaceTable object (namespaces) on Object Model. It may be used while some expression deeper in elements hierarchy is evaluated. Even though namespaces are only supported by JXPath we cannot putting them on Object Model. If we put something, we need to remove it from Object Model, that's what EndPrefixMapping does: objectModel.cleanupLocalContext(); That's why we need to introduce new context when encountering new namespace prefix. jx:if, jx:choose, jx:forEach, etc. should create a new local context. Do you want to say that all instructions that contain other instructions create a new context? If so, I'm fine with such behaviour. jx:call (along with alternative macroName/ invocation) should create a new context that DOES not inherit from parent context (only the parameters explicitly passed with jx:call macro=macroName param1=value param2=value/) should be visible. That's something new for me but after a while of thinking I agree with you. This means that Call instruction will need to create it's own instance of ObjectModelImpl class that will be created every time the call is made. That's not the best option because it couples Template and Object Model implementation. I must think it over. I have no experience in xml namespaces area. Are these valid xml files?: root foo:foo xmlns:foo=http://foo.org/1.0; /foo:foo !-- different namespace, same prefix -- foo:foo xmlns:foo=http://bar.org/2.0; /foo:foo /root Yes, it's valid. It's worth to say that namespace prefix does not matter at all because it's defined locally and makes it easier to indicate which elements belong to which namespaces. root foo:foo xmlns:foo=http://foo.org/1.0; /foo:foo !-- namespaced element outside namespace declaration -- foo:foo /foo:foo /root If the second one is valid we have to keep all declared namespaces till the end of xml file (gets worse for xmls with jx:imports). Second file is valid XML but second foo element is in the same namespace as root element (empty namespace) and it's full name is foo:foo. Lack of namespace declaration makes prefix meaningless and part of element's name (if prefix is attached to the namespace it's part of element's name also). Namespace declarations are not available to sibling elements. Unnecessary namespaces are cleared anyway by a filter: XMLConsumer consumer = new AttributeAwareXMLConsumerImpl(new RedundantNamespacesFilter(this.xmlConsumer)); Leszek, you are mixing two things: 1. SAX events declaring namespaces pushed down the pipeline that you say are filtered out. 2. Namespaces declaration put on Object Model that are used solely for JXPath purpose and have nothing to do with SAX events. Once again: the contract of jx:set is clear. On the contrary we have inconsistent context creation contract for all other jx:* instructions. From ObjectModel point of view everything is fine. StartPrefixMapping puts something on ObjectModel that will need to be cleaned up later on so it needs to create local contexts. However, what we want to is to attach variable to context upper in hierarchy. I'm thinking about named contexts. For example, jx:if could create new local context this way: objectModel.markLocalContext(jx:instruction); Then in jx:set we could use: objectModel.put(variable_name, variable, jx:instruction); so object model would attach this variable to the first context with name jx:instruction found when searching the context hierarchy. I'm not particularly happy with such approach because it pollutes Object Model API but I couldn't come with something more elegant. Thoughts? -- Grzegorz Kossakowski http://reflectingonthevicissitudes.wordpress.com/
Re: cocoon-template incompatible change
On 26.08.2007 16:07 Uhr, Grzegorz Kossakowski wrote: Are these valid xml files?: Nit-picking: None of them is valid as there is nothing to validate against like a DTD or a schema. You can only talk about well-formedness. root foo:foo xmlns:foo=http://foo.org/1.0; /foo:foo !-- namespaced element outside namespace declaration -- foo:foo /foo:foo /root If the second one is valid we have to keep all declared namespaces till the end of xml file (gets worse for xmls with jx:imports). Second file is valid XML but second foo element is in the same namespace as root element (empty namespace) and it's full name is foo:foo. Lack of namespace declaration makes prefix meaningless and part of element's name (if prefix is attached to the namespace it's part of element's name also). That's not correct. This one is not well-formed, it should result in a undeclared namespace prefix-exception. Namespace declarations are not available to sibling elements. That's true. Joerg
Re: [VOTE] Introduce component/module specific version fields in JIRA
On 26.08.2007 7:29 Uhr, Grzegorz Kossakowski wrote: Unexpectedly, Nils Kaiser has come up with much better and, in general, less intrusive solution. He proposed[3] to introduce custom fields where information about version specific to the *component* would be stored. I don't want to rain on the party again, but have you checked the approach with infrastructure team? I fear this effects all projects and I'm not sure they want to do this. Second I wonder if this really works (or if I misunderstood something). Nils only seems to talk about an additional field to differ between global version (like Cocoon 2.2) and component version (like CForms 1.0). I guess you can't add component-specific select options to the fields. I don't see a logical reason that Jira has support for this while it has not the same for the existing version fields. My vote is +1 though. Joerg
