[seam-dev] conventions to work out: implementation JAR names and event types

[Pete Muir]

On 9 Nov 2010, at 22:39, Dan Allen wrote:

> 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.

Sounds good.

> 
> 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.

Sounds good.

> 
> 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

Can you write up some more detailed description (would suggest a pull request w/ javadoc) so that we can understand their purpose more?