Hard coded artifact bundle names and un-maven like conventions makes it impossible to create standard maven projects

[bertramn]

Not sure how to sell this issue other than "here is some customer feedback". Albeit most of the issues below can be overcome, it comes at a great deal of inconvenience and fighting for standard practice. Below some thoughts on how a more maven'ish experience can be created for the plugin users.

Issues

1. Configuration over convention

Instead of following the maven convention for the construction of apiproxy bundles, the apigee-edge-maven-plugin insists on custom maven properties that must be configured by a developer.

2. Using ${project.name} as the artifact identifier is a (double) bad idea

If the developer does not explicitly sets projectName on the apigee plugin, the plugin will use the project.name property by default as proxy identifier. For a (standard) pom like this:

<project xmlns="http://maven.apache.org/POM/4.0.0">
  <modelVersion>4.0.0</modelVersion>
  <groupId>foobar</groupId>
  <artifactId>apigee-example-proxy</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <name>API :: Apigee Example Proxy</name>
</project>

the plugin will either generate an invalid zip file:

/home/fred/workspaces/apigee-example-proxy/target/API :: Apigee Example Proxy1.0.0-SNAPSHOT-null.zip (The filename, directory name, or volume label syntax is incorrect) -> [Help 1]

OR if the file name happens to work (e.g. just white spaces) the plugin will generate an invalid resource URL to apigee edge management API:

https://api.enterprise.apigee.com/v1/o/fredinc/apis/API%20Apigee%20Example%20Proxy

3. Trouble using external environment configuration only

E.g. if we use externally provided JVM/pom properties to drive packaging and deployment instead of the magical config.json file that needs to be checked into the source (smell), the plugin will get its nickers caught in a twist because the profile id is hard coded in the bundle name generation. If we do provide a profile id, the plugin falls over because it cant find the file and refuses to validate.

Also the hard coded formatting on GatewayAbstractMojo.java line 262 is missing a dash between the artifact and version number and includes null for a profile id was not provided nor is required.

${project.basedir}/target/apigee-example-proxy1.0.0-SNAPSHOT-null.zip

4. Having to re-create each bundle from source for each environment

Leads us to a conversation about releasing a build once. The plugin assumes that a developer will just spin a maven build, nominate the environment and the apigee proxy sources are (re)packaged and deployed for that specific environment. Whilst the concept looks appealing on the surface, the result is a different build running in any environment. This is not how good software is delivered . period.

It also leads to bizarre errors such as the one outlined in item 3.

Recommendations

1. Work with maven conventions

• try to stay within the maven workflow and use standard conventions instead of custom crafted conventions.
• don't default to project.name knowing that maven uses artifactId to generate resource bundles (unless overridden)

2. Use existing maven capabilities

Use resources or assembly plugins instead of creating yet another weird and wonderful way of creating a zip file to upload to a server.

3. Separate task types

the configuration item GatewayAbstractMojo#apiType kind of suggests that there are different types of packaging and validation required. A better approach in maven is to turn these into goals, side benefit is much simpler code in the maven plugin.

4. Externalize Configuration

Find ways to externalize configuration from runtime code. This makes bundle deployment and overall management much simpler and makes the process auditable. Other integration platforms also have a concept of environment customization but these are applied at deploy time and not at build time. A feature enhancement no doubt but definitely a big plus for your platforms developer experience.

[masterspambot]

Any update in here?