airavata-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [1/3] airavata-sandbox git commit: Added Readme file which explains the design changes which were made
Date Fri, 28 Oct 2016 14:51:05 GMT
Repository: airavata-sandbox
Updated Branches:
  refs/heads/master 39613cd5a -> cc4fcf050

Added Readme file which explains the design changes which were made


Branch: refs/heads/master
Commit: cc4fcf050d46707cd68aafcc521aac9d75146196
Parents: 1932e86
Author: Abhishek Jain <>
Authored: Thu Oct 27 18:00:30 2016 -0400
Committer: Suresh Marru <>
Committed: Fri Oct 28 10:50:48 2016 -0400

 gsoc2016/Design Changes in Airavata/ | 36 ++++++++++++++++++++++
 1 file changed, 36 insertions(+)
---------------------------------------------------------------------- Changes
in Airavata/
diff --git a/gsoc2016/Design Changes in Airavata/ b/gsoc2016/Design Changes in Airavata/
new file mode 100644
index 0000000..d6e5857
--- /dev/null
+++ b/gsoc2016/Design Changes in Airavata/	
@@ -0,0 +1,36 @@
+# Re-Factoring Aurora Marathon Integration Module and gfac-orchestrator core files to incorporate
design changes.
+* Apache style packaging : Organized the AuroraMarathonIntegration code to follow the Apache
+* Maven integration : Integrated Maven with the module as Airavata is build using Maven.
+* Dependency injection pattern
+  * Dependency Injection makes it simple for to manage dependencies between objects. In turn,
that makes it easier to break coherent functionality off into it's own     contract (interface).
As a result, the code has been far more modularized.
+  * Another result of this is that I can much more easily see my way through to a design
that supports the Open-Closed Principle.[software entities (classes, modules, functions, etc.)
should be open for extension, but closed for modification]. This is one of the most confidence
inspiring techniques (second only to automated testing).
+  * Major advantage : Two important ones are the ability to control functionality from a
central place (the Main() function) instead of spreading it throughout your program, and the
ability to more easily test each class in isolation (because you can pass mocks or other faked
objects into its constructor instead of a real value).
+* Extract out the redundant code and create utilities.
+* Kept updating code and made the above design changes to be in sync with his changes.
+* Path to file : orchestrator/orchestrator-core/src/main/java/org/apache/airavata/orchestrator/core/utils/
+  * Change the class containing constants to enums.
+  * Type safety
+  * You get free compile time checking of valid values.
+      * Catches typos
+* Path to file : orchestrator/orchestrator-core/src/main/java/org/apache/airavata/orchestrator/core/utils/
+  * Use enums instead of directly accessing the static final constants. [Changed the usage]
+* Path to file : /orchestrator/orchestrator-core/src/main/java/org/apache/airavata/orchestrator/cpi/impl/
+  * Captured in a multiple catch block, instead of 3 different catch clauses.
+  * In some functions, the function argument and the instance variable have the same name.
This may create ambiguity. Hence the function arguments names were changed to remove the ambiguity.
The following are the functions in which had this issue :
+* Path to file : airavata/modules/orchestrator/orchestrator-core/src/main/java/org/apache/airavata/orchestrator/core/OrchestratorConfiguration.jav
+* Path to files :
+  * gfac/gfac-core/src/main/java/org/apache/airavata/gfac/core/authentication/
+  * gfac/gfac-core/src/main/java/org/apache/airavata/gfac/core/authentication/
+  * gfac/gfac-core/src/main/java/org/apache/airavata/gfac/core/authentication/

View raw message