[Middlegen-user] Change proposal: plugins configuration

[Marco Papini]

Hi everybody !

That's my proposal: move from MiddlegenTask the plugin configuration and
use a property file instead. The static block in MiddlegenTask will be
something like:

static {
ResourceBundle rb =
ResourceBundle.getBundle("middlegen/plugins/entitybean/middlegen-plugins");
Enumeration enum = rb.getKeys();
while (enum.hasMoreElements()) {
String pluginName = (String)enum.nextElement();
_plugins.setProperty(pluginName, rb.getString(pluginName));
}
}

And, of course, a property file named middlegen-plugins is needed, with
all the tag/class couples.

Greetings

Marco Papini
Italy

[a***@netcom.no]

Yup, that's nicer than the ugly hardcoding, but it's a bit ugly IMHO.
The nicest would be to include a deployment descriptor in each plugin
jar. That would make the plugins really pluggable. This is currently
being done for XDoclet's new module/plugin structure, and I'll borrow
the same code for Middlegen.

[Marco Papini]

Until I get time for this, I'll throw in your patch.

Thanks,
Aslak

----- Original Message -----
From: Marco Papini <***@cinetica.it>
Date: Friday, May 3, 2002 11:00 am
Subject: [Middlegen-user] Change proposal: plugins configuration

Post by Marco Papini
Hi everybody !
That's my proposal: move from MiddlegenTask the plugin
configuration and
use a property file instead. The static block in MiddlegenTask
will be
static {
ResourceBundle rb =
ResourceBundle.getBundle("middlegen/plugins/entitybean/middlegen-
plugins"); Enumeration enum = rb.getKeys();
while (enum.hasMoreElements()) {
String pluginName =
(String)enum.nextElement();
_plugins.setProperty(pluginName, rb.getString(pluginName));
}
}
And, of course, a property file named middlegen-plugins is needed,
withall the tag/class couples.
Greetings
Marco Papini
Italy
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors.
We supply
middlegen-user mailing list
https://lists.sourceforge.net/lists/listinfo/middlegen-user

[a***@netcom.no]

Hi Marco
(cc'ed to middlegen-devel, since this isn't top secret stuff)

----- Original Message -----
From: Marco Papini <***@cinetica.it>
Date: Friday, May 3, 2002 1:16 pm
Subject: Re: [Middlegen-user] Change proposal: plugins configuration

I think you're right. Do you have any idea on how those plugin jar
should be built ? Which files in it, what's in the descriptor and

It's taken care of by middlegen/build.xml. Read
middlegen/plugins/readme.txt (in CVS of course)

As for the deployment descriptor, The same build script will build
these (using xdoclet and looking for @middlegen:plugin tags in Plugin
classes)

The result will be something like:
<plugin name="papini" class="it.mafioso.PapiniPlugin"/>
, and it will go into META-INF of each plugin jar


Middlegen will introspect all jars in the same directory as itself upon
startup, and read these deploymentdescriptors. Then it'll register them
on the MiddlegenTask, so that you can have
<middlegen ...>
<papini...>

(This uses the new DynamicConfigurator feature in Ant 1.5 alpha which
is available from CVS, and is shipped in Middlegen's CVS)

so on
? Where can I find some directives on it ?

If you're *really* curious, take a look at the xdoclet.loader package
in XDoclet's MODULE_REFACTORING_BRANCH branch on CVS. It'll basically
work in the same way in MG. If you can wait a week or two, you'll see
it in Middlegen too.

Cheers,
Aslak

Marco

Post by a***@netcom.no
Yup, that's nicer than the ugly hardcoding, but it's a bit ugly

IMHO.

Post by a***@netcom.no
The nicest would be to include a deployment descriptor in each

plugin

Post by a***@netcom.no
jar. That would make the plugins really pluggable. This is

currently

Post by a***@netcom.no
being done for XDoclet's new module/plugin structure, and I'll

borrow

Post by a***@netcom.no
the same code for Middlegen.