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 >
