On Sep 18, 2008, at 11:54 PM, M. Ranganathan wrote: > On Thu, Sep 18, 2008 at 10:54 PM, M. Ranganathan <[EMAIL PROTECTED]> > wrote: >> On Thu, Sep 18, 2008 at 6:23 PM, Kevin Thorley <[EMAIL PROTECTED] >> > wrote: >>> >>> On Thu, 2008-09-18 at 17:55 -0400, Andy Spitzer wrote: >>>> Woof! >>>> >>>> In the beginning, we looked at JAIN-SIP and saw that it was good. >>>> >>> [...] >>>> >>>> Oh wise and merciful keepers of JAIN-SIP, can you point the way to >>>> salvation for this confused and weary pilgrim? >>>> >>>> --Woof! >>> >>> I am neither wise, merciful, nor a keeper of JAIN-SIP. However, I >>> can >>> say that it is the opinion of the sipXconfig team that the RPM >>> approach >>> is the way to go. In sipXconfig we use the RPM version of JAIN- >>> SIP (as >>> well as some other packages such as commons-net). >>> >>> Kevin >>> >>> >>> _______________________________________________ >>> sipx-dev mailing list >>> [email protected] >>> List Archive: http://list.sipfoundry.org/archive/sipx-dev >>> Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev >>> >> >> O one that Woofs! Behold I am the keeper of JAIN but verily I do not >> keep the RPMs there unto. Forsooth it was thusly explained unto me >> that jars shall not be included into repositories in keeping with >> the >> customs of the land if we wish to be included in distributions of the >> metaphysical future. I witness several jars other than JAIN-SIP that >> reside upon the commons (as mere commoners are wont to do). Therefore >> I do ponder upon the practicality of that goal of a pristine >> distribution in the near future as by Jingo, there is no half measure >> in meeting it. >> >> Thusly I have spoken. > > > And having spoken I speak again...Perhaps the time has come to read > some tea leaves or animal entrails or something and make a decision > one way or the other and all follow that choice. Going down from 3 to > 2 jars is progress but the ideal is one jar. > > >> >> >> >> -- >> M. Ranganathan >> > > > > -- > M. Ranganathan
I will spare everyone any more prose and get right down to the point. Our java based services use a growing number of third party packages, i.e. .jar files. Currently sipx includes over 80 of these .jar files. The methodology for handling and deploying them has been up to this point to maintain them as part of the code base and to install them along side the sipX runtime. This has been further refined with the introduction of sipXcommons, a component which is intended to supply common java code as well as common third party jars. This methodology has many advantages: - Tight control over which version of each third party package is utilized. This ensures version consistency across development, QA and product deployment. Jar files are tracked just as tightly as any other piece of our code. - Maintenance of the third party packages is compartmentalized to within the software components that own them. In addition, each component has the ability to either use the packages supplied by sipXcommons or incorporate an overriding version. - Developers and Release Engineering do not need to be aware of or deal with satisfying third party package dependencies as they are automatically included with the source code. There is no need to hunt for RPM's or be concerned about version mismatch. - This method of third party package deployment is operating system agnostic as it does not rely on OS specific packaging mechanisms such as RPM's. - In many cases, the installation footprint is reduced when compared to a RPM based package deployment scheme due to the fact that only the required .jar files are installed. Recently there has been movement within the sipXconfig group to move away from the current methodology and instead move to an RPM based scheme. In this scheme, the third party packages will no longer be maintained along side the code. Nor will they be installed as part of the sipX runtime. Instead, each third party package will be supplied by installing an associated RPM. Going with this scheme will eliminate all of the advantages stated above. It will also introduce the following: - Given that many, if not most of the required third party packages are not available via RPM's, it will become our responsibility to package and maintain a very large number of new RPM builds. - Every developer and Release Engineer will now be required to ensure that their environments contain all of the required RPM's as well as ensuring that the correct versions are maintained. Just this week, I found that I could no longer build sipXconfig because I had the incorrect version of the jain-sip RPM installed. - The additional bloat introduced by these RPMs could force us to either go to a multi-CD or DVD based ISO install. - Further uncertainty within the engineering organization could subject us to even more bad prose. At this stage the config server team have only introduced three RPM's, dnsjava, commons-net and jain-sip, all of which are available from sipXcommons. Before they go any further down this path, they should seriously rethink this new strategy. -Mardy _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
