Hi Christophe, Gary, Andy, I’m trying also to build projects on a local Jenkins and I’m facing some issues related to the nexus-staging-maven-plugin. I am reaching out to clarify a few things :
1) On the nexus-staging-maven-plugin documentation page (https://github.com/sonatype/nexus-maven-plugins/tree/master/staging/maven-plugin), it states that it’s mandatory to have the Nexus Repository Pro version to leverage the staging feature. Can you please confirm ? 2) Is there any – quick - workaround to build all projects and skip the staging step if we want to stick with Nexus Repository OSS version ? 3) I understand that all the staging process was meant to be temporary, and to add on Gary’s last question, what is the plan moving forward and how could we contribute to that effort ? Thanks, Sébastien On 2017-05-16, 1:30 PM, "onap-discuss-boun...@lists.onap.org on behalf of Gary Wu" <onap-discuss-boun...@lists.onap.org on behalf of gary.i...@huawei.com> wrote: Hi Christophe, Thanks for adding the historical context. If I understand correctly, the staging approach was meant to be temporary right before a release. Is a release imminent, or has that been canceled? What's the current timeline to move all the artifacts back to SNAPSHOT versioning (and remove Staging repo from build dependencies) in preparation for active ONAP development? Thanks, Gary -----Original Message----- From: Closset, Christophe [mailto:cc6...@intl.att.com] Sent: Friday, May 12, 2017 5:52 AM To: Gary Wu <gary.i...@huawei.com>; Andrew Grimberg <agrimb...@linuxfoundation.org>; onap-discuss@lists.onap.org Subject: RE: [onap-discuss] Staging repo in settings.xml Hi Gary, Andy, As for the OpenECOMP history, the whole original idea was also to align everyone's release number and date to a common one for the launch (the current release-1.0.0 branch). Concerns were raised in the dev teams (as you pointed below) that everyone's pace would be different eventually and that we should have a way of releasing components independently even though we have serious inter dependencies within ONAP. So instead of a MEGA build - all components have their independent release jobs building on staging. This hybrid approach somehow suited us nicely, now we did not go through the blessing process to move all these to proper release artifacts and kept moving with this in the master branch as Andy explained. I agree that it's confusing and not ideal right now (the concept of not really released 'release artifacts' is puzzling at first but we got used to it). If (and that's probably a TSC decision to make) we want to move to a fully decoupled model - which with the number of repositories growing is probably a good idea - then we should also remove the joint numbering somewhat (TSC) so that components can truly release independently. This indeed brings the issue of managing dependencies in a non-intuitive manner (I'm building ONAP release X and I see dependencies with strange numbers, potentially from previous ONAP releases )and would need to be adopted by the community as well. One benefit of the staging approach is that it allows to limit version variance during a stabilization period. Staging should be limited in time, probably for a period at the end of the official release cycle when everyone's artifact are mostly ready. The Release Candidate approach is another way of achieving this I believe. Regards Christophe -----Original Message----- From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Gary Wu Sent: Friday, May 12, 2017 12:29 AM To: Andrew Grimberg <agrimb...@linuxfoundation.org>; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] Staging repo in settings.xml Hi Andy, thanks for the explanation. It sounds like this will require a larger discussion on the overall versioning and release strategy across ONAP projects and artifacts. For everyone's reference, in OPEN-O we decided to keep all artifact versions in sync across projects in order to minimize the management and support burden. Under this assumption, the autorelease "mega-build" that builds everything together was a way to enforce synchronized version labels and to detect cross-project compilation issues since everyone was building against SNAPSHOT dependencies that can change at any time. If we don't want to build against SNAPSHOT dependencies across projects, then it means that different projects may have different release cycles, and we may end up with a mix of different artifact versions for the official "ONAP Version 1" distribution. This has the benefit of breaking up the autorelease "mega-build", at the cost of having to manage and support a mix of artifact versions and differing release schedules. Can someone from ECOMP pipe in to add some historical perspective and/or the current assumptions on artifact versioning? Regarding the issue at hand (Staging in settings.xml), a better approach may be to release the upstream artifact using a version label like "1.0.0-RC0" as an intermediate Release (i.e. no longer changing) artifact. This will allow downstream projects to build against an artifact version that is truly locked-down (and not from Staging), while allowing the upstream team some flexibility to make tweaks before releasing the final "1.0.0" version. If anyone has thoughts on this topic, please jump in. Thanks, Gary -----Original Message----- From: Andrew Grimberg [mailto:agrimb...@linuxfoundation.org] Sent: Thursday, May 11, 2017 1:17 PM To: Gary Wu <gary.i...@huawei.com>; onap-discuss@lists.onap.org Subject: Re: [onap-discuss] Staging repo in settings.xml On 05/10/2017 02:05 PM, Gary Wu wrote: > What's the rationale behind including Staging in the global > settings.xml? This seems unorthodox. > > I have now observed instances (e.g. sdnc/core, mso) where a clean > build in a local environment will fail unless Staging is included in > local settings.xml. This is because there are snapshot artifacts in > Nexus that have been built with a dependency on a "release versioned" > artifact which has only been staged but not yet released. This > doesn't seem right. You're correct that it's rather unorthodox. The rational was supposed to be temporary as the original intent was that each of the base projects would be doing _independent_ releases (that whole Continuous Delivery concept). The thing is that no actual release happened before ONAP started as I was being led to believe was going to happen. As downstream of the core projects wanted to only depend on a release version so that they weren't tied to the SNAPSHOTS except for when a new feature that they were developing against was only there, I was asked to add the staging repo to the profiles. Once the core projects released I was supposed to remove the staging repo from the global profiles and then anything depending on a release version really would only be depending on the actual release version. So, either the current projects need to do some sort of actual release so that the staging repos can be dropped out of the standard global profile (or at least disabled unless explicitly enabled) or all the projects need to make modifications to how they do their builds / dependencies. Lastly I have a few things that I want to point out that the current system (admittedly flawed right now) is trying to do. 1) I would rather that all projects be more decoupled in their individual releases so that things can move _faster_. The current model is trying to bootstrap into this. 2) Monster Autorelease style jobs ala ODL and Open-O have some serious flaws in that they build the entire world when each project can (and as is currently the case for ONAP) build their own staged artifacts so that any sort of simultaneous release vehicle only has to assemble and test instead of also build. The issue with having each of the individual projects doing their own staged artifacts is that they absolutely _must_ depend on release artifacts. The current model basically makes this possible. 3) I would really like for us to get away from the idea of a megalithic code drop. It means that any time we have issues with one component it blocks and potentially causes releases to slip. Tightening the releases down to the individual components means that we can on any given "release" date say that all the currently released components are part of the new release and if someone misses the window it shouldn't be so fare in the future for the next one. This is essentially how the Linux Kernel operates now. They basically hold to cadence of ~6 - 7 weeks for a kernel release. If someone misses the window, well, it's only another 1.5 - 2 months out before the next one. It means that features tend to get better polish. -Andy- -- Andrew J Grimberg Lead, IT Release Engineering The Linux Foundation _______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.onap.org_mailman_listinfo_onap-2Ddiscuss&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=dnnJbZr4ZyquG9ib2bthXCpy6mcsShHseeENa-AmKrM&m=SUAeiWnpa1xRNyQa-mO3CXySTiJ64MfG9ypBBv1HwtE&s=irNbs1cbGth-rk2K0htEyeTa9iLUsPqyZe9am-qPTDQ&e= _______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss _______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
