Sounds good to me, as also the combined jars for various other
profiles. Jason, care to add this to the agenda for next week's IRC
meeting and we can flesh it out a little further?
On 10/06/11 08:40, Dan Allen wrote:
I suggested this a while back as the "Seam for Web
Profile".
seam-web-profile.jar
Calling it seam.jar is way too ambiguous and is going
to do nothing but lead to confusion. Let's give the stack a name
(such as "Seam for Web Profile") and qualify the jar.
That's a fair point,
however to address this (and for simplicity's sake) what
if we were to provide a combined jar that included most of
the modules? I would say that the following list
represents the "core" of Seam:
Solder
Catch
Config
International
JMS
Mail
Persistence
REST
Security
Servlet
Validation
We would simply call this combined jar seam.jar, and on
top of that, the developer would also add dependencies for
whatever view technology they're using (i.e. seam-faces,
errai or seam-wicket), and then the extra features if they
require them (Cron, JCR, Remoting, Reports, Social, etc).
That should greatly reduce the number of jar files in a
deployment.
On 10/06/11 08:08, John D. Ament wrote:
-1
In my opinion the combined jar helps keep the number
of JAR files down in deployments.
We
discussed this briefly on IRC,
however I thought we should
discuss it
on seam-dev before we make any
concrete decision. To
summarise the plan:
1. Remove the combined jar
file from each of the modules
2. If the module has a single
implementation, rename it to
whatever the
combined jar was called.
E.g. for Seam Catch, the
impl module would be called
seam-catch.
3. If the module has multiple
implementations, then add a
suffix to the
artifact name that reflects
the individual implementation.
E.g. Seam Reports has two
implementations, which would
be called
seam-reports-jasper (for
Jasper reports) and
seam-reports-pentaho (for
Pentaho).
4. Leave the API naming as it
is, e.g. seam-reports-api.
The idea is that by importing
the simplified module artifact
name (i.e.
"seam-xxx") you would get the
default implementation, which
in turn
depends on the API. The
advantage of this is that we
won't break
backwards compatibility - e.g.
someone currently declaring a
dependency
on "seam-catch" in their pom
file won't have their app
broken when we
rename the modules. Also we
remove the complexity
introduced by having
a combined jar in the first
place.
If you can spot any issues
with this, please speak up now
;)