I was never involved with Blueprint so hopefully others will speak up with any concerns. My understanding is that blueprint-parser exists because, at least at some point, we had a requirement for a standalone version that can run outside of OSGi. Turning it into a bundle would not necessarily change that. However, if we want to ensure it is a valid bundle that works properly (whatever that means) within an OSGi environment, extra work may be required. Unless the requirement for a standalone version has gone away, I don't think merging it with core would be an option, but again, I'm hoping that more knowledgeable folks will speak up.
Another interesting thing I'll note is that the 1.3.1 release of blueprint-parser already includes the Namespaces class. Since my understanding based on previous discussions is that bundle versions are now really nothing more than a categorization, I'm not sure it really matters what version we assign to it? Well, as long as it's higher than the previous one I guess. On Wed, Oct 21, 2015 at 4:39 PM, Christian Schneider <ch...@die-schneider.net> wrote: > I think as the parser is no bundle the whole version checks do not work > correctly. So it might make sense to make it a bundle to at least make sure > the checks can work on it. > Another possible solution would be to try to merge the parser with core for > later versions. I am not sure why there is the separation at all. > > To make this work without further changes we would need to bump the version > of parser to 1.4.0. What do you think? > > Christian > > > On 21.10.2015 22:09, John Ross wrote: >> >> It looks to me like the packageinfo file under >> blueprint-core/src/main/java/org/apache/aries/blueprint needs to get >> bumped from 1.3 (as it was in the last release) to 1.4. Interestingly, >> there is also a packageinfo file under blueprint-parser at version >> 1.2.0. However, I think this can be safely ignored since the parser is >> not an OSGi bundle. >> >> On Wed, Oct 21, 2015 at 2:54 PM, Samuel E Bratton <sbrat...@us.ibm.com> >> wrote: >>> >>> If I pull down the org.apache.aries.blueprint.core-1.4.4.jar from maven >>> central, it does not have the class org.apache.aries.blueprint.Namespace >>> class yet that bundle exports org.apache.aries.blueprint;version="1.3.0". >>> Since that class is added in release 1.4.5, but the package export is still >>> 1.3.0. It seems like this is wrong. How can a user of the Namespace class >>> ensure getting wired to the right bundle? >>> >>> Of equal concern from our perspective: we tried to pull in the latest >>> blueprint uberbundle which has the same exports to use it in our product >>> build but our verification tools are choking on the new class appearing >>> without the package export changing. >>> >>> Thanks >>> Samuel Bratton >>> >>> >>> -- >>> Samuel Bratton >>> IBM WebSphere System Management >>> Bldg 903 5E005, 11501 Burnet Road, Austin, Texas 78758 >>> >>> sbrat...@us.ibm.com >>> phone: (512)286-5440; TL 363-5440 >>> >>> >>> -----Christian Schneider <cschneider...@gmail.com> wrote: ----- >>> To: dev@aries.apache.org >>> From: Christian Schneider >>> Sent by: Christian Schneider >>> Date: 10/21/2015 02:12PM >>> Subject: Re: [Vote] Release Aries blueprint parser 1.3.2 and blueprint >>> core 1.4.5 >>> >>> I think this package is embedded from the blueprint-parser jar which is >>> at version 1.3.2. So the 1.3.0 version is probably correct. >>> At least it should be the same version as for the blueprint-core 1.4.5 >>> bundle. >>> >>> Christian >>> >>> On 21.10.2015 20:53, Samuel E Bratton wrote: >>>> >>>> The Namespaces class is a new class for this release but the >>>> org.apache.aries.blueprint.core-1.4.5.jar MANIFEST shows the package >>>> exported as org.apache.aries.blueprint;version="1.3.0". Doesn't that need >>>> to >>>> be raised to 1.4? Or is that happening elsewhere as part of the release >>>> process? >>>> >>>> Thanks >>>> -- >>>> Samuel Bratton >>>> >>>> >>>> sbrat...@us.ibm.com >>>> phone: (512)286-5440; TL 363-5440 >>>> >>>> >>>> -----Christian Schneider <cschneider...@gmail.com> wrote: ----- >>>> To: dev@aries.apache.org >>>> From: Christian Schneider >>>> Sent by: Christian Schneider >>>> Date: 10/21/2015 11:34AM >>>> Subject: Re: [Vote] Release Aries blueprint parser 1.3.2 and blueprint >>>> core 1.4.5 >>>> >>>> I added the license header to Namespaces. >>>> >>>> Do we need to fix the script to work with the new maven plugins? >>>> >>>> Christian >>>> >>>> On 21.10.2015 18:24, Daniel Kulp wrote: >>>>>> >>>>>> On Oct 21, 2015, at 12:17 PM, John Ross <jwross.apa...@gmail.com> >>>>>> wrote: >>>>>> >>>>>> I'm receiving the following RAT failures when running the verify >>>>>> script against 1045. The last simply means that Namespaces.java needs >>>>>> a license header. I'm more concerned about the bad MD5s and SHA1s. Am >>>>>> I doing something wrong on my end? I have the latest KEYS file >>>>>> imported. >>>>> >>>>> With the latest releases of the various maven plugins, the “asc” files >>>>> aren’t deployed with MD5 and SHA1 files. Your script is checking for >>>>> them >>>>> but not finding them. >>>>> >>>>> Dan >>>>> >>>>> >>> >>> -- >>> Christian Schneider >>> http://www.liquid-reality.de >>> >>> Open Source Architect >>> http://www.talend.com >>> >>> > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com >
