Mostly coming from a java background, I am unable to completely understand how Hybris application is to be developed.
I want to know if a single setup of Hybris (on a developer machine) can be used for multiple projects i.e. lets say a b2b_acc and b2c_acc, can we have both at the same time on the same hybris 6.x platform?
Since all configurations happen in the same localextensions.xml, will they not conflict with each other and cause any problems?
Assume that both the b2b and b2c sites are for completely different customers.
Also the database tables that are created.Will these work as expected?
Further how about the backoffice, hmc, hac URLs?
Do these need to be configured on different ports for both these sites?
In eclipse, just as we can have multiple java projects in the same workspace,
Is it possible to work on two completely different Hybris projects (having the same hybris 6.0 setup) in the same workspace?
Lastly, in normal java world, Tomcat does not require different ports for two different applications, i.e. we can deploy multiple apps in tomcat. Is the same possible for two different Hybris projects?
There is a system in place for running multiple shops on one hybris instance.
It's called Tenants.
Search the hybris wiki for "Multi-Tenant Systems" it should give you the details.
Related
Recently i've started learning hybris and come across these two terms.I feel both are same because they both are related to User Interface.
somebody please help me understand how backoffice and cockpit are different.
Since Hybris 6, Backoffice is the new more generic UI for managing your Hybris Store. This is the successor of HMC. (Hybris Management Console) Cockpits will become deprecated in a few versions. Using them, you have to handle several different extensions (Product Cockpit, Customer Service Cockpit, CMS Cockpit etc..), which use different frameworks and styles.
The main idea of having different cockpits is to separate different dedicated teams and concerns. Also they have some customizations, which are much more usable, than HMC. With Backoffice, you can create the same functionality with different modules.
In general, if you start a new shop, i would recommend using the Backoffice. This is the new way to administrate you shop.
backoffice is a new framework which is a replacement for old cockpits.
backoffice advantages:
the new architecture allows developer to focus and spend more time on important things (application logic) instead of all secondary tasks (e.g. security - authentication and authorization, notifications etc.)
it offers a lot of standard reusable components so you can create new applications faster (from ready blocks):
actions: create, delete, search etc.
editors: decimal editor, text editor, reference editor etc.
widgets: collection browser, border layout, explorer tree etc.
your applications will be more consistent and intuitive, because they use the same components
it groups applications in one place, so the client does not need to know many URLs (he can open one application and everything will be in one place)
background
I've been a religious user for github/zenhub for quite a while. We recently moved our repos to gitlab for many reasons, including free pipelines, security, more flexible groups etc.
Problem
Zenhub is a greasemonkey app that's added to github, one of its features is the scrumboard that's similar to gitlab's native issue board. One of the amazing things about zenhub scrumboard is that it allows you to put many repos on the same board (I recall jira had the same thing).
question
Is there a way to do this on gitlab?
Beside a third-party like kanban.leanlabs.io, recent GitLab releases do integrate a more sophisticated issue management.
See "Announcing The GitLab Issue Board " (presented here)
But it might be limited to only the current repo.
Note that with GitLab 13.6 (November 2020), this is no longer limited to a repository:
Group-level management of project integrations
In GitLab 13.3, we added the ability to enable an integration across an entire instance. With GitLab 13.6, that feature is being expanded to allow integrations to be managed at the group level as well!
Group owners can now add an integration to a group, and that integration will be inherited by all projects under that group. This has the potential for saving massive amounts of time, as many organizations have specific integrations that they want rolled out to every project they create.
A great example of this is using our Jira integration. If you’re using Jira, it’s almost always across the whole company. Some of these companies have thousands of projects and therefore had to configure each and every one of those integrations individually.
With group-level management of project integrations, you can add the integration at each parent group, reducing the amount of configuration required by orders of magnitude!
Read more in our announcement on the GitLab blog.
See Documentation and Epic.
In GitLab issues and merge requests within a group display a collection of issues and merge requests from all projects below them.
And they also have an Issue Board available, which aggregates the issues from the projects within the given group. This is currently not reflected in the documentation, and could be well worth a Pull Request in doc/user/group/index.md and doc/user/project/issue_board.md.
Using this together with group labels and milestones, which also span across all subprojects, you can create the desired board view.
I do use github/zenhub in the past. https://gitboard.co is the zenhub alternative for gitlab. Which shows all your issue and merge request in one simple dashboard across multiple projects.
As I'm in development on my 2nd and 3rd kentico sites, we're looking at code management. Our ideal solution is a single Kentico Solution, with individual CMS folders.
In theory this should be fine, but would there be any potential issues, especially regarding versioning? Right now, I have one site on 9 hotfix 5, and the other two on 9 hotfix 30.
There would be a problem with applying hotfixes and upgrades. They both count on the fact that the web project is in a folder called CMS... So you would introduce some manual steps in those processes. Conclusion - don't do that.
I certainly agree with #rocky. I'd question what advantages you expect from this scenario? I assume the 3 sites are entirely independent of each other (don't share a database) so keep them as separate Kentico solutions. They're separate applications so why share a solution file? This'll make your life so much easier. A solution should only contain multiple applications if they're intrinsically linked.
If it's because you have custom code that you'd like to share between the instances, best to move that code into custom assemblies and share those in your various solutions. If necessary your separate solutions could include the same files as per this folder structure overview below. This way your hotfixes and upgrades remain entirely localised and you remain safe from harm!
Development
Kentico 1
CMSApp.sln
CMS
CMSApp_AppCode.csproj
References My.CustomBusinessLogic and My.SharedCore
Kentico 2
CMSApp.sln
CMS
CMSApp_AppCode.csproj
References My.SharedCore only
Kentico 3
CMSApp.sln
CMS
CMSApp_AppCode.csproj
My.CustomBusinessLogic
My.CustomBusinessLogic.csp
My.SharedCore
My.SharedCore.csproj
From a development standpoint you should be fine. When performing upgrades, hotfixes or new installs this may cause problems because the KIT looks at the actual .sln file or the actual root directory the .sln file is in.
What I would do is setup a solution like this and try out an upgrade and a hotfix and some local development.
Now our team is facing new project - creation of new company's intranet portal. Because of some reasons we are considering java open source portals and deciding between Liferay and GateIn.
One of very important requirements is following: portal representation for users must depend on country/language settings of customer computer, it means not only portlets localization but users in US subsidiaries of the company should see probably other structure than users in France.
Is it possible to implement the requirement in Liferay and GateIn?.
This can definitely be achieved through Liferay. Please have a look at the concepts of creating organisations.
Am not sure if this can be done in GateIn. However, there are many other things that you may need to keep in mind before choosing these Portals. I have tried to mention few of them here.
1. Check the stability of the Portal server that you will choose to run on a particular Container. GateIn initially was unstable.
2. You may have to override few files (for your customization) if required. GateIn uses GTMPL view technology for the same. Check how good are you in this. In this case, Liferay is easier (Liferay doesn't use any GTMPL UI framework)
3. Apart from developing a location based Portal, if you are also trying to achieve other things like fully Ajax based pages, a good UI framework (like JSF) etc then check if the Portal server you are choosing runs on a particular Container which supports Ajax, JSF (latest versions)
Above were few and list may grow. But, to conclude I would suggest to go for Liferay :)
This can be achieved with Gatein at different level :
Sites : you can declare multiple sites running on the same portal instance(sharing same User Base). In this case you can automatically redirect user to different country sites, based on the country/language of the user.
Sites Navigations : Gatein provides portal, group and user navigations. Navigation is created dynamically when a user connects to the portal. You can have only websites, navigation will created dynamically by user (based on group and user permissions).
Pages (Dynamics layout rendering): GateIn renders each page dynamically. A page is composed of multiple containers that contains portlets or gadgets.
By setting permissions on each container and by using User Group or Membership of the connected user, it's possible to have different page layout.
Of course, you can also mixed these 3 approaches to build your portal.
Liferay is very buggy, and community is very bad. Unless you pay the support.
GateIn promises much, but still lacks functionality.
You may consider JBoss Juzu and Apache Struts to develop generic portlets in order to void any portal vendor lock-in.
Struts provides features of internationalization, localization, timezones achieve my project.
I make use of struts2-portlet plugin to achieve a reporting portlet running on multiple portals. Here is my sample: code.google.com/p/jasperrocks/wiki/Features
I have a Liferay portal that was configured to use filesystem persitence for jackrabbit.
It seems like this persistence mode creates a lot of files on the filesystem (so far something like 113'000) and I'm slowly reaching the file count quota of the server.
I would like then to switch to database persistence. I know how to configure it but I don't know how to migrate the existing content.
Exporting and importing the various libraries (document, images, etc.) sounds like a lot of work and very error-prone, especially because it's a multi-homed deployment. Plus, I don't know if it will recreate the same exact URL for the documents, which is important to me.
Short update:
I managed to upgrade to Liferay 6. There is however no way to migrate the jackrabbit data from file system to database from within Liferay; what the Data Migration panel offers is to migrate from jcr hook to another persistence hook.
My initial issue was not to have the data in a database but to reduce the number of files on the filesystem (quota limit). I then switched to the FileSystemHook.
Here is the file count number (find . | wc -l).
JCRHook: 107566
FileSystemHook: 2810.
Don't know why Jackrabbit creates so much files...
In Liferay 6, there is a new dedicated page in the portal administration that is intended to facilitate migrations like that. You have to log in as an administrator (omniadmin if you have multiple portal instances in your server)and go to the Control Panel.
In the Server Administration pannel, click on the Data Migration menu and you will be offered to migrate from FileSystem to database.
It appears that you are not yet in Liferay 6 (Glassfish WebSpace Server is a Liferay 5.2), so there are several options :
upgrade the portal itself to from 5.x to 6.0.5, as explained in the Liferay Wiki and the use the migration page.
stay with your version, and create dedicated class inspired by the ones provided by Liferay in version 6
export the community pages (Liferay ARchive), create a new portal with DB persistance and import the pages and their content.
The migration would be my pick, either with the whole portal (but chances are that it's not something on your roadmap) or with ad hoc migration classes.
Arnaud
There are several ways to migrate, most of them are documented in the Jackrabbit Wiki:
Export to XML may not work for large repositories, because it uses too much memory (you need to try). I have never used the other migration tools, so I can't comment on them.