In our current modules distribution for AS7 we currently are distributing: - JUnit - HTMLUnit - JSFUnit - Arquillian SureFire - the AS7 Arquillian subsystem - ShrinkWrap - Various glue and support modules for the above - Probably more test-oriented stuff I missed in my glance-over The question is: 1. Do we really want to be distributing these test frameworks? 2. If so, should we put them in their own area somehow? 3. Also if so, should be recommend, as a policy, how and when these modules should be used by end users? 4. If not, how can we exclude them from the final build? -- - DML _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

To me, lean and mean is a matter of RAM footprint and CPU cycles, not necessarily download size. Some blogs might use MB count as some indicator, but this is the age of broadband. I could pull down 100M from my phone before I my coffee order was filled. I'm in favor of arming developers with all tools they'll need to develop (which I believe implies testing) alongside the distribution. Profiles, on the other hand, refer to the services started at AS boot. And with on-demand that becomes even less of an issue. So yes, I think it's natural to put SW, Arquillian and the like inside the distro. Users grabbing AS via Maven can pull these in transitively, much like we do now in AS6's "depchain" module. S, ALR On 03/17/2011 09:30 PM, Bruno Georges wrote: > Does it make sense to align this with the notions of profiles? > I like the idea of shipping a lean and mean which is what applications developer are used too and look for, however new development paradigm will be relying on those modules. > Saying that I like the idea of isolating them in a different area. > I don't know what's the best option for our users, am interested to read feedbacks on this. > Maybe Max and Andrew have thoughts on how we could provide those modules to the end users (maven/Eclipse,...?) without fattening the distro. > > -- > Bruno Georges > > On Mar 18, 2011, at 5:56, "David M. Lloyd"<david.lloyd(a)redhat.com> wrote: > >> In our current modules distribution for AS7 we currently are distributing: >> >> - JUnit >> - HTMLUnit >> - JSFUnit >> - Arquillian SureFire >> - the AS7 Arquillian subsystem >> - ShrinkWrap >> - Various glue and support modules for the above >> - Probably more test-oriented stuff I missed in my glance-over >> >> The question is: >> >> 1. Do we really want to be distributing these test frameworks? >> 2. If so, should we put them in their own area somehow? >> 3. Also if so, should be recommend, as a policy, how and when these >> modules should be used by end users? >> 4. If not, how can we exclude them from the final build? >> >> -- >> - DML >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On 3/17/11 9:05 PM, Bruno Georges wrote: > Thank you Andrew > I think there are requirements where size matters and will require to exclude modules like those. Outside the fact that here in AsiaPac you may have to order and drink your coffee before u get 10mb downloaded :-), Am thinking in term of the different "profiles" like those targeting cloud, production, smart devices, etc although this can be customized later it is good to aet on the mechanism/infrastructure now. > It is my understanding tjat profiles are slighlty different from pre-AS7, but I may be on wrong on this. > The AS 7 profile notion is all about configuration and what modules get used in the runtime. There's no different set of jars associated with different profiles. Modules all declare their dependencies, so given a particular profile it should be possible to analyze the set of necessary modules and create a distribution limited to that set. We shouldn't use the term "profile" for that though. > +1 on tooling /maven > > -- > Bruno Georges > > On Mar 18, 2011, at 9:35, Andrew Lee Rubinger<andrew.rubinger(a)redhat.com> wrote: > >> To me, lean and mean is a matter of RAM footprint and CPU cycles, not >> necessarily download size. Some blogs might use MB count as some >> indicator, but this is the age of broadband. I could pull down 100M >> from my phone before I my coffee order was filled. >> >> I'm in favor of arming developers with all tools they'll need to develop >> (which I believe implies testing) alongside the distribution. >> >> Profiles, on the other hand, refer to the services started at AS boot. >> And with on-demand that becomes even less of an issue. >> >> So yes, I think it's natural to put SW, Arquillian and the like inside >> the distro. >> >> Users grabbing AS via Maven can pull these in transitively, much like we >> do now in AS6's "depchain" module. >> >> S, >> ALR >> >> On 03/17/2011 09:30 PM, Bruno Georges wrote: >>> Does it make sense to align this with the notions of profiles? >>> I like the idea of shipping a lean and mean which is what applications developer are used too and look for, however new development paradigm will be relying on those modules. >>> Saying that I like the idea of isolating them in a different area. >>> I don't know what's the best option for our users, am interested to read feedbacks on this. >>> Maybe Max and Andrew have thoughts on how we could provide those modules to the end users (maven/Eclipse,...?) without fattening the distro. >>> >>> -- >>> Bruno Georges >>> >>> On Mar 18, 2011, at 5:56, "David M. Lloyd"<david.lloyd(a)redhat.com> wrote: >>> >>>> In our current modules distribution for AS7 we currently are distributing: >>>> >>>> - JUnit >>>> - HTMLUnit >>>> - JSFUnit >>>> - Arquillian SureFire >>>> - the AS7 Arquillian subsystem >>>> - ShrinkWrap >>>> - Various glue and support modules for the above >>>> - Probably more test-oriented stuff I missed in my glance-over >>>> >>>> The question is: >>>> >>>> 1. Do we really want to be distributing these test frameworks? >>>> 2. If so, should we put them in their own area somehow? >>>> 3. Also if so, should be recommend, as a policy, how and when these >>>> modules should be used by end users? >>>> 4. If not, how can we exclude them from the final build? >>>> >>>> -- >>>> - DML >>>> _______________________________________________ >>>> jboss-as7-dev mailing list >>>> jboss-as7-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> _______________________________________________ >> jboss-as7-dev mailing list >> jboss-as7-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev -- Brian Stansberry Principal Software Engineer JBoss by Red Hat _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev