Jars not included in J2EE Library DC SDA

[Former Member]

I'm trying to create a J2EE Library DC that contains a few jar files (JUnit and JUnitEE) that I want to upload to the J2EE server for usage by a set of test classes.

I created an external library DC, imported the two jar files into the libraries folder, and added both jar files to both a compilation and assembly public part. I then built the DC. Great, the jar files are copied into the hierarchy under gen/default/public/assembly and gen/default/public/compliation. Everything seems to be in order.

I then created a J2EE Library DC, and added the external library DC as a used DC, with a build and run time dependancy.

When I build the J2EE Library DC, the two jar files are NOT included in the SDA file. Nothing I've tried can get the two jar files to be placed in the SDA file for deployment.

Why why WHY are the jar files not in the SDA? What am I doing wrong? I've spent the last while reading everything I can find on SDN about j2EE Library DCs, and it seems that I'm doing everything correctly - or am I?

I'm running SP16. Can someone verify that a) my procedure above is correct, and b) that this does work under SP16?

FYI, I have done this before, but not with SP16 - this is my first attempt. That said, I've always had problems getting the imported jar files to appear in the final SDA file....it's frustrating to say the least. DCs are wonderful things, but man, when they don't work, it's a royal pain in the rear end trying to figure out what's wrong.

[former_member212767]

Hi,

I've had the exact same issue, so if you could keep this thread updated with the results I'd be happy.

Kind Regards,

Jari Pakarinen

[Former Member]

Hi,

I've had the same issue, too. Does anyone have new

informations about the problem?

Kind regards,

Claus

[former_member192347]

I had similar problem with wrapping external jar in Development Component, in NW 2004s SP7 environment.

Here is how I solved it,

1. Open the .SDA file using WinZip.

2. Added the jar file to .SDA file.

3. Added following entry that was missing from provider.xml file

<jars>

<jar-name>mdm4j.jar</jar-name>

</jars>

4. Deployed the updated .SDA using SDM.

Abhay

[Former Member]

Hi Abhay,

So you mean that This process will hold good for any patch Level(SP16?) also?

If it works for SP16 Pls do let me know how to add the jar files into the .SDA file - Step by step procedure.

Thanks & Regards,

Sirisha.R.S

[Former Member]

I've noticed that from the latest SP levels, you must not create an entity reference to the public parts of the External Library DC, but you must create entity references to the jars inside the public parts of the External Library DC.

[Former Member]

You should all check the solution Ivan proposes in this topic: That worked very well for me.

[Former Member]

Hello Ken,

when I implemented newest JDI patch I didn't have problems with packing jars, but now I have problem with building sda. I don't know if it's related to the patch or I do something wrong. Please see this topic

Best regards,

Ivan

[Former Member]

I think I've confirmed that SP16 is broken with respect to J2EE Library DCs and External Library DCs.

I had sp15 installed on another server. I created a couple of test DCs to test out the packaging, and sure enough, it worked perfectly the first time - the jar file was packaged in the SDA file.

I then upgraded the environment to SP16, and went through the same steps. No jar file in the SDA.

I then re-built the original SDA file, and the jar file that was previously present in the SP15 build was not present in the SP16 build.

So, it appears that SP16 is either broken, or requires different handling of external libraries. I'll be opening an OSS ticket to try and get this solved.

Can someone confirm this on their end? A 5 minute test with a SP16 NWDS is all that's required......

[Former Member]

Hi Ken,

Yes, we have also experienced this problem. We have had to change our DC architecture to resolve it. Please let us know the result of your OSS ticket.

Thanks,

Jonathan

[Former Member]

Hi Jonathan,

we are to use SP 16 for development. can you please let me the change to the DC architecture that helped you resolve the issue.

Regards,

S.Divakar

[Former Member]

Did you define an Entity Reference from the J2EE DC's public part to the External Lib DC's public part? This is required to expose a public part of an encapsulated DC.

[Former Member]

Pascal, could you elaborate a bit? Previous to SP16, or at least in SP15, manually creating an entity reference was not required to get the packaged jar to appear in the generated SDA.

I tried to create an entity reference as you suggested, but the dialog tells me "There is no valid usage relation to the Public Part".

Do you have access to SP16, and if so, could you try to create a J2EE Library DC?

[Former Member]

As far as I am concerned you've always had to create an entity reference, which is in fact logical: You want a part of another DC's public part to become part of your DC's public part. You can only do this by creating a link (the entity reference) to the public part of the used DC.

The error you're getting can be caused by two things:

1. You didn't specify the DC as a Used DC with a Build Time dependency

2. You're selecting the wrong public part of the Used DC (they must both be of the type Assembly).

[Former Member]

Hmmm, perhaps this is part of the problem: here is the defLib.pp file which is automatically generated when you create a J2EE Library DC:

<?xml version="1.0" encoding="UTF-8"?>
<public-part ....>
	<name>defLib</name>
	<purpose>compilation</purpose>
	<caption></caption>
	<description></description>
	<entities>
		<entity>
			<name>sap.com~test~lib</name>
			<entity-type>SERVER_COMPONENTS</entity-type>
		</entity>
	</entities>
</public-part>

I created a new Server Library DC and changed the purpose to assembly, and then was able to create an entity reference. However, now I get this error:

createPublicParts:
  [pppacker] Packing assembly public part 'defLib'
  [pppacker] Packed   0 files for entity sap.com~zzz~lib (SERVER_COMPONENTS)
  [pppacker] Packing entity reference zzz/jars (sap.com), assembly:  ()
  [pppacker] ERROR: java.util.zip.ZipException: Access is denied

(sigh)

I'm not sure what SP you're running, but perhaps the later SP's understand the structure of External Libraries, and automatically propagate the references for you....at least, that must be what was happening with SP15, since it worked properly.

I think I'll install SP15 again, and have close look at the generated public parts, and see if I can't detect a difference.

[Former Member]

Hi, We are having the same problem. Things which used to work in SP 11 and SP 15 are not working any more. No Jars has been added to the SDA file.

Could you please share the SAP response?

Thanks.

[Former Member]

I'm still waiting - we've had a few exchanges, and Sap is current investigating.

Near as I can tell, the generated build scripts are broken in Sp16. In Sp15, there's a snippet in the build.xml file that does this:

<copy todir="D:src.dtcLocalDevelopmentt8A5BD61AD0687C82F61ED34994AAE013/sda" flatten="yes">
	<fileset dir="D:src.dtcLocalDevelopmentDCssap.comzzztestext_compgendefaultpublicassembly">
<include name="**/*.jar"/>
</fileset>
</copy>

This bit of code is missing in the SP16 build.xml file. There's a fileset definition, but the copy wrapper is excluded. The other strange thing is that the fileset definition looks at the src directory, and not the libraries directory.

I'll be sure to post an update when I know more.

[Former Member]

Thanks. As a work around we did installed another Developer Studio with SP 15, deployed Library to the server, and it worked.

Regards.

[Former Member]

Hi,

yes, there's an issue with the SP16 build plugins.

As another workaround you can create a "postbuild.vm" file in the cfg/-folder of the external library DC with the following content:

[code]

#StartProject("dummy" "build" ".")

#StartTarget("build")

#foreach($pp in $dc_public_parts)

<delete file="$/public/${pp.getName()}/PublicPartFileList.xml"/>

#end

#EndTarget()

#EndProject()

[/code]

This will simply delete the content descriptor for the public parts of the external library DC. Afterwards the Jar files are correctly included in the J2EE library.

Hopefully, SAP will provide a patch soon.

Best regards,

Marc

[Former Member]

I'll confirm that this has been marked as a bug. I'll follow up when a patch has been posted.

[Former Member]

Hi,

<i><b>As a work around we did installed another Developer Studio with SP 15, deployed Library to the server, and it worked.</b></i>

we are also working in the same issue. Could you please tell us the steps that u followed or any reference documents will do.

Thanks,

Nagarajan.

[Former Member]

Hi, the problem happens only when you have installed NetWeaver Developer Studio SP 16. So, you can install SP 15 (download it from Service Market Place) which doesn't have this Bug and succefully includes the Jars into the SDA files.

Hope this helps.

Regards.

[Former Member]

SP15 of the NWDS also has other issues - depending on the build version, SP15 does not properly handle DCs. I believe it forgets to create the .dcdef file, or soemthing to that effect.

Hopefully the forthcoming patch set against SP16 will stabilize the environment......

[Former Member]

Correct, the installation of the SP15 NWDS "forgets" to copy the .dcdef files. You can copy them manually by executing the following command from the eclipse/plugins folder of the extracted installation after you've run the installation:

xcopy /s /d .dcdef "C:\Program Files\SAP\JDT\eclipse\plugins"

[Former Member]

A patch has been released for the JDI. See note 935334.

Note that I don't think this patch addresses builds done from the Developer Studio, since the patch contains the build plugins. So, while you can create the DCs, they won't be properly built in NWDS, only in the JDI once the changes have been checked in.

I've asked SAP about a NWDS patch....

BTW, the above postbuild.vm code does work, so that can be used in lieu of a NWDS patch.

[Former Member]

Hi Ken

(Here is my guess)

When you create a project the build plugins are synced from the archive pool (JDI DB) into your NWDS so this should cause successful build of projects. However if you are creating local DCs then Build plugins delivered with NWDS is used. So depending on where you create your project the patch might or might not work

Regards

Pran