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 <ch...@die-schneider.net> 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 >> <ch...@die-schneider.net> 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 >>> 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 >
