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

+1 -Dan On Thu, Jun 9, 2011 at 00:12, Jason Porter <lightguard.jp(a)gmail.com&gt;wrote: > +1 > > > On Wed, Jun 8, 2011 at 17:32, Shane Bryzak <sbryzak(a)redhat.com&gt; 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

On Thu, Jun 9, 2011 at 18:08, John D. Ament <john.d.ament(a)gmail.com&gt; wrote: -1 In my opinion the combined jar helps keep the number of JAR files down in deployments. # of jars really doesn't matter, it's the size of the war that matters (when we are talking about sizes). The problem with the combined JAR is that it's too easy for a developer to inadvertently *also* add the implementation and api jars separately, and then the application goes haywire. This is a slippery slope because of transitive dependencies. The other point that a colleague of mine pointed out is that by making a combined jar, you undermine the whole effort of having an api/impl split. And seeing how we are trying to encourage interface-based development and separation of these concerns, it's the right thing to do. I'll also add that scanning behaves differently when you have a combined jar vs individuals. So you are introducing subtle differences that could lead to bugs. -Dan On Thu, Jun 9, 2011 at 12:54 AM, Dan Allen <dan.j.allen(a)gmail.com&gt; wrote: +1 -Dan On Thu, Jun 9, 2011 at 00:12, Jason Porter <lightguard.jp(a)gmail.com&gt; wrote: +1 On Wed, Jun 8, 2011 at 17:32, Shane Bryzak <sbryzak(a)redhat.com&gt; 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 -- 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

-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

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&gt; wrote: > +1 > > -Dan > > > On Thu, Jun 9, 2011 at 00:12, Jason Porter <lightguard.jp(a)gmail.com&gt;wrote: > >> +1 >> >> >> On Wed, Jun 8, 2011 at 17:32, Shane Bryzak <sbryzak(a)redhat.com&gt; 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 listseam-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/seam-dev

+1 to Dan idea. We could extend that and have a "Seam for Business Profile", that has the JMS, Persistence, Reports and REST for example.

+1 for "profile" jars and removal of the combiner jar. I'd like to see a friendly user interface for choosing modules which would generate the required Maven/Gradle/Ivy dependency list you can copy/paste... that is of course if you're not using Forge. This would be hosted at the Seam University for example.

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. So +1 to that revised idea :) -Dan On Thu, Jun 9, 2011 at 18:26, Shane Bryzak <sbryzak(a)redhat.com <mailto:sbryzak@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 > <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 <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