IntelliJ Seam support improvements
by Sebastian Hennebrueder
Hello,
the hot deployment support in Seam finds new compiled classes and reloads them. Using IntelliJ this currently requires that you press a key to
compile the class to get it picked up before you can reload a page in the browser.
IntelliJ has an option to do resources deployment on frame deactivation (=switching to another program like the browser). For developers using IntelliJ it would be great to have not only the deploy resources on frame deactivation but to compile on frame deactivation. This would lead to a Seam development cycle like 'change Java code' -> go to Browser -> Reload page
I would appreciate if further IntelliJ users could vote for the issue.
http://youtrack.jetbrains.net/issue/IDEA-52080
The same applies to Tapestry as well and I mentioned it on their mailing list as well.
--
Best Regards / Viele Grüße
Sebastian Hennebrueder
-----
http://www.laliluna.de
Java software developer and trainer for Hibernate and Java Persistence
14 years
conventions to work out: implementation JAR names and event types
by Dan Allen
A quick look through the modules last night made me aware of two conventions
that we need to clarify.
*Implementation JAR names:*
All modules are following the naming convention seam-%module%-api for the
API JAR. However, the names of the implementation JARs are inconsistent.
There are three naming patterns in use: seam-%module%, seam-%module%-impl
(persistence) and seam-%module%-core (js-remoting)
Several modules use the root name seam-%module% to make it easy to remember
and aesthetic when including as a dependency. However, seam-%module%-impl is
more technically correct since it only contains the implementation classes,
with just a dependency on the API.
My proposed solution is to publish the api and impl JARs as normal, then
publish a third JAR that combines the two into one using the
maven-shade-plugin.
*Event types:
*
I'm seeing some event types (the type of the event payload) that use the
suffix "Event" and those that do not. I think we should either have one or
the other...or have rules as to when one is chosen.
My proposed solution is that we should try to use the data object as the
payload with an event qualifier to specify the action if possible. If it
needs to be wrapped to bundle up other information, then the wrapper type
should be named with the Event suffix.
Here are examples of the data object as payload:
@Initialized ServletContext
@Updated @Client DateTimeZone
@Created SeamManagedPersistenceContext <- proposed change
Event wrappers are used when the payload is a composite (and there isn't
already a logical wrapper type). However, I'm finding it hard to come up
with cases where a data object + qualifiers won't suffice. Could also just
be a style thing.
I also think we should push the standard action qualifiers into Seam Solder
(Weld Extensions). Where possible, we should avoid synonyms (e.g., both
@Changed and @Altered). Candidates so far are:
@Initialized
@Destroyed
@Updated (or @Changed or @Altered)
@Created (can this just be @Initialized?)
@Before
@After
maybe...
@Failed
@Added
@Replaced
@Inserted
@Deleted
Please note these are suggestions. Feel free to provide feedback.
-Dan
--
Dan Allen
Principal 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
14 years
Seam 3.0 roadmap
by Pete Muir
After last weeks IRC meeting, I now have a good understanding of where modules have got to.
http://seamframework.org/Seam3/Seam30Roadmap
Headlines:
* Aiming to get most modules to beta by end of Oct. A few (security, persistence, drools) likely still in alpha
* Beta of Seam 3 by 12th Nov in time for Devoxx
* Second beta in early December with all modules at beta
* First release candidate in early January
All module leads, please look at the roadmap and check that you can get your module to beta by then.
Ken, Shane, Jozef, still need to hear from you about when you can get International, Security and REST to beta -- please ping me.
Pete
14 years
Documentation issues
by Shane Bryzak
I thought this might be relevant to us. It would be great if each of
the module's docs had a link in the introduction to the module's JIRA
for readers to submit documentation-related issues.
-------- Original Message --------
Subject: Re: On sucking less
Date: Thu, 04 Nov 2010 12:05:18 +1000
From: Darrin Mison <dmison(a)redhat.com>
To: Robb Greathouse <robb.greathouse(a)jboss.com>
CC: The Core <thecore(a)redhat.com>
On Wed, 2010-11-03 at 16:31 -0400, Robb Greathouse wrote:
> Hi,
>
> In the field we come across client complaints about documentation and what we could do to make it suck less. Where should we funnel these? It would be great if there was a place (Version control) where we could enter clarifications into the document. They wouldn't go out right away, but they could accumulate there where someone could look at them and accept or reject them for regular updates to documentation.
>
> For example, here is one I hear all the time. We have snippets from xml files showing how to configure something. An experienced developer will recognize which XML file it belongs in right away. However, a new comer or someone who configures infrequently may not be able to figure out which xml file the snippet pertains.
>
> Suggestion. Put the FQN for the file in the title to the snippet.
>
> Example: jboss/servers/[server]/conf/standardjboss.xml
>
> OR
>
> [Application].ear/WEB-INF/web.xml
>
> Now that there are so many jboss-service.xml files the confusion is growing.
>
> Robb Greathouse
> JBoss
> CELL (505) 750-3481
> skype: rgreathouse
>
Log a bug against the document :-)
If it is a product document (JBoss Enterprise Widget Platform) then
there should be a feedback section right at the beginning with the info
about where/how to log docs bugs. It's not very discoverable IMHO but
it is there.
If it is a community document then your milage may vary but each project
generally has a docs component in JIRA.
In that particular example it's probably better to have the example
title summarize the purpose of the example, rather than a file name.
The accompanying procedure that the example is illustrating should
define what file/s etc it applies to.
---
Darrin Mison
Red Hat JBoss Middleware Documentation
14 years
Re: [seam-dev] Is this something worth looking at?
by Lincoln Baxter, III
Right, this is more about Seam 2 JSF 2 compatibility.
On Wed, Nov 3, 2010 at 10:12 AM, Shervin Asgari
<shervin(a)redpill-linpro.com>wrote:
> I think the more correct title is
> Seam2 + JSF2
>
> Shervin
>
>
> On 03. nov. 2010 14:48, Lincoln Baxter, III wrote:
>
> I just saw this on twitter
>
> "Seam2 + Primefaces 2.2 is possible with patch by he youlin.
> https://github.com/heyoulin/seam2jsf2 It works like a charm."
>
>
> --
> Lincoln Baxter, III
> http://ocpsoft.com
> http://scrumshark.com
> "Keep it Simple"
>
>
> _______________________________________________
> seam-dev mailing listseam-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/seam-dev
>
>
>
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
14 years
