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
