I am currently upgrading a module that uses setContent(), that used to be available for JournalArticle (package com.liferay.journal.model) in 7.3.
I checked the guidelines at:
https://learn.liferay.com/dxp/latest/en/liferay-internals/reference/7-4-breaking-changes.html
But I could not find a direct replacement, or anything about its removal.
Did I miss something in the breaking changes documentation?
I also checked the github repository, and the method that was on 7.3.x does not seem to be present in 7.4.x.
This is one of the classes I checked when I first noticed the method was gone:
https://github.com/liferay/liferay-portal/blob/7.4.x/modules/apps/journal/journal-service/src/main/java/com/liferay/journal/model/impl/JournalArticleModelImpl.java
I also checked the public api at for JournalArticles, as in:
https://github.com/liferay/liferay-portal/blob/7.4.x/modules/apps/journal/journal-api/src/main/java/com/liferay/journal/model/JournalArticleModel.java
https://github.com/liferay/liferay-portal/blob/7.4.x/modules/apps/journal/journal-api/src/main/java/com/liferay/journal/model/JournalArticle.java
Related
I try to develop a thirdparty unixODBC driver, it is a secondary development based on the original file libodbc.so.2.0.0.
so I want to rename 'libodbc.so.2.0.0' to 'libodbc.so.2.0.0_renamed'. And soft link my dynamic library file to libodbc.so.2.0.0.
But I found an issue bothering me, when I rename native file and run 'sudo ldconfig', the file named 'libodbc.so.2' automatically linked to the renamed file 'libodbc.so.2.0.0_renamed', as below:
I could not understand that:
why it occurs;
how to appropriately replace the library.
I don't have enough ackownledge about linux, so that I failed to get any keyword to search and deal with it.
Could you help me, thank you very much!
Shared objects under GNU/Linux follow a specific version naming scheme, which is known by the loader (and OS component, actually part of libc framework) to determine if a newer library is retro-compatible with some older version to which a binary was originally linked against. By adding the renamed suffix, you are violating the convention and the dynamic linking system is getting confused. You should renamed as suggested by #Bodo above.
In addition, perhaps rather than using rename, you might consider using the very versioning scheme. From GNU Build System (aka Autotools) manual, the version cheme is like it follows:
Versioning: CURRENT:REVISION:AGE
CURRENT The latest interface implemented.
REVISION The implementation number of CURRENT (read: number of bugs fixed...)
AGE The number of interfaces implemented, minus one.
The library supports all interfaces between CURRENT − AGE and CURRENT.
If you have
not changed the interface (bug fixes) CURRENT : REVISION+1 : AGE
augmented the interface (new functions) CURRENT+1 : 0 : AGE+1
broken old interface (e.g. removed functions) CURRENT+1 : 0 : 0
Therefore a possible history of your lib might be:
1:0:0 start
1:1:0 bug fix
1:2:0 bug fix
2:0:1 new function
2:1:1 bug fix
2:2:1 bug fix
3:0:0 broke api
3:1:0 bug fix
4:1:1 bug fix
5:0:0 broke api
You might, for instance, call the older and newer versions of libodbc.so.x.y.z, according to your needs. Just an idea.
I am attempting to convert parts of an Android app to iOS using Doppl, and I am getting a strange result: Doppl keeps trying to pull in android.arch.lifecycle:reactivestreams, even though I don't want it to.
Specifically, in app/build/j2objcSrcGenMain/android/arch/lifecycle/, there is a reactivestrams/ subdirectory with R.h and R.m files in it. This seems to make Xcode cranky and may explain why I had some oddities with pod install.
My app/build.gradle has compile "android.arch.lifecycle:reactivestreams:$archVer", because my activity is using LiveDataReactiveStreams.fromPublisher(). However:
The activity is not in the translatePattern (and since its code is not showing up in app/build/j2objcSrcGenMain/, I have to assume that the translatePattern is fine)
I do not have a doppl statement related to reactivestreams, because there does not appear to be a Doppl conversion of this library (nor should it be needed here)
AFAIK, nowhere else in this app am I referring to LiveDataReactiveStreams, which AFAIK is the one-and-only public class from the reactivestreams library
So, the questions:
What determines whether Doppl creates R.h and R.m files for some dependency? It's not the existence of a doppl statement, as I have doppl statements for a lot of other dependencies (RxJava, RxAndroid, Retrofit) and those do not get R.h and R.m files. It's not whether the dependency is referenced from generated code, as my repository definitely uses RxJava and Retrofit, yet there are no R files for those.
How can I figure out why Doppl generates R.h and R.m for reactivestreams?
Once I get this cleared up... do I re-run pod install, or is there some other pod command to refresh an existing pod with a new implementation?
Look into 'app/build/generated/source/r/debug' and confirm there's an R.java being created for the architecture component. It'll be under 'android/arch/lifecycle/reactivestrams'.
I think there are 2 problems here.
Problem 1
Somehow Doppl/J2objc is of the opinion that this file should be transpiled. It could be either that 'translatePattern' matches with it, or that something in the shared code is referencing it. If you can't figure out which, please post a comment and I'll try to help (or post in slack group).
Problem 2
Regardless of why that 'R.java' is being sucked into the translate step, because of how stock J2objc is configured, the code is being generated with package folders instead of creating One Big Name. That generated file should be called 'AndroidArchLifecycleReactivestramsR.h' (and AndroidArchLifecycleReactivestramsR.m). Xcode really doesn't like package folders. That's why there's a slightly custom J2ojbc being used with Doppl, so we can have files with big names instead of folders.
In cases where you intentionally use package names that match with what J2objc considers to be "system" classes, you need to provide a header mapping file to force long names. The 'androidbase' doppl library needs to add a lot of files that are in the 'android' package, which J2objc considers "system". We override those names in the mapping file.
build.gradle
https://github.com/doppllib/core-doppl/blob/master/androidbase/build.gradle#L19
mapping file
https://github.com/doppllib/core-doppl/blob/master/androidbase/src/main/java/androidbase.mappings
I screwed up.
In my dopplConfig, I have:
translatePattern {
include '**/api/**'
include '**/arch/**'
include '**/RepositoryTest.java'
}
In this case, **/arch/** not only matches my arch package, but also the arch package from the Architecture Components.
Ordinarily, this would not matter, because the Architecture Components source code is not in my project. But, R.java gets generated, due to resources, and the translatePattern includes generated source code in addition to lovingly hand-crafted source code. So, that's where my extraneous Objective-C was coming from.
Many thanks to Kevin Galligan for his assistance with this, out on the #newbiehelp Doppl Slack channel!
Since upgrading to Gradle 3.3 I'm having trouble building my code due to missing-translation errors:
Error: xxx is not translated in "af" (Afrikaans), "am" (Amharic), "ar" (Arabic), "az" (Azerbaijani), "az-AZ" (Azerbaijani: Azerbaijan), "be" (Belarusian), "bg" (Bulgarian), "ca" (Catalan), [...], "zh-TW" (Chinese: Taiwan), "zu" (Zulu) [MissingTranslation]
The majority of the reported languages are those supported by a 3rd-party module included in my project, and it now seems to define the supported languages for the entire project, giving me this kind of error for all strings that are not translated into above languages. Before upgrading to Gradle 3.3 this was not causing any problems.
I considered the following solutions:
Remove surplus translations from other modules. I want to avoid that because those modules are external and needlessly altering them would really hurt maintainability of my project.
Disable the "incomplete translation" Lint inspection - the most common suggestion for similar questions on SO. This is sub-optimal because I want to be made aware of translations that are missing in my code (working so far). Besides that, disabling the check does not get rid of the error.
Define the supported configurations in build.gradle as described in this answer. I like this option (specifying languages instead of relying on translations available in the modules), but it also does something strange: I'm getting missing-translation errors for strings that are marked translatable = false.
For now, I'm downgrading again to the previous Gradle version. But what is the best apporach for fixing these build errors?
Hoping that there might have been corrections since I posted this question a few months ago, I checked the situation.
It seems that the issues were introduced with the Gradle plugin 2.3.0 and not Gradle 3.3 itself as I suggested in the question. Downgrading the plugin avoids the errors but can hardly be a long-term solution.
I found that option 3 in the question is the best way to handle it: add this to the app's build.gradle:
android {
defaultConfig {
...
resConfigs "en", "fr"
}
}
This is described in Googles documentation and, as mentioned, also in this answer. It removes all unnecessary resources - and the warnings/errors along with them.
Quoting the documentation:
The Gradle resource shrinker removes only resources that are not referenced by your app code, which means it will not remove alternative resources for different device configurations. If necessary, you can use the Android Gradle plugin's resConfigs property to remove alternative resource files that your app does not need.
For example, if you are using a library that includes language
resources (such as AppCompat or Google Play Services), then your APK
includes all translated language strings for the messages in those
libraries whether the rest of your app is translated to the same
languages or not. If you'd like to keep only the languages that your
app officially supports, you can specify those languages using the
resConfig property. Any resources for languages not specified are
removed.
The "false positives" (missing translation error for a non-translatable string) I got were for strings that were defined in more than one module. Renaming the strings or providing translations for them solved the problem. This, too, seems to be introduced with Gradle plugin 2.3.0.
In build.gradle add below code
lintOptions {
disable 'MissingTranslation'
}
I'm using a chef community cookbook that downloads, installs, a configures an SDK. (Let's call it the blah-sdk.) You just include_recipe 'blah-sdk' and viola, it's installed. It has an attribute specifying the version of the blah-sdk it will install. This version attribute in turn is used to form the value of a corresponding 'download_url' attribute. In theory I should be able to set the value of version attribute to something else in the cookbook where I include the blah-sdk. But there is a problem. The download_url attribute gets set (using the default version specified in the blah-sdk cookbook) before my override version attribute does. So the wrong url is used to retrieve the default version rather than the version I want. I could set the download_url in my cookbook as well, but that breaks the encapsulation of the 'blah-sdk' cookbook. I also might end up playing whack-a-mole experimentally with some long stream of attributes before getting it to work. There has got to be a better way. What is it?
cookbooks/blah-sdk/attributes/default.rb:
default['blah']['version'] = '24.4'
default['blah']['download_url'] = "http://dl.company.com/blah/blah-sdk_r#{node['blah']['version']}-linux.tgz"
cookbooks/blah-sdk/recipes/default.rb:
...
print("blah version: #{node['blah']['version']}")
print("blah download_url: #{node['blah']['download_url']}")
...
cookbooks/my_cookbook/attributes/default.rb:
normal['blah']['version'] = '24.4.1'
(I've also tried using default, force_default, override, and force_override. Made no difference.)
cookbooks/my_cookbook/recipes/default.rb
...
include_recipe 'blah-sdk'
...
Output:
==> default: blah version: 24.4.1
==> default: blah download_url: http://dl.company.com/blah/blah-sdk_r24.4-linux.tgz
Code demonstrating the issue and coderanger's suggested solution (if you can fix the third party cookbook):
https://github.com/marc-swingler/stackoverflow_question
Not the best solution, but due to the order in which attributes are loaded, dropping the version into a role or environment works too.
https://christinemdraper.wordpress.com/2014/10/06/avoiding-the-possible-pitfalls-of-derived-attributes/
See https://coderanger.net/derived-attributes/ for an overview of this problem. There is no good solution that doesn't involve modifying the upstream cookbook. Easiest solution is to duplicate the derived attribute in your wrapper as well.
I'm having problems in a project that runs on the v3.9.0.0 version of servicestack.
So I'm trying to download source for it. But on github there are no tags so it seems I cant get hold of the source. So... I downloaded the latest stack and the source for that.
Obviously I'm getting some deprecated warnings but except for that the compiler seems happy enough except for in one place
public virtual void Configure(IAppHost appHost, Container container)
{
appHost.HtmlProviders.Add(new HtmlProvider().ProcessRequest);
The compiler complains that IAppHost does not have a property HtmlProviders
Like so:
ServiceStack.WebHost.Endpoints.IAppHost does not contain a definition for HtmlProviders and no extension method 'HtmlProviders' accepting a first argument of type ServiceStack.WebHost.Endpoints.IAppHost could be found (are you missing a using directive or an assembly reference?)
I can't find anyone mentioning this missing so I'm guessing I'm missing something but what.
So at the end I guess the questions are:
Does anyone know how to get the source for the v3.9.0.0 version of servicestack?
Does anyone know what to do to migrate from v3.9.0.0 to current 3.x version considering the above HtmlProviders problem?
(I edited this post as I misread the version number at first)
Checking history for IAppHost your probably looking for roughly v3.94, about 10 months ago. How to upgrade to latest version? I'd suggest migrating a single service to the new API and going from there.