In software development, a general rule is to not reinvent the wheel. This meas: If there is already a library available, that does the job, use that library. Without this thinking, even the simplest projects would consume too much time in solving already solved problems. A drawback is that the project will depend on a lot of external libraries. Managing these library dependencies is important. Java projects are no exception to that. For instance, there are many standard classes available from Apache that everyone uses, but are not part of core Java.
In the Java world, two main tools help to take care of this: Maven and Ivy. Both allow to define the dependencies for each project and download them from a central repository. There are public accessible Maven repositories available and while it is easy to find there the needed library, it raises a simple question: is this the right way for your project to do?
Once published there, the library can be downloaded from anyone. Most probably, this is not what you want for your internal project. When you have several developers, makes it sense that each one is accessing the outside repository and downloads hundreds of MB when resolving the library devependencies? When a developer creates a new internal JAR, how to distribute it to the other developers? For code quality analysis, how to get the jars needed for a binary analysis?
There are solutions available for internal repository managers that also act as a proxy for public repositories. The most famous ones are:
- Nexus
- Artifactory
Installation, configuration and usage of both is simple. In case the Java project is already using maven or ivy to resolve dependencies, it is only changing the name of the repository server to the internal one. In case a project depends on an external library, the repository manager connects the public maven server and downloads them. As all developers are using the internal server, caches help to minimize traffic and reduce overall time needed to resolve a dependency. Libraries created by the Java projects can be uploaded to the internal repository manager and are automatically accessible by other developers. Maven and Ivy take care of this.
What about SAP Java jars? How to get these and publish to Nexus / Artifactory? SAP isn’t making them available in a public repository manager. There is also no other way given by SAP to import the jars. What you get are the SCs and DCs. NWDI is the repository manager for SAP Java, but when you use continuous integration, NWDI is not the best option.
Using NWDS and NWDI it is possible to sync all DCs to a local computer. This sync process creates a folder structure and copies the associated files, including the jar files. DCs have a public part concept, and each defined public part resolves to a jar file.
To get the jars, open the Development Infrastructure perspective in NWDS and select the DC to get the jar from and sync it.
Where are the files stored? In the workspace directory for NWDI projects. In my case, I have a workspace named test and only 1 NWDI connection (resolved to 0): <path>\test.jdi\0\DCs\sap.com
If you do this for all of SAP`s DCs, the directory will look like
The jar files are stored depending on their DC name.
Tc/je/usermanagement/api resolves to: <path>\test.jdi\0\DCs\sap.com\tc\je\usermanagement\api\. The jar file is stored in the standard directory, that is: _comp\gen\default\public\api\lib\java
This is the jar that needs to be uploaded to your repository manager server. This can be done manually or automated by a script. I developed a small script for that that also replaces the ~ with a . and that I can run from Jenkins.
In Artifactory, the artifact is shown with additional meta data, like age, size and download statistics.
Searching for a class is possible as well as browsing the content of the jar to see the individual class files.
- SAP Managed Tags:
1 Comment
