aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Ross <>
Subject Re: [Vote] Release Aries blueprint parser 1.3.2 and blueprint core 1.4.5
Date Thu, 22 Oct 2015 14:08:48 GMT
The justification for me would be that we're trying to distribute a
critical defect fix as quickly as possible and no one has the capacity
to address the other issue in a timely manner at the moment. The
workaround for folks who require the Namespaces class is to ensure the
proper bundle version is installed and, if necessary, use
Require-Bundle or the bundle-symbolic-name/bundle-version attributes
on the package import.

On Thu, Oct 22, 2015 at 8:22 AM, Christian Schneider
<> wrote:
> Well it is not ideal but as soon as we release the next version people can
> specify the 1.4.0 version and make sure they get a correct impl.
> So I think it should kind of heal itself :-)
> Christian
> On 22.10.2015 15:17, John Ross wrote:
>> In order to address Sam's issue (and mine since we work together), we
>> just need to fix this in SVN since our build pulls from there rather
>> than using the released versions. So, in that respect, releasing the
>> current candidate is not an issue.
>> However, if we release the current candidate, it will be possible for
>> users specifying the correct package version to get wired to packages
>> both with and without the Namespaces class. The last blueprint-parser
>> release of 1.3.1 contains the class, but the last blueprint-core
>> release of 1.4.4, which also exports the org.apache.aries.blueprint
>> package at version 1.3, does not. So, in that sense, it is worse than
>> before. Can we justify that?
>> On Thu, Oct 22, 2015 at 7:44 AM, Christian Schneider
>> <> wrote:
>>> I agree. Lets be careful with parser as long as we do not know for sure
>>> it
>>> is not needed seperately.
>>> About the bundle version. You are right .. normally the bundle version
>>> does
>>> not matter as in a bundle Manifest each package can have a separate
>>> version
>>> assigned.
>>> In this case though as parser is no bundle the maven bundle plugin will
>>> use
>>> the maven version as package version for all exports. So setting the
>>> maven
>>> version is the easiest way to achieve
>>> having the correct exported package version. The better way would be to
>>> make
>>> parser a real bundle and manage the package versions separately and with
>>> the
>>> help of the version plugin.
>>> If the old parser version already included the file then I propose we
>>> release with the problematic package version as it is not worse as before
>>> and fix it in the next release.
>>> Christian
>>> On 22.10.2015 13:35, John Ross wrote:
>>>> 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.
>>> --
>>> Christian Schneider
>>> Open Source Architect
> --
> Christian Schneider
> Open Source Architect

View raw message