Update:
What works is adjusting the root pom for each module one at a time in
dependency sequence - essentially simulating separate repos for each artifact.
I could have done separate pom branches together like java and python.
Gildas,
The docker and release jobs for logging are fixed (am through 1 of 6
releases) (just checking a recently red sonar)
Sending the release mail to Jessica for 1 of 6 so far
https://gerrit.onap.org/r/#/c/69736/
https://jenkins.onap.org/view/logging-analytics/job/logging-analytics-master-release-version-java-daily/254/
this is the sequence
remove all links between poms
at the root pom - enable a single jar/war project module one at a time -
release and then fix the poms at the end of the release process
1) logging-slf4j (jar)
2) logging-slf4j-demo (jar)
3) logging-library (jar)
4) logging-mock-service (jar)
5) logging-demo (war)
6) pylog (py)
Skipping both root poms, kubernetes, docker modules
Thank you
/michael
From: [email protected] <[email protected]> On Behalf Of
Michael O'Brien
Sent: Tuesday, October 2, 2018 6:15 PM
To: Gary Wu <[email protected]>; [email protected]
Cc: Prudence Au <[email protected]>; Jessica Wagantall
<[email protected]>
Subject: Re: [onap-discuss] Release procedure for repos with a pom hierarchy
that includes multiple war/jars per repo #logging #pomba #release
Gary,
Clearer - I'll follow this - won't do my two pom artifacts, I currently am
verifying doing one branch starting with logging-sl4j up to the war that
includes 3 jars - later I'll do the pylog and slf4j-demo branches (simulate 3
repos by rotating through 3 split pom branches - after a talk with Prudence).
I may bundle the entire pom project branch (3 jars + 1 war) into one release as
you suggested
Part 2 https://gerrit.onap.org/r/#/c/69692/2
Thank you
/michael
From: Gary Wu <[email protected]<mailto:[email protected]>>
Sent: Tuesday, October 2, 2018 4:22 PM
To: [email protected]<mailto:[email protected]>; Michael
O'Brien <[email protected]<mailto:[email protected]>>
Cc: Prudence Au <[email protected]<mailto:[email protected]>>;
Jessica Wagantall
<[email protected]<mailto:[email protected]>>
Subject: RE: Release procedure for repos with a pom hierarchy that includes
multiple war/jars per repo #logging #pomba #release
The ONAP way of doing releases is probably different from what you'd expect.
This is how it's typically done right now:
1. We don't commit a change of the pom version to remove the "-SNAPSHOT"
version; the "-SNAPSHOT" is left as-is in source control.
2. A separate daily job usually with "-version-" in the name runs a "mvn
versions:set" to strip the "-SNAPSHOT" version at job build time, resulting in
artifacts that are release-versioned and pushed to the nexus staging repo.
3. The "mvn versions:set" command is typically run against the root pom, and
is smart enough to recursively make the same change through all its
children/subtree poms, IF the children/subtree poms are set up correctly to
have their versions inherited from the root pom.
4. Given the above, it is fine for the "-version-" job to do a staging build
of multiple simultaneous artifacts from an entire tree.
This should work if all your artifact versions can be the same. I don't know
the specifics of your docker job, but if the above works for you on the
Java/Maven side then maybe what you need is to run the "mvn versions:set"
command within the docker job to strip the "-SNAPSHOT" from the poms like how
it's done for the Java builds.
Thanks,
Gary
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Michael O'Brien
Sent: Tuesday, October 02, 2018 12:46 PM
To: [email protected]<mailto:[email protected]>
Cc: Prudence Au <[email protected]<mailto:[email protected]>>;
Jessica Wagantall
<[email protected]<mailto:[email protected]>>
Subject: [onap-discuss] Release procedure for repos with a pom hierarchy that
includes multiple war/jars per repo #logging #pomba #release
Team,
Bringing this up to the community because we have a couple general
questions around how to release projects with many artifacts per repo.
Running into an issue where I need to 1 artifact at a time but the jobs
and my pom structure is set for a single global build.
Prudence, Jessica and I are looking into this - adding community - if
there are any others with my same issue.
Either I need to flatten and disassociate my pom tree or find a way to
build specifically at folder level - not from the root pom.xml of the repo.
Release a specific jar
https://git.onap.org/logging-analytics/tree/reference/logging-slf4j/pom.xml
instead of the default root which builds 5 jars and 1 war (leaving out the
non-java pom projects for python, kubernetes and docker
https://git.onap.org/logging-analytics/tree/pom.xml
We are working very closely with Jessica right now and in the past on our
repos and now on our release of the 2 projects logging and pomba - but running
into issues with the release job failing because I have one release job for all
my artifacts.
https://gerrit.onap.org/r/#/c/69618/
This is the first release of either project (pomba is new, logging has a
deep pom structure in Casablanca)
We are having an issue with a conflict between the release job expecting a
single root pom.xml
Pom structure
logging-analytics (root) (pom)
+ logging-reference (pom)
+ logging-demo
+ logging-docker-root
+ logging-kubernetes
+ logging-library
+ logging-mock-service
+ logging-slf4j
+ logging-sl4fj-demo
+ logging-pylog (pom)
Jar/war dependencies
+ logging-demo
+ logging-library (can be removed)
+ logging-mock-service
+ logging-library
+ logging-slf4j
+ logging-sl4fj-demo
+ logging-sl4j
The issue is how do we deal with projects that have multiple artifacts
per repo (1:m)? I may have created a special case where I use 1 repo to create
a war and several dependent jars - where I should have requested more repos to
keep it (1:1)
In pomba there are several repos each with one pom and one artifact -
this is good.
In logging because there is only one repo - there is a tree of folders
each with their own pom with pom, war and jar artifacts like the following
The logging project follows a similar but different structure to
ccsdk/slk and sdnc/oam for example - except that my root pom's parent is
oparent.
Ccsdk and sdnc all reference their parents to odlparent-* whether 1 or 2
levels deep in the project.
So I am also wondering if there are any other projects out there
following a pom.xml structure where there is a single root with multiple levels
of subchild poms where each level references the level above - not the same
root level 0
Others:
Root
+ child-level1 - references root
+ child-level2 - references root
Mine:
Root
+ child-level1 - references root
+ child-level2 - references "child-level1"
It is also significant whether the child/subfolder poms are pom
artifacts or war/jar artifacts.
I tried
* Adjusting the version (1.2.2-SNAPSHOT to 1.2.2) from the root down - this
won't work because the docker build kicks in for all the artifacts expecting
1.2.2 - Prudence pointed out I was doing the reverse and should work my way up
from the leaf poms - which makes sense when I thought about it - they have no
dependencies on the rest of the repo.
* Working my way up from for example the slf4j-demo jar (At the bottom of
the pom tree) - works only if I "mvn clean install -U
Questions
Q1) the Jenkins release job targets the root pom.xml of the repo
- but this will build all the artifacts - so either we release all the
artifacts at the same time or we
Q2) the pom.xml hierarchy is derived from the parent reference of
each subtree - not from the parent itself - therefore we can only change the
parent references to the root pom.xml in sequence starting with the leaf slf4j
- but then the Jenkins job would not pickup the pom.xml deeper in the folder
structure (would be reverted when we finish releasing all artifacts)
Q3) try adjusting my pom structure so it is flat like sdnc/oam or
ccsdk/sli - where all multi-level subtree poms reference a single root.
I might have missed something in this mind dump
Thank you
/michael
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
This message and the information contained herein is proprietary and
confidential and subject to the Amdocs policy statement,
you may review at https://www.amdocs.com/about/email-disclaimer
<https://www.amdocs.com/about/email-disclaimer>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12816): https://lists.onap.org/g/onap-discuss/message/12816
Mute This Topic: https://lists.onap.org/mt/26675742/21656
Mute #logging: https://lists.onap.org/mk?hashtag=logging&subid=2740164
Mute #pomba: https://lists.onap.org/mk?hashtag=pomba&subid=2740164
Mute #release: https://lists.onap.org/mk?hashtag=release&subid=2740164
Group Owner: [email protected]
Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
