70 x consumes migration i

[vadler]

Migration of CommonTools/TriggerUtils to 'consumes'/'getByToken'-API.

[cmsbuild]

A new Pull Request was created by @vadler (Volker Adler) for CMSSW_7_0_X.

70 x consumes migration i

It involves the following packages:

DQM/SiStripMonitorCluster
Validation/RecoVertex
DQMOffline/JetMET
DQMOffline/Muon
DQM/SiStripMonitorTrack
DQM/TrackingMonitor
DQM/TrackerMonitorTrack
CommonTools/TriggerUtils
Validation/RecoTau

@smuzaffar, @thspeer, @danduggan, @rovere, @nclopezo, @deguio, @slava77, @vadler, @eliasron can you please review it and eventually sign? Thanks.
@cerati, @TaiSakuma, @GiacomoSguazzoni, @rovere this is something you requested to watch as well.
You can sign-off by replying to this message having '+1' in the first line of your reply.
You can reject by replying to this message having '-1' in the first line of your reply.
@ktf you are the release manager for this.

[nclopezo]

+1
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/930/summary.html

[vadler]

@rovere , @deguio , @eliasron
Since CommonTools/TriggerUtils provides mostly helper classes used in DQM, I also needed to modify the instantiation of thos classes in the DQM modules. Some of the DQM modules do not inherit from EDM modules, so the functionality of EDConsumerBase has been added.

[nclopezo]

Hi,

Now there are conflicts in the files:

DQMOffline/Muon/interface/MuonRecoOneHLT.h
DQMOffline/Muon/src/MuonRecoOneHLT.cc

with respect to the current HEAD of the branch.

[vadler]

Ah, lots of new stuff in the latest IB since pre6, which was the most recent one available for development last night :(
I'm gonna update this one accordingly...

[Dr15Jones]

I'm afraid inheriting from EDConsumerBase won't work since the framework only asks modules what they consume. Filling 'consumes' here will still cause the framework to abort any module which uses this code.

[vadler]

In fact, I was also not sure and hoped for a comment on this.
Does that mean, these modules MUST inherit from EDM modules to use 'getByToken'?
@rovere , @deguio , @eliasron , is there a reason why they do not?

[rovere]

'cause sometimes people think smarter.

I fear some restructuring of the code is needed here. I'll discuss with @deguio @danduggan and see how to proceed.

[vadler]

BTW: The change causing the conflict in MuonRecoOneHLT (#1106 (comment)) resolved that issue at least there. It was ported to be an EDAnalyzer.

[vadler]

It looks like I misunderstood the code structure of that package.
Fix is here: vadler@b3fc2a2

[cmsbuild]

Pull request #1106 was updated. @smuzaffar, @thspeer, @danduggan, @rovere, @nclopezo, @deguio, @slava77, @vadler, @eliasron can you please check and sign again.

[cmsbuild]

Pull request #1106 was updated. @smuzaffar, @thspeer, @danduggan, @rovere, @nclopezo, @deguio, @slava77, @vadler, @eliasron can you please check and sign again.

[cmsbuild]

Pull request #1106 was updated. @smuzaffar, @thspeer, @danduggan, @rovere, @nclopezo, @deguio, @slava77, @vadler, @eliasron can you please check and sign again.

[vadler]

+1

[nclopezo]

+1
https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/937/summary.html

[deguio]

+1

[slava77]

+1

tested
#1106 fa38838
as sign262
in CMSSW_7_0_X_2013-10-25-0200
No diffs, as expected.

[cmsbuild]

This pull request is fully signed and it will be integrated in one of the next IBs unless changes or unless it breaks tests. @ktf can you please take care of it?