2014-07-14 12:54 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
Good point on OGM' s need for a specific micro. We could propose
a 4.4
series of ORM after you finish defining the integration point? So OGM
x.Final will be able to depend on a more reasonable version range.
Yes, that'd be vey nice.
About BOM files, I'm just skeptical as I don't see how we
should
maintain and test them:
We'd maintain it in the same way as we maintain the dependencyManagement
block in our current POMs. Only that it's not part of the parent POM itself
but is extracted into a separate POM file. We'd import that BOM in our own
build and thus verify and test it.
The significant difference would be that a user can do the same (import
that BOM) and thus get matching versions of our artifacts.
- would we update some separate BOM project at every release?
It would be just a module of each project, e.g. hibernate-ogm-bom, which
gets released as all the other modules.
- would you re-run the testsuite of each and all projects at every
BOM
update overriding the testsuite versions to make sure it's a valid
combination? (how to automate?)
- I'd also expect some integration tests to actually verify the
correctness of the BOM file (e.g. syntax)
See above, as the BOM would be used in a project's build itself, it gets
verified.
Also the documented dependency ranges on the website could need some
testing in a perfect world, but:
a) I'd expect it to be simpler as it' s a smaller matrix if each
project documents its own dependencies only
b) each project somehow "is aware" if when it breaks compatibility
with older dependencies, like you notice now with OGM: it's an
explicit step you just have to remember to document (and rare enough
so that I wouldn't bother too much to automate).
c) *Personal opinion* I feel like a statement about *expected
compatibility* does create a lower expectation in terms of accuracy
than a BOM file, so that I wouldn't expect need for actual QA on this
subject as much as I would expect it on BOM files which we would
officially distribute.
Atm. we also specify which version of our dependencies we expect (in our
parent POMs). So this information is there, it's only very hard for users
to extract it if they want to add any of our dependencies themselves
(they'd have to look up the version we depend on to make sure they don't
override it with a non-compatible one). By giving users the BOMs for
importing, this information is much more conveniently accessible (and there
is no risk for it of getting out-dated as with a wiki/web site based
approach).
I'm not strictly against BOM but it sounds like taking a lot of our
bandwidth for a minor practical improvement.
Maybe we have different things in mind?
It's not a huge effort, actually I've just pushed a branch for this for
OGM:
https://github.com/gunnarmorling/hibernate-ogm/compare/hibernate:master.....
Ultimately we should be very aware that our modules are in constant
change, and people mixing our latest are aware of a little bit of
risk
in using latest as there is a mismatch between our expectations vs our
capacity to test and deliver a single unified platform, I think that's
more something for assemblies such as WildFly, JBoss EAP, Spring, and
whoever else redistributes our jars as a combination. We should be
ready to provide recommendations (as what we expect to work) to the
people making these distributions and our users but.. would you
consider untested BOM files to be good for that?
They are not untested (at least in my model), as they are used for our own
build.
Sanne
--Gunnar
> On 14 July 2014 11:21, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> > 2014-07-13 14:47 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
>
> >> I've been explaining $subject to a forum user
[1]. I'm confident it's
> >> only a problem for newcomers, but are we expecting more expert
> >> developers to pass this lore by word of mouth?
>
>
> > Not so sure whether
it's not a problem for expert users as well every now
> > and then.
>
> > Looking at OGM for instance, we're currently in
the situation that we
> depend
> > on a specific micro version of ORM (4.3.6 once it's out), which may be a
> > surprising fact. Personally, I think it'd be rational for a user to
> expect
> > compatibility based on minor version families of our projects, e.g. that
> > each OGM 4.1.x release is compatible with each ORM 4.3.x release.
>
> > As we can't guarantee this due to the rapid
evolvement atm. (e.g. we add
> new
> > SPIs in ORM micro releases for the sake of OGM), some clear
> documentation is
> > highly desirable.
>
> >> I think we should add an explanation on these on
the website but I'm
> >> not sure where this would be more appropriate to present.
> >
> >> Should we highlight
compatible versions of other integration points on
> >> each sub section?
> >> For example I could edit the Search area to mention which versions of
> >> ORM, OGM, Lucene, Validator, Envers, Infinispan(we might have two
> >> different ones!), Commons Annotations, etc.. are supposed to work for
> >> each release.
>
>
> > Documenting the
matching/required versions of upstream projects in each
> > project area may be one way. E.g. Search could document its requirements,
> > OGM its own etc. I don't think Search should document any expectations
> > towards OGM versions as the dependency is the other way around?
>
> > Speaking in Maven terms, I still think that providing
this information in
> > form of bill-of-materials POMs would be the approach most helpful to
> users.
> > Such project BOM would contain the versions of all its components and
> > dependencies. Users would reference this BOM using the "import" scope
in
> > their dependency management configuration and thus get matching versions
> > when declaring a dependency to any of the artifacts listed in the BOM.
>
> > I vaguely remember though that in the past there had
been reservations
> > towards providing such BOMs?
>
> > @Davide, I've created
https://hibernate.atlassian.net/browse/OGM-574 to
> do
> > this for OGM; Shall we give it a try?
>
> > --Gunnar
>
>
> >
> >> [1]
https://forum.hibernate.org/viewtopic.php?f=31&t=1035292
> >
> >> -- Sanne
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev(a)lists.jboss.org
> >>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>