+1 to that idea.
Provides a quick way for someone new to Seam 3 to get the most common modules bundled
together to get started building a new app.
Ken
Sent from my iPhone
On Jun 9, 2011, at 18:26, Shane Bryzak <sbryzak(a)redhat.com> wrote:
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>
wrote:
> +1
>
> -Dan
>
>
> On Thu, Jun 9, 2011 at 00:12, Jason Porter <lightguard.jp(a)gmail.com> wrote:
> +1
>
>
> On Wed, Jun 8, 2011 at 17:32, Shane Bryzak <sbryzak(a)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
>
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,
pgp.mit.edu
>
> _______________________________________________
> seam-dev mailing list
> seam-dev(a)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
>
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
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev