Dan Allen wrote:
Should we qualify the term modules? Meaning instead of modules and
sandbox we have something like
modules
sandbox-modules
thirdparty-modules
Modules (I'm open to a qualifier like official-modules) would be
official modules in Seam...stuff that is going into EAP. sandbox
would be modules we want to put into core, but they just aren't
ready yet or may never be. thirdparty would be modules we are
hosting for a community member but we don't want to maintain. For
instance, perhaps the host the tapastry integration module or
whatever. I'd be interested in doing that with examples too.
examples
sandbox-examples
thirdparty-examples
Thoughts? This should be easy to add without affecting what you
have setup already.
Any thoughts on this yet?
I don't think it's necessary to split up the modules into
official/unofficial - the modules that are included in EAP are up to the
productization team, and IMHO something we shouldn't care about in the
community version. Sandbox is exactly as you described it. I also
don't see a need for differentiation between thirdparty and "in house"
modules - we already have lots of Seam features that are maintained by
community members. If we make the judgment that something is
polished/stable enough to leave the sandbox, then it just becomes a
module like everything else. We can easily give the community member
SVN commit access for their own module.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://in.relation.to/Bloggers/Dan
NOTE: While I make a strong effort to keep up with my email on a daily
basis, personal or other work matters can sometimes keep me away
from my email. If you contact me, but don't hear back for more than a
week,
it is very likely that I am excessively backlogged or the message was
caught in the spam filters. Please don't hesitate to resend a message if
you feel that it did not reach my attention.