| time |
nick |
message |
07:39 |
<gertv> |
gnodet_: good morning |
07:39 |
<gnodet_> |
hey gertv ! |
07:40 |
<gertv> |
is it OK if I try to finish up on the Camel features thing today? |
07:40 |
<gertv> |
or is there anything else to attend to? |
07:43 |
<gnodet_> |
no, it's ok |
07:53 |
<gertv> |
gnodet: what was the problem you had with OBR again? |
07:54 |
<gnodet> |
two problems mainly: it automatically install optional libraries, and the default uri location in the obr repository generated is not usable afaik (but i haven't looked much at the latest one) |
07:55 |
<gnodet> |
i was a bit worried about the complexity of the generated xm file, but if we really don't need to touch it, i guess it's ok |
07:56 |
<gnodet> |
one nice thing would be to use the maven url inside the obr file |
07:56 |
<gertv> |
well, we could use the OBR file to generate the features.xml, no? |
07:57 |
<gertv> |
the OBR file has the version ranges that would make it easier to manage dependencies |
07:57 |
<gnodet> |
i would think the other way if possible: from the features.xml, reference an obr thing and let obr handle the installation |
07:57 |
<gnodet> |
not sure though |
07:57 |
<gertv> |
e.g. we now need to upgrade the bundle for saxon once again (to 9.1.0.1) because camel upgraded it |
07:59 |
<gnodet> |
yeah, but there is no requirement to upgrade everything here even it would be be way cleaner of course |
07:59 |
<gnodet> |
i think we should use version ranges in our imports |
07:59 |
<gnodet> |
for example, servicemix-saxon could specify [9.0.0.0, 10.0.0.0) |
07:59 |
<gnodet> |
or something like that |
07:59 |
<gnodet> |
(not sure if 9.0 and 9.1 are compatible) |
08:00 |
<gertv> |
well, camel-saxon in this case needs 9.1 for some threading issues |
08:00 |
<gnodet> |
yeah, i know. I meant that we can always end up with two saxon versions in smx4 |
08:00 |
<gertv> |
yep |
08:00 |
<gnodet> |
i don't say we should, but we could ;-) |
