cancel
Showing results for 
Search instead for 
Did you mean: 

Need advice in designing an External library DC

Former Member
0 Kudos

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

Accepted Solutions (1)

Accepted Solutions (1)

snehal_kendre
Active Contributor
0 Kudos

Hi Roy,

Its a good practice to create one public part for all the jar file.

As you are creating a library DC that means its going to have no of jars in it. so it is benficial to just provide one path to access .jar file rather than creating no of public parts.

Lets see even if your application only needs a single .jar file, and you have created public parts for each jar. Then also when you build your application the whole external library project is going to be build with it.

Former Member
0 Kudos

That's true but what if my DC only needs one jar from this list? Creating everything in one public part will result in adding all the jar files when I just need one.

You can say just add the entity you need but in practice that adds the entire public part...

Edited by: Roy Cohen on Jul 30, 2008 2:04 PM

snehal_kendre
Active Contributor
0 Kudos

Hi Roy,

Creating everything in one public part will result in adding all the jar files when I just need one.

This will never happen.it will add only the one you need, not all.

Former Member
0 Kudos

Define the pps as you need it. You can define as many pps as you want (if it makes sence, is an other questions).

Maybe it would be better to define different ExtLibs (thats the way I'm doing). The design always depends on what you want to develop!

If you've need some input (experience of my own), please ask!

Regards,

Daniel

Former Member
0 Kudos

Hi Daniel,

Well, I've given u the scenario I', just looking to hear more thoughts on the subject. both implementations will work I just want to chose the more efficient one.

Former Member
0 Kudos

Hi,

I can only share my experience with you. There's isn't a best practice on "how to design", thx to java, we are freeeee

Ok, some points that may help you:

1. How often are the libs are used in your projects? Find out which of them are used frequently and pack them into an own DC/SC

2. If the ext. libs are often used in Web apps, create a j2ee (or more) library which contains all (or not) jars and define the pps as you need it

(e.g. as I'm using apache libs often, I've created a J2EE lib fo the common files which are often used from other libs). Depended on the

app I've defined pps (or other j2ee libs) as I thought they make sence (Advantage: the general SC is deployed one, and I get acces everytime I need it).

3. As always in development, develop as small parts as possible that will be reusable (ok when possible )

4. Have a look at SAP SCs, to get an idea how you could design your software (get the best out of it, but not all )

Hope, I could gave some ideas. Will be always open for questions, ideas, critics ....

I think this is a good thread which could be open for discussions (or maybe our moderates, take the topic and create a new one, wouldn't it be nice?)

Regards,

Daniel

Answers (1)

Answers (1)

Former Member
0 Kudos

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.

Former Member
0 Kudos

James,

Thank you for sharing your thoughts, you've raised some interesting observations!

Roy