Age | Commit message (Collapse) | Author | Files | Lines |
|
Bump minor version in preparation for Amsterdam
branching.
Change-Id: Ia7e97a72053a2d1cd10c0b9d5c179817c3ac7e23
Issue-ID: CIMAN-120
Signed-off-by: Jessica Wagantall <jwagantall@linuxfoundation.org>
|
|
Released 1.1.1, now must bump patch by 1
Issue-ID: POLICY-436
Change-Id: I3f5e4c369575f6fe1fa06cabb96a5bd43cb11087
Signed-off-by: Pamela Dragosh <pdragosh@research.att.com>
|
|
Releasing v1.1.0 so need to update version to 1.1.1
Issue-ID: POLICY-436
Change-Id: I8b85de39bb3a32f5f4faeeb4fcdfb5d95291ae31
Signed-off-by: Pamela Dragosh <pdragosh@research.att.com>
|
|
Clean up a few "mso" references.
Disable 1.0.0 template build for now (note that some
references are still pointing to old mso).
Ie., see
https://git.onap.org/policy/drools-applications/tree/controlloop
/templates/template.demo.v1.0.0/template.demo
/src/test/java/org/onap/policy/template/demo/TestSO.java
Since this
is going away, rather than maintaining it, and changing this
code, disabling it for the build.
It will be deleted within the next few days.
Issue-ID: POLICY-162
Change-Id: Ibb819a318fbbb2b7f3aa14cdf76155bdec321024
Signed-off-by: Jorge Hernandez <jh1730@att.com>
|
|
This is work in progress, the official pom.xml with dependencies,
drl template, and support files for controller deployment
are maintained here. In the near future the junit template
should be consolidated with this one.
Added controlloop.properties.environment, this environment file
will be populated at installation time with the lab's aai url,
etc .. and will be accessible by any drools application such as
control loops through the PolicyEngine interface. Note that PDP-D
server already supports these environment files, so it is just natural.
Therefore, this is the default mechanism to provide to applications, the url, username,
and passwords to use at runtime by the control loops for the time being.
In the future MSB could set them globally here through existing APIs,
or it can be queried by any drools application using MSB library,
doesn't matter.
There's been some trouble playing nicely with the dependencies used
by a control loop application classsloader, and the pdp-d middleware one,
causing issues between dependencies version of libraries. Specifically,
the snakeyaml library does not play well across classloader when using
constructor functionality, note that the snakeyaml libraries are pulled
also from jackson parsers used in the pdp-d. I made a change in ControlLoopProcessor
to specifically tell the "Yaml" object which classloader to use in order to
find the class with the constructor that is intended to be built, otherwise,
yaml libraries use a different classloader that does not have visibility
into the ControlLoopPolicy that is trying to construct, and fails. This also
should respect junits that use the same classloader I pressume and does not
give issues.
Change-Id: I36271d29cdbf8ff861f9c03ff91cf7116927906a
Issue-ID: POLICY-162
Signed-off-by: Jorge Hernandez <jh1730@att.com>
|
|
Change-Id: I5f9bb3908f8d55c466dd847ae5e01a424e9ba364
Signed-off-by: Gao, Chenfei (cg287m) <chenfei.gao11@gmail.com>
Signed-off-by: Pamela Dragosh <pdragosh@research.att.com>
|