Changes between Version 12 and Version 13 of Modules


Ignore:
Timestamp:
2011-01-31T10:26:07+01:00 (14 years ago)
Author:
jvelde
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Modules

    v12 v13  
    1 Status: this is under development for MOLGENIS 4.0
    2 Don't expect this if you use MOLGENIS 3.x!
     1= Modules =
     2
     3Status options?
     4
     5|| Planned || Scheduled to start work ||
     6|| W.I.P. || Currently under development ||
     7|| Prototype || One or more first implementations exists for review ||
     8|| Draft || Working towards final version, working demo ||
     9|| Finished || Module is done, but can undergo fixes or small changes ||
     10
     11List of modules
     12
     13|| Name || Description || Applications || Status || Screenshot ||
     14|| !StudyBook || Shows an overview of elements in a study, for example InvestigationElements, Data and Files. || XGAP, Pheno, NGS || Prototype || [ x ] ||
     15|| !MatrixViewer || Browse matrix data, allows twodimensional filtering, sorting and searching. || .. || || ||
     16|| || || || || ||
     17
     18Status: this is under development for MOLGENIS 4.0 Don't expect this if you use MOLGENIS 3.x!
    319
    420= Architectural overview =
     21MOLGENIS is organized as a set of modules which we call plugins. Each plugin adds a combination of
    522
    6 MOLGENIS is organized as a set of modules which we call plugins. Each plugin adds a combination of
    723 * MolgenisModels - models that use the domain specific language to define functionality compactly
    824 * MolgenisGenerators - templates that expand the models into working software
    9  * MolgenisComponents -
    10 and/or handwritten code. Other plugins may extend other plugins to yet add more functionality. The first plugin where all others build upon is the MOLGENIS database core. The last plugin is typically a fully functional application that assembles other plugins
     25 * MolgenisComponents -
     26
     27and/or handwritten code. Other plugins may extend other plugins to yet add more functionality. The first plugin where all others build upon is the MOLGENIS database core. The last plugin is typically a fully functional application that assembles other plugins
    1128
    1229TODO core architectural picture.
    … …  
    1734
    1835= Extension mechanism =
     36Each building block may add framework code, model extensions, generators and/or models.  In this last case the module may regeneration against the last versions before it can be used (which we can do automatically?). After that we could use a osgi drop in mechanism to add the produce funtionality into a running system.
    1937
    20 Each building block may add framework code, model extensions, generators and/or models.
    21 In this last case the module may regeneration against the last versions before it can be used (which we can do automatically?).
    22 After that we could use a osgi drop in mechanism to add the produce funtionality into a running system.
     38Design 0: simply link to projects In this procedure the model files are puth on classpath and can be simply imported. The code has to be generated by the imported projects themselves. This is ideal for development (as long as re-generation is a one push on a button event and checks if generators are changed (hash or something)).
    2339
    24 Design 0: simply link to projects
    25 In this procedure the model files are puth on classpath and can be simply imported.
    26 The code has to be generated by the imported projects themselves.
    27 This is ideal for development (as long as re-generation is a one push on a button event and checks if generators are changed (hash or something)).
     40Design 1: linking in code We imagine a procedure where when a user runs the generator (ant script, nothing else)
    2841
    29 Design 1: linking in code
    30 We imagine a procedure where when a user runs the generator (ant script, nothing else)
    31 - downloads the core molgenis and starts the model parser/generator
    32 - when <import="db" .../> is in your local model dependencies are automatically checked out from svn to /generated/java (incl libs!)
    33 - each of these dependencies is regenerated in dependency order
    34 - tests run to verify that the modules are sanitized (no compile errors, test cases work)
    35 - and then produced as osgi modules that are simply loaded by the current project during the rest of development
     42 * downloads the core molgenis and starts the model parser/generator
     43 * when <import="db" .../> is in your local model dependencies are automatically checked out from svn to /generated/java (incl libs!)
     44 * each of these dependencies is regenerated in dependency order
     45 * tests run to verify that the modules are sanitized (no compile errors, test cases work)
     46 * and then produced as osgi modules that are simply loaded by the current project during the rest of development
     47
    3648And have a 'clean' action to redo the procedure.
    3749
    38 Design 2: downloading maven/osgi modules.
    39 We imagine a procedure where when a user runs the generator from maven (maven pom + molgenis core as plugin, nothing else)
    40 - downloads all depedencies using maven model (all MOLGENIS settings should be in this model as well to keep it simple?)
    41 - add generate tasks to maven to get all stuff done
     50Design 2: downloading maven/osgi modules. We imagine a procedure where when a user runs the generator from maven (maven pom + molgenis core as plugin, nothing else)
     51
     52 * downloads all depedencies using maven model (all MOLGENIS settings should be in this model as well to keep it simple?)
     53 * add generate tasks to maven to get all stuff done
     54
    4255Complicating factor here is that the maven repos should be rebuild now and then.
    4356
    4457We could allow both design 1 and 2 in order to speed up development?
    4558
    46 i.e. organize maven compatible but still allow ant.xml type of interactions to do this low-tech.
    47 Or use maven in the back and don't necessarily bother the user with it.
     59i.e. organize maven compatible but still allow ant.xml type of interactions to do this low-tech. Or use maven in the back and don't necessarily bother the user with it.
    4860
    4961= Core modules =
    50 These are the foundational building blocks that can be reused between all MOLGENIS applications.
    51 Package org.molgenis.*
     62These are the foundational building blocks that can be reused between all MOLGENIS applications. Package org.molgenis.*
    5263
    5364Core:
    54  * [wiki:Plugins/OrgMolgenis core] - core platform of model (parsers), generators and util packages
     65
     66 * [wiki:Plugins/OrgMolgenis core] - core platform of model (parsers), generators and util packages
    5567 * [wiki:Plugins/OrgMolgenisDb db] - database interface framework on top of MySQL, PostgreSQL and HypersonicSQL (extends core)
    56  * [wiki:Plugins/OrgMolgenisExchange exchange] - file import/export mechanisms from and to csv, tab, excel, (xml), etc (extends db) 
     68 * [wiki:Plugins/OrgMolgenisExchange exchange] - file import/export mechanisms from and to csv, tab, excel, (xml), etc (extends db)
    5769 * [wiki:Plugins/OrgMolgenisApi api] - application programming interfaces to Java, R, REST, SOAP, RDF, etc on top of Db (extends exchange)
    58  * [wiki:Plugins/OrgMolgenisUi ui] - web user interface framework with forms, menus and plugins (extends api) 
     70 * [wiki:Plugins/OrgMolgenisUi ui] - web user interface framework with forms, menus and plugins (extends api)
    5971 * [wiki:Plugins/OrgMolgenisCompute compute] - compute interface framework for short, long and parallel running computations (extends ui?)
    6072
    61 Discussion:
    62 ui could be moved to depend on core only, and then have other packages extend on that to add particular UI components for db, compute, etc.
    63 Or have separate ui extensions like ui.db, ui.compute, etc.
     73Discussion:  ui could be moved to depend on core only, and then have other packages extend on that to add particular UI components for db, compute, etc. Or have separate ui extensions like ui.db, ui.compute, etc.
    6474
    65 = Components =
    66 These are the semi-finished building blocks that can be shared between different applications to reuse common work.
    67 These components typically provide data model (modules) that need to be generated before a plugin is ready to use.
    68 Hence, there is a need to regenerate on the first installation of the plugin.
    69 package org.molgenis.*
     75= Components =
     76These are the semi-finished building blocks that can be shared between different applications to reuse common work. These components typically provide data model (modules) that need to be generated before a plugin is ready to use. Hence, there is a need to regenerate on the first installation of the plugin. package org.molgenis.*
    7077
    7178Cross cutting:
     79
    7280 * [wiki:Component/OrgXgapAuth auth] - secure authentication and sharing framework (extends ui)
    7381 * [wiki:Component/OrgXgapVersionable versionable] - mechanism to have versioned data elements by simply extending an interface
    7482
    75 Discussion: need ability to weave this in later, like a special decorator that is applied everywhere?
    76 Or should we just make these core features and move it into db package?
     83Discussion: need ability to weave this in later, like a special decorator that is applied everywhere? Or should we just make these core features and move it into db package?
    7784
    7885Generic:
     86
    7987 * [wiki:Component/OrgXgapOnto molgenisdata.onto] - for using ontologies including tree based browser, search box (extends ui)
    8088 * [wiki:Component/OrgXgapMatrix molgenisdata.matrix] - for working with matrix like data having 'dimensionelements' and 'dataelements'
    81  * [wiki:Component/OrgXgapProtocol molgenisdata.protocol] - for track and tracing of materials/data, protocols, protocolapplications (compatible with MAGE-TAB SDRF) 
     89 * [wiki:Component/OrgXgapProtocol molgenisdata.protocol] - for track and tracing of materials/data, protocols, protocolapplications (compatible with MAGE-TAB SDRF)
    8290 * [wiki:Component/OrgXgapTool tool] - for integrating R scripts onto the application (extends protocol, compute)
    8391 * [wiki:Component/OrgXgapMaterialTracker tool] - for integrating R scripts onto the application (extends protocol)
    8492
    8593Domain:
     94
    8695 * [wiki:Component/OrgXgapLocus locus] - tools for managing and browsing genomic sequence annotations
    8796 * [wiki:Component/OrgXgapPheno pheno] - for representing deep phenotypic data collected in clinics and the field (extends onto, tracker, matrix)
    … …  
    9099More ideas: pedigree, comments
    91100
    92 
    93101= Applications =
    94102Systems are ready to use and download. Ideally end users would be able to choose from these online.
    95103
    96104 * [wiki:Apps/PhenoTrackerMolgenis PhenoTracker] - for storing phenotypics annotations on individuals and panels
    97  * [wiki:Apps/GwasMolgenis GwasPlatform] - for GWAS studies like in EU-GEN2PHN, LifeLines and BBMRI-NL 
     105 * [wiki:Apps/GwasMolgenis GwasPlatform] - for GWAS studies like in EU-GEN2PHN, LifeLines and BBMRI-NL
    98106 * [wiki:Apps/QtlMolgenis QtlPlatform] - for QTL studies in model organisms like EU-Panacea
    99107 * [wiki:Apps/MutationMolgenis MutationTracker] - for locus specific annotations (extends pheno, muta)
    … …  
    101109 *
    102110
    103 
    104111= Ideas for more enhancements =
    105 
    106112== Core ==
    107113 * [wiki:Plugins/OrgMolgenisUi/Theme ui.theme] - catalog of UI web themes for MOLGENIS applications the use can choose from (extends ui)