Archive for the ‘Development Tools’ Category

Oracle/Fatwire CSDT (Content Server Developer Tools) : Part 2

Monday, November 14th, 2011

Content Server Developer Tools are the latest and the first ever supported tools from Oracle (Fatwire) which provides plugin to eclipse and command line utility to help manage Fatwire artefacts in a file system. Once the artefacts are in file system, it opens a whole new doors to managing them. I covered about CSDT in my previous post and this is extention to the original post.

CSDT has been designed keeping in my the new development as the priority with not much thought around the projects upgrading to CS 761. But in my view the focus should have been other way around as there will be lot more upgrades than new implementations as the initial use case for CSDT.

    If you are planning to use CSDT across developers setup, here are some pointers to be aware:

  • CSDT V1 has a limitation that it expects the work space name to be cs_workspace at the location /export/envision. So, one option to make csdt work is to create a project with the same name at expected location.
  • CSDT expects the same folder structure within workspace, src/_metadata and src/jsp. So it is important that if you are trying to manage CSDT export within CVS, setup the same project structure
  • When you have all the artefacts you want to manage within CVS, make sure everyone sync their local instances with the CVS export so that everyone are at the same code level before starting any development
  • Word ‘Exception’ causes CSDT import to fail. Make sure that during development, do not specify name/ description fields with it. Or use Excaption :)
    If you are upgrading to CS761, there are number of issues which you need to be aware of:

  • Fw_uids need to be same across all the upgraded environments otherwise csdt deployments will fail
  • As part of best practice, if you have extracted element as cselement to make code go through the publishing process, make sure that all such dependencies are changed manually in Meta information. (.main.XML) file else the import will fail
    General CSDT issues:

  • Workflows can not be exported and imported through CSDT so there is need to either mirror to server the workflows or use catalog mover to move them
  • Categories can not be exported using CSDT
  • If Treetabs or start menus or any other artefact is enabled for any site, it is not exported out when we export artefacts for specific site, though they are part of the at site
  • modified date command line parameter doesn’t work as expected
  • Not applicable for no asset tables. A classic example is usage of SystemLocateString.
  • Incremental deployments are tough to achieve and its more manual work to arrive at the dependency set. Full deployment is the easiest way to achieve code drop.
  • CSDT doesn’t check if the asset has actually modified and updates all the assets which are part of workspace. So, if you carry out full deployment everytime, one drawback is that it will invalidate whole of the cache.
  • Etc..etc.

Even though there are number of issues with the current version of CSDT, it is a good to start using it as it will provide a platform which is going to improve over time. And hopefully version 2 of CSDT is not far which will definitely address some of the above issues, it not all.

Happy CSDTing !

Fatwire’s CS 7.6: Content Server Developer Tools (CSDT): review

Monday, June 13th, 2011

Fatwire recently released 7.6 version of the product with one of the interesting addition is CSDT (Content Server Developers Tool). Accoridng to Fatwire,

CSDT enables developers to work in a distributed environment using tools such as the Eclipse Integrated Development Environment (IDE) and version control system (VCS) integration. CSDT does not interfere or integrate with other development models. Using CSDT, a development team can manage Content Server resources and exchange those resources with other members of the team

One of the important factor which comes along with CSDT is file system representtion of CS repository. What CSDT does is convert the native CS asset representation to .mail.xml files and vice-versa.
This enable developers to work either in CS or in eclipse. Once the resources are in filesystem, its much easy from management and deployment point of view.

Positives

  • Easy to setup and get started
  • Finally a development tool to make developers life easy with more controlled release and code management
  • Develop JSP elements with standard Eclipse features such as tag completion, syntax highlighting, debugging, and so on
  • Command line utility to export, import ,list both CS and workspace artefacts
  • Manage most of the CS work from within eclipse, including log level changes, access to log files etc.

After playing a bit with the development tool, here are my findings around CSDT OOTB usage:

  • While exporting/importing data from CS using command line utility, there is no way to specify absolute path for datastore. It is always relative to export/envision within CS directory
  • CSDT import requires workspace to be present on the server before running the script within export/envision. There is no way to specify remote workspace/zip file, though you can start the process remotely
  • Incremental builds, for example, only changed files from CVS, can’t be achieved using import command line utility as the utility looks for all the dependency files to be present in workspace even though they have not changed
  • “modifiedSince” option on command line only works for Assets and not for other Fatwire artefacts
  • Logging available is limited
  • Listing commands (listds, lisrcs) doesn’t check for dependency
  • There is no option to see if the existing artefacts within a workspace meets all the dependecy checks before importing in an environment, though when you run import it log errors of not locating the dependent files
  • There is no support to export/import workflow artefacts from CS and vice-versa
  • There is no option available to export users association to sites

So, typical steps for moving a new site from one CS instance to other includes:

  1. Export/check-out from CVS @SITE, @ROLE, @ASSET_TYPE, @TREETAB, @STARTMENU, @ELEMENTCATALOG, @SITECATALOG, @ALL_ASSETS for a site
  2. Import all the exported artefacts in a specific order with @SITE first and maintaining all dependencies
  3. Manually setup workflow in the new environment (assuming there is no connectivity between the instances)
  4. Manually configure users to site association

And Bingo, new CS instance is up and running with the latest managed code.