Is it even possible to keep selected Annotations with Proguard?
For instance I would like to remove all annotations from
javax.xml.bind.annotation.*
But keep all from from
org.mycompany.annotations.MyAnnotation
I was trying to tell to Proguard to keep annotetion like below but does not work at all.
-keep #interface org.mycompany.annotations.MyAnnotation
Or should I keepattributes Annotation and then remove somehow rest of not needed annotations?
Not sure if I understood completely, generally we retain all annotations by using
-keepattributes *Annotation*,
If you remove this from -keepAttributes list you will lose other annotation too, and code might not work.
Ideally I will play with classes on which annotation is applied , not the annotation itself, for instance if you have annotation MyModelClass which is applied on MyService class
# MyModelClass
public class MyService {
}
and I want nothing to happen to MyService class, then I will use
-keep #MyModelClass class * {
<methods>;
<fields>;
}
As you mentioned you don't need some jaxb annotation, I assume they are compile time annotation.
In case you want to remove all compile time Annnotations and retain runtime annotation probably you should use -keepattributes RuntimeVisibleAnnotations
Related
I have a
data class A(){
fun c(){}
} .
I need to create a fake implementation of it for testing, but it says that class must be open. open modifier is incompatible with data class. Any ways to do it?
To mock final classes update mockito
testCompile 'org.mockito:mockito-core:2.8.9'
and then add a folder in your resources folder called mockito-extensions that includes a text file called org.mockito.plugins.MockMaker. Inside there just add
mock-maker-inline
That should solve your problem
How to tell ProGuard to do not change in any way specific class/package?
Do not optimize it, do not shrink it, do not obfuscate, do not do anything at all with it, just look but don't touch?
-keep class com.example.** { *; } seems to shrink private/unused constructors/methods
I think you should try -dontoptimize & -dontshrink in your configuration file and then use allowshrinking and allowoptimization with your keep option wherever you want this to apply with your class/package.
Not sure where to look for this. I want to make changes to a Silverstripe module I added to my site with composer but I don't want the custom code to be overwritten when I update the module at a later stage.
How can I make a few changes to some of the code without editing the core files? The code in question is in a function that is in a controller.
It definitely depends on your case.
If you want to add some custom methods use an Extension(see Simon's
answer)
If you want to add some database fields or relations, a DataExtension
is your friend
If the module is extensible and provides hooks, you
can change behaviour in your (you guessed it) Extension. Look for
$this->extend('functionName') in the module, you can modify stuff
in a method functionName() in your Extension
But sometimes it's a
bug or the module doesn't provide a hook you can use, then you have
to subclass the class and tell SilverStripe to use your Subclass instead:
class MySubClass extends SomeClass
{
public function doSomething()
$something = parent::doSomething();
//your changes
return $something;
}
}
You just need your changes and overwritten methods in your subclass, no need to copy all stuff in your subclass. This way you'll get most module updates later on.
Then you need to configure Injector to use your MySubClass instead of SomeClass in your config.yml:
Injector:
SomeClass:
class: MySubClass
You can make your own extension to it, e.g. class MyModuleExtension extends Extension
And override/edit/change code in there.
In your config.yml, register the new extension like so:
OriginalController:
extensions:
- MyModuleExtension
I am working in this project where I have a mix of old pre-ARC et ARC Objective-c files co-existing with swift since the start of the year. For some reason, that I can not find, to day all new Swift files I have added set to public are not being added to the Swift auto-generated header.
I have check target ownerships, build phase, that it is public as #objc and inherits NSObject. still I can not call the class from Objc and I can from other swift class. it is as if it was set to be private to the swift module or something even after setting it access public..
for example :
#objc public class SomeSwiftClass: NSObject
{
public func sayit()
{
print("Hello!")
}
}
this does not show in any of the OBjc classes where project-swift.h is imported. I am able to call previously created classes, but not the one I added today.
I would guess that some setting is wrong if all my classes are no longer available, but no just the new class !!?!??!?!?!?!?!?!?!
Edit:
- restarting Xcode does not fix it.
- rebooting system does not fix it.
- deleting derived data does not fix it.
strange thing building while having 1 line of code in Objc accessing the swift class does not cause an error. So Its looking like some type of problem with code completion.
If I have the following class hierarchy:
abstract class Foo<out T : Bar>() {
abstract protected val thing: T
}
class Baz : Foo<BarImpl> {
override protected val thing: T = ...
}
I get a warning on Baz::thing saying:
Redundant visibility modifier
Does that mean the compiler treats it as protected without you needing to specify that, or that it has to be public?
You will receive an IDE inspection style warnings in Kotlin for things like extra semi-colons you don't need, an extra generic type parameters that can already be inferred, and more. Yours for redundant visibility modifier is along the same lines.
If you expand the inspection message you will see the full text:
This inspection reports visibility modifiers which match the default visibility of an element (public for most elements, protected for members that override a protected member).
And you can turn the inspection off within your IDE if you no longer what to see it.
A few more notes about this:
When overriding a method or member of an ancestor class you are already at the same access level as when it was declared. Saying protected is stating the obvious (to the compiler which knows it is protected).
You are allowed to restate the access modifier again if you want. And you can open it up more, by changing it to public. But you cannot restrict it further, for example going to private (because if it is private how could you override it, that idea is incompatible with override) which becomes a compiler error.