Infobuttons are context-sensitive links embedded in the electronic health record (EHR). They use clinical context information from the EHR, such as patient demographics, medications, diagnoses, user role, and clinical setting to help find answers to clinicians' and patients' questions using online health information resources.
28
stars
29
forks
source link
POM changes to facilitate managing/releasing artifacts #4
As we rely on stable releases (i.e. non-snapshot artifacts), our fork includes some additional changes. I figured I would share these with you all in case you want to follow.
Within oib-request, I noticed that versions of the modules did not specify -SNAPSHOT (i.e. 1.4 instead of 1.4-SNAPSHOT). By convention, when installed/deployed, these artifacts are mis-represented. So, I added the –SNAPSHOT to the managed modules within oib-request. I also changed the dependency on edu.utah.further.core from snapshot to 1.4.0 release.
Now, there are no transitive snapshot dependencies and I can use the Maven release plugin to create a release.
• In the README.md, you mention removing “Duke” references, yet some groupIds still reflect “Utah” edu.utah.openinfobutton. Maybe this is appropriate. If this was an oversight and you intend for all artifacts to be “org.openinfobutton”-related (i.e. all have that as the groupId), I might suggest having all oib-request modules add a section, like below. This would allow you to omit groupId & version from all submodules, inheriting “org.openinfobutton” and version 1.4-SNAPSHOT. This would assume that you intend to version all modules consistently. There are a few advantages with this approach. You can see with my changes, I have added a root pom.xml to the repository root (to get around a Maven release plugin scm bug when releasing from non-repository-root directories like oib-request/pom.xml), with only a single module (oib-request). This root/aggregator pom.xml is where the dependencyManagement is done for each module. I opted for minimal changes in order to release so I just listed the modules but you could add all dependencies in this section and remove specific versions from each descendent pom.xml. Each pom.xml has a parent declaration and inherits from the parent.
Let me know if you have any questions.
org.openinfobuttonoib-request1.4-SNAPSHOT
Other Items for Consideration (Not Included in Pull Request):
• I noticed that during compilation, URLs to WSDLs are used. I have run into cases where the compilation fails due to remote web service availability. I might suggest storing a copy of the WSDL in src/main/resources so that the service availability is not a requirement for compilation/testing.
• Revert “outputDirectory” of maven jaxb plugin to something like the default (Default value is: ${project.build.directory}/generated-sources/jaxb). Having the classes generated in the build directory (target) would prevent you from having to keep under DCVS and therefore the generated classes from showing under “git status”.
As we rely on stable releases (i.e. non-snapshot artifacts), our fork includes some additional changes. I figured I would share these with you all in case you want to follow.
Within oib-request, I noticed that versions of the modules did not specify -SNAPSHOT (i.e. 1.4 instead of 1.4-SNAPSHOT). By convention, when installed/deployed, these artifacts are mis-represented. So, I added the –SNAPSHOT to the managed modules within oib-request. I also changed the dependency on edu.utah.further.core from snapshot to 1.4.0 release. Now, there are no transitive snapshot dependencies and I can use the Maven release plugin to create a release.
For example: $ mvn clean release:clean release:prepare release:perform -DuseReleaseProfile=false -Dgoals=deploy -DautoVersionSubmodules=true -Darguments='-DskipTests -DaltDeploymentRepository=internal::default::http://arm.regenstrief.org/archiva/repository/internal'
• In the README.md, you mention removing “Duke” references, yet some groupIds still reflect “Utah” edu.utah.openinfobutton. Maybe this is appropriate. If this was an oversight and you intend for all artifacts to be “org.openinfobutton”-related (i.e. all have that as the groupId), I might suggest having all oib-request modules add a section, like below. This would allow you to omit groupId & version from all submodules, inheriting “org.openinfobutton” and version 1.4-SNAPSHOT. This would assume that you intend to version all modules consistently. There are a few advantages with this approach. You can see with my changes, I have added a root pom.xml to the repository root (to get around a Maven release plugin scm bug when releasing from non-repository-root directories like oib-request/pom.xml), with only a single module (oib-request). This root/aggregator pom.xml is where the dependencyManagement is done for each module. I opted for minimal changes in order to release so I just listed the modules but you could add all dependencies in this section and remove specific versions from each descendent pom.xml. Each pom.xml has a parent declaration and inherits from the parent.
Let me know if you have any questions.
Other Items for Consideration (Not Included in Pull Request): • I noticed that during compilation, URLs to WSDLs are used. I have run into cases where the compilation fails due to remote web service availability. I might suggest storing a copy of the WSDL in src/main/resources so that the service availability is not a requirement for compilation/testing. • Revert “outputDirectory” of maven jaxb plugin to something like the default (Default value is: ${project.build.directory}/generated-sources/jaxb). Having the classes generated in the build directory (target) would prevent you from having to keep under DCVS and therefore the generated classes from showing under “git status”.