FHIR Chat · hapi-fhir: pull request 287: Enhancements to osgi-core pr... · hapi

Stream: hapi

Topic: hapi-fhir: pull request 287: Enhancements to osgi-core pr...


view this post on Zulip Zulip HAPI Bot (Jan 20 2016 at 01:49):

bdenton opened pull request 287

This pull request contains several small improvements to the OSGi core project that I have been meaning to push out for a while now.

  • Improve OSGi manifest
  • make SimpleFhirProviderBundle class visible
  • include DSTU2x validation projects
  • include DSTU 2.1 (might need rework as further 2.1 work proceeds -- particularly WRT the utilities packages)

cheers,
Bill Denton

view this post on Zulip Zulip HAPI Bot (Jan 21 2016 at 08:02):

bdenton commented on pull request 287

James..

The Travis build errors in this pull request are being caused by the package/class conflicts between the hl7org-dstu2 and the dstu2.1 projects being combined into a single compile.

Is the resolution of these issues on me because of the OSGi thing?

Actually, ideally, I would like to see each of the core HAPI projects be able to produce a well structured OSGi bundle on its own without having to combine them into a single compile like we are currently doing.

This takes some work to resolve all of the split-package and duplicate class issues... fruit for a future pull request.

cheers, Bill

view this post on Zulip Zulip HAPI Bot (Jan 21 2016 at 13:56):

jamesagnew commented on pull request 287

Hi Bill,

I've put a commit into master that I think should avoid the conflict. Can you try syncing your fork and let's see if Travis passes now.

In terms of individual libraries each being individual bundles, I agree that this is the ideal end state.. but I'm not optimistic we'll get there anytime soon. There are a lot of things happening in parallel:
* The RI structures and validator are being developed in an SVN repo with a very different structure to HAPI and I'm trying to keep us in sync with that
* FHIR itself continues to evolve and we're trying to keep up with that
* There are several projects for alternate methods of using HAPI (OSGi is one, Android lib is another, JAX-RS server is yet another.. actually I guess CLI is yet another) and we're trying to keep things working for each one of these without ending up with 50 subprojects to maintain.

Hopefully over time things will start to stabilize to the point where we can say "this package lives in this JAR so that's the bundle you need for that" but at this point there aren't enough hours in the day to keep up with everything. :)

view this post on Zulip Zulip HAPI Bot (Jan 21 2016 at 17:00):

bdenton synchronized pull request 287

view this post on Zulip Zulip HAPI Bot (Jan 21 2016 at 17:03):

bdenton commented on pull request 287

James..

I did the upstream merge and pushed to my fork.. do I need to reissue the pull request or should Travis pick up the fact that my fork has been updated??

Cheers, Bill

Ps.. I totally get the struggle it is to keep all the balls in the air

From: James Agnew [mailto:notifications@github.com]
Sent: Thursday, January 21, 2016 5:56 AM
To: jamesagnew/hapi-fhir
Cc: Bill Denton
Subject: Re: [hapi-fhir] Enhancements to osgi-core project (#287)

Hi Bill,

I've put a commit into master that I think should avoid the conflict. Can you try syncing your fork and let's see if Travis passes now.

In terms of individual libraries each being individual bundles, I agree that this is the ideal end state.. but I'm not optimistic we'll get there anytime soon. There are a lot of things happening in parallel:

  • The RI structures and validator are being developed in an SVN repo with a very different structure to HAPI and I'm trying to keep us in sync with that
  • FHIR itself continues to evolve and we're trying to keep up with that
  • There are several projects for alternate methods of using HAPI (OSGi is one, Android lib is another, JAX-RS server is yet another.. actually I guess CLI is yet another) and we're trying to keep things working for each one of these without ending up with 50 subprojects to maintain.

Hopefully over time things will start to stabilize to the point where we can say "this package lives in this JAR so that's the bundle you need for that" but at this point there aren't enough hours in the day to keep up with everything. :)


Reply to this email directly or view it on GitHub<https://github.com/jamesagnew/hapi-fhir/pull/287#issuecomment-173576272>.

view this post on Zulip Zulip HAPI Bot (Jan 21 2016 at 17:07):

jamesagnew commented on pull request 287

It picks it up automatically... You can actually watch its progress here if you want: https://travis-ci.org/jamesagnew/hapi-fhir/pull_requests

Travis is really cool.

view this post on Zulip Zulip HAPI Bot (Jan 21 2016 at 17:11):

bdenton commented on pull request 287

Failed again but in the DSTU2 structures tests.. not sure how it is related to my changes

view this post on Zulip Zulip HAPI Bot (Jan 22 2016 at 02:41):

jamesagnew commented on pull request 287

Arg, that one is from a test I added. Looks like a bug in the test that is triggered only occasionally (accidental dependency on the order of keys coming out of a hashmap). Do you mind to sync once more?

Sorry about that!

view this post on Zulip Zulip HAPI Bot (Jan 22 2016 at 02:58):

bdenton synchronized pull request 287

view this post on Zulip Zulip HAPI Bot (Jan 22 2016 at 07:49):

bdenton commented on pull request 287

So, the build was successful but the Cobertura step had an error of some sort... something about multiple slf4j bindings...

How do we proceed from here? Should I merge the pull request? Are you going to do that at some point? I don't want to break protocol here.

cheers, Bill

view this post on Zulip Zulip HAPI Bot (Jan 22 2016 at 08:21):

bdenton commented on pull request 287

I resync’d and the Travis build part seemed successful. The pull request is still showing that “some tests have failed”.. I guess this is because the Cobertura test phase is throwing an error about multiple SLF4J bindings being present on the classpath (multiple versions of logback on the classpath… why???)…. Line 5425 in the log for Travis build #386

From: James Agnew [mailto:notifications@github.com]
Sent: Thursday, January 21, 2016 6:41 PM
To: jamesagnew/hapi-fhir
Cc: Bill Denton
Subject: Re: [hapi-fhir] Enhancements to osgi-core project (#287)

Arg, that one is from a test I added. Looks like a bug in the test that is triggered only occasionally (accidental dependency on the order of keys coming out of a hashmap). Do you mind to sync once more?

Sorry about that!


Reply to this email directly or view it on GitHub<https://github.com/jamesagnew/hapi-fhir/pull/287#issuecomment-173785046>.

view this post on Zulip Zulip HAPI Bot (Jan 23 2016 at 08:12):

bdenton commented on pull request 287

James..
Are you normally the one that initiates the merge process? Seems like the important tests passed.. Don't quite understand what is going on with the Cobertura tests but that does not impact my stuff.

cheers, Bill

view this post on Zulip Zulip HAPI Bot (Jan 25 2016 at 16:15):

jamesagnew commented on pull request 287

This look good to me! Please feel free to go ahead and merge.

view this post on Zulip Zulip HAPI Bot (Jan 25 2016 at 17:44):

bdenton closed pull request 287

view this post on Zulip Zulip HAPI Bot (Jan 25 2016 at 17:46):

bdenton commented on pull request 287

Thanks James.. done

BTW, what was the deal with the failing Cobertura test with multiple versions of logback on the classpath??

cheers, Bill

view this post on Zulip Zulip HAPI Bot (Feb 03 2016 at 03:05):

jamesagnew commented on pull request 287

I'm actually not sure what that was about.. The cobertura tests can be a bit flaky sometimes. Ultimately the final build succeeded, so I don't think it's a concern.


Last updated: Apr 12 2022 at 19:14 UTC