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 > > > > 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 > >
<<pivotal-logo-email-signature.png>>
_______________________________________________ gemini-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/gemini-dev
