What next?

[gavia]

Wow, @thewheat, you've done a lot this past week. It looks like we're coming close to completion.

Apart from splitting the modules into two separate projects, what else needs to be done?

[shangxiao]

Splitting into 2 separate projects? What for?

Gil: I think we need to move away from Go and see if we can revisit the
idea of running the functional tests on Travis using Sauce Labs. The last
time I looked at that the main roadblock was that Travis doesn't chain
builds. The workaround for this is to create a deploy repo that the
functional test job will watch.

On Tue, Oct 28, 2014 at 4:40 PM, Gil Azaria [email protected]
wrote:

Wow, @thewheat https://github.com/thewheat, you've done a lot this past
week. It looks like we're coming close to completion.

Apart from splitting the modules into two separate projects, what else
needs to be done?

—
Reply to this email directly or view it on GitHub
#105.

[gavia]

One of the thoughts that has been floating around the past few weeks is to split the modules into two separate projects. Whether this means two separate java projects (presumably separate build scripts, no cross module dependancies) under the same git repo or two separate repos altogether I think is still a discussion point.

As far as I can tell this was suggested mainly for abstraction purposes since they are not necessarily meant to be packaged together when deployed.

Dave: My question was intended to be focused around core functionality. Another question that was asked in the last few weeks is "What is left that needs to be done to get a first version out into the world?"

I'm not up to speed on the functional test issues. What are the current problems with running them through Go, and what is the motivation to move to Travis?

On 28 Oct 2014, at 4:59 pm, David Sanders [email protected] wrote:

Splitting into 2 separate projects? What for?

Gil: I think we need to move away from Go and see if we can revisit the
idea of running the functional testson Travis using Sauce Labs. The last
time I looked at that the main roadblock was that Travis doesn't chain
builds. The workaround for this is to create a deploy repo that the
functional test job will watch.

On Tue, Oct 28, 2014 at 4:40 PM, Gil Azaria [email protected]
wrote:

Wow, @thewheat https://github.com/thewheat, you've done a lot this past
week. It looks like we're coming close to completion.

Apart from splitting the modules into two separate projects, what else
needs to be done?

—
Reply to this email directly or view it on GitHub
#105.

—
Reply to this email directly or view it on GitHub.

[shangxiao]

I just need to clear up a couple of assumptions:

• They already are treated as 2 separate Java projects with separate
  build scripts, which just happen to inherit from the base build script,
  which just generalises some common build properties.
• There will inevitably be cross module dependencies as the 2 projects
  share some code.
• They are not packaged together.

That said, I'm not necessarily opposed to the idea of 2 separate
repositories, although it wouldn't bring much to the table.

One of the thoughts that has been floating around the past few weeks is to

split the modules into two separate projects. Whether this means two
separate java projects (presumably separate build scripts, no cross module
dependancies) under the same git repo or two separate repos altogether I
think is still a discussion point.

As far as I can tell this was suggested mainly for abstraction purposes
since they are not necessarily meant to be packaged together when deployed.

[gavia]

Glad you cleared that up — I was trying to reproduce a conversation we had that I didn’t really understand.

Anyway, Tim did say to me tonight that the idea was to split them into two repos. I don’t really care either way to be honest.

On 28 Oct 2014, at 10:08 pm, David Sanders [email protected] wrote:

I just need to clear up a couple of assumptions:

• They already are treated as 2 separate Java projects with separate
  build scripts, which just happen to inherit from the base build script,
  which just generalises some common build properties.
• There will inevitably be cross module dependencies as the 2 projects
  share some code.
• They are not packaged together.

That said, I'm not necessarily opposed to the idea of 2 separate
repositories, although it wouldn't bring much to the table.

One of the thoughts that has been floating around the past few weeks is to

split the modules into two separate projects. Whether this means two
separate java projects (presumably separate build scripts, no cross module
dependancies) under the same git repo or two separate repos altogether I
think is still a discussion point.

As far as I can tell this was suggested mainly for abstraction purposes
since they are not necessarily meant to be packaged together when deployed.

—
Reply to this email directly or view it on GitHub #105 (comment).

[thewheat]

I believe it was Adam that floated the idea of splitting the code base into 2 separate code bases to see if that would also help with the classpath issues. But since we've reverted that, we've headed on to fixing other things.

With regards to Go, I've managed to get the functional tests running on it, but the Travis pull request checking is great and we could possibly use Travis deploy options to possibly even just push to separate functional test repo to trigger a change and thus mimic a chain? The functional test repo could then be configured to run headless xvfb session

Or alternatively if possible they could all be in one repo, using custom deployment tactics similar to this

[AdamNowotny]

The classpath issues suggested that the modules are not actually that
separate even though they should be.
After all they would likely be deployed separately and as far as I
understand they don't directly communicate with each other.
The fact that some configuration is common is not enough to justify this
coupling in my opinion.
Separating the modules is a good way to enforce loose coupling of these
modules.
I do not however have enough context to understand how much work would that
actually involve.
Happy to discuss that, I am however in favour of keeping modules small and
independent.

Adam Nowotny https://google.com/+AdamNowotny01/about
Software Developer at ThoughtWorks
mobile: +(61) 466 927 972

On 28 October 2014 23:46, Timothy Lim [email protected] wrote:

I believe it was Adam that floated the idea of splitting the code base
into 2 separate code bases to see if that would also help with the
classpath issues. But since we've reverted that, we've headed on to fixing
other things.

With regards to Go, I've managed to get the functional tests running on
it, but the Travis pull request checking is great and we could possibly use Travis
deploy options http://docs.travis-ci.com/user/deployment/ to possibly
even just push to separate functional test repo to trigger a change and
thus mimic a chain? The functional test repo could then be configured to run
headless xvfb session
http://docs.travis-ci.com/user/gui-and-headless-browsers/

Or alternatively if possible they could all be in one repo, using custom deployment
tactics similar to this
http://hgc.io/2014/08/28/Continuous-deployment-to-Heroku-with-Travis-CI/

—
Reply to this email directly or view it on GitHub
#105 (comment)
.

[shangxiao]

That was because I'd set the review module to depend on the propose module,
before I understood how OpenMRS worked. I like the idea of forced loose
coupling to be honest - I actually use separate repos for Django/Angular
projects. They're mainly in the same repo originally for convenience and
because some DTO's and entity classes are shared; sharing configuration was
just extra benefit.

On Thu, Oct 30, 2014 at 5:55 PM, Adam Nowotny [email protected]
wrote:

The classpath issues suggested that the modules are not actually that
separate even though they should be.
After all they would likely be deployed separately and as far as I
understand they don't directly communicate with each other.
The fact that some configuration is common is not enough to justify this
coupling in my opinion.
Separating the modules is a good way to enforce loose coupling of these
modules.
I do not however have enough context to understand how much work would
that
actually involve.
Happy to discuss that, I am however in favour of keeping modules small and
independent.

Adam Nowotny https://google.com/+AdamNowotny01/about
Software Developer at ThoughtWorks
mobile: +(61) 466 927 972

On 28 October 2014 23:46, Timothy Lim [email protected] wrote:

I believe it was Adam that floated the idea of splitting the code base
into 2 separate code bases to see if that would also help with the
classpath issues. But since we've reverted that, we've headed on to
fixing
other things.

With regards to Go, I've managed to get the functional tests running on
it, but the Travis pull request checking is great and we could possibly
use Travis
deploy options http://docs.travis-ci.com/user/deployment/ to possibly
even just push to separate functional test repo to trigger a change and
thus mimic a chain? The functional test repo could then be configured to
run
headless xvfb session
http://docs.travis-ci.com/user/gui-and-headless-browsers/

Or alternatively if possible they could all be in one repo, using custom
deployment
tactics similar to this
<
http://hgc.io/2014/08/28/Continuous-deployment-to-Heroku-with-Travis-CI/>

—
Reply to this email directly or view it on GitHub
<
https://github.com/OpenMRS-Australia/openmrs-cpm/issues/105#issuecomment-60749300>

.

—
Reply to this email directly or view it on GitHub
#105 (comment)
.

[shangxiao]

Which reminds me:

Gil: If you're looking for something to do, we've always wanted to clean
up the entity code. An early developer set it up using inheritance and it
would be good to "flatten" it so there are no more base classes. It's
always been confusing to me and removing the inheritance will improve the
clarity.

What do you think Tim? Or should we just leave it?

On Fri, Oct 31, 2014 at 12:24 AM, David Sanders [email protected]
wrote:

That was because I'd set the review module to depend on the propose
module, before I understood how OpenMRS worked. I like the idea of forced
loose coupling to be honest - I actually use separate repos for
Django/Angular projects. They're mainly in the same repo originally for
convenience and because some DTO's and entity classes are shared; sharing
configuration was just extra benefit.

On Thu, Oct 30, 2014 at 5:55 PM, Adam Nowotny [email protected]
wrote:

The classpath issues suggested that the modules are not actually that
separate even though they should be.
After all they would likely be deployed separately and as far as I
understand they don't directly communicate with each other.
The fact that some configuration is common is not enough to justify this
coupling in my opinion.
Separating the modules is a good way to enforce loose coupling of these
modules.
I do not however have enough context to understand how much work would
that
actually involve.
Happy to discuss that, I am however in favour of keeping modules small
and
independent.

Adam Nowotny https://google.com/+AdamNowotny01/about
Software Developer at ThoughtWorks
mobile: +(61) 466 927 972

On 28 October 2014 23:46, Timothy Lim [email protected] wrote:

I believe it was Adam that floated the idea of splitting the code base
into 2 separate code bases to see if that would also help with the
classpath issues. But since we've reverted that, we've headed on to
fixing
other things.

With regards to Go, I've managed to get the functional tests running on
it, but the Travis pull request checking is great and we could possibly
use Travis
deploy options http://docs.travis-ci.com/user/deployment/ to
possibly
even just push to separate functional test repo to trigger a change and
thus mimic a chain? The functional test repo could then be configured
to run
headless xvfb session
http://docs.travis-ci.com/user/gui-and-headless-browsers/

Or alternatively if possible they could all be in one repo, using
custom deployment
tactics similar to this
<
http://hgc.io/2014/08/28/Continuous-deployment-to-Heroku-with-Travis-CI/>

—
Reply to this email directly or view it on GitHub
<
https://github.com/OpenMRS-Australia/openmrs-cpm/issues/105#issuecomment-60749300>

.

—
Reply to this email directly or view it on GitHub
#105 (comment)
.

[thewheat]

Yeah, that inheritance was a bit confusing to me too actually. I guess
there are always areas for more code refactoring, but I guess it comes down
to the current focus: to finish it off as a MVP or more code touch ups.

Some other areas of improvement off the top of my head

• Proper testing of the module communications: test with 2 different
  instances of OpenMRS and ensure that the communications work between the
  instances
• Finish up some functional tests
• Proposal functional tests can utilize query browser to populate data
  instead of relying on repeating tests to populate data
• Convert some $http.get calls in Angular to services maybe?
• Proposal module: Proposal status similar to how we have completed
  Incoming Proposals on the Review side, we could have something similar for
  completed proposals (see point 1 below)
• Some UX testing? (Case in point the "I created this concept" may need
  extra information asking the Dictionary Manager to create the new concept
  and then select it). Date when comments / status last refreshed?

I do have 2 questions though:

1. Should the proposer have a 'get proposal status' function to retrieve
   the latest status of the proposal? I.e. if it has been fully processed by
   the Dictionary Manager. If it has, the status on the proposal side can be
   changed from Submitted to Completed.
2. When reviewing proposals, the Dictionary Manager can link a concept to a
   concept in a proposal (via I created this concept / This concept already
   exists). Should to proposer get a link to/have some information about the
   concept that the Dictionary Manager has selected? Considering they are
   different installations, IDs and UUIDs can be different and thus may
   require extracting the necessary Concept info from the Dictionary Manager's
   OpenMRS instance.

Which reminds me:

Gil: If you're looking for something to do, we've always wanted to clean
up the entity code. An early developer set it up using inheritance and it
would be good to "flatten" it so there are no more base classes. It's
always been confusing to me and removing the inheritance will improve the
clarity.

What do you think Tim? Or should we just leave it?

On Fri, Oct 31, 2014 at 12:24 AM, David Sanders [email protected]
wrote:

That was because I'd set the review module to depend on the propose
module, before I understood how OpenMRS worked. I like the idea of forced
loose coupling to be honest - I actually use separate repos for
Django/Angular projects. They're mainly in the same repo originally for
convenience and because some DTO's and entity classes are shared; sharing
configuration was just extra benefit.

On Thu, Oct 30, 2014 at 5:55 PM, Adam Nowotny [email protected]
wrote:

The classpath issues suggested that the modules are not actually that
separate even though they should be.
After all they would likely be deployed separately and as far as I
understand they don't directly communicate with each other.
The fact that some configuration is common is not enough to justify this
coupling in my opinion.
Separating the modules is a good way to enforce loose coupling of these
modules.
I do not however have enough context to understand how much work would
that
actually involve.
Happy to discuss that, I am however in favour of keeping modules small
and
independent.

Adam Nowotny https://google.com/+AdamNowotny01/about
Software Developer at ThoughtWorks
mobile: +(61) 466 927 972

On 28 October 2014 23:46, Timothy Lim [email protected] wrote:

I believe it was Adam that floated the idea of splitting the code base
into 2 separate code bases to see if that would also help with the
classpath issues. But since we've reverted that, we've headed on to
fixing
other things.

With regards to Go, I've managed to get the functional tests running
on
it, but the Travis pull request checking is great and we could
possibly
use Travis
deploy options http://docs.travis-ci.com/user/deployment/ to
possibly
even just push to separate functional test repo to trigger a change
and
thus mimic a chain? The functional test repo could then be configured
to run
headless xvfb session
http://docs.travis-ci.com/user/gui-and-headless-browsers/

Or alternatively if possible they could all be in one repo, using
custom deployment
tactics similar to this
<
http://hgc.io/2014/08/28/Continuous-deployment-to-Heroku-with-Travis-CI/>

—
Reply to this email directly or view it on GitHub
<

https://github.com/OpenMRS-Australia/openmrs-cpm/issues/105#issuecomment-60749300>

.

—
Reply to this email directly or view it on GitHub
<
https://github.com/OpenMRS-Australia/openmrs-cpm/issues/105#issuecomment-61052264>

.

—
Reply to this email directly or view it on GitHub
#105 (comment)
.