Seam 3 space on JBoss Community
by Dan Allen
Two forces are converging that cause us to rethink where we are hosting Seam
3 project documentation and discussions. I'll enunciate those forces and
propose a solution that Lincoln and I have devised.
Seam 3 is a very different beast than Seam 2. In some ways, I liken it to
the relationship between Maven 2 and Maven 1. Both the Maven projects are
build tools that are founded on the same principle, a software project
management and comprehension tool that leverages an extensive ecosystem of
plugins that tie into a unified build lifecycle. But Maven 2 is built on a
different foundation than Maven 1, making them, in the end, very different
solutions.
Seam 3 relinquishes the context and dependency management and event
notification responsibility to CDI, something that evolved out of the Seam 2
core. Seam 3 is also focused on extensibility punctuated by container
portability. While you can expect similar convenient APIs and integrations
in Seam 3, and a bridge module that allows you to use or emulate Seam 2
components, pragmatically speaking, it's new project that is going to be
organized and governed very differently.
Having established that Seam 3 differs from Seam 2 is several fundamental
ways, mixing Seam 2 and Seam 3 information is massively confusing for
developers. I'm referring specifically to the forums and the wiki. The
driving force here is to establish a new "space" for Seam 3. Let's set that
point on the table and move to the next force.
Seam and Weld are projects brought to you by JBoss and its valued community.
Yet, for some time now, these projects have isolated themselves from the
JBoss community by being hosted outside (seamframework.org) of the JBoss
community umbrella (http://community.jboss.org). The creator of the
seamframework.org software is no longer with the team and the rest of us
must assume the responsibility of keeping it up to date. The problem is, any
work we spend on seamframework.org takes away from our ability to improve
Seam and Weld, review patches, analyze issues or write documentation. It's
an unnecessary drain. What makes it even more ridiculous is that we have a
entire team, the JBoss Community infrastructure team, that works full time
on providing a collaboration site to host projects, discussions and
documentation. A resource we are not currently leveraging.
Although it's a bigger discussion, we are reconsidering the use of the JBoss
Community for technical reasons. Lately we've identified some pain points
with seamframework.org that will immediately be solved by using Jive SBS
(the Java-based software behind community.jboss.org).
- Inability to monitor community discussion via "subscribe to this
thread"
- Inability to monitor comments on wiki pages
- Inability to post deep, complex links - including links to our own
threads on swfk.org
- A rigid navigation structure that cannot easily be altered
In short, we are concerned that we are lacking proper tools to effectively
manage and grow the Seam and Weld projects and community.
As simple as it sounds, there are still some considerations to take into
account before deciding to return Seam and Weld home to the JBoss Community.
That migration will require more planning. However, what Lincoln and I
suggest we can do as a first step is to take advantage of the need to create
a new space for Seam 3 and initiate that space in the JBoss Community. In
addition to the technical benefits, this would give us:
- a clean break for Seam 3, avoiding muddling with Seam 2 discussions and
information
- a proving ground to decide how we like the JBoss Community
collaboration platform, considering a full migration of
seamframework.orgin the future
- a chance for Seam community members across the board to establish their
JBoss Community accounts
- a better experience, in our mind
We propose:
- Creating a Seam 3 space at http://community.jboss.org with a user
discussion forum and wiki
- Creating a development subspace with a wiki (no discussion forum)
In the short term, we'll still use the seam-dev mailinglist for development
discussions (though we can consider enabling the discussion forums in the
development subspace if the e-mail bridge can be activated).
Would the majority of you be agreeable to this approach? It really will
provide a lot more clarity for Seam 3 and will show that we are sincere
about reuniting with the JBoss Community. Understand that this move will not
take away from the focus on portability in any way.
-Dan
p.s. Take a look at http://hibernate.org
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
13 years, 9 months
Interceptor packaging convention
by Lincoln Baxter, III
Seam Devs,
Dan and I have been working on the @Begin and @End conversation support for
Seam Faces, and we've discovered that there is a new fact of life for
consumers of portable CDI extensions. Due to the fact that @Interceptors
cannot be enabled in the extensions themselves (due to restrictions on
beans.xml for purposes of absolute ordering in the application. See:
http://seamframework.org/Community/EnablingAnInterceptorInALibrary )
This presents an interesting issue; we want to be providing a good
out-of-box experience, but interceptors must be registered manually.
This means that @Interceptor classes must be:
- Exposed to the developer
- Registered manually by the developer in beans.xml -
<interceptors>...</interceptors>
- Consistently named and packaged to prevent refactoring / backwards
compatibility issues
- Checked at startup in order to warn devs that they are using
annotations with no enabled @Interceptor
We would like to propose the following conventions in order to address the
above concerns:
All @Interceptor classes must:
1. Adhere to the following package and naming scheme:
org.jboss.seam.intercept.*Interceptor
2. Warn users (or Error out when appropriate) if they are using
interceptable @Annotations when the @Inteceptor itself is not registered:
(@Interceptor registration can be checked in the Extension class
AfterBeanDiscovery via BeanManager.resolveInterceptors(type,
interceptorBindings)
This presents users with:
1. A consistent naming scheme to help prevent typos.
2. A safety net to catch them when they fall down (because we forgot to
tie the ladder.)
3. A protected namespace so that when we refactor, we don't break their
world. (Even though #2 would catch it.)
I've updated the Seam 3 Development
Guidelines<http://seamframework.org/Seam3/DevelopmentGuidelines>to
reflect these conventions - they can be changed as needed pending the
outcome of this discussion :)
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
14 years
Seam JIRA for Seam 3
by Pete Muir
All,
As we split Seam into modules (and as some like remoting and XML approach a beta release), we need to consider how JIRA should look for Seam 3.
We plan to release modules independently, with a "feature-boxed" lifecycle, releasing modules either as features are added, or critical issues arrive. We also plan a "bundle release" at regular intervals, which takes all the modules, and provides a single stack that are tested to work well together.
Keeping JIRA simple and monolithic has the advantage of being easy to understand and point people at. We can use components to track a module. We would have to prefix the version with the module name, and tracking issues to releases becomes pretty difficult.
Using a JIRA project for each module allows much cleaner tracking of issues to releases.
I favour the latter, but am interested in others opinions.
Pete
14 years
Warnings from Seam 3 Parent POM
by Lincoln Baxter, III
We should probably resolve these, if for no other better reason than I find
warnings annoying -- thoughts?
--Lincoln
3/22/10 1:29:40 PM EST: [WARN] Some problems were encountered while building
the effective model for org.jboss.seam:seam-faces:jar:3.0.0-SNAPSHOT
3/22/10 1:29:40 PM EST: [WARN] The expression ${pom.url} is deprecated.
Please use ${project.url} instead. @
org.jboss.seam:seam-faces:3.0.0-SNAPSHOT,
/home/lb3/JBoss/seam3/faces/trunk/pom.xml
3/22/10 1:29:40 PM EST: [WARN] The expression ${pom.name} is deprecated.
Please use ${project.name} instead. @
org.jboss.seam:seam-faces:3.0.0-SNAPSHOT,
/home/lb3/JBoss/seam3/faces/trunk/pom.xml
3/22/10 1:29:40 PM EST: [WARN] The expression ${pom.organization.name} is
deprecated. Please use ${project.organization.name} instead. @
org.jboss.seam:seam-faces:3.0.0-SNAPSHOT,
/home/lb3/JBoss/seam3/faces/trunk/pom.xml
3/22/10 1:29:40 PM EST: [WARN] The expression ${pom.name} is deprecated.
Please use ${project.name} instead. @
org.jboss.seam:seam-faces:3.0.0-SNAPSHOT,
/home/lb3/JBoss/seam3/faces/trunk/pom.xml
3/22/10 1:29:40 PM EST: [WARN] The expression ${pom.organization.name} is
deprecated. Please use ${project.organization.name} instead. @
org.jboss.seam:seam-faces:3.0.0-SNAPSHOT,
/home/lb3/JBoss/seam3/faces/trunk/pom.xml
3/22/10 1:29:40 PM EST: [WARN]
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
14 years
Seam patches and SVN logistics
by Arbi Sookazian
HI all,
Are there any documented "rules of engagement" or best practices concerning
committing patches, bug fixes, etc. for JIRA issues with respect to Seam
3.0, for example?
Specifically, do the Seam core devs and miscellaneous committers work
directly off of trunk for all JIRA issues for a particular release or do
they create a separate branch for each JIRA issue which is then reintegrated
back into trunk?
If the latter, then what about using Mylyn in Eclipse for task mgmt and
context mgmt? The activation of tasks and tracking of change sets by Mylyn
are useful in Eclipse workspaces where there are multiple JIRA issues (or
tasks) to work on and isolate context for.
And is a continuous integration server like Hudson or Continuum used as
well? Is a build created by the CI server every time a file or change set
is committed to trunk or is it schedule by CRON job?
thx.
14 years
Re: [seam-dev] Seam 3 Internationalization & Localization module ideas / thoughts
by Asgeir Frimannsson
Hi all,
A slightly late reply, but my 5 cents:
It would be really nice if Seam 3 could support some sort of type-safety in the messages format, rather than having to manually maintain a java .properties template.
GWT is a great example of how this could be done [1], where an interface extending Messages can be annotated with all the relevant information, including default source-language values. An quick example:
@DefaultLocale("en_US")
@Generate(format = "com.google.gwt.i18n.rebind.format.PropertiesFormat")
public interface MyMessages extends Messages {
@DefaultMessage("{0} users online")
@PluralText({"one", "One user online"})
@PluralText({"none", "No users online"})
@Description("Title of the minimized users panel")
String nUsersOnline(@PluralCount int numUsers);
@DefaultMessage("I can ommit @Optional items here")
String anExampleUsingOptional(@Optional int n);
@DefaultMessage("However here I would get an exception as n is not @Optional")
String aFailingExample(int n);
}
The source-language properties file can then simply be generated from this type-safe and refactor-friendly model, and there is no need to manually maintain a properties file. At runtime, the target-language MyMessages.properties file would be used if available, and it would fallback to using @DefaultMessage values otherwise.
cheers,
asgeir
[1] http://code.google.com/webtoolkit/doc/latest/DevGuideI18n.html
----- "Ken Finnigan" <ken.finnigan(a)sorstech.com> wrote:
> All,
>
> I'm currently in the process of pulling together some thoughts and
> ideas
> as to what to include in the new i18n and l10n module within Seam 3.
>
> Here are some initial ideas that have been put forward:
>
> - Remove all hard dependencies to JSF from within the module
> - i18nable logging
> - Pushing the default locale to JSF and other view layers based
> on
> the system locale
> - Modify the message interpolation mechanism to remove the use of
>
> #{} and be consistent with Java by using simply {}
> - The ability for multiple view frameworks to co-exist with the
> appropriate messages being returned to the calling framework. My
> initial thoughts on this are to convert the existing StatusMessages
> class into a conversational scoped bean which can be used by
> application
> code to create a message for display. Then a view framework would
> create the mechanism to convert the StatusMessages content into
> messages
> appropriate to them. With JSF this could be achieved by taking the
> existing FacesMessages class and injecting the StatusMessages instance
>
> (while retaining the extends) to retrieve the messages that are
> present
> and FacesMessages can be used by SeamPhaseListener as it is now.
>
> Any comments on the above are most welcome, as well as any thoughts
> about what else would be useful to have within this module.
>
> Regards
> Ken
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
14 years
