Leveraging in an OEM managed package?

[KeithClarke]

Hi,

This looks great to me, and I wanted to give it a go in a scratch org, but that was blocked by this:

You cannot install an unlocked package without a namespace into an org with a namespace

because the scratch org had a namespace defined. I can use a different org to try it out so no biggie there.

But this does prompt the question of how to leverage apex-rollup in a managed package where the managed package development is done in a namespaced scratch org? A namespaced managed package of apex-rollup would likely solve that, but that is not something you have chosen to provide?

[jamessimone]

@KeithClarke yes, I agree that a namespaced managed package version would probably be the best option here. Let me do some investigation on this over the next week. In the meantime, let me know if you have other questions, and thanks for reaching out!

[KeithClarke]

Thanks James. Maybe e.g. Salesforce security reviews would be an unwelcome burden. And being able to work straight away without a user haven't to configure is important, so e.g. providing an override to the custom setting in the CMDT would allow that - relates to #360.

[jamessimone]

@KeithClarke I was out of town this weekend and wasn't thinking clearly when answering this initially - it's possible to provide namespaced unlocked packages (2GP), which takes quite a bit out of the bite of providing this functionality. I'll be prototyping the namespaced version of Apex Rollup this week and hope to release that over the next few days.

[jamessimone]

@KeithClarke just finished the work necessary to add a namespaced version of the package. I'll be looking to release this in the next day or two. Thank you!

[jamessimone]

@KeithClarke #362 put the first beta package for the namespaced version of Apex Rollup out there. I’ll be doing additional work next week on the next version to get it ready for production for real. I’ll keep you updated!

[jamessimone]

@KeithClarke the namespaced version of the package is now available! Please see the namespaced package's README for further info.

[jamessimone]

The namespaced version of the package is now available!

[pyao-bwc]

Hi @jamessimone , I had trouble using the namespaced package and our custom logger that extends RollupLogger.

If I try to create a class like this:

public with sharing class ApexRollupLogger extends please.RollupLogger {

I get:

Type is not visible: please.RollupLogger

Is that because RollupLogger is defined as public and not global?

We could implement ILogger instead of extending RollupLogger (though we like RollupLogger.getLogStringFromObject and would have to copy paste it). But ILogger is public instead of global as well, if that's the problem.

[jamessimone]

@pyao-bwc I can raise the visibility of that class in the next version. You've brought up some challenges with keeping logging enabled that I'll have to think over - it almost seems like there's two separate needs here that might help:

• ability to stipulate a Rollup Plugin Parameter which suppresses a given plugin - this gives you the ability to fine-tune which loggers end up being initialized in a way that's compatible with CI
• ability to stipulate "always on" loggers via a Plugin Parameter which allows you to bypass which Rollup Control a given plugin is associated with

Let me know what you think!

[pyao-bwc]

Thanks @jamessimone !

What if we put the class name in another field on the RollupPlugin__mdt record? Then, the class wouldn't be in the DeveloperName, which has to be unique. Our own Rollup Control record could reference our own Rollup Plugin record that references the RollupLogger class. This way, it wouldn't conflict with the Org Default that ships with the package which we wouldn't use.

But your suggestion sounds more flexible and meets other needs. And there might be reasons why making the class name separate from the DeveloperName isn't ideal (like backward compatibility). We've just scratched the surface of the features of apex-rollup, so I'll follow your lead!

Also, we'll probably switch to the namespaced package anyways. We report our code coverage via gearset which excludes namespaces, and the non-namespaced package causes our coverage % to drop since apex-rollup tests don't install by default (which makes sense to me).

[jamessimone]

I'm keen on keeping backward compatibility, but I'll think this one through today and get back to you. Also just a note - I'm sure you saw this but it bears repeating - you can install the Extra Tests plugin to meet the code coverage requirements for Apex Rollup. No worries if you still want to cut over to the namespaced package; just want to ensure you know which options are available to you!

[pyao-bwc]

Oh! I did see something about the Extra Tests plugin but didn't look into it carefully enough. I'm glad you mentioned it, that'll help us, thanks!!