Oliver Kiessler wrote:
sure. i'd rather not duplicate effort :) and i'd rather not maintain
such a tool for the long run, as i don't have a large development
community and want to concentrate on my main project.
my tool is *extremely* simple. i hadn't considered the dependencies
described in the jira issue, mainly because i haven't encountered them
in the node types i'm registering.
my requirements are 1) that i can run the tool from maven or the command
line so that i can create and populate the repository for my server when
building a distribution of the server and 2) that using the tool does
not force me to use the rest of your mapping layer.
while i'm definitely interested in the mapping layer, my jcr needs right
now are extremely simple, and i'd rather keep my small amount of jcr
client code than track another evolving, pre-alpha api - it's hard
enough keeping up with jackrabbit :) when your mapping stuff is farther
along, tho, i will definitely look to use it.
so what are your plans for node type registration? i noticed that you've
defined an interface but have no implementation yet.
The current plans are to have an xml file with java beans to jcr node
type mappings which is being read with jaxb for example. The java bean
objects being mapped will be "graffito content objects" but it should
very easy to handle this very flexible to allow a mapping of any java
bean type.
Graffito committer Sandro Böhme is currently working on GRFT-23 so I
don't know all the details. But in my mind there will be a central Jcr
Session class which has a setupRepository method to register
namespaces and custom node types at repository creation time. Custom
node types are created by a CustomNodeTypeCreator implementation which
Sandro is working on (nothing committed yet). This
CustomNodeTypeCreator will also have a method to add custom node types
at any time later on. So the CustomNodeTypeCreator can probably be
used from the command line or maven... graffito jcr-mapping totally is
an API for CMS applications, content based applications, portals and
so on and is not GUI based.
regards,
oliver
As it looks like my previous mail did not reach the list, here is my
comment again:
Personally I would say, our registration component registers only node
types that are mapped to java classes and it is not a general purpose
node type registration component.
But of course if it makes sense, we could discuss how to implement it.
Regards,
Sandro
