I was recently working on modifying one huge PI java development which involved lot of Java projects. The projects involved using libraries for:
- openSQL for optimizing data access for db2 databases.
- Reading configuration set for the application to set system specific properties
- Sending idocs via JRA
- Checking permission using security permissions API
And the development was executed as a Java job which sends a Java proxy message in some cases and as idocs in others.
As I was making changes to the project, I realized that the deployment was taking pretty long – it was taking around 2:19 minutes to perform the deployment of the two EAR files for the project
The two EAR files are around 5.5 MB together and hence it’s not surprising that the deployment takes so long. Development systems are always thin in terms of configuration and I was looking for ways to speed this up.
How to reduce the file size?
Assume we’ve an EJB project which gets deployed as an EAR. The same approach can be extended for any Java EE object.
The EJB project stays as is . The below screenshot shows the libraries required for build. We don’t make any changes here.
In the EAR project, we need to do the following ( after all, it’s the EAR project which gets deployed ).
1) The EAR project was set up to add the extra libraries. They need to be removed.
So it appears as follows after the change is done with all libraries removed.
2) To satisfy dependency at runtime, go to Javadoc for the class and find the DC.
eg. for NamePermission class the link is
and the DC info is :
Copy the DC name and replace / by ~ .So the value is tc~je~usermanagement~api.
Search for this in Java class loader in NWA.
So the entry to be added to application-j2ee-engine.xml will be :
Now, if we build the project and check the EAR file size, it has reduced a lot.
And the deployment takes much lesser time.
It’s down to 23 seconds from 139 seconds !
The same approach can be used for custom libraries if they’re being used in another project. This applies to PI adapter modules development as well since they get deployed as EAR files.
Using this approach, the deployments are optimized in both size and time. More importantly, it optimized the most valuable resource – a developer’s brain cycles which are not spent waiting . I also see it as aligned with DRY principle of software engineering. There’s one library doing a certain activity in a system.
Hope it’s useful for the developer community as more developments are created on Java stack .