| Warning | ||
|---|---|---|
| ||
This archetype is currently out of date, contains an internal project-only configuration, and should not be used. |
| Info | ||
|---|---|---|
| ||
WIP. POM contents have yet to be decided (although we are pretty sure the parent will not be the idp-parent). |
...
| Code Block |
|---|
git clone git@git.shibboleth.net:philsmart/java-idp-plugin-archetype |
...
Make sure you change the groupId, artifactId, pluginBase and vendor to appropriate values. Or omit them and you will be prompted to add them - or leave them as they are for testing
| Warning |
|---|
Running the install will cause maven to resolve multiple artifacts which are (currently) unknown to our signature checker ('The maven enforcer'). |
Project Structure
The archetype creates a multi-module Maven project; the aggregator (or the parent), and three submodules. There is a single submodule to handle the assembly/distribution of the plugin. For the other two, one submodule encapsulates implementation classes whilst the other encapsulates the plugin's public API. It is not always necessary to create a public API, instead developing solely against the IdP's public API that relates to the functionality of the plugin e.g. the authentication API. The module structure is shown in the table below:
...
- I think that now that 4.1 of the IdP is out the versions of the upstream projects should be pinned to 4.1.0 (OpenSAML and IdP) and parent project
- PS - pinned.
- It may also be worth aligning the version of the archetype to the IdP e.g. v 4.1.0 of the archetype is pinning to v 4.1.0 of the IdP etc.
- PS - pinned.
- The documentation probably needs to warn about using the java-parent project if you are not us
- PS - agreed, I just need to think through what happens if you don't so I can advise.
- I got confused between
-DarchetypeArtifactId=plugin-archetypeand-DgroupId=org.example.combut that was my fault and easily fixed- PS - so did I went I went back to it!
- I was going to suggest moving the Version stuff into impl, but my memory is that the tests fail and need care (because they don't run from the jar). So lets leave it there
- A
.gitignorewould be nice- Added
- The
<automatic.module.name>looked weird:net.shibboleth.idp.plugin.metadatagen.metadatagen.api- PS - the format here is `${groupId}.${pluginBase}.api` do you remember what $pluginBase was when you created the project?
- As did the
<Implementation-Vendor>FINISH</Implementation-Vendor>- PS - Added a
vendorparameter that defaults toFIXME-VENDORif not supplied.
- PS - Added a
- It would be nice if there was more templating in the
assembly.xmlfile