5:26 p.m.
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.
On Thu, Jun 9, 2011 at 12:54 AM, Dan Allen <dan.j.allen(a)gmail.com
<mailto:dan.j.allen@gmail.com>> wrote:
+1
-Dan
On Thu, Jun 9, 2011 at 00:12, Jason Porter <lightguard.jp
<http://lightguard.jp>@gmail.com <http://gmail.com>> wrote:
+1
On Wed, Jun 8, 2011 at 17:32, Shane Bryzak <sbryzak(a)redhat.com
<mailto:sbryzak@redhat.com>> wrote:
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 ;)
Shane
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org <mailto:seam-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp
Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling
PGP key id: 926CCFF5
PGP key available at: keyserver.net <http://keyserver.net>;,
pgp.mit.edu <http://pgp.mit.edu>
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org <mailto:seam-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org <mailto:seam-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/seam-dev
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev