Yes, the assumption is correct. The registry itself is not created until
the RegistryDefinition
is passed to the RegistryBuilder.
Achim
Johan Lindquist schrieb:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Sounds good to me too.
Is there is enough "events" coming out of the Registry defintions to
connect the doxia APIs to?
Is it correct to assume that by using the registry definition, a
registry is not created, but simply a structure holding all modules etc?
Thanks,
Johan
[EMAIL PROTECTED] wrote:
Sounds good:
- I think, I'd rather leave out the xml-generation/xslt part and use maven's
doxia-API directly. The advantage of this is, that the project's site-skin is
used automatically.
- Classpath access from maven should be no problem.
- Contributions from annotated modules will be problematic since I don't think
building the registry is an option at compile-time (thinking of eager-load
services trying to connect to resources). Maybe, it's possible to just link to
the Javadoc of methods annotated with @Contribution .
-----Original Message-----
From: Achim Hügen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 11, 2007 9:30 PM
To: [EMAIL PROTECTED]
Subject: Re: HiveMind Site
Here is my plan:
All XML files and the annotated modules are parsed by the
hivemind libs.
This can be executed by calling
RegistryBuilder#autoDetectModules or by manually loading the
modules like this:
RegistryDefinition registryDefinition = new RegistryDefinition();
XmlModuleReader reader = new XmlModuleReader(registryDefinition);
reader.readClassPathModule("META-INF/hivemodule.xml");
reader.readClassPathModule("foo/hivemodule2.xml");
AnnotatedModuleReader reader = new
AnnotatedModuleReader(registryDefinition);
reader.readModules("**/*Module.class");
The resulting RegistryDefinition can be used to iterate over
all module definitions, its extension points and extensions.
(see
http://hivemind.apache.org/hivemind2/hivemind-framework/apidoc
s/org/apache/hivemind/definition/package-frame.html)
By iterating over the definitions a DOM tree gets created
(like RegistrySerializer does today) and serialized. The
resulting XML file does not conform to the hivemind module
deployment descriptor schema.
Finally a stylesheet transformation is applied on it to generate HTML.
Sounds straightforward but there are some catches:
* The core framework doesn't know anything about xml.
As a consequence, the ServicePointDefinition for example
doesn't have a schema property (for service factories). But
the information can be acquired by casting a service point
definition from a xml module to
XmlServicePointDefinitionImpl, which gives access to the
schema. So the plugin must be aware of the different
definition types. In case of configuration points there is an
additional layer of indirection in form of ConfigurationParsers.
* configurations can be of any type and they needn't have an
associated schema.
Question is, how do you represent contributions which are not
backed by xml?
In the case of annotated modules it's not even possible to
access the contributed data without constructing the registry.
* To read the annotated modules with AnnotatedModuleReader
the module classes must be loaded. So the classpath must
contain all referenced classes.
Whereas a maven plugin has access to the classpath which was
used for compilation and is considered to be complete, hasn't it?
Achim
Am Tue, 10 Apr 2007 14:50:09 +0200 schrieb <[EMAIL PROTECTED]>:
Hi Johan,
I think, I used the Apache License - so no problem here.
However, I have to blushingly admit, that the hivedoc
plugin is quite
a quick hack. So don't expect any clean abstraction from the
xml-Registry-Definition.
On the positive side, the code is short and straightforward, so it
shouldn't be really difficult to pull apart the xml-parsing and the
output-generation.
Unfortunately, I've not yet had the time to look into the new API.
Basically, one probably needs to search the source-files for
HiveMind-2.0 annotations.
This annotation-parsing thing should be common for validator and
hivedoc mojos. The simplest thing might be to generate the good old
xml-registry as a temporary file from the annotations and use it as
input for both tools.
Marcus
-----Original Message-----
From: Johan Lindquist [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 10, 2007 9:04 AM
To: [EMAIL PROTECTED]
Subject: Re: HiveMind Site
Hi,
For the verifier mojo, there are no issues - not sure about the
HiveDoc one - Marcus?
And yes, HiveMind 2.0 integration should be considered.
verifier should definately be possibly to re-use for XML
descriptors
but it needs to be retrofitted to handle annotated
registries. For
HiveDoc, I would assume the same thing applies?
Johan
Achim Hügen wrote:
It would be great to add that plugin to the hivemind subversion
repository as an additional module.
Does any licensing issues or copyright speak against it?
BTW, we will have to check how such plugins can be
integrated with the
HiveMind 2 registry definition API.
Achim
Am Thu, 05 Apr 2007 10:09:17 +0200 schrieb Johan Lindquist
<[EMAIL PROTECTED]>:
Hi,
Ok, I will take a look - and file the JIRA.
About the plugin - basically there are two mojos that were
mentioned
on the list - a hivedoc report plugin (written by Marcus
Schulte) and
a hivemodule.xml verifier plugin (started by myself).
The thoughts
were to create one single hivemind plugin with these two
sub-goals (if
that is the correct wording). Then of course, any other
sub-goals
that come along would slot in quite nicely as well. Makes sense?
Cheers,
Johan
Achim Hügen wrote:
Your changes are very welcome.
Please use JIRA for submitting the patches.
Maybe the IE bug has already been fixed on the tapestry
site where
I copied the styles from.
Could you give me a short update on the plugin subject?
Did you create the plugins or who is the owner?
Achim
Am Tue, 03 Apr 2007 09:42:24 +0200 schrieb Johan Lindquist
<[EMAIL PROTECTED]>:
Hi Achim,
I think misunderstood the problem with the pom -
thought it was
related to the "root" source repository location as
indicated by
the project info on the homepage. Apologies for my
hasty conclusions.
In any case, I think we all agree that the site should
be updated
and I understand fully if time prevents this . And as far as
committers go, I guess James is only one still active?
On a different note - looks like the site doesn't
work entirely
correct on IE (at least for me, the left nav is not
visible in IE -
firefox works fine) - do you mind if I make one or two
changes to
the hivemind site project to correct this? Would you
want another
JIRA for this to keep track?
And lastly, was also hoping to incorpororate the
Maven Hivemind
plugins previously mentioned - module verification and
hivedoc. Thoughts?
Cheers,
Johan
Achim Hügen wrote:
Johan, the bug refered to the HiveMind 2 poms and
I fixed it.
Nevertheless it would be nice if someone could apply
the patches
to the 1.2 site and release it.
Unfortunately my time is limited and I focus on
version 2.0 in
the moment.
Anybody else?
Achim
Am Mon, 02 Apr 2007 09:17:01 +0200 schrieb Johan Lindquist
<[EMAIL PROTECTED]>:
Hi All,
Over the weekend there was a JIRA opened for the
SVN links on
the HiveMind site. Looks like the current project
info (as
generated by
Maven) uses the site scm URL (someone correct me if I
am wrong)?
Now, to make sure that users don't get confused can I
suggest we
try to get the updated site up for Hivemind? The
patch already
supplied will provide the new look and feel and
other updates
that the maven build brings. The 2.0 site should
of course
still be there but I guess it depends somewhat on how
complete the documentation is
- Achim? If
there is some work required to complete it,
anything someone
else can pick up?
In any case, we should try to clean up the site
and make sure
links (such as the SCM) works correctly.
Only my two cents worth, but we don't want to confuse
the users
further by having the (so far very good)
documentation fall
apart on us.
Thoughts?
Cheers,
Johan
- --
you too?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGHgsR1Tv8wj7aQ34RAvs4AJ42Bx5qLF872Gnkof4JJrf0w47+aQCcC9X7
qd20wFfrVI2lrB3rK1vkyhY=
=rcA4
-----END PGP SIGNATURE-----
