In applications based on NetBeans Platform 7.2, it is possible to
replace the ModuleInstall classes with this code:
import org.openide.modules.OnStart;
import org.openide.modules.OnStop;
#OnStart
public final class Installer implements Runnable {
#Override
public void run() {
System.out.println("enable something...");
}
#OnStop
public static final class Down implements Runnable {
#Override
public void run() {
System.out.println("disable something...");
}
}
}
My problem is that, after obfuscation, the class loader does not find
the annotated classes.
In the Proguard configuration I added (as suggested here)
-keep #org.openide.modules.OnStart class *
But apparently this is not enough or it does not work.
Does anybody have a suggestion?
From I could figure out, you need to explicitly keep the annotations that you use to keep whatever specifications. So, in your case, adding
-keep enum org.openide.modules.OnStart
would allow this annotation to be used as a selector.
Proguard really ought to include a warning message if annotation selectors are not actually matching. It also doesn't really make sense to keep the annotation, especially if it's not of runtime retention.
Have you tried -keepattributes *Annotation*? It might do the trick, based on proguard usage.
Related
We're currently coding a cn1lib for OpenTok framework, but we're stuck at the inclusion of the required libraries.
We need the appcompat-V7-18.0.0.aar and support-v4-18.0.0.jar in order to use the opentok-android-sdk-2.11.0.aar, but we failed at including them.
We get this log from the CN1 build server and use this codenameone_library_appended.properties :
codename1.arg.android.proguardKeep=-keep class android.support.v4.** { *; } -keep class android.support.v7.** { *; } -keep public class * extends android.app.Service -keep public class * extends android.content.BroadcastReceiver -keep public class * extends android.app.Activity -keep public class * extends android.preference.Preference -keepclassmembers class * implements android.os.Parcelable { public static final android.os.Parcelable$Creator *; }
codename1.arg.android.xpermissions=<uses-permission android\:name\="android.permission.READ_LOGS" /> <uses-permission android\:name\="android.permission.ACCESS_NETWORK_STATE" />
We think that something is missing in this file, but what ? At this time we're just trying to do the android part, iOS later.
Any idea will be helpful, thanks in advance :)
While there are instructions on adding AAR files in the developer guide this isn't the answer you need... Support libraries are a special case. You probably don't need these build hints either.
Check out these build hints for the Intercom cn1lib:
codename1.arg.java.version=8
codename1.arg.ios.pods=Intercom
codename1.arg.ios.pods.platform=8.0
codename1.arg.android.buildToolsVersion=25.0.1
codename1.arg.android.playServicesVersion=9.8.0
codename1.arg.android.supportv4Dep=compile 'com.android.support\:support-v4\:25.+'
You can define a different version of play services and build tools, I'm guessing 25 will be new enough to support the requirements of this library.
I have been trying desperately to ignore the following method during Proguard obfuscation:
package com.foo.me;
public class MyClass extends Activity implements Callback {
...
public void setButtonColor(String color, Button button){
...
}
...
}
I feel like I've been through all the answers here with no luck. Can any share the correct statement to skip over this method with Proguard?
Thanks,
Josh
You can keep ProGuard from removing or renaming the class and the method with this configuration:
-keep class com.foo.me.MyClass {
public void setButtonColor(java.lang.String, android.widget.Button);
}
See the ProGuard manual > Examples > Processing callback methods
Let's assume that you want to create editor which implements interface LeafValueEditor<int[]> something like this:
class MyEditor implements LeafValueEditor<int[]> {
#Override
public void setValue(#NotNull int[] value) {
}
#NotNull
#Override
public int[] getValue() {
return new int[0];
}
}
If you are still using GWT 2.4 than above code will fail at runtime with NPE
Generator 'com.google.gwt.editor.rebind.SimpleBeanEditorDriverGenerator' threw an exception while rebinding 'HERE IS YOUR DRIVER CLASS' java.lang.NullPointerException: null
at com.google.gwt.editor.rebind.model.EditorModel.findBeanPropertyMethods(EditorModel.java:509)
at com.google.gwt.editor.rebind.model.EditorModel.createEditorData(EditorModel.java:407)
at com.google.gwt.editor.rebind.model.EditorModel.calculateEditorData(EditorModel.java:345)
at com.google.gwt.editor.rebind.model.EditorModel.<init>(EditorModel.java:237)
In GWT 2.5 the situation is a bit better. Editor framework will just ignore editors with such array-args in your driver description. Why does GWT-team decide to ignore the problem instead of solving it at this release?
I've looked through the source code of EditorModel and it doesn't look really hard to implement JArrayType support in that case. But it's really annoying problem cause I need to write boilerplate classes for wrapping arrays or to use java collections.
I'm sitting with a legacy project, and we're starting to replace some old legacycode. As Rmock don't have support for junit4, we would like to replace it. One thing i was wondering is - how could i replace the dynamictestsuite feature of rmock. This is a good feature where you create a dynamic testsuite for each run, and can do stuff like.
#Override
protected void setupSuite() {
forEach(is.clazz.assignableTo(TestCase.class).and(is.not(is.clazz.name(is.endingWith("oldTest")))).perform(addAllToSuite);
}
that would get all testclasses not ending with oldTest and create a dynamictestsuite. And so on, you get the point.
ClasspathSuite can define a suite by searching for JUnit test classes in the class path, with a filter on the test class names to include or exclude.
import org.junit.extensions.cpsuite.ClasspathSuite.*;
import org.junit.runner.RunWith;
#RunWith(ClasspathSuite.class)
#ClassnameFilters({"!.*oldTest"})
public class MySuite {}
I've begun experimenting with dependency injection (in particular, MEF) for one of my projects, which has a number of different extensibility points. I'm starting to get a feel for what I can do with MEF, but I'd like to hear from others who have more experience with the technology. A few specific cases:
My main use case at the moment is exposing various singleton-like services that my extensions make use of. My Framework assembly exposes service interfaces and my Engine assembly contains concrete implementations. This works well, but I may not want to allow all of my extensions to have access to all of my services. Is there a good way within MEF to limit which particular imports I allow a newly instantiated extension to resolve?
This particular application has extension objects that I repeatedly instantiate. I can import multiple types of Controllers and Machines, which are instantiated in different combinations for a Project. I couldn't find a good way to do this with MEF, so I'm doing my own type discovery and instantiation. Is there a good way to do this within MEF or other DI frameworks?
I welcome input on any other things to watch out for or surprising capabilities you've discovered that have changed the way you architect.
Is there a good way within MEF to
limit which particular imports I allow
a newly instantiated extension to
resolve?
Load the extension code in a separate container, and make sure that the restricted parts are not available in that container. Let's simplify the situation to these classes to construct an example:
[Export]
public class MyExtension
{
[Import]
public PublicService Service { get; set; }
}
[Export]
public class PublicService
{
}
[Export]
public class InternalService
{
}
[Export]
public class Program
{
[Import]
public MyExtension Extension { get; set; }
[Import]
public PublicService Service1 { get; set; }
[Import]
public InternalService Service2 { get; set; }
}
The goal is to allow MyExtension to import PublicService, but not InternalService. Internal code like Program should be able to import anything. You can achieve that like this:
var publicCatalog = new TypeCatalog(typeof(PublicService), typeof(MyExtension));
var publicContainer = new CompositionContainer(publicCatalog);
var internalCatalog = new TypeCatalog(typeof(Program), typeof(InternalService));
var internalContainer =
new CompositionContainer(internalCatalog, publicContainer);
var program = internalContainer.GetExport<Program>();
This code will not throw a composition exception. If you now change the import on MyExtension to the forbidden InternalService, you will get a composition exception as desired.
A side effect of this set-up is that PublicService cannot import any private services either, just like MyExtension. This kind of makes sense, because otherwise nothing would stop PublicService from exposing a private service via a property.
I have used TypeCatalog for the example, but in practice you should probably use something like the FilteredCatalog sample.
This particular application has
extension objects that I repeatedly
instantiate. I can import multiple
types of Controllers and Machines,
which are instantiated in different
combinations for a Project. I couldn't
find a good way to do this with MEF,
so I'm doing my own type discovery and
instantiation. Is there a good way to
do this within MEF or other DI
frameworks?
You might just be after the PartCreationPolicy attribute, which controls whether a part is shared (as in, created only once per container) or instantiated multiple times for each import. You can also specify the RequiredCreationPolicy parameter in an import attribute.
If that doesn't solve your problem, take a look at the PartCreator sample in the MEF sources (though note that it will probably soon be renamed to ExportFactory, it already has been in the silverlight edition of MEF).