Hi Glyn!
I've submitted a bug about outdated docs [1] and attached my patch to it.
However as I indicate in my comment I've noticed another thing that I was
unable to fix - there are broken image links (e.g.
'images/callouts/1.png'). In fact this can be even seen in the online
documentation [2]. I was unable to find neither such folder ('callouts')
nor such images ('1.png', '2.png' etc.) so I suppose they are either
missing from the project (if they're static) or do not get generated due to
some error (if they're dynamic). I guess it would be great if we could
figure this out and include a fix in my docs patch.[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=410296 [2] http://www.eclipse.org/gemini/blueprint/documentation/reference/1.0.2.RELEASE/html/compendium.html 2013/6/7 Glyn Normington <[email protected]> > Sure - two bugs seem appropriate: fix the current docs and add your > contribution. > > Regards, > Glyn > > > > On 7 Jun 2013, at 08:53, Alexander Shutyaev <[email protected]> wrote: > > I've checked under felix and knopflerfish profiles already - everything's > alright there. I'll get to the docs as soon as possible. Should I already > file a bug so we can continue our discussion there? > > > 2013/6/7 Glyn Normington <[email protected]> > >> Great news that the tests are passing now. If you want to be really >> thorough, you should check they pass with the Felix and Knopflerfish >> profiles too, if you haven't already. >> >> As for the docs, I think they really are outdated if the following is any >> indication: >> >> $ pwd >> >> /Users/gnormington/dev/eclipse/org.eclipse.gemini.blueprint/docs/src/docbkx >> [localhost:docbkx master]$ ack update-strategy >> reference/compendium/compendium.xml >> 195: one can configure <literal>managed-properties</literal> element to >> receive configuration updates through the <literal>update-strategy</literal> >> 231: <osgix:managed-properties persistent-id="labX" >> update-strategy="container-managed"/> >> 236: <osgix:managed-properties persistent-id="labY" >> update-strategy="bean-managed" update-method="updateCallback"/> >> 252: <entry><literal>update-strategy</literal></entry> >> 381: <entry>update-strategy</entry> >> 418: update-strategy="bean-managed" >> 469: Finally, due to the specified <literal>update-strategy</literal>, >> any updates executed to each CM configuration will cause the >> >> Would you be able to provide a correction to the docs as a separate patch >> which you could then base the patch for the new docs upon? >> >> Regards, >> Glyn >> >> >> <pivotal-logo-email-signature.png> >> >> On 7 Jun 2013, at 07:27, Alexander Shutyaev <[email protected]> wrote: >> >> Hi Glyn >> >> I've started looking into the documentation sources and found them a >> little bit outdated. It seems that the *managed-service-factory* is >> described as it was in schema *spring-osgi-compendium-1.2.xsd* while >> even in the latest release (1.0.2) the latest version is >> *spring-osgi-compendium-2.0.xsd >> *or *gemini-blueprint-compendium-1.0.xsd*.* *One of the differences is >> that *update-strategy* attribute in *managed-service-factory* which is >> mentioned in the documentation was replaced by *autowire-on-update* attribute >> in the latest schema. Moreover, I've checked that the online documentation >> and the documentation which ships with 1.0.2 release has the same outdated >> information. As my new attribute's behavior somehow depends on * >> autowire-on-update* I need it to be present in the docs :) Could you >> please check whether the docs are really outdated or am I missing something? >> >> >> 2013/6/6 Alexander Shutyaev <[email protected]> >> >>> Nope, I'm on ubuntu. I've tried it on Windows with the same jdk >>> version. Everything works fine. I can confirm that both before and after my >>> changes all tests pass. >>> >>> >>> 2013/6/6 Glyn Normington <[email protected]> >>> >>>> Windows? >>>> >>>> Regards, >>>> Glyn >>>> >>>> >>>> <pivotal-logo-email-signature.png> >>>> >>>> On 6 Jun 2013, at 14:21, Alexander Shutyaev <[email protected]> wrote: >>>> >>>> Ok, I've tried running tests on the project *without* my >>>> modifications. I've git-cloned it about an hour ago. Then I've run *mvn >>>> clean test -Pit,equinox* from the project's root folder. >>>> >>>> I'm getting about 190 test error in *core* module. They seem weird. >>>> Most of them are because a classpath resource that is created is *null* >>>> (see >>>> attached NestedElementTest.xml report). Next there are two tests that fail >>>> because *System.out* is *null *(see attached DictionaryEditorTest.xml >>>> report). There may be other types of errors but because the number of >>>> failures is so high it's hard for me to find if there are any others. >>>> >>>> The weirdness of these failures has lead me to believe I was missing >>>> something in the environment. I've tried switching the jdk (from 1.6.0_43 >>>> to 1.7.0_21) but the errors are the same. Maven version is 3.0.5. >>>> >>>> Do you have any clues? Should I maybe post a new thread so the others >>>> would see it under a more appropriate title (like "tests fail")? >>>> >>>> >>>> 2013/6/6 Glyn Normington <[email protected]> >>>> >>>>> Thanks. I think your highest priority should be to get the tests to >>>>> pass before raising a bug. >>>>> >>>>> Unfortunately, I don't have much detailed knowledge of Gemini >>>>> Blueprint internals. I'm acting as a caretaker project lead until such >>>>> time >>>>> as a project lead can be found who has the necessary time and/or existing >>>>> expertise in the codebase. This means I probably won't be much help >>>>> debugging failing tests. >>>>> >>>>> Your best best would be to do as much analysis as you can and if you >>>>> are still stuck, post to this list and hope the other committers can help. >>>>> I'm afraid this might cost you quite some time. I guess another strategy >>>>> would be to get all the tests passing without your changes and then phase >>>>> the changes in gradually so you can narrow down very quickly which part of >>>>> your change is breaking a test. I'd certainly adopt that approach if I was >>>>> you. >>>>> >>>>> Hope that helps! >>>>> >>>>> Regards, >>>>> Glyn >>>>> >>>>> >>>>> <pivotal-logo-email-signature.png> >>>>> >>>>> On 6 Jun 2013, at 10:58, Alexander Shutyaev <[email protected]> >>>>> wrote: >>>>> >>>>> Hi Glyn >>>>> >>>>> 1. I've looked at their latest release source code. It seems that they >>>>> propagate all properties (both private and public) and there is no way to >>>>> turn it off. I'll write a test to confirm this. So I guess the answer is >>>>> 'partially yes but rather no' :) >>>>> >>>>> 2. The problem is I can't get all the tests pass on the original >>>>> project :) I've tried to do something about it but then I gave up. While I >>>>> developed I ran only PropertyPlaceholderTest and my >>>>> PropertyPropagationTest >>>>> (they are very much alike in the setup procedures). They both pass. >>>>> However, I understand that rules are rules so I should ensure that tests >>>>> pass. I'll try once again to get the original project's tests to pass. And >>>>> if I succeed I'll run them with my patch applied. However if I don't >>>>> succeed I may require your help to get the original tests to pass. >>>>> >>>>> 3. No new dependencies except from Apache Felix Configuration Admin >>>>> version upgrade from 1.2.4 to 1.2.8. >>>>> >>>>> 4. I'll start working with the docs. >>>>> >>>>> 5. As for raising a bug - should I do it already? A new one or is >>>>> there an existing one? >>>>> >>>>> >>>>> 2013/6/6 Glyn Normington <[email protected]> >>>>> >>>>>> Hi Alexander >>>>>> >>>>>> Thanks for raising this contribution. Some questions: >>>>>> >>>>>> 1. Does Apache Aries Blueprint support this function? >>>>>> >>>>>> 2. Does the build pass, including all tests, with your patch applied? >>>>>> >>>>>> 3. What new build or runtime dependencies does this patch require, if >>>>>> any, in addition to upgrading Felix config admin? >>>>>> >>>>>> I welcome comments from the other Gemini Blueprint committers, but >>>>>> the next step should be to raise a bug and attach the code. We'll need to >>>>>> do IP due diligence and obtain a documentation patch before we can >>>>>> commit >>>>>> the code. One of us can easily review your English, which looks good so >>>>>> far! >>>>>> >>>>>> Regards, >>>>>> Glyn >>>>>> >>>>>> >>>>>> <pivotal-logo-email-signature.png> >>>>>> >>>>>> On 6 Jun 2013, at 09:39, Alexander Shutyaev <[email protected]> >>>>>> wrote: >>>>>> >>>>>> Hi all! >>>>>> >>>>>> Recently I've developed an enhancement for Gemini Blueprint and I >>>>>> want to contribute it. The description is below, the patch is attached >>>>>> (must be applied to project's root dir). Any suggestions are welcome! If >>>>>> this contribution is accepted (which I very much hope will happen :) I'm >>>>>> ready to make changes to the documentation (although English is not my >>>>>> native so maybe a final revision from a native speaker would be nice :) >>>>>> >>>>>> Property propagation >>>>>> >>>>>> This contribution is inspired by the Section 104.4.4 "Property >>>>>> Propagation" of the OSGi Configuration Admin specification. First, let me >>>>>> quote it. >>>>>> >>>>>> ===== >>>>>> A configuration target should copy the public configuration >>>>>> properties (properties whose name does not start with a ’.’ or \u002E) of >>>>>> the Dictionary object argument in updated(Dictionary) into the service >>>>>> properties on any resulting service registration. >>>>>> >>>>>> This propagation allows the development of applications that leverage >>>>>> the Framework service registry more extensively, so compliance with this >>>>>> mechanism is advised. >>>>>> >>>>>> A configuration target may ignore any configuration properties it >>>>>> does not recognize, or it may change the values of the configuration >>>>>> properties before these properties are registered as service properties. >>>>>> Configuration properties in the Framework service registry are not >>>>>> strictly >>>>>> related to the configuration information. >>>>>> >>>>>> Bundles that follow this recommendation to propagate public >>>>>> configuration properties can participate in horizontal applications. For >>>>>> example, an application that maintains physical location information in >>>>>> the >>>>>> Framework service registry could find out where a particular device is >>>>>> located in the house or car. This service could use a property dedicated >>>>>> to >>>>>> the physical location and provide functions that leverage this property, >>>>>> such as a graphic user interface that displays these locations. >>>>>> >>>>>> Bundles performing service registrations on behalf of other bundles >>>>>> (e.g. OSGi Declarative Services) should propagate all public >>>>>> configuration >>>>>> properties and not propagate private configuration properties. >>>>>> ===== >>>>>> >>>>>> At present Eclipse Gemini Blueprint does not provide such >>>>>> functionality. The goal of this contribution is to add support of it. >>>>>> >>>>>> Now, to the implementation details. *managed-service-factory*element now >>>>>> has a new property - >>>>>> *propagate-properties* (boolean, default=false). If it's set to true >>>>>> then the following changes apply: >>>>>> >>>>>> - during the initial instance creation all public properties (those >>>>>> whose name does not start with '.') are propagated as service properties >>>>>> of >>>>>> the resulting service registration. >>>>>> >>>>>> - during the initial injection both public and private properties are >>>>>> injected into the instance bean; the private properties get their first >>>>>> dot >>>>>> removed before injection; in case there is a name conflict between >>>>>> private >>>>>> and public property during injection, private property takes precedence >>>>>> >>>>>> - if *autowire-on-update* is set to true then the subsequent >>>>>> injections are done in the same manner and service properties are also >>>>>> updated. >>>>>> >>>>>> More specific implementation details can be seen in the code itself. >>>>>> There is also a new integration test - PropertyPropagationTest that >>>>>> covers >>>>>> the described functionality. >>>>>> >>>>>> P.S. Apache Felix Configuration Admin implementation used in tests >>>>>> had to be updated from v1.2.4 to v1.2.8 because v1.2.4 for some reason >>>>>> prohibits configuration properties that start with dot. >>>>>> >>>>>> Best regards, >>>>>> Alexander >>>>>> <property-propagation.patch> >>>>>> _______________________________________________ >>>>>> gemini-dev mailing list >>>>>> [email protected] >>>>>> https://dev.eclipse.org/mailman/listinfo/gemini-dev >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> gemini-dev mailing list >>>>>> [email protected] >>>>>> https://dev.eclipse.org/mailman/listinfo/gemini-dev >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> gemini-dev mailing list >>>>> [email protected] >>>>> https://dev.eclipse.org/mailman/listinfo/gemini-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> gemini-dev mailing list >>>>> [email protected] >>>>> https://dev.eclipse.org/mailman/listinfo/gemini-dev >>>>> >>>>> >>>> >>>> <TEST-org.eclipse.gemini.blueprint.blueprint.config.NestedElementsTest.xml> >>>> <TEST-org.eclipse.gemini.blueprint.DictionaryEditorTest.xml> >>>> _______________________________________________ >>>> >>>> gemini-dev mailing list >>>> [email protected] >>>> https://dev.eclipse.org/mailman/listinfo/gemini-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> gemini-dev mailing list >>>> [email protected] >>>> https://dev.eclipse.org/mailman/listinfo/gemini-dev >>>> >>>> >>> >> _______________________________________________ >> gemini-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/gemini-dev >> >> >> >> _______________________________________________ >> gemini-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/gemini-dev >> >> > _______________________________________________ > gemini-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/gemini-dev > > > > _______________________________________________ > gemini-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/gemini-dev > >
<<pivotal-logo-email-signature.png>>
_______________________________________________ gemini-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/gemini-dev
