/ Development  

How to create an AppWorks package

Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

And this is the time where we export our current solution (crafted in ‘Development’) to a package that can be installed/deployed to the next environment (e.g. ‘Test’). Let’s see what we can do on the package creation action and what exactly is created.

Let get right into it…

Let’s first spin up our regularly used development image and check out what we have so far for our solution…

package_001

Let us first focus on the package properties for now by right clicking the project and select the corresponding action

package_002

What do we see in this screen?

package_003

Most of the fields are filled in by default based on the information you provided when we created a new workspace together with the project.

But the other actions might need some explanation and later we play with the settings to see the results in real life:

  • ‘Package for’ will create a .cap file (you’ll see later)

    • ‘Run Time’ is the default and the most used setting. It will deploy the application directly into runtime for the end-users.

    • ‘Staging’ is a kind of in-between ‘Staging area’ pre-deployment where you can manipulate certain artifacts (e.g. ‘Business Calendar’s’ and ‘Schedules’) configurations that are specific for an environment before you publish it to the ‘real’ runtime environment, but also with some consequences (see the OpenText Documentation delivered with the suite).

      As the for ‘Staging’ packaging is not commonly used we’ll skip that one for now. After some discussion with other consultants it’s also not used that much which relieves me a bit as we also had some troubles to make it work now on our image!). Better keep focus on the good stuff…for now!

      Other notes we found in the documentation also tells me to avoid the for ‘Staging’ packaging option:

      package_003_1

  • ‘Create Model Package‘ will create a .mpk file and makes it possible to modify existing models in other applications to your own needs (you’ll see later).

    • Only available for ‘Runtime’ packages

  • ‘Supported Deployment Spaces‘ is where the package can be deployed

    • ‘Shared’ makes the package accessible over all the organizations and is the most common option for your solution

    • ‘Organization’ makes the package available only within the organization where it is deployed (also only for those users within the organization).

      This is useful when the AppWorks platform instance is used for deploying packages for different customers

  • ‘License Agreement‘ tab makes it possible to add some license information to your solution and even specific license agreements on the java archive files that include your custom written code. More information about possible license agreements can be found here as an example.

    package_004

Close the ‘Package Properties’ screen and let’s first create a new package with the default settings…

Packaging for runtime and check out the result

On the project right click and select the ‘Create Package’ action

package_005

And after some seconds you see some results like this where you can directly download the package (but when you hit close you can also ‘Download latest Package’ from the menu as you probably noticed!)

package_006

What do we get after that download?

It’s a file called ‘AppWorksTips AppWorks 1.0.0.cap’ and that matches all the settings of the ‘Package Properties’ we just saw.

Let’s open this file with 7-zip

package_007

It’s a little bit different from the what is stored the SVN, but this is always the case as SVN stored the ‘sources’ of the project and the .CAP file is a ‘runtime’ extraction from the sources!

package_008

Packaging for a specific organization and what makes it different from the ‘Shared’ package option

Add the ‘Organization’ mark in the package properties and package again…

package_009

Let’s see what WinMerge has to say after the old and new .cap files are extracted to separate folders like this

package_010

We see one (expected! change in the file)

package_011

We’ll see more difference once we start to deploy the package in our environment in the next post.

Next is de option ‘Create Model Package’, but what’s in it?

Mark the option in the ‘Package Properties’ and recreate a new package that you can download again for a compare!

package_012

The first thing we see is that 2 files are downloaded

  • ‘AppWorksTips AppWorks 1.0.0.cap’ that we already saw
  • ‘AppWorksTips AppWorks 1.0.0.mpk’ which is a new file!

Let’s extract it with 7-zip to see the results. You might have noticed that it matches with the entity information (= the model) saved in SVN for our project!

package_013

So, now you see that it is indeed a reusable package for other solutions, but now 2 questions might be valid to ask.

  1. How do we reuse this in a new solution?
  2. What has this reusability to do with ‘Enable reuse in other applications’ option on the entity properties

package_014

We will cover both questions in a separate post!

Adding a license…

Not required, but if you want to ‘protect’ your created solution that is your way to go. Here you can add the license agreement which ‘leases the rights to the legally protected piece of intellectual property’

First choose a license like for example the ‘MIT license’ and copy the text to your clipboard.

Now just create a new file called ‘LICENSE.txt’ (extension .txt or .html is required!), paste the text content into the file and upload this file into your project space.

package_015

Browse for you created license file and upload it to the project

package_016

Open the package properties again and go to the ‘License Agreements’ tab. Browse for the uploaded license file and select it for usage in the package.

package_017

Once selected we’ll create a new package and see how the license is used in the .CAP file

package_018

Small note that the created .mpk file does NOT have this information!

One big final question I have: “What changes for our beloved end-users after a second package with new features (in a new package version) is deployed in the already in-use environment?

Also, this one, my AppWorks friends, is placed on the backlog for further investigation!

And this makes this post an enough ‘DONE’ where we learned about packaging. What we should do and what we should not do. Also, some questions where raised that we’ll cover in other posts…They are placed on the backlog. Next step is to deploy this package (the .cap file) on a clean environment. See you in the next week’s most interesting post.

Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The AppWorks guy”?