On 22.06.2015 15:29, Thomas Watson
Basically I hoped that the full release 1.4.0 would go into equinox
as it then would be identical to the felix 5.0.1. code. I can
understand though that you are picky about the commits as it is
really a core part of the framework.
> So I got some questions:
> - When is the next planned release of the equinox
framework that would
> contain the new resolver sources?
Our Mars Equinox release (version 4.5) is
(June 25th). The last felix resolver fix that will go into
of Equinox is:
That is svn revision 1680878
I'm guessing you also want https://issues.apache.org/jira/browse/FELIX-4914
I need to understand that fix better. I don't
like the idea of modelling fragment identity as hosted by
their host bundles
since these are not payload capabilities. I fear something is
overlooked. I need to get a testcase up in equinox to take a
look at the issue.
Unfortunately karaf internally uses the resolver from the framework
also for their own feature resolution. Maybe we need to change this
again in karaf to be more flexible.
For now I will stay with a custom build of equinox for our product.
In karaf we will use the newest release from equinox. Hopefully it
will work well enough.
Thanks I will use it.
Assuming the current fix is good or we find a
alternative I think we could target this fix for the Mars
1 (which is in September). But for now could you open an
framework bug to track the fixes you want made to the Felix
> - For my custom release which tag of equinox should I
base my fork
Eventually we will create a new tag R4_5 in
this will not happen until the end of this week. But unless
really catastrophic occurs that would force us to respin I can
that the commit at tag I20150603-2000 will be used for the
R4_5 tag. I
would go ahead and use that for your fixes so that you have
Mars release + the latest Felix resolver code.
In general. Is the correct approach to look into the jar of a
release and look up the tag ?
I first set the custom qualifier in the pom but it complained about
differences with the Manifest. So I also set it there. For now I
simply use a different maven groupId. This was the easiest way to
distinguish it from the official version.
> - I would like to create a suffixed version for my custom
> can be easily distinguished from the original equinox
release. I tried
> several variants like 3.10.2-Talend or 18.104.22.168 but all
lead to an
> during the build. So how can I create a suffixed custom
'-' cannot be used as a version separator for
qualifier. How are you trying to specify the qualifier.
the build the qualifier is filled in because the key word
used in the manifest. I assume you instead just try to fill
in with your own custom qualifier?
Yes. It makes it very difficult to use any eclipse
code in plain maven. It would be great if eclipse could have the
policy to always also publish to maven central. Maybe p2 could be
even changed to just contain the meta data and always retrieve the
jars from a maven repo. This would also make the p2 repos a lot
> - In maven central there are several artifacts for the
> (org.eclipse.osgi). Which of these is the official one
That is a sore topic. Unfortunately there is
not one that we can call official from the equinox project.
we can work out with Ray Auge how to publish all the latest
from Mars once
it is available. Unfortunately this is not automatic right
Open Source Architect