addiction modules drupal 7 - module

I'm using version 7 of Drupal and I'm adding additional modules, in particular the modules of Open Atrium.
When I add a module I have many required modules set to "missing" and I can't activate the module.
Can I install a module and automatically all dependent modules?
Alternatively I have to manually install more than 100 modules.
Thank you.

You can use drush to download and enable modules.
Here you have all the info for installing drush: https://drupal.org/node/1791676
for example:
>drush dl views
Project views (7.x-3.7) downloaded to /var/www/drupal_7_test/sites/all/modules/views. [success]
Project views contains 2 modules: views_ui, views.
this will download views module only, then you can enable it and if the module have declare dependencies, drush will download and enable it.
>drush en views
The following projects have unmet dependencies:
views requires ctools
Would you like to download them? (y/n): y
Project ctools (7.x-1.4) downloaded to /var/www/drupal_7_test/sites/all/modules/ctools. [success]
Project ctools contains 10 modules: ctools_plugin_example, ctools_ajax_sample, bulk_export, ctools_custom_content, term_depth, stylizer, views_content, page_manager, ctools_access_ruleset, ctools.
The following extensions will be enabled: views, ctools
Do you really want to continue? (y/n): y
ctools was enabled successfully. [ok]
views was enabled successfully.
Not all modules have declare such dependecies and you should install them manually but as you can see is an easy task with drush.

Related

How to handle package dependencies for some build targets when building with Copr?

I want to have a rpm package build with Copr1. My current build target list is Fedora 35, 36, rawhide and Centos 7 and Stream 8. I have not yet created the copr project.
Compiling on one of my machines, the package builds successfully on the Fedora variants with mock. The problem is that on Centos variants one of the build dependencies and some of its dependencies are not available. I have found appropriate srpm files and compiled them on one of my machines with the Centos Stream 8 (one of them required two custom patches). With those custom dependencies I am able to successfully compile the original package.
So just to be clear, the problem is that the spec file contains for example
BuildRequires: libsomething
where libsomething is available as a plain upstream package in some of the build targets while needs an additional custom repo for some other build targets.
The FAQ says the following about dependencies:
Can I depend on other packages, which are not in Fedora/EPEL?
Yes, they just need to be available in some yum repository. It can either be another Copr repo or a third-party yum repo (e.g jpackage). Click on “Edit” in your project and add the appropriate repositories into the “Repos” field. Packages from your project are available to be used at build time as well, but only for the project you are currently building and not from your other projects.
But this sounds like an all or nothing approach, and I absolutely do not want to override the already existing upstream packages, only provide them when they are missing.
So what strategy do people use to handle this?
Update: I have now created copr projects and made some attempts at building (after resolving dependencies of dependencies in several levels), but the problem is as I describe above. If I add copr://hlovdal/projectname as a build dependency then epel-8-x86_64 compiles fine because it is provided with the missing dependencies while fedora-35-x86_64 fails because the repository does not have any fedora packages. If I remove the repo epel fails while fedora succeeds.
I also attempted to add the base url from the corresponding /etc/yum.d.repo file, and only hardcode epel instead of $distname hoping that the fedora builds would just ignore non-existing/wrong repo setting, but the build does not like that and still fails.
1 Copr is Fedora's freely available build system.

Configuring IntelliJ Platform plugin's workspace

I've been setting up the workspace for IntelliJ's plugin development. There is one issue that I'm not able to solve.
I have two plugins: A and B. The B plugin depends on A. The A plugin is provided as an install-ready zip package (I don't have the code and I don't want to add it to my project).
In the manual, I met this page. I added jars from the A plugin (extracted from the zip file) to the SDK that is use when running B plugin. Unfortunately, when the sandbox is being bootstrapped, I get the following error:
Problems found loading plugins:
Plugin "B" was not loaded: required plugin "A" not installed.
Disable B
Open plugin manager
Does it mean that plugins from the SDK are not installed automatically?
I tried to install the A plugin in the sandbox but then I got a casting exception - two different class loaders were used.
Of course, I have appropriate dependency configuration in the B.plugin.xml file:
<depends>A</depends>
My question is how should I provide the A plugin to be able to develop the B plugin? Is it possible to develop the B plugin without A's sources?
In the jars that I added to the SDK's classpath, there is a package that contains the plugin.xml file for the A plugin. This plugin is also not listed on the list of plugins.
I'm sure that both plugins are configured properly because there are no problems when I install both of them in a standalone IntelliJ instance. Additionally, I don't have any compilation errors.
After couple more hours of debugging. The A plugin is marked as not installed because in the PluginManagerCore:loadDescriptorsFromClassPath method there are no appropriate jars URLs provided. It seems that BootstrapClassLoaderUtil doesn't include all of the entries configured in the SDK.
I tried to set -Didea.additional.classpath property, but I got the class cast exception again.
Finally, I have found the solution.
The B plugin consists of other B submodules:
B.submodule-1
B.submodule-2
B.submodule-3
One of these submodules had dependencies to the A's submodule. Something like this:
B:
| B.plugin-submodule
| B.submodule-1
| A.submodule1
| A.submodule2
| B.submodule-2
| B.submodule-3
Based on the gradle setup, IntelliJ resolved all of the dependencies for all submodules. Initially, I removed Gradle dependencies and set the JDK only for the plugin submodule. It was required to do so for the others (submodule-1/2/3).

Creating independent Module in Magnolia 5.3

I created custom Module with Magnolia Archetype from this link : Module QuickStart
But directly in my workspace, I mean without creating webApp Project.
So when I want to use on my module that is integrated in webApp project I can't find resources like component.ftl.
Please help me if there is useful tutorial for creating a custom independent module and thanks.
by CMD go to your workspace with the command cd: for example
cd users/workspace
Now in your workspace run this command:
mvn archetype:generate -DarchetypeCatalog=https://nexus.magnolia-cms.com/content/groups/public/
This command creates your module, there is 5 options, follow the instructions to create your best module.

Vaadin 7 Portlets error on Glassfish V3

I am creating a Vaadin (version 7) portlet, my development environment is eclipse 4.3.1 + tomcat-7.0.27+Liferay-portal-6.1.1-ce-ga2, I am checking the stuff on tomcat and the portlet runs fine there.
Now my deployment environment is Glassfish-3.1.2+Liferay-portal-6.1.1-ce-ga2, the same portlet and the log message is: "sampleApp was successfully deployed", the Portlet error is "Failed to load the bootstrap javascript: ./../../VAADIN/vaadinBootstrap.js".
Please help me solve this.
From Book of Vaadin:
Liferay 6.1, [...], comes bundled with an older Vaadin 6 version. If you want to use Vaadin 7, you need to remove the bundled version and install the newer one manually as described in this chapter.
In these instructions, we assume that you use Liferay bundled with Apache Tomcat, although you can use almost any other application server with Liferay just as well.
12.5.1. Removing the Bundled Installation
Before installing a new Vaadin version, you need to remove the version bundled with Liferay. You need to remove the Vaadin library JAR from the library directory of the portal and the VAADIN directory from under the root context. For example, with Tomcat, they are usually located as follows:
tomcat-x.x.x/webapps/ROOT/html/VAADIN
tomcat-x.x.x/webapps/ROOT/WEB-INF/lib/vaadin.jar
12.5.2. Installing Vaadin
Get the Vaadin installation package from the Vaadin download page
Extract the following Vaadin JARs from the installation package:
vaadin-server.jar,
vaadin-shared.jar,
as well as the vaadin-shared-deps.jar and jsoup.jar dependencies from the lib folder
Rename the JAR files as they were listed above, without the version number
Put the libraries in tomcat-x.x.x/webapps/ROOT/WEB-INF/lib/
Extract the VAADIN folders from vaadin-server.jar, vaadin-themes.jar, and vaadin-client-compiled.jar and copy their contents to tomcat-x.x.x/webapps/ROOT/html/VAADIN.
$ cd tomcat-x.x.x/webapps/ROOT/html
$ unzip path-to/vaadin-server-7.1.0.jar 'VAADIN/*'
$ unzip path-to/vaadin-themes-7.1.0.jar 'VAADIN/*'
$ unzip path-to/vaadin-client-compiled-7.1.0.jar 'VAADIN/*'
You need to define the widget set, the theme, and the JAR in the portal-ext.properties configuration file for Liferay, as described earlier. The file should normally be placed in the Liferay installation directory. See Liferay documentation for details on the configuration file.
Below is an example of a portal-ext.properties file:
# Path under which the VAADIN directory is located.
# (/html is the default so it is not needed.)
# vaadin.resources.path=/html
# Portal-wide widget set
vaadin.widgetset=com.vaadin.portal.gwt.PortalDefaultWidgetSet
# Theme to use
vaadin.theme=liferay

In IntelliJ how do I Update Project (ctrl+T) with modules from different SVN locations

I have an IntelliJ project made up of many modules (15+), where each module comes from their own (distinct) SVN location. The project is not stored in SVN, just each module.
Project Foo (not in SVN)
Module 1 http://svn.example.com/projects/module1/trunk
Module 2 http://svn.example.com/projects/module2/branches/bar
Module 3 http://svn.example.com/projects/module3/tag/2012-11-01
I would like to be able to do Update Project (Ctrl+T). Normally (when the entire project is stored in the same VCS location) I can do this once. But with each module stored in a different VCS location I have to update each module manually.
Is there a way that I can update all modules with a single command?
I am using IntelliJ 11. (But nothing is stopping me from upgrading to 12 if needed.)
In Project settings -> Version Control, you can add all your vcs Directory with vcs type.