[forge-dev] packaging of plugins for Forge

Lincoln Baxter lbaxter at redhat.com
Wed Jan 5 11:35:45 EST 2011


Addressing to https://lists.jboss.org/mailman/listinfo/forge-dev

Rodney, good questions.

My current state of thinking:

1) Yes, there will be a core set of Forge plugins, these currently reside in shell/org.jboss.seam.forge.shell.plugins.builtin

2) list-commands :) documentation is not really up-to-par at the moment, since attempting to do so would probably be futile for a while longer as things shift (they are settling down.) But if you are referring to more than just the shell API commands, then we haven't really decided what will be "core" or not yet. I feel like a set of Java EE core plugins would be a good start, which is what I've got going on right now in the "j2ee-plugins" module. A plugin for each of the major specs, and corresponding Facets to allow plugin-authors to extend/enhance. For instance, the CDIFacet can manipulate beans.xml, and would probably be used by the "SeamConfigFacet", in turn being used by SeamConfigPlugin itself. Is that what you were thinking or am I off in the woods? :)

3) This is the tricky part - I am very tempted to say that we should simply delegate to the maven repository system, and use Aether. This would let us do a few things:

* Add/edit active repositories (Forge would come standard with a plugin-repository management system, of course.) Each active repository would be scanned, just like Maven scans, when Forge boots - however, we would probably need to require folks to bundle additional metadata, or a file in META-INF in order to make scanning possible (unless we go purely on JAR file name)

* Search active repositories for a new plugin (Forge would probably need to pull down the artifact and attempt to verify if it were indeed a plugin or facet.) Perhaps it would be useful to come up with a Forge-specific name for this type of JAR, containing either Plugins, Facets, or both. A "Skill" perhaps. Get a "Skill"? Meh, needs brainstorming for sure. It's possible we could simply require a certain packaging type in Maven, and that would be enough, more research needed here.

4) Scriptlet-plugins: Mike is working on the ability to Script a plugin, and would allow hot-swapping of scriptlets. This would be the preferred way of generating plugins for casual developers, for sure, since it would allow rapid turnaround and still enable all the core functionality of a bundled Plugin. You could even provide them access to Aether and let them have Forge pull in any deps they need automatically, based on the Scriptlet metadata.

--
Lincoln Baxter, III
JBoss, by Red Hat
lbaxter at redhat.com

"If you want something, you'll find a way; if you don't, you'll find an excuse."

----- Original Message -----
From: "Rodney Russ" <rruss at redhat.com>
To: "Lincoln Baxter" <lbaxter at redhat.com>
Cc: "Mike Brock" <cbrock at redhat.com>
Sent: Wednesday, January 5, 2011 10:45:30 AM
Subject: packaging of plugins for Forge

Lincoln,

I was thinking a little about how Forge will be "packaged".  Forge provides the infrastructure for creating project plugins.  But I have a couple of questions about the plugins themselves.

1) Will there be a "core" set of plugins that ship with Forge that create the base for other plugin developers.
2) If so, what are those core plugins (maybe this is on the site)?
3) What do we do with plugins that are created?  (e.g. are they included as the distribution, as a separate jar, other?)

Mostly curious at this point. :)


-Rodney


More information about the forge-dev mailing list