I would like to obfuscate a single package and its all dependent classes and non-java resources files.
Can anybody let me know if this is possible using proguard.
if yes how we can achieve this?
You can preserve all classes (with their fields and methods) outside of the package:
-keep class !mysinglepackage.** { *; }
Note that obfuscating just a single package generally isn't very effective, since so much of the code is being preserved.
Related
To resolve jar conflicts in my application, I use the shaded plugin's relocation feature. It works for me, but i feel it is a hack. I would like to understand the downsides of using the relocation feature if any.
The main issue is that it can fail in cases where the package name is directly defined (not just imported). For example, if you are using reflection and instantiating the a class by its name (including the package name) it will generate the wrong one. Similar problems can occur when the the package is defined in a manifest (there is a transformer for that). See the plugin info for more information.
Another place where this could be an issue is with a third party dependency which uses the same dependency. Consider for example package A which is provided. If package A depends on the relocated package it will in the run time use the provided instance instead of the relocated one. This can lead to unforeseen effects.
An additional issue is that in some cases, the package may contain some initialized/static information (e.g. it downloads some info once or has some big static table). In these cases it is important to understand that there are now TWO completely separate instances of the package.
I've been working on a large TS project for work and absolutely love it. When the project started we stored all of our custom-defined interfaces and types in a single types.ts file, which just exported each of them. That way, we could import only the types we needed in each module (in our case, React components). In this sense, we essentially have a global.d.ts file as defined here with the added benefit of it actually being a module because of the export syntax in types.ts.
Of course, the project has scaled and it's really time to move these definitions elsewhere. My question is how to actually build out separate .d.ts files to do this. Should I have separate .d.ts files for each component (or perhaps component group) and then reference them in a single index.d.ts? Should I just stick with what I have? Other suggestions? Really I'm just looking for advice on how other devs manage type definitions in a scalable, maintainable way. We are using TS 2.4.2 with React, Redux, redux-saga, and webpack.
What is the best way to write flowtype definitions for a module?
I am aware of the flow-typed project, is this the best way to write definitions even if you own the library? The documentation is not very clear about this.
flow-typed approach does not work for private modules. What is the recommendation in this case?
I'd recommend reading through Authoring and publishing JavaScript modules with Flow.
The short answer is that you can distribute your module with .js.flow files that Flow will read to get type information. Usually these are just copies of your original source code from before the type annotations were deleted, created using the flow-copy-source package.
flow-typed exists to provide definitions for modules that do not provide them automatically, but you can include the type definitions right inside your own modules.
I'm writing a small application in CakePHP 2.1, and I want to use Nick Baker's file upload plugin. I downloaded the cakephp2.0 branch (I know that isn't done yet), and placed it in my apps Plugin folder. I made some necessary modifications on it, but I'm curious what the right way is to replace those App::import function calls (at start of FileUploadComponent, FileUploadBehavior and FileUploadHelper classes) with the App:uses function.
It needs to import the FileUploadSettings class from Config/file_upload_settings.php and the Uploader class from Vendor/upload.php. It can be done with the require_once function, but I'm sure there is a CakePHP way to do it.
From what I've gathered:
use import() for external libraries
and uses() for framework files
For example:
App::import('Vendor', 'ExternalLibrary');
App::uses('Inflector', 'Cake.Utility');
According to the Cake manual App::import() is comparable to the way require_once() works. From what I understand you would load classes using App:uses() and Vendor files using App:import().
The API documentation says the following on the subject:
All classes that were loaded in the past using App::import(‘Core’, $class) will need to be loaded using App::uses() referring to the correct package. This change has provided large performance gains to the framework.
The method no longer looks for classes recursively, it strictly uses
the values for the paths defined in App::build()
It will not be able to load App::import('Component', 'Component') use App::uses('Component', 'Controller');.
Using App::import('Lib', 'CoreClass'); to load core classes is no longer possible. Importing a non-existent file, supplying a wrong type or package name, or null values for $name and $file parameters will result in a false return value.
App::import('Core', 'CoreClass') is no longer supported, use App::uses() instead and let the class autoloading do the rest.
Loading Vendor files does not look recursively in the vendors folder, it will also not convert the file to underscored anymore as it did in the past.
The migration guide also has some things to say about App:uses() and is a good starting point in general to compare best practices for 2.0 with the older methods from 1.3 and lower.
This related question deals with loading Vendor files in Cake 2.0, I can't verify the claim by José Lorenzo that App:import() is a "silly wrapper" for require_once(), nor the statement that it's the preferred way of including files. The only reference I could find for the latter is in the Coding Standards for Cake contributors, viz. developers contributing to the Cake core, not applications built on the framework.
EDIT
Let's say you want to import the Twitter OAuth library, residing in Vendor/twitter, the main class file is twitteroauth.php in Vendor/twitter/twitteroauth/twitteroauth.php:
App::import('Vendor', 'twitteroauth', array('file' => 'twitter'.DS.'twitteroauth'.DS.'twitteroauth.php'));
Is there any way in Salesforce to group apex classes under a package or namespace? Can we use managed package for internal organization purpose?
This is a limitation in the force.com stack that makes medium-large size projects painful, if not impractical. Using managed packages in order to get a package prefix doesn't really solve any problems, so it's not really worth the trouble.
I usually try to organize a project into one flat level of namespaces. In lieu of actual namespaces, I'll give each would-be-namespace a 3-5 character name, to be used as a prefix. Any class that belongs in the "namespace" gets prefixed. E.g., if I need a payroll namespace, I'd use a PYRL prefix. A class called PaycheckCalculator becomes PYRL_PaycheckCalculator.
The practical advantage of this type of convention is it helps prevent name clashes and classes are grouped by their "namespace" when viewed in a sorted list, such as in an IDE, or Setup > Develop > Apex Classes
Unfortunately, several basic OO principles are still fundamentally broken. Probably the most important one is every class forms an implicit dependency on every other class it has visibility to, which is all of them.
I'd love to hear how others have worked around this limitation.
Well, you can use managed packages, but as Jeremy mentioned it doesn't really buy you much. Of course managed packages are essential for developing publicly listed apps to sell on the AppExchange. But internally it's really an org-wide problem since once you create a managed package with a prefix, everything that touches any other part of it gets stamped with the same namespace prefix, including all custom objects. And worse, you can't access code in a managed package from outside the managed package (which is actually the whole point of them in the first place).
Although it's not the prettiest solution, what I personally do is maintain numerous named orgs with different purposes, applications and utility classes. When I need a utility class in one org, say I'm building a new app destined for the AppExchange, I'll do an Eclipse Export/Import from the utility org in question. It definitely seems strange but having a library of orgs is the best way I've managed to keep track of everything and to manage "internal" organization. But the end result is really just a glorified copy-paste operation between arbitrary code stores.
I faced similar challenges while working on big projects, wrote this blog post sometime back to share the approach I am following now : http://www.tgerm.com/2011/11/apex-class-naming-convention-suggestion.html