I've checked the images, they seem ok. As they are binary adding a patch is inapropriate, so I've just left a comment in bugzilla as to where they should be extracted. Do you require any further information/action from me for this bug to be resolved?
2013/6/11 Glyn Normington <[email protected]> > Hi Alexander > > I dug out the missing images from an old copy of the Spring DM repository > and attached them to the bug. I haven't looked at the content to see if the > images need reworking. Hope that helps! > > Regards, > Glyn > > > > On 10 Jun 2013, at 07:23, Alexander Shutyaev <[email protected]> wrote: > > 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 >> >> >> <pivotal-logo-email-signature.png> >> >> 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 >> >> > _______________________________________________ > 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
