Bundle-ClassPath prefixed with comma prevents application from starting in TEA.

[artificialintellect]

Maven Plugin version: 1.3.1

Maven version: 3.2.5

Product : TIBCO ActiveMatrix Businessworks 6

Product version: 6.4.2

Component: Maven build plugin

Steps to reproduce the issue:

1. Create a new mavenized bw application and application module.
2. Add maven dependencies such that the MANIFEST.MF Bundle-ClassPath is updated with at least one external jar reference
3. Add a non external jar reference to the Bundle-ClassPath as the final entry (In my case the designer added .annoxfiles/ - but the for the purposes of the test manually modifying the classpath will likely work too)
4. Run mvn package

Additional environment details if any:

Describe the results you received: The build succeeds however after deploying the project to TEA the application will not start. TEA reports that the application is Impaired. Using the bwadmin tool I'm able to start the OSGI console and run the la command. This reports the following: Name : product-nrt.application:1.0 Bundle : product-nrt.application_1.0.0.201807311322 [431] Bundle Id : 431 State : Impaired ConstituentBundle(product-nrt.module_1.0.0.201807311322) ConfigState : InSync Modules : (OSGi Bundle) product-nrt.module 1.0.0.201807311322: Bundle Id : -1 Bundle State : UNINSTALLED Dependencies: ConstituentBundle(product-nrt.module_1.0.0.201807311322) EngineDep(Main=BWEngine[BW=6.3.800.012, BX=2.1.200.011, PVM=4.1.200.007, Alias=TESTDomain_ProductNRT_QA_AS_ProductNRT_QA_AN]) Unresolved Dependencies: See also 'lr' and 'dsr' commands for details ConstituentBundle(product-nrt.module_1.0.0.201807311322)

Describe the results you expected: I expect the EAR to run in TEA without error

Additional information you deem important (e.g. issue happens only occasionally): I worked with Tibco Support on this issue. They had me build the EAR via the designer's Create Enterprise Archive tool. This EAR worked without error in TEA (and running la in the OSGI console also showed the application module as resolved correctly).

I investigated the differences between the EAR created from the designer and the one created from the maven plugin and found that the biggest difference was the application module's MANIFEST.MF Bundle-ClassPath property. The key difference is that maven removes all of the external jar references and I end up with a classpath of ,.annoxfiles/,/lib/[*.jar]. If I manually update my MANIFEST.MF to be the same as the one created by maven and then build using the designer the EAR fails in the exact same way as when created through maven. On the flip side, if I revert the Bundle-ClassPath back to its original form (external:[jar],.annoxfiles/,external:[jar]) but then move .annoxfiles to be the first value in the list and build via maven the projects also runs on TEA just fine.

The end result is that when the first classpath entry is external: and you have non external: entries in the list then the list ends up prefixed with a comma and that prevents the application from starting correctly.

I debugged the tibco maven plugin a bit and found the issue seems to be in BWModulePackageMojo.removeExternals(). In there there is a check if start != 0 then add a comma. However external entries are counted when incrementing start. I believe start should only be incremented from within the check if (entry.indexOf("external == -1)). Alternatively you could do away with start all together and just check if the buffer is empty.

PS. I'm not sure how the classpath was messed up by having non-external entries not be first but since it is possible to get in that state I would definitely like to see this bug fixed as it took quite a long time to debug despite the final cause being seemingly trivial.

[NidhiRajeshDhoka]

@artificialintellect Can you please attach your MANIFEST.MF file or directly the project for our reference.

[artificialintellect]

I've attached 5 different MANIFEST.MF files.

• The first is the original failing source file.
• The second is the source file with updates to make it work.
• The third is the original failing source file that is in the application module jar file when the EAR is built using the designer.
• The fourth is the original failing source file that is in the application module jar file when the EAR is built using maven
• The Fifth is the updates working source file that is in the application module jar file when the EAR is built using maven

Let me know if you need any additional info.

01 - Source - Failing - MANIFEST.MF.txt 02 - Source - Working - MANIFEST.MF.txt 03 - Built from source failing (01) - Designer - Working - MANIFEST.MF.txt 04 - Built from source failing (01) - Maven - Failing - MANIFEST.MF.txt 05 - Built from source working (02) - Maven - Working - MANIFEST.MF.txt

[SujataDarekar]

Issue is fixed with Pull request #169. Hence closing the issue