Running Cernunnos XML in the CRN_HOME\bin directory
Andrew Wills
Over the weekend I worked on an enhancement for the cernunnos-cmd-tool
(the command line client): the ability to resolve the path of a
Cernunnos XML document within the Cernunnos bin/ directory.
Normally you can invoke a script using a relative path (like this):
>crn test.crn
an absolute path (like this):
>crn \Users\awills\danann\cernunnos\test.crn
or even a URL (like this):
>crn http://cernunnos.googlecode.com/svn/etc/WebProject/create-web-project.crn
But it seems to me there are some commonly-used operations that I'd
like to be able to invoke from anywhere, without having to dig up the
full path. There are some cernunnos-specific operations, moreover,
that I'd like to be able to check into SVN and version with the source
code. A good example is the grammardoc.crn file, which actually is
checked in and versioned with the source already. It might be nice to
be able to re-build the Manual (by invoking grammardoc.crn) from
anywhere, without knowing the full path of that resource.
Another good example -- probably a better one -- of the sort of thing
I'm thinking of is discussed in this article from over a year ago:
http://www.unicon.net/node/822, which was later revised and updated in
this discussion:
http://groups.google.com/group/cernunnos-discussion/browse_thread/thread/7c798244ee86c0c9
It would be better to provide these capabilities within the tool
itself; that approach would make it easier for these operations to
evolve and grow with the capabilities of the platform, without having
to force users to update to the latest-and-greatest version of CRN to
use them. It would also make these tools easier to use offline.
On that note, I recently refactored the 'create-web-project.crn' tool
as a Maven Archetype. It seemed more suitable to support that
capability -- auto-generating a new Maven 'war' project that's
pre-configured for Cernunnos -- using m2's baked-in approach.
Creating the project makes sense as an archetype, but adding servlets,
portlets, and user attributes (for portlets) dynamically doesn't work
as well. Based on my research, it seems the Maven Archetypes feature
isn't really good at creating new projects by layering archetypes
where multiple archetypes need to alter the same file (e.g. web.xml,
portlet.xml). These operations can continue to be supported by
Cernunnos scripts; and if we put those scripts in the bin/ directory,
we can version them with the platform and easily invoke them anywhere.
drew wills
Drew Wills
Last night I wrapped up some work in this area. I just committed 3
issues related to this topic:
- Issue #76 (http://code.google.com/p/cernunnos/issues/detail?
id=76): Enhance the shell tool to run Cernunnos XML in the CRN_HOME
\bin directory from anywhere
- Issue #77 (http://code.google.com/p/cernunnos/issues/detail?
id=77): Provide baked-in Cernunnos XML for defining Servlets,
Portlets, and Portlet User Attributes
- Issue #78 (http://code.google.com/p/cernunnos/issues/detail?
id=78): Provide a Maven archetype for creating a webapp project with
pre-configured Cernunnos dependency
There is a nifty new Manual page -- Cernunnos & Maven -- that
documents using these capabilities.
drew wills
On Feb 16, 10:30 am, Andrew Wills <wills.d...@gmail.com> wrote:
> Hey folks,
>
> Over the weekend I worked on an enhancement for the cernunnos-cmd-tool
> (the command line client): the ability to resolve the path of a
> Cernunnos XML document within the Cernunnos bin/ directory.
>
> Normally you can invoke a script using a relative path (like this):
>
> >crn test.crn
>
> an absolute path (like this):
>
> >crn \Users\awills\danann\cernunnos\test.crn
>
> or even a URL (like this):
>
> But it seems to me there are some commonly-used operations that I'd
> like to be able to invoke from anywhere, without having to dig up the
> full path. There are some cernunnos-specific operations, moreover,
> that I'd like to be able to check into SVN and version with the source
> code. A good example is the grammardoc.crn file, which actually is
> checked in and versioned with the source already. It might be nice to
> be able to re-build the Manual (by invoking grammardoc.crn) from
> anywhere, without knowing the full path of that resource.
>
> Another good example -- probably a better one -- of the sort of thing
> I'm thinking of is discussed in this article from over a year ago:http://www.unicon.net/node/822, which was later revised and updated in