Andrea, I agree with your comments. At the end of the day what matters is end user experience. So having something work out of the box is definitely a huge plus. Having more granular release artifacts seems like a reasonable approach.
Regards, Rajith On Mon, Jan 19, 2009 at 4:44 PM, Andrea Gazzarini <[email protected]>wrote: > Hi Rajith, > From my point of view the problem is (as you told) the level of granularity > of what we are distributing... > This is my personal approach about downloading frameworks & products but > when I decide to experiment or to use a framework or a product I'm in one > of > the following two scenarios: > > 1) in the first I must evaluate, try it and therefore I don't know what is > exactly contained in the box so I'm interested in downloading a whole > bundle > without size problems at all; > > 2) second scenario comes when I have a clear idea of what I need and under > these circumstances I'd like to download exaclty what I need. For example > if > I need a JMS client, I want download only a JMS client and the same applies > if I need a Java broker etc... > > In both scenarios (but again, it's my personal point of view), I like have > an immediate working distribution, ready to start, and I hate, after the > download, to follow a long readme that indicates me a list of n > dependencies > (with the exact version for each one) that need to be downloaded. > This is because sometimes (for me everytime :) ) this process is tedious > especially from a user perspective who wants simply run & use the > application. > > For example two weeks ago I downloaded a product structured like that > (without dependencies) and the readme file indicated a jar library > (xyz-1.2.3.jar) as required. Well, the readme file pointed me rightly to > the > URL where I could download the libraries but that version was no longer > available....what loss of time (and money for company which is paying)...I > found that libraries in an old Application Server distribution....after > three hours! > > So, at the end, what I'm saying is that we could solve this issue with > distribution...if you want to download a java broker QMan (for example) has > nothing to do with that so IMO the archive shouldn't contain that... > > Regards, > Andrea > > > 2009/1/19 Rajith Attapattu <[email protected]> > > > Hi All, > > > > I have noticed that our list dependencies have grown quite big. > > This invariably makes our standard distributions quite large. > > Majority of our users would want to download a broker (c++ or java) and a > > JMS client distribution with only the required dependencies. > > I have noticed that eclipse and qman have the most numbers of deps and > was > > wondering how many of them are runtime deps as opposed to compile time. > > Perhaps we could eliminate the runtime deps by having clear and concise > > documentation on what dependencies are needed and where to download them. > > We could also streamline our release process and have separate artifacts > > for > > client, broker and management modules. > > This will ensure that only the required deps are packaged with each > > artifact. > > > > Thoughts/Comments are most welcomed. > > > > Regards, > > > > Rajith Attapattu > > Red Hat > > http://rajith.2rlabs.com/ > > > -- Regards, Rajith Attapattu Red Hat http://rajith.2rlabs.com/
