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? _______________________________________________ seam-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/seam-dev
