This document guides the reader through creating a fresh IdentityIQ project with Eclipse, the Services Standard Build (SSB), and IdentityIQ Deployment Accelerator (IIQDA). This setup enables the IdentityIQ project to be built and deployed (via SSB or IIQDA or both), while also preparing the same for inclusion in a source code repository.
Each of the examples below assume you have cloned the repository to a location that makes sense for your developer tools. Keep track of this location, as you'll be headed back to work from it frequently enough for commits and other ad-hoc work outside of Eclipse.
Each walkthrough assumes you have Eclipse installed and the IIQDA plugin installed.
These examples use Eclipse Neon + IIQDA 3.0.1 (20170227-1747).
It is assumed SSB is also at work here. You will see references to SSB build commands to make IIQDA work properly in this walkthrough.
The example files here assume the Oracle JVM 1.8 is used.
Below are a few examples, each with a different starting point to cover the most common use cases.
This walkthrough assumes you have a valid .project
file in your repository and that IIQDA nature has already been added to it.
See examples below if you need to verify.
This walkthrough assumes you have a valid .project
file in your repository and that IIQDA nature has NOT already been added to it.
See examples below if you need to verify.
.project
file to include both the IIQDA nature and buildCommand
(see example of working .project
file below), then save changes.classpath
file to look like the example in this article, then save changesbuild main
with the SSB to create the identityiq.jar
and commons-logging-1.1.3.jar
required for full IIQDA functionality
.classpath
example shown below utilizes a relative project path (which is portable but requires at least 1 build first to make it available)
This example assumes you do NOT have a valid .project
file in your repository. This might be because you have a brand new repo or the repo has been under source control without a .project
file (i.e. someone didn't check that file in for some reason or others used another IDE or editor previously that did not use .project
, as that is Eclipse-specific).
.project
& .classpath
file set for you to edit later.project
file to include the IIQDA nature & buildCommand (see example of working .project
file below) - save changes.classpath
file to look like the example in this article - save changesbuild main
with the SSB to create the identityiq.jar
and commons-logging-1.1.3.jar
required for full IIQDA functionality
.classpath
example shown below utilizes a relative project path (which is portable but requires at least 1 build first to make it available)
In the absence of any specific team guidelines, consider that putting .project
and .classpath
files for Eclipse in source control means saved time - as no one else has to learn and work with a "raw" file set w/o any Eclipse functionality. The first developer establishes the IIQDA and Eclipse project file set and all other developers can simply import an established Eclipse project into their workspace.
Thus, the general recommendation is to put .project
and .classpath
into source control (as everyone editing the project should be using the same configuration, Eclipse version, etc.).
Here are examples of each file for a working example of a faceted Eclipse project with Java + IIQDA (.project
file + .classpath
file).
Example .project
file:
<?xml version="1.0" encoding="UTF-8"?> <projectDescription> <name>IdentityIQ</name> <comment></comment> <projects> </projects> <buildSpec> <buildCommand> <name>org.eclipse.jdt.core.javabuilder</name> <arguments> </arguments> </buildCommand> <buildCommand> <name>sailpoint.IIQ_Deployment_Accelerator.IdentityIQ.iiqArtifactBuilder</name> <arguments> </arguments> </buildCommand> </buildSpec> <natures> <nature>sailpoint.IIQ_Deployment_Accelerator.IdentityIQ.iiqNature</nature> <nature>org.eclipse.jdt.core.javanature</nature> </natures> </projectDescription>
Example .classpath
file:
<?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="servicestools"/> <classpathentry kind="src" path="src"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/JavaSE-1.8"> <attributes> <attribute name="owner.project.facets" value="java"/> </attributes> </classpathentry> <classpathentry kind="output" path="bin"/> <!-- added for supporting iiqda - note the "build/extract" location won't be present until a "build main" is run with SSB --> <classpathentry kind="lib" path="build/extract/WEB-INF/lib/identityiq.jar"> <attributes> <attribute name="javadoc_location" value="build/extract/doc/javadoc/"/> </attributes> </classpathentry> <classpathentry kind="lib" path="build/extract/WEB-INF/lib/commons-logging-1.1.3.jar"/> </classpath>
You can add XML DTD assistance when editing XML artifacts. This is similar to code completion we are used to with Java files in IDEs, but for XML documents.
The DTD validates and guides with respect to format of elements and attributes.
Note that it will not provide assistance with specific key names or values for entries in sailpoint.object.Attributes
(as those are not in the DTD), but it will help in many other ways (like overall structure and permitted nesting of elements and attributes).
This DTD adjustment generally done is per-user for Eclipse. It can be project-specific, but such settings will likely not be in source control (nor should they be). Thus, the following steps highlight this change from an Eclipse-wide perspective. You need an established Eclipse project and you should run the SSB build main
target at least once, as this creates the DTD in the build/extract area (which we refer to next).
Start in Eclipse -> Window menu -> Preferences and then:
sailpoint.dtd
DTD file there with a version number on it - select itpublic id
sailpoint.dtd
Note the "key" we mentioned should look familiar - e.g. <!DOCTYPE Application PUBLIC "sailpoint.dtd" "sailpoint.dtd">
.
Now open an XML artifact - a CTRL + Space (on PC) brings up code/markup assist features. A sample screenshot below shows this feature with a workflow XML document.
FYI, the .project file listed here is only valid with the 3.x plugin and earlier. The IIQDA 4.x was renamed so the build command and nature needs to be updated here. This is documented in the actual IIQDA installation and user guide, but was never updated here.
Here's what it would look like for the latest 4.x+ IIQDA plugin:
<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
<name>IdentityIQ</name>
<comment></comment>
<projects>
</projects>
<buildSpec>
<buildCommand>
<name>org.eclipse.jdt.core.javabuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>sailpoint.IIQ_Deployment_Accelerator.IdentityIQ.iiqArtifactBuilder</name>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>sailpoint.IIQ_Deployment_Accelerator.IdentityIQ.iiqNature</nature>
<nature>org.eclipse.jdt.core.javanature</nature>
</natures>
</projectDescription>
Thanks for the prompt here - updated the doc to better fit the new compass stuff and added that nature change.
Thank you for this; it's particularly helpful. One thing that I noticed is that it doesn't appear to have instructions for setting up an Ant build configuration (under External Tools). (Basically, the configuration would point at the SSB's build.xml.) Since I've seen this done by one organization, I want to ask: is setting up an Ant build configuration (pointed at build.xml) necessary? Or, if not necessary, is it at least helpful?