Moving Ext I18N module under OpenMRS

github
jira
module
Tags: #<Tag:0x00007f88d54d8bd0> #<Tag:0x00007f88d54d87c0> #<Tag:0x00007f88d54d84a0>

(Dimitri R) #1

Hi all,

I would like to create a new repo under OpenMRS for Ext I18N:

Just wondering about best practices and implications:

  • I guess I should not fork but instead push the current history directly to the new repo?
  • Should I squash the pre-OpenMRS history or just keep it as it is?
  • What about JIRA, where would issues be tracked about it?

Any comments or suggestions are welcome!


Problem Setting up Drug data using CSV import
(Dimitri R) #2

Well I guess I will just go ahead then… :slight_smile: And I will also create a Bamboo plan for that one.


(Burke Mamlin) #3

Hey @mksd. Sometime’s the community’s silence can be deafening. :wink:

Yes. Migrate, do not fork.

Keep it as is.

We’d create a JIRA project for it.


(Dimitri R) #4

Thanks @burke. There’s actually a ‘Transfer ownership’ button, I just did that and now Ext I18N has become an OpenMRS project! I gave access to all /dev/3 in order for me to not loose access, I hope that’s ok?

Regarding JIRA… sure, but I personally think it’s a bit overkill. I would rather see Ext I18N as a component of a project dedicated to gather such components in one place. The day a component deserves its own project, one can always select its issues and move them to the project created for the occasion.

Cc @mksrom


(Dimitri R) #5

Actually that was a bad idea, I can’t push to it anymore :frowning: Could someone grant me the appropriate access on that new repo?

Internally at MKS we use a ‘dev’ branch as the main “develop” branch, and this remained through transferring the repo to OpenMRS. It is while attempting to rename the default branch to ‘master’ that I realised that I couldn’t write to it anymore…


(Mike Seaton) #6

I just went in and made you an admin.


(Daniel Kayiwa) #7

I also noticed that /dev/3 had Read instead of Write access.


(Burke Mamlin) #8

FYI – for the majority of repos, /dev/1 & /dev/2 get read access, /dev/3 & /dev/4 have write access, and /dev/5 has admin access. Folks who need additional access (e.g., a /dev/2 needing write access or a /dev/3 needing admin access), we add them as collaborators in the specific repo with the additional access.


(Dimitri R) #9

Everything is set up, including Bamboo. The first SNAPSHOT is in the box on Nexus. I will do a commit for the TravisCI build and everything should be in order.

Thanks all!


(Dimitri R) #10

Ok two more questions:

(Q1.) Who’s responsible to add the TravisCI service to the GitHub repo?

(Q2.) Should a webhook be added for triggering Bamboo buids, or how does that work?


(Daniel Kayiwa) #11

Q1: I think you may need to write to help desk. Q2: As you can see here, Bamboo is already triggered for every commit: https://ci.openmrs.org/browse/EI18N-EI18N-2


(Dimitri R) #12

Great! Somehow I didn’t see that #2 build… Ok helpdesk case created!


(Burke Mamlin) #13

8 posts were split to a new topic: Configuring CI for exti18n module


(Dimitri R) #14

Ok! I could finally release Ext I18N 1.0.0. A few tips for others and for reference…

The variable maven.release.version is the release version to come (obviously). Whereas the variable maven.development.version is the next desired development version. Working example:

In the main POM all this is necessary:

<scm>
 <connection>scm:git:git@github.com:openmrs/openmrs-module-exti18n.git</connection>
 <developerConnection>scm:git:git@github.com:openmrs/openmrs-module-exti18n.git</developerConnection>
 <url>scm:git:git@github.com:openmrs/openmrs-module-exti18n.git</url>
 <tag>HEAD</tag>
</scm>
  • The distribution management section, example:
<distributionManagement>
 <repository>
  <id>openmrs-repo-modules</id>
  <name>OpenMRS Modules</name>
  <url>http://mavenrepo.openmrs.org/nexus/content/repositories/modules</url>
 </repository>
 <snapshotRepository>
  <id>openmrs-repo-snapshots</id>
  <name>OpenMRS Snapshots</name>
  <url>http://mavenrepo.openmrs.org/nexus/content/repositories/snapshots</url>
 </snapshotRepository>
</distributionManagement>
  • The Maven release plugin, example:
<plugin>
 <groupId>org.apache.maven.plugins</groupId>
 <artifactId>maven-release-plugin</artifactId>
 <version>2.3.2</version>
 <configuration>
  <autoVersionSubmodules>true</autoVersionSubmodules>
  <tagNameFormat>@{project.version}</tagNameFormat>
 </configuration>
</plugin>