It does make sense, at least from the perspective you described. I
guess we have to take off our engineer-tinted glasses from time to
time ;)
On 10/06/11 12:01, John D. Ament wrote:
I do like the idea of profile based JARs, makes a lot
of sense. While I get a lot of perspective on how splitting api
and impl works well for engineering, for business app developers
(like me) complexity of a project is defined by the number of JARs
in the deployment. If we show too many files in there it makes
the project look too complicated.
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
;)