Obfuscation across multiple gradle modules with proguard possible? - reference

I have a Gradle project containing the main module and one library module and each one is set up with proguard.
My problem is, that the class which is obfuscated in the library module to "A" or similar is still referenced from the main module with the original name, lets say "MyUtil", which doesn´t exist anymore.
I don´t want to exclude this class from the obfuscation if possible, so is there any way to do obfuscation accross modules?

Sounds like you need to create a API class in the you library that is excluded from the obfuscation. The API class would just be a facade and call your internal library methods.

The problem was solved after using
consumerProguardFiles
in the library project.
Now it works accross modules without doing anything

Related

Reusing a component in lit-element

Anyone that can point to any documentation on howto reuse code in lit-element.
The problem now is that if I declare an element, in my case a close-button and I want to reuse it by importing it into 2 or more lit-elements, there will be an error in the browser about the close-button being declared more than once.
Understandable enough, but how do I reuse a component, I could of course move the button to a separate file and add it to the document, but then there would be dependencies on that for other components to work.
Any suggestions
If close-button self-registers itself, with a call to customElements.define('close-button', ...), then you should be able to import its defining module and not have any errors due to the module caching behavior of JS.
You must have multiple customElements.define('close-button', ...) calls, so I'd make sure that 1) it's self-registering and you're not registering it again in each component that uses it, and 2) you're using standard JS modules.
After investigating a bit more, I concluded that sharing HTML templates might be the way to do it.

Recommended way to find out what Liferay module provides a class

In my Liferay module, I want to use Liferay's SomeConvenientClass.
What is the recommended way to find out what module provides that class?
So that I can quickly add it to my build.gradle.
Ideally it should either:
return the module's group/name/version,
or say with certitude that this class does not exist in Liferay or is not exported.
Until now I go by trial-and-error and copy/paste from build.gradle files found in the wild, but I am looking for a more reliable method.
I have Liferay installed, and the source code of the exact same Liferay version, if that helps.
I tried mvnrepository but it does not seem to return anything, example: https://mvnrepository.com/search?q=AuditMessageProcessor
Have you tried http://search.maven.org/#advancedsearch ?
For example:
http://search.maven.org/#search|ga|1|c:"AuditMessageProcessor"
This is more an option than a real thing, but this is how I normally do:
be familiar with package naming conventions used by liferay and
inside apps: api, service, web...
be familiar with the bundle structure used by liferay, as their
use of resource folders, which are not so obvious sometimes...
With that in mind, normally on github is enough to navigate: portal->(kernel/impl/services/apps)->app service/api/web...
But this is a natural process that comes when you spend your day inside the code.
Normally, online jar locators help, but quite often I just rely on my IDE.
On my IDE I have all set-up with Spring dependency management, after I extracted the dependencies using Gogo shell with a running bundle. With Gogo you will not find classes, but modules and packs will be listed. (Gogo is probably what you are looking for btw, as it is able to list with version numbers)
Bottom line, if you need a list as a picture of a running environment, use Gogo.
With regards to the master code, just do not trust it! When it comes to modularity and bundles versioning Liferay is pretty messy (read The dependency management problem here: https://www.e-systems.tech/blog/-/blogs/liferay-digital-experience-platform-review-7-0-ga4).
For your step 7, you will need to chose an api version and code against it. The apis are more stable. You can impose a limit for compatibility on you bnd file, which will cause the system to issue warnings. On your environment, you can catch api changes earlier, let's say, you can ask gradle to use a module with an version number but any patch (using the "+" sing), when you build with a fresh cache or if you change gradle resolution strategy to download you dependencies more frequently, if the build breaks, well, you will see it.
Helpful start point: https://dev.liferay.com/pt/develop/reference/-/knowledge_base/7-0/using-the-felix-gogo-shell
This is how I do, it is slow and manual, so don't hesitate to suggest other methods.
Download Liferay's source code if you don't have it already.
Run find . -name SomeConvenientClass.java. If nothing is found, you can be sure the class is not part of Liferay.
In the path to the class, find the src folder level, and go just under that, so for instance if it is modules/apps/collaboration/document-library/document-library-web/src/main/java/com/liferay/document/library/web/portlet/action/DLViewMVCRenderCommand.java then go to modules/apps/collaboration/document-library/document-library-web/.
Hopefully there is a bnd.bnd file there, open it.
If the package of the class is not in the Export-Package section, then either give up (duplicate Liferay's code into your module), or use some dark tricks. If you believe the class should be exported, you can explain your case at https://issues.liferay.com/browse/LPS-70480 for future generations to enjoy.
Module name is the value of Bundle-SymbolicName.
Version is the value of Bundle-Version.
Group is probably com.liferay, although sometimes it is com.liferay.portal, not sure how to tell.
Build. Sometimes it fails because Maven repositories are missing a version, for instance com.liferay.document.library.web 1.0.11 is not available despite being used by DXP fix pack 30. Not sure what to do in such cases except choosing a "similar" version and hoping for the best.

system.runtime.serialization and mvvmcross

I am stuck with this issue and I cant seem to solve it. I have my logic in a PCL and a a .Droid and .iOS clients.
I need to use the [serializable] attribute in my logic so I need to add a reference to system.runtime.serialization. The problem is there is a different dll for android and iOS how can I manage this? I did not encounter this problem before because I used shared files between the projects so each project had its own reference to the correct system.runtime.serialization and I could use the [serializable] attribute with no problems.
Have I missed something?
Thanks
Amit
In general I'd recommend avoiding trying to use the SerializableAttribute in portable code. That type of serialization is basically not portable. However, if you really need to do it, that attribute is actually treated specially and is represented by a bit on the type as opposed to a normal attribute. So if you define your own attribute with the same name and namespace in a PCL, the compiler will emit the bit and everything may just work like you need it to.

C# Accessing classes in a WinForms project from a classes in a Class Library

I have two c# projects within a solution.
The first project is a winforms project with several classes and is called QuantumGUI. The second project is a class library project with several classes and is called QuantumDAL.
My objective is from a class in QuantumDAL to access and set variables in a QuantumGUI class or and in Form.cs.
I have tried adding a reference to QuantumGUI in my QuantumDAL project but received the following error: “A Reference to ‘QuantumGUI’ could not be added. Adding the project as a reference would cause a circular dependency”.
I received a similar error message trying to add Project Dependencies. When you think about it, the error message makes sense.
I’ve tried other, what I consider possible ways of doing this but came up empty. I believe there must be a clever way of getting this done.
If I’m going about this in a wrong way, is there a way to have a “global” class that can be accessed by code in both projects?
Thank you for taking the time to look at this.
There are two problems with what you're trying to do:
First, as the IDE is warning you, you're about to create a circular dependency. This means that the compiler would need to build project A before it can build project B, but it would need to build project B before it can build project A. Neither project can go "first".
The second problem is that your WinForms project is most likely an executable, and you cannot add references to *.exe files via the IDE. You can add those references via the command-line, but the fact that Visual Studio is trying to stop you from doing it should be a red flag that it's a really bad idea.
The correct way to do what you want is to refactor the common classes into a third class library that you reference from both other projects. If needed, you can wire up events (in particular, look at the INotifyPropertyChanged interface and its event) that notify interested observer objects when things change.

TypeScript extend object in module

What I want to do is really similar to this and this except I'm trying to figure out how to put an ArrayExtension inside a module.
I'm trying to get something similar to the way C# extension methods work, that way I can just import the module and I'll have my extra methods. The links I provided show how to extend an existing object, but I haven't been able to figure out how to encapsulate that into a module.
If you're targeting non-browser environments like node.js this will be possible because you will be able to pass references to your module's global members, such as Array, to other modules. Those other modules can then extend the passed in object and/or its prototype with extra functionality which will be only accessible by the calling module. Other modules would have to do the same in order to get these extensions; therefore, conflicts are minimized since imports are explicit.
However, in browser environments this is not the case since there is only one window object and any changes to its members are available everywhere. As soon as any of your modules extended Array those extensions would be available to all other modules -- increasing the possibility for conflicts and making the code harder to reason about.
With that said, there are patterns in JS, and therefore TypeScript, which should accomplish what you want. One such pattern is the 'mixin' pattern which allows you to add on extra functionality on an object instance basis. You could separate re-usable code into mixin modules which could then be applied to an object when needed, or even automatically in constructors. Take a look at this for a decent overview and implementation examples: http://javascriptweblog.wordpress.com/2011/05/31/a-fresh-look-at-javascript-mixins/
If you're trying to extend the built in Array type you can't do that within a module. You're extension will need to live in an ArrayEx.ts file and occur outside of any modules. The reason for that is that if you did it within a module you'd be extending the Foo.Array type which isn't the same as Array.
But you said you just want to be able import the module to have your extra methods show up and all you really need to do is add a /// <reference path='ArrayEx.ts' /> to any file you want the extension methods to be available to. This is essentially the same thing.

Resources