Is it possible to update Alloy UI to newest version in Liferay? - liferay

My current version of Liferay (6.2) has Alloy UI with few bugs.
Those bugs are repaired in newest version of Alloy Ui. Is it possible to use newest version of Alloy Ui instead of the old one?
Thank you.

I think it's possible, but there's a good chance, that you have to do extensive testing before doing it on your production environment and possibly some hand work also will be needed to make it work (if there is major version change, I think it won't work anyway because of the huge changes in the code base).

Related

Update LCI inputs from old to newer ecoinvent version

I have a big database of activities which in the LCI have activities from an old ecoinvent version.
Is there a fast and easy way to update all the LCIs in the database so that they use a newer version of ecoinvent?
I suppose there might be problems of activities not existing anymore/changed names, if that can be a case, how do you manage that?
I'm new to Brightway so I have no idea about how to do this ;).
Thanks a lot!
Daina
There isn't yet, but we are working on it. What we normally recommend is to have a reproducible workflow, using whatever data source you prefer. It is very helpful to be able to reproduce your projects if something happens to your computer, and in this case you could re-create your own data and link it to a newer version of whatever database. But you are right, things change from version to version, and this normally requires some metadata on how to handle these changes - hence the library under development.

Upgrading node version doesn't effect previous node js projects

I have to upgrade nodejs version for new project, but i am not sure, as my previous projects are running on node version 6 or less. So will they be affected (meaning functionality wise), if i upgrade nodejs to new version?
Thanks in advance.
It depends on which version they were created. As Node.js documentation stands:
Minor releases:
Do not generally change APIs nor introduce backwards-incompatible breaking changes, except where unavoidable.
Major releases:
Usually introduce backwards-incompatible, breaking changes.
You have to check which version were you using and compare to current one.
Generally a new major version of node might introduce backwards incomptible changes, but that doesn’t mean your projects won’t run.
You can go over the node releases and check the changelogs, see if something catches your eyes, depending on which version you want to upgrade to. You’re the only one who knows tour projects and their complexity, and can decide if it’s worth to upgrade.

how can I update loopback.io to a newer version when I already have my code written?

I have an API server built with loopback.io (NodeJS) version 3.0.0, however latest version is 3.17.1 and there obviously have been a lot of security and bug fixes over all this time, which makes me feel on potential danger and outdated.
How can I update the framework without affecting my own code? How do other frameworks deal with this kind of issue?
Your code should be completely separate from the loopback.io code. As such, you should be able to do npm update looback.io from the right directory and it should update the loopback.io code and not affect your code at all.
Now this assumes you were using loopback.io as a library that you loaded with require() and that you did not modify the actual loopback.io code yourself in any way.
Before upgrading, you will want to examine the release notes for the revisions of loopback.io since the version you originally installed and make sure there are only bug fixes and no compatibility issues with code written for prior versions (e.g. API changes, etc...). If there are any API changes or "breaking" fixes, then you may have to slightly modify your code in that one area to update to the new API.
Then, after upgrading, run your unit tests to see if everything is still working as you would expect.

How cleared issues in the issues.liferay.com can be applied in our Liferay Portal

I want to know how to apply the issue changes done in the Liferay Issues can be applied in our portal.
For example my issues are cleared in the following links,
https://issues.liferay.com/browse/LPS-14417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
https://issues.liferay.com/browse/LPS-14220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
I want to apply the issue changed in the above links in my portal.
Please some one help me to achieve this.
Thanks in Advance.
Regards,
Dinesh M K
You have to see the resolution and fix version stated.
the second issue says :
Fix Version/s: --Sprint 12/11, 6.1.0 CE RC1
and that means that the issue was solved in all Portals after version 6.1.0 CE.
the first issue , is no longer reproducible, and duplicate of https://issues.liferay.com/browse/LPS-14220 which is again solved in 6.1.0 CE RC1
In other words, If your portal is older than this version, you can't do anything. You'll have to upgrade to version 6.1.0 RC1 or later
It seems that the fixed-in version is a bit weirdly set in those issues - e.g. LPS-14220 is a subtask of a story in LPS-14414, which is stated as completed for 6.2.0. Careful: I did not fully read through all of the issue's descriptions, links and mix what I read with the answer (and comment to) #yannicuLar gave
Basically, this seems to be a new feature. The way to backport it to your installation is to identify the relevant commits (e.g. download the repository from https://github.com/liferay/liferay-portal or https://github.com/liferay/liferay-plugins, identify the relevant commits (they all contain the LPS number), "backport" them (e.g. see if they can just be applied to your codebase or if they need manual adaptation because the whole code changed.
Some features are easier to backport than others, I can't tell about the complexity for this one.
In order to separate your changes from Liferay's core changes, you should try to implement this in plugins (or patched plugins) rather than changing the original code and recompile. Most likely it's only the kaleo-web plugin that's effected, but if there are core changes, you'd be better of having them isolated in plugins.
The simplest (and most futureproof) possibility is to wait a bit for 6.2 (RCs are already out) and upgrade your portal to this version. If you want to stay on a version that gets updates, you should do this soon anyway.

Migrate Liferay 5 -> 5.2

We have a liferay portal running on a hosting company, and We want to bring it to our own structure. So, I've downloaded the excellent bitnami stack and loaded it in our vmware server.
I've no experience on liferay whatsoever, all I know its that it uses mysql as database. Is there any docs on how to do it?
Tks!
Use the Liferay's Wiki:
5.0 to 5.1: http://www.liferay.com/community/wiki/-/wiki/Main/Upgrade+Instructions+from+5.0+to+5.1
5.1. to 5.2: http://www.liferay.com/community/wiki/-/wiki/Main/Upgrade+Instructions+from+5.1+to+5.2
I recommend to do a 2-step upgrade since direct upgrade from 5.0 to 5.2 is more troublesome.
There have been reports that it's some work to upgrade older versions to the latest and greatest, so you should be prepared for some efforts.
That said, the way you should go is to backup the previous installation (e.g. all directories, database entries etc) and deploy that on your own server. This installation then is updated to the latest version by installing the latest version and pointing it to the data from the previous installation. During the first startup, liferay will (given sufficient privileges on mysql) update the database structure and everything it needs. Keep your backup ready and test thoroughly if everything is upgraded the way you intended it to be.
Also you need to keep an eye on your customized stuff - if you have portlets or other components that use the liferay api, you might need to upgrade those manually to take changed APIs into account.
Theoretically that should be it. I've heard of people having had some problems with this - but it all depends on your level of customization and utilization of features in liferay.
The liferay folks intend to circumvent this in future with their EE environment, where you get better defined upgrade paths and long term support with minor upgrades to your environment, keeping APIs and database requirements stable. I'd hope that even upgrades between major versions will benefit from this, but have not yet tried it.

Resources