Difference between revisions of "ESciDoc Development environment"

From MPDLMediaWiki
Jump to navigation Jump to search
 
Line 78: Line 78:
* Define a release process ( how is versioning done( major, minor version number)? tag label strategy etc.  )
* Define a release process ( how is versioning done( major, minor version number)? tag label strategy etc.  )


[[Category:eSciDoc|Development environment]]
 
[[Category:eSciDoc-Team|Development environment]]
[[Category:ESciDoc_Developer|Environment ]]

Latest revision as of 15:14, 10 September 2009

Subversion repository[edit]

Currently the developers are using multiple subversion repositorys for each of the components of the escidoc project. Since there are dependencys between these repositorys, the usage of a single one shall be investigated.

An alternative: Tie together multiple repositories using svn:externals.

Advantages:

  • Imported repositorys can be secured by a common version tag.

Disadvantages:

  • More overhead


Some ideas why using one repository instead of multiple ones:
  • Easier to checkout the whole escidoc-project
  • External libraries can be checked in the repository. This ensures that every developer uses the same library and application server versions
  • build, dist and lib paths can be made relative, instead of using local_build.property files

Directory structure inside the single repository:


/escidoc
     /dev
         /src
              /citationmanager_service
                   /bin
                   /src
                   /resource
                   .
                   .
                   .
              .
              .
              .
         /build
         /dist
         /lib
         /ext
               /jboss
     /doc

Further ideas of improving the environment[edit]

  • At the moment the whole pubman module is compiled and deployed from the pubman_presentation component. It might be better if

there's a further component pubman, which includes the necessary components and is responsible for building and deploying the whole module.

             pubman     
           /          \
          /            \
pubman_presentation   pubman_logic    ....
  • Also it might be interesting to have an ant-buildfile at top level. Which means that a single build-file can, e.g. run all unittests or

create the complete javadoc application in one command call. With this buildfile nightly builds, automatic unittests etc. would be easily to maintain.


Restructuring of the code repositories and build environment[edit]

The following layout shows how the respoitorys will be changed in future. There shall be one common_repository server and several application repository servers. Working copies of application repositories pull the common repository via a <svn:externals> declaration, which means that the dependent modules are automatically retrieved from the common repository. With this technique the user only has to check out the application repository.


Repos.png


Tasks for this environment changing process are:

  • Kickoff the ReleaseManager from SMC
  • Restructure Repositories (see above)
  • Create ant-scripts for building and testing processes
  • Define a publishing process to www.escidoc-project.de ( ant-script ?? )
  • Provide a method to publish the nightly test runs (simple approach, e.g. textfile on webserver)
  • Define a release process ( how is versioning done( major, minor version number)? tag label strategy etc. )