Need advice in designing an External library DC

Question

Hello,
We've got about 10 jar files that we use in our developments that needs to be exposed via External library DC.
Each DC that we develop uses a different combination of these jar files.
I am wondering whether to create a seperate public part for each jar or create just one public part and add each jar to it as an entity.
I would be happy to hear your opinion and pros/cons for each method.
Roy

Answer 1

Hi Roy
I think we need to look at what you mean by 'efficiency' with this requirement first. I suppose you need to decrease the size of the classpath at three distinct points: compilation in the IDE, build time in the NWDI, and runtime on the application server.
At compile time (in your NWDS), having a single external library DC with multiple public parts will cut down on the classpath with which NWDS has to work in your referencing project - only the classes within the public parts of your external library DC will be accessible. (And God knows it's not the most efficient little IDE, so it needs all the help it can get.)
Having said that, if your external library DC contains code (which it can), you'll probably need to be rebuilding it fairly frequently, even if you don't change anything. In this case, you need to take into account the size of the external library DC itself - so splitting your libraries into separate DCs and setting up the graph of dependencies would be preferable.
However, in this instance, you need to remember that the NWDS (or, more correctly, the Web DynPro tools) is essentially broken with respect to its resolution of dependencies. You're constantly having to rebuild things in a certain order to get it to recognise your libraries, open and close the IDE in order for things to compile correctly, and so on. Creating a large dependency graph will likely only exacerbate this problem.
With respect to builds by the NWDI, before the assembly step, your classpath should be the same as at compile-time in the NWDS. When the assembly occurs, however, everything in your track is built - so it doesn't really matter where you put things. Everything is also going to be deployed to TEST and PROD anyway (which is what Snehal was alluding to).
Although I'm not certain of this, I assume that the situation at runtime is the same as at compiletime. I don't know if SAP has released in-depth information about the class-loading strategies employed by the Web DynPro runtime with respect to public parts, but I'd expect that the runtime and compile time classpaths would be consistent. (The class-loading strategies employed by the Web Application Server more generally would also suggest that this were the case.)
Obviously, the more complex you make your dependency structure (the more independent public parts you have, and even moreso, the more separate library DCs you have), the more complex you'll make the process whereby other developers will declare dependencies upon your DC, as they'll have to reference multiple public parts and DCs. However, using more conventional referencing methods, they would need to determine which JAR files they needed anyway.
Consequently, in the greater scheme of things, one questions how much real efficiency there is to be gained here. The more granular your dependencies, the more efficient your design will be. But this complicates things in practice in the NWDS, and whether it is worth the extra effort depends on how large your libraries are, and how many of them you have - i.e., how much you have to gain by optimising.