10:35 a.m.
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(a)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(a)redhat.com>
To: "Lincoln Baxter" <lbaxter(a)redhat.com>
Cc: "Mike Brock" <cbrock(a)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