I think the point were we need optional dependencies is were we should
stop merging bundles. Apart from that I think we should
try to combine as many parts as possible.
So what I could imagine is to combine api, parser, core, authz, cm.
Merging cm would create a dependency to config admin but I could live
with having this as a mandatory dependency.
One way would be to combine these in a blueprint-bundle just for runtime
as we do already for api, parser, core. In that case we could at least
release these together.
Not sure about the compatibility bundles. Do we still need them at all?
So the remaining ones would be jexl, web, noosgi, spring. Not sure about
these.
Christian
On 09.01.2017 09:45, Guillaume Nodet wrote:
IIRC, initially, we had a single bundle.
It has been split at some point between api + parser + extender + cm. I
understand the split of the api, in case we want to support updating the
implementation bundle without having to refresh everything (though, given
the application is recreated fully anyway, I'm not sure it's really worth
it...). I think the parser has been extracted because it was used in some
tooling.
The problem is that if we get back to a smaller number of bundles, we'll
have to use optional imports everywhere (spring, web, ...)
Is this really a big issue ? I've been doing a lot of the recent blueprint
core / cm / spring / web releases, and it was usually only one or two
bundles affected, so doing a full release is not necessarily a big win (if
it actually is).
2017-01-09 9:36 GMT+01:00 Jean-Baptiste Onofré <[email protected]>:
+0
I generally agree but some bundles make sense (for instance blueprint non
OSGi).
Regards
JB
On Jan 9, 2017, 09:26, at 09:26, Christian Schneider <
[email protected]> wrote:
I guess there is some truth in this :-)
I checked the blueprint project. We currently have 18 bundles in the
blueprint subproject (not counting tests and samples).
I agree with David that this sounds like too much.
As we do not seem to find an agreement for the per subproject release
we
remain with the status quo.
Christian
On 05.01.2017 01:34, David Jencks wrote:
Maybe there are too many bundles? DS only needs one bundle.
david jencks
On Jan 4, 2017, at 2:44 PM, Christian Schneider
<[email protected]> wrote:
On 04.01.2017 18:52, Holly Cummins wrote:
I also think if the root problem is test framework doesn't
properly handle
using the most recent code from peer projects then that is the
thing that
is broken...
Addressing this problem is what the 'build with most recent
versions' build did - it would ratchet the versions of all internal
dependencies up to the latest level and then run the tests. So across
the two builds there were two test runs, one to make sure everything
still worked with the minimum declared level, and one with the latest
level.
However, that build has been broken for a while, I think.
I know. One problem with this approach is that it took me quite a
while to understand the approach at all. Theoretically I think it was a
good idea but in practice I think it did not really work well. At least
when I started with Aries the build with the latest versions never
worked and I did not understand it well enough to fix it. I also doubt
it works when we have maintenance branches like for Aries JPA 1.x.
What I try to achieve is to make the build simpler. So people with
less experience and or less involvement in Aries can still understand
it.
You can call it lazy, Felix ... and it is true to a degree but it is
also an effort to decrease the complexity in development. The more
complex development is the more errors we make and the less new people
we attract. I think in an open source project it is necessary to keep
things approachable.
As a user I was always glad that karaf had features for blueprint
and other Aries bundles as so I had at least one tested combination.
For people who used plain Aries it must have been a horror to keep up
with all the little releases and combine the bundles into a working
whole. With the release by subproject it is much easier to explain to
someone which versions to use. It is also easier to document the
releases on the lists or in blogs. It is a huge difference for users if
they need to follow 10 subprojects or 100 individual bundle releases.
Christian
--
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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
