External Libraries in NWDI

[Former Member]

Hello all,

i have already read about several post, with that topic, but still found not an acceptable solution for my problem.

We try using NWDI (SPS14). In my SLD i created a new SC EXTLIBS. I configured a Track and loaded the Dev-Conf into the NWDS.

- I created a External Library DC and added the external jars (log4j, jdom a.o.).

- Made my Public Parts.

- Build and Activation works fine.

Due to External Libraries are not deployable i packed all into a J2EE Library Project. With "Used DC`s" as described https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/2361. [original link is broken] [original link is broken] [original link is broken] [original link is broken] [original link is broken] [original link is broken]

Built and Activation worked well and the Track was transported successfull.

Now i created a new SC in SLD, where i defined the EXTLIB as dependency.

Now i run into trouble. I import the new Development Configuration into NWDS and create a project. I see the defined SC in my local Development configuration, but im not able to sync this SC, nor can access the included DC`s.

If i view this SC in its own Development Configuration i can see the DC`s, also the CBS WebUI tells me the correct nummber of included DC`s.

What do i wrong?

Also Pascal Willemsen mentioned a different method for external libs in /thread/47565 [original link is broken] "The 2nd available option (based on NWDI) is to create an External Library DC and add your jars to that. Create an extra public part for assembly (next to the existing public part for compilation called ExternalLibs). Then, for each portal app DC add the External Library DC as a used DC, create an assembly public part and add an Entity Reference to the assembly public part of the External Library DC. This way the jars will be assembled in the PAR file for each portal app. The nice thing is that you are still maintaining the jar files in one central place, but that you have the option to update and test the portal apps individually.".

But here im not able to share the the External Library to different Development Configurations.

Isn`t that possible at all in NWDI?

Thanks for any help

Best regards

Oliver Walter

[Former Member]

Hi Oliver,

just some thoughts that went through my mind, maybe this helps clarifying things a bit...

An External Library DC in NWDI is just like a Java DC (except that you don't have sources or do not want to compile them): It's a simple building block that is used during build. Maybe it has a specific "API" subset (in which case you could publish different Jar files in compilation/assembly public parts) or it hasn't (in which case the jars in compilation/assembly public parts would be identical). Anyway, public parts are relevant for build.

If you want to share a common library then putting the library into an External Library DC is a first step: It allows reuse of the same library within one development configuration. If you now transport the DC (as part of the SC which contains the DC) to another track you can again reuse the same library in that other track.

What Pascal wrote refers to the runtime in contrast to the build. During build you reuse the library using public parts, during runtime you reuse the library by either assembling it into each single deployable archive, or by assembling it into one single (J2EE Server Component) library that is reused at runtime of you application. Both solutions are possible within NWDI and each has its own advantages and disadvantages: Either you mulitply the number of Jar files that are deployed (potentially increasing memory usage/required hard disk space but creating an independently updatable application) or you have to worry about version conflicts at runtime.

Marc

[Former Member]

Hello all,

thanks for your help. Right now im able to add a used DC to my Development Project (Portal Standalone).

Unfortunatly i`m not able to add these DC`s to my Built Path, but the JAR Files are on my local Filesystem and the "Add Used DC" seems to work fine.

What is wrong here with my Setup?

regards Oliver

[Former Member]

The build path is constructed automatically by adding all jars that are part of public parts for compilation from Used DCs during a DC build. Therefore you should never manipulate the build path yourself (it'll be overwritten anyway).

Did you create the necessary public parts (you need at least a public part for compilation) and add the jars to them?

PS. Please remember to reward points for helpful answers.

Message was edited by: Pascal Willemsen

[Former Member]

Hello Pascal,

that means, i have to create 2 public parts to my library project, one for development/compilation and another one for assembly, if want to pack the jar to each project.

Wich one do use in my Used DC`s in my IDE? Are the jars packed automatically to the SC in CBS when they have a pp for aasembly and i used the pp for compilation in my IDE?

regards Oliver

[Former Member]

Yes, at least that's my personal experience...

[Former Member]

Hello Pascal,

now im really close to get crazy. Ok i followed your recommedation and added two PP to each External Library DC.

One for purpose compilation with ending _api and one with the purpose assembly with ending _jar. I transported the whole through its track and reimported it into my actual development track.

BUT on the Development Configuration is still the old SCA with only the PP for assembly? I synced everything, reimported the Conf. and even did a restore system state in CMS. But nothing helped?

It`s still showing my old External Library PP Definition.

Is there anything else, that can/have to do? Is SPS14 buggy and not useable?

regards Oliver

[Former Member]

Hello Pascal,

i really get a strange behaviour. When i check the updated external lib in the buildspace(s), i can see that there are my two public parts defined (compilation and assembly). But when reimport the development configuration to NWDS, still the old configuration is loaded.

Is there anything i miss?

[Former Member]

Hello Oliver,

check the WebUI on CBS if it shows the correct public parts. If it does go the IDE and try to unsync/resync the archives.

If CBS does not show the correct public parts then something with the track connection or the CMS import went wrong.

Did you do the full release/import to cons/assembly/... steps?

Marc

[Former Member]

Hi Marc,

the WebUI of CBS shows the correct PP`s. Even with unsync (remove from local drive) and Sync Used DC`s there is no change in my IDE it still shows the old release.

When i did the full release and assembly steps, i just changed the patch level of the SC.

2006/07/05 15:55:34 br.com_EXTLIBS 1.0 Level 2 Update CPSELIBS.07051553 olivwalt Import finished

2006/07/05 14:55:21 br.com_EXTLIBS 1.0 Level 1 Update CPSELIBS.07051453 olivwalt Import finished

2006/07/05 11:18:21 br.com_EXTLIBS 1.0 Level 0 Update CPSELIBS.07051110 olivwalt Import finished

My IDE still shows only br.com_EXTLIBS 1.0 Level 0 Update.

The WebUI of CBS does not show me the version of the SC, but its DC`s contain the correct public parts.

If you don`t have a solution, i will create a oss message.

regards

Oliver

[Former Member]

Hi Oliver,

strange indeed. Even if you don't unsync the IDE should talk to CBS and show the DC as outdated, in unsynced state the information from CBS should be shown. If a sync produces a different result than what is shown on CBS I suspect some mixup in between.

Unless you are looking at the wrong buildspace I'm out of ideas.

Marc

[sid-desh]

Hi Oliver,

The step i see missing is that when you created a second track for the new SC you didnt checkin the SCA file of the EXTLIB SC. Hence you are not able to see the DC that are available.

Please do let us know know whether you have carried out this step.

Regards

Sidharth

[Former Member]

Hello Sidharth,

yes, you are right. We only created the project and deployed and transported it, therefor i that this will be enough to reuse this SC for additional projects.

When i put the pieces together, we have to transport the SC to the assembly stage, where a SC archive is built automatically, then we have to place this SCA into the import queue of new SC, which has a dependency on EXTLIB.

Is this correct?

regards

Oliver

[Former Member]

Yes that's correct. And to simplify the SCA import, you can create a Transport connection from the EXTLIB track to the track using EXTLIB.

[Former Member]

Hello Pascal,

that sounds much better now, thanks for the reply :). Two more questions:

1. Can i afterwards change the runtime systems of my defined track? Because i dont`t think, that i will need a cons and test system, for the library project. My dev should just end in a assembly stage, and then i can connect this track to my real development SC, which goes through all stages.

2. As above mentioned you desribed a second possiblity to use a External Library DC with a public part for assembly, but this can not be used for a different development configuration, is that right?

regards

Oliver

[Former Member]

Hi Oliver,

1. Yes, you can change runtime systems at any point in time. I'm not sure if the J2EE libraries of your EXTLIB SC will get deployed if you remove the runtime systems however. I think Required SC's (like EXTLIB in your other track) are only imported into the Development Configurations of a track, but not deployed to the runtime systems assigned to the track.

2. You should still be able to use this method (why not?), but in my opinion it's not the preferred solution.

regards,

Pascal