Dealing with External (Open Source) Libraries

[Former Member]

We're currently constructing a Netweaver-based environment that encompasses many different types of systems: XI, Portals, BW, and R3, along with the many associated software packages for each environment. With the addition of EP and XI into our system landscape (we've had R3 for quite a while noe) Java is now becoming an alternative to ABAP development, especially in the EP arena.

There is of course a large amount of freely available, open source Java code out in the wild, and we want to take advantage of this code base - why re-invent the wheel, right?

However, there are lots of issues surrounding the use of open source code:

- who supports the code? It's free, so there is no 'technical support hotline' to call. For every package that we install, we therefore increase our workload.

- testing strategy - how many hoops do we make the code go through before we can be assured that it's 'production' ready?

- what is the SAP stance on incorporating open source code into the J2EE engine? Does this in any way affect supportability?

- rapid change - Open source code can change quite rapidly, so how do you handle this?

One of the things that we're looking at is restricting what developers can upload to the server. Throught he use of JDI repository checks, we plan on preventing java developers from uploading Java archives 'willy-nilly'; rather, we want all external libraries to be packaged and uploaded by the J2EE support group, thereby controlling the importation of 3rd party code.

How do other people deal with these issues? What policies do people have in place to govern the use of 3rd party java code?

Any comments and/or suggestions that people have would be greatly appreciated.

[Former Member]

Ken,

Few suggestions from my side.

>>who supports the code? It's free, so there is >>no 'technical support hotline' to call. For every >>package that we install, we therefore increase our >>workload.

This varies from package to package. If you see Hibernate which is a OR mapping library, you get support for it which is run by a altogether different company but you might not get the support for your other library codes. so..varies with what you are trying to use.

>>testing strategy - how many hoops do we make the code >>go through before we can be assured that >>it's 'production' ready?

This will also depend on the free source stuff you are trying to use. Say in case of Struts or log4j like packages, you wont find any flaws as the industry is heavily relying on these today. but a new library and yes, you need fair amount of testing for that.

>>what is the SAP stance on incorporating open source >>code into the J2EE engine? Does this in any way affect >>supportability?

SAP would be the best option to enquire with :).

>>rapid change - Open source code can change quite >>rapidly, so how do you handle this?

Not necessary you have to upgrade.If a current version suffices your business requirement then stick with it.

Even if you change to a latest version,you might need to tweak with your java versions (say upgrade java also) but the existing functionality in previous versions will continue to work fine though..

Hope this helps..

Rgds,

Amol