Module Group support in Zero

The CLI will ship bootstrap.properties and it will contain information regarding the default URL(s) of a given modulegroup. Our installers will either have burned in the initial values based on the installer or adjust the values based on the installation values.

When a task is invoked, we look at the current application, if cli.tasks is resolved, we invoke the command using the current resolved.properties. If cli.tasks is not present, then we invoke the task using the zero.cli resolved.properties. If the task being executed requires the modulegroup value, we first look on the command line, then we look at the app's history, and finally we use the cli. Note: this was decided by Michael and Jason on Friday

We realize that you may specify a modulegroup on the command line and the tools that we are using are from another modulegroup. That is ok. We are willing to live with this discrepancy. We can at least explain how tasks are invoked and explain how to get them sync'ed if its that important. We are probably putting too much pressure on the idea that people are going to be switching between rather than picking one or having the other for very specific applications.

We should walk up the current directory to determine if we are sitting within an application and execute it as such.

The default module group will be set in the resolve.history file packaged in the cli zip. Did not add this yet, the default is still in local.properties until we can change the installer.

Walking up the current directory

There are two aspects of walking up the directory path. The first is setting up zero.core.Main from the script. The second is for the tasks so the can find .zero files.

Apphome

The script needs to walk up the path to see if it can find the config directory so that -apphome can be set correctly for zero.core.Main. The implementation will still look for config/ivy.xml, since all zero applications have to have an ivy file. The app_home that is found is passed to zero.core.Main using -apphome for the dependency aggregation.

Approot

Programmatically, we need to figure out where .zero is so we can read/write the zero meta data like resolved.properties and history. We have to be selective how we deal with user.home. For example, create will use user.home to create the application where the zero command is invoked from, but some other commands like version, resolve, compile, etc need to be able to determine where the root of the application is so it can use .zero files. Note, the apphome set it the script can be obtained from the gc.

Bootstrap properties file

The bootstrap properties file is used to get the hosts

zero create app -mg=bvt

The create command will run with the module group that the cli is configured to, but will pull the zero.application.template from the specified module group and will resolve the application against the specified modulegroup. The new application will use the specified modulegroup as long as it has a .zero/shared/resolved.history file. If this file is deleted, then the application will be resolved using the cli's module group if no module group is specified.

zero modulegroup_create

Note: this changed The modulegroup_create will generate the site.xml for the specified modulegroup using the z.c.t that the cli is pointing to. The modulegroup_create command does not actually get artifacts from the new host. The first command that tries to use the new module group will cause the download of artifacts.

We talked about using the template from the new host, but this was problematic. I was able to get the new z.c.t and get the artifacts expanded so the modulegroup_create command could find the new template. The problem is the z.c.t from the cli can not be used to create the site using the site.xml template from the new z.c.t, can't mix cli and templates yet. The modulegroup_create command needs to also have templates for zero and maven resolvers that get invoked. I didn't get this implemented so for now the modulegroup_create will use the current cli to create the site.xml for the new modulegroup.

Getting the -modulegroup from args ( future )

following bat seems to work for windows side. equals are split

@echo off
@setlocal
rem tested with text create -modulegroup=bvt
set modulegroup=
:Main
if /i "%1"=="" goto :ExitBatch
if "%1" == "-modulegroup" (
   echo found module group
   set modulegroup=%2
   goto ExitBatch
)
shift
goto :Main

:ExitBatch
echo %modulegroup%
@endlocal