aboutsummaryrefslogtreecommitdiffstats
path: root/bpmn/pom.xml
AgeCommit message (Collapse)AuthorFilesLines
2017-10-19Restore MSOMockServer to the buildRob Daugherty1-2/+1
Classes in this artifact are needed for unit tests. For a long term solution, we should find a way to build these classes into a test-scoped artifact. Issue: SO-242 Change-Id: I1a57fead07250c841a9f59afb805aea26c7bc102 Signed-off-by: Rob Daugherty <rd472p@att.com>
2017-10-12Build support for Camunda EE CockpitRob Daugherty1-0/+1
The community edition Camunda Cockpit does not have the capability to inspect a running or completed process. This makes it useless for debugging purposes. If a user has an enterprise license, it should be possible to build SO using the enterprise version of Camunda. This commit modifies the SO poms so that the camunda version may be specified on the maven command line, as follows: -Dcamunda.version=7.7.3-ee -Dcamunda.bpm.webapp.artifact=camunda-webapp-ee-jboss-standalone A maven repository containing the enterprise artifacts (in this case, 7.7.3-ee) would also need to be provided at build time in the maven settings.xml configuration. Issue: SO-216 Change-Id: Idff63ce70475299924333b37aa51f8d963adf568 Signed-off-by: Rob Daugherty <rd472p@att.com>
2017-10-10Merge "Change bpmn surefire plugin to reuse forks"Seshu Kumar M1-1/+1
2017-10-10Change bpmn surefire plugin to reuse forksRob Daugherty1-1/+1
This is how it was prior to the SO-193 fix. Some unit tests are now failing in the jenkins environment. Maybe this will help. Issue: SO-193 Change-Id: Idac2a25e2f85581aaceaae10b8eacb5f312b2a70 Signed-off-by: Rob Daugherty <rd472p@att.com>
2017-10-10Delete unwated codeseshukm1-1/+1
Change-Id: I05931195c51f171a59bb8f831e8fbbf7fd7ea11f IssueId: SO-202 Signed-off-by: seshukm <seshu.kumar.m@huawei.com>
2017-10-08Fixes for sonar coverage in bpmnRob Daugherty1-5/+3
1. Coordinated jacoco and surefire JVM arg line options 2. Changed sonar plugin version to 2.19.1 3. Removed dead code (unused classes) Issue: SO-193 Change-Id: I21b7a77510eec71f4d4ca9afde5b7f86f0e3cbd7 Signed-off-by: Rob Daugherty <rd472p@att.com>
2017-09-29Fix the SO build issuesDeterme, Sebastien (sd378r)1-150/+113
Fix the AAI java package names that was still openecomp, remove the variable for LF repositories due to Oparent, Fix the jacoco to overwrite the oparent settings (fix test coverage) Change-Id: I40b9b326e33ff27992a1bf2cc9d3094d338f8828 Issue-ID: SO-168 Signed-off-by: Determe, Sebastien (sd378r) <sd378r@intl.att.com>
2017-09-081710 Rebase - Second AttemptArthur Martella1-6/+1
This commit rebases changes from openecomp-mso/internal-staging-1710 up to and including this codecloud commit: 54483fc6606ddb1591a2e9da61bff8712325f924 Wed Sep 6 18:12:56 2017 -0400 Rebasing was done on a branch on top of this commit in so/master in ONAP: 93fbdfbe46104f8859d4754040f979cb7997c157 Thu Sep 7 16:42:59 2017 +0000 Change-Id: I4ad9abf40da32bf5bdca43e868b8fa2dbcd9dc59 Issue-id: SO-107 Signed-off-by: Arthur Martella <amartell@research.att.com>
2017-08-04Another attempt to fix deploy problemRob Daugherty1-1/+1
The top level pom will contain: <groupId>org.openecomp.so</groupId> <artifactId>so</artifactId> Child modules will contain: <parent> <groupId>org.openecomp.so</groupId> <artifactId>so</artifactId> <version>1.1.0-SNAPSHOT</version> </parent> <groupId>org.openecomp.so</groupId> <artifactId>some-child-artifact</artifactId> Note that the groupId for the direct child module will be the same as the groupId for its parent. Issue: SO-21 Change-Id: I1976819df459d92937c6a4780959c32599dc3e71 Signed-off-by: Rob Daugherty <rd472p@att.com>
2017-08-04Failed to deploy so artifacts in nexus (again)Rob Daugherty1-2/+2
There are Linux Foundation rules (enforced by nexus) that I still don't really understand. I'm convinced this is absolutely true: The groupId of every artifact in a project MUST begin with: org.openecomp.<project> --or-- org.onap.<project> The top-level artifact is no exception. So for example, this is NOT allowed: <groupId>org.openecomp</groupId> <artifactId>so</groupId> Here's what I'm trying now. The top level pom will contain: <groupId>org.openecomp.so</groupId> <artifactId>so-parent</artifactId> Child modules will contain: <parent> <groupId>org.openecomp.so</groupId> <artifactId>so-parent</artifactId> <version>1.1.0-SNAPSHOT</version> </parent> <groupId>org.openecomp.so</groupId> <artifactId>some-child-artifact</artifactId> Note that the groupId for the direct child module will be the same as the groupId for its parent. Issue: SO-21 Change-Id: I0d3cd2eb7a1883e23e3c0878ee7fa3dd4a7d55b2 Signed-off-by: Rob Daugherty <rd472p@att.com>
2017-08-01Failed to deploy so artifacts in nexusRob Daugherty1-3/+3
More problems encountered since mso repos were renamed. We now have found that this declaration in the top-level so pom causes the deploy to fail with a 403 Forbidden error: <groupId>org.openecomp</groupId> <artifactId>so</artifactId> We are changing this to: <groupId>org.openecomp.so</groupId> <artifactId>framework</artifactId> Issue: SO-21 Change-Id: I4e21d689c73c5071bde725127bb81482ce3d91f9 Signed-off-by: Rob Daugherty <rd472p@att.com>
2017-07-19Fix artifact group IDs (org.openecomp.so)Rob Daugherty1-2/+2
Since the repositories were renamed from "mso" to "so" the artifact group IDs in the poms must be updated to match. Issue: SO-39 Change-Id: I617fe738a77d0f6c1d1cc0ac9474fb753f4e234c Signed-off-by: Rob Daugherty <rd472p@att.com>
2017-04-11[MSO-8] Update the maven dependencyxg353y1-21/+24
Update the maven depenency for sdc-distribution-client to cooperate with the sdc changes. Change-Id: I2da936e5c40cb68c7181bb78307192dd5655b5dc Signed-off-by: xg353y <xg353y@intl.att.com>
2017-03-13Update to version 1.1.0ChrisC1-9/+9
Change-Id: Id054e7a04ce88450c3cfe108c8259c4d287681c8 Signed-off-by: ChrisC <cc697w@intl.att.com>
2017-01-31Initial OpenECOMP MSO commitChrisC1-0/+159
Change-Id: Ia6a7574859480717402cc2f22534d9973a78fa6d Signed-off-by: ChrisC <cc697w@intl.att.com>