Just an FYI. We have added a new feature called “odl-genius-tools”, and have started migrating some of the datastore related utils to a new module called genius/tools . This is just to make a light weight feature for use by applications who just need datastore related utils. Please use this new feature, so that you won’t have to add dependency on a heavier genius feature, just to use datastore related utilities. Also make sure to use the utils from the new module for any of the upcoming patches, as the older ones are deprecated and the migration to the new utils in the existing code is in progress.
Thanks, Faseela  https://git.opendaylight.org/gerrit/#/c/69755/ From: Michael Vorburger [mailto:vorbur...@redhat.com] Sent: Thursday, March 15, 2018 3:14 PM To: Faseela K <faseel...@ericsson.com> Cc: genius-...@lists.opendaylight.org Subject: Re: [genius-dev] Move datastoreutils and other infra utilities outside mdsalutil? Hello, On Thu, Mar 15, 2018 at 8:24 AM, Faseela K <faseel...@ericsson.com<mailto:faseel...@ericsson.com>> wrote: Hi, Recently there was a requirement from openflowplugin, that they need an “srm” only feature. And they don’t want any dependency on mdsalutil as mdsalutil inturn depends on openflowplugin. Currently srm depends on mdsalutil, as some of the utilities(like AbstractClusteredSyncDataTreeChangeListener, FutureRpcResults etc) are within mdsautil-api. Was wondering whether we should have a separate module (“genius-infra” ??) so that we can separate out the openflow utilities and other infra utilities? mdsalutil-api truly has grown into a bit of too much, and the package names in it are a mess, so I'm totally in favour of doing such a split. In addition to resolving your specific short term problem re. genius' SRM use by openflowplugin, I think by clearly separating and offering a few of the general purpose utilities which have grown in genius in a separate bundle and Karaf feature, we can perhaps make them more of interest to other projects than just genius itself and netvirt as well; I'm specifically thinking e.g. openflowplugin perhaps having an interest to later use some of them even directly, not indirectly via SRM, or e.g. for upcoming work in neutron. The "scope" of this new bundle IMHO should include MD SAL DataBroker related utilities (which we cannot host in the only lower-level infrautils; where they should continue to go if appropriate), but without any YANG models (just because those are typically always already "higher-level functionalities" which should better be placed elsewhere). For example, a specific functionality such as SRM should remain in its own bundle, that's just fine, and lets us have good modularity boundaries. As such, I would expect this new bundle to only ever have dependencies to infrautils, controller & mdsal but never to openflowplugin, ovsdb or any other genius bundles, nor the binding-parent. Makes sense? Specifically which existing classes shall we start that bundle with? Here's my initial proposal, for discussion: * org.opendaylight.genius.datastoreutils.listeners (incl. the AbstractClusteredSyncDataTreeChangeListener) * org.opendaylight.genius.infra (incl. the FutureRpcResults you need; also ManagedNewTransactionRunner stuff) * org.opendaylight.genius.mdsalutil.cache * org.opendaylight.genius.utils.metrics.DataStoreMetrics only as a non-public package local class in the new listeners package * NOT the SingleTransactionDataBroker - I think we should discourage its use, in favour of the ManagedNewTransactionRunner * NOT org.opendaylight.genius.datastoreutils's @Deprecated Listener helpers, BUT MAYBE the Chainable* stuff, IFF (when) we make the new genius.datastoreutils.listeners use them for testability * NOT IMdsalApiManager and org.opendaylight.genius.mdsalutil, mdsalutil.actions, mdsalutil.instructions, mdsalutil.[nx]matches (obviously) * NOT org.opendaylight.genius.mdsalutil.packet * NOT org.opendaylight.genius.utils.batching (at least not in its current form) * NOT org.opendaylight.genius.utils * NOT anything Hwvtep related We can do this with a few steps, of course; don't have to move everything in one big Gerrit change. And we obviously need to keep backwards compatibility at least for a while. This should be possible by making mdsalutil-api dependant on this new bundle, and delegating. We should very much avoid to simply copy/paste ANY code, IMHO. Could I suggest that we use the opportunity of a new bundle as the occassion to set a high bar for code quality? Beyond CS (that's old news), and FB (that's so 2017), we should mandate also that all code in this new bundle complies with findbugs-slf4j (which we're just about to enforce accross all of genius anyway), Google's Error-Prone, enforces no copy/paste, has a 100% clean classpath without duplicates? This is easy by using the infrautils:parent for this new bundle, see https://github.com/opendaylight/infrautils/blob/master/common/parent/pom.xml. There will be further code quality checks added there in the coming months (incl. e.g. https://git.opendaylight.org/gerrit/#/c/67838/, and more null analysis related stuff). What do you guys want to call this new bundle? How about genius[-\.]tools? That's perhaps better than genius-infra, just because there is already an org.opendaylight.genius.infra package in mdsalutil-api, and that could be very confusing. Also genius.infra could possibly create confusion with infrautils. Who's going to do it? Or at least make a start? Tx, M. -- Michael Vorburger, Red Hat vorbur...@redhat.com<mailto:vorbur...@redhat.com> | IRC: vorburger @freenode | ~ = http://vorburger.ch<http://vorburger.ch/> Thanks, Faseela _______________________________________________ genius-dev mailing list genius-...@lists.opendaylight.org<mailto:genius-...@lists.opendaylight.org> https://lists.opendaylight.org/mailman/listinfo/genius-dev
_______________________________________________ sfc-dev mailing list email@example.com https://lists.opendaylight.org/mailman/listinfo/sfc-dev