What is best practice for the Package Creator to either require a dependency of another package, i.e. the Forms Rendering package, or install the required dependency. The configuration packages are available from Package Creator but that appears tedious if a package has numerous config items.
The current release of Composite C1 Package Creator (v.3.3) do not have features for specifying required packages via the UI. I suggest you register a feature request for this and describe your need. You can use 'Create New Item' on http://compositec1.codeplex.com/workitem/list/basic
Writing custom validation logic
With some C# development you can add this check to a package though. The C1 Package system is based on 'installer plug-ins' that validate state before install and do the install work. You can write such an 'installer plug-in' and make it validate the presence of a required C1 Package and then associate your plug-in with your package.
Create a class that inherit from
Composite.Core.PackageSystem.PackageFragmentInstallers.BasePackageFragmentInstaller
Override Install() and Validate() - put your validation into Validate() and return one or more PackageFragmentValidationResult is your validation fails. Let Install() simply return.
Register your new 'fragment installer' class in the packages install.xml file - add a section like this inside the root element:
<mi:PackageFragmentInstallerBinaries> <mi:Add path="~/MyAssembly.dll"/> </mi:PackageFragmentInstallerBinaries>
where path points to your assembly as you added it to the zip.
Inside the existing <PackageFragmentInstallers /> element, add calls to your class inheriting from BasePackageFragmentInstaller by using an element like <mi:Add installerType="MyFragmentInstallers.MyValidator, MyFragmentInstallers"/>
Doing this will make Composite C1 call your Validate() method as part of the package install, and alert the user if any validation messages are returned.
Detecting if a package is installed
If you know the ID of a package, you can check if it has been installed using Composite.Core.PackageSystem.PackageManager.IsInstalled(Guid packageId).
Related
I have an application (let's call it frontend) importing a custom library of React components (design-system) that's Material UI based.
In the frontend app, I have a ShadowDOM-contained component (using react-shadow) that I want to import a Button component from design-system to. I wrapped the whole tree inside ShadowDOM with StylesProvider that I passed a custom instance of jss to (with different injectionPoint, so the styles from inside that tree are attached not at the head of the document, but inside the ShadowDOM.
The issue I have is, that frontend uses its own copy of StylesProvider from #material-ui/styles package (I have no need to install the whole #material-ui/core as all components should be imported from design-system instead) and design-system uses its own copy of StylesProvider from #material-ui/core, resulting in a situation, where the Button is being wrapped with another StylesProvider by MUI because it doesn't detect any styles context available (and it doesn't, because MUI creates the context in global scope of StylesProvider.js file - so there are two different contexts that do the same), resulting in Button having access to default JSS instance where the insertionPoint is pointing to document head.
What I'd like to achieve is, have MUI not create another styles context for every single component imported from design-system but use the one I defined in frontend - without passing it as a prop manually to every component imported. I considered adding #material-ui/styles on top of #material-ui/core to design-system and adding it to webpack's "externals" (so, theoretically, only one StylesProvider.js would be used and in turn - one context), but I was hoping there's a better solution.
TLDR:
Just adding #material-ui/styles to externals in design-system's webpack config was enough (even if you don't add it explicitly as dependency, #material-ui/core depends on it and will use it anyway, so it works).
Long answer:
My setup is such that the "main" entrypoint in package.json of design-system points to dist/index.js (so, already bundled/minified version of the library). Without adding #material-ui/styles to "externals" in webpack config, it was bundled along the whole library, so at this point, whatever I did there would always be two copies of StylesProvider.js:
One solution is to mark #material-ui/styles as external - this way, it won't be bundled in dist/index.js and instead, expected to be available during runtime (and it is):
Besides the aforementioned solution, there's also another one that worked - pointing "main" entry in package.json to "src/index.ts" instead. It made the frontend webpack treat it as a part of frontend code, instead of separate library:
As a bonus, it ended up with the final bundle being smaller (as common dependencies weren't duplicated). One minus of this approach was, however, that each frontend build had to also rebuild design-system, which increased the total build time.
I'm using Gradle and have 2 dependencies in my project:
implementation group: 'org.seleniumhq.selenium', name: 'selenium-api', version: '3.1.4'
implementation group: 'io.appium', name: 'java-client', version: '5.0.2'
Both dependencies have a class WebDriver under the same package:
org.openqa.selenium.WebDriver
Despite the order of these 2 dependencies in the build.gradle file when I use WebDriver the reference goes to the second dependency - java-client.
How does Gradle decide which dependency to use?
If I comment out java-client the reference goes to the other one (selenium-api - the one I expect to be used).
Playing around with versions of the java-client showed even more confusing results:
while using a version less than 4.1.0 WebDriver class dependency is resolved correctly - from the selenium-api;
while using version 4.1.0 and higher it is resolved to the java-client.
I can't figure out what is the rule here.
Or how can I specify a resolution strategy in this case?
The question is not about the build tool and it's dependency resolution. From Gradle perspective those dependencies have nothing in common and are resolved independently.
Each dependency becomes an entry in the class path of the runtime, so which of the classes used is just a question of the class path order which is a bad idea in general.
Two different library artifacts differing in more than the version should not offer equal classes - except you really want to replace it and must never be used together like SLF4J wrappers. Instead they should change the package structure (see Apache Commons Lang e.g. moving package org.apache.commons.lang to import org.apache.commons.lang3 to avoid conflicts when included by transitive dependencies or prefixing repackaged classes).
In this case Appium did a bad job including Selenium classes instead of declaring a transitive dependency. You should not use both dependencies in one project module or will get unpredictable results especially if the implementations of the selenium classes differ. As far as I know this problem has been addressed in later versions of Appium, try to upgrade to version 7 instead of 5.
I am very new to Zeppelin/spark and couldn't get an accurate description of steps to configure new dependencies like that of NLP libraries.
Found similar issue here.
I was trying to use Johnsnowlabs NLP library in Zeppelin notebook (spark version2.2.1).
Setup included :
In Zeppelin's Interpreters configurations for Spark, include the following artifact:
com.johnsnowlabs.nlp:spark-nlp_2.11:2.5.4
Then, in conf/zeppelin-env.sh, setup SPARK_SUBMIT_OPTIONS.
export SPARK_SUBMIT_OPTIONS=” — packages JohnSnowLabs:spark-nlp:2.2.2". Then restarted Zeppelin.
But the below program gives the error :
%spark
import com.johnsnowlabs.nlp.base._
import com.johnsnowlabs.nlp.annotator._
<console>:26: error: object johnsnowlabs is not a member of package com
import com.johnsnowlabs.nlp.base._
^
<console>:27: error: object johnsnowlabs is not a member of package com
import com.johnsnowlabs.nlp.annotator._
Can someone please share how this can be done? I referred this link .
TIA
you don't need to edit the conf/zeppelin-env.sh (anyway you're using it incorrectly, as you're specifying completely different version), you can make all changes via Zeppelin UI. Go to the Spark interpreter configuration, and put com.johnsnowlabs.nlp:spark-nlp_2.11:2.5.4 into spark.jars.packages configuration property (or add it if it doesn't exist), and into the Dependencies at the end of configuration (for some reason, it isn't automatically pulled into driver classpath).
currently to install and run material-ui docs locally, it requires two npm install, one within material-ui, another within material-ui/docs.
cd <project folder>/material-ui
npm install
cd <project folder>/material-ui/docs
npm install
But I want to use the docs site as a starting point to create my own app. How can I install the docs without installing the whole material-ui? I've tried adding "material-ui": "^0.14.4",, and ALL dependencies in material-ui/package.json to the material-ui/docs/package.json.
With that, npm install doesn't complain anything, but when I do npm run start or npm run browser:development, it doesn't work. Instead, it spits out whole bunch of error message (see below for part of it).
ERROR in ../src/table/table-header-column.jsx
Module build failed: ReferenceError: Unknown plugin "transform-replace-object-assign" specified in "/home/ubuntu/repos/tutorials/mui/.babelrc" at 0, attempted to resolve relative to "/home/ubuntu/repos/tutorials/mui"
.....
Please advise! Thanks.
I have teased the MUI-Docs site from parent MUI here in this repo: https://github.com/lmaccherone/material-ui-template.
In addition to removing the dependency upon parent material-ui, it has these advantages:
DRY and n-levels of left nav menu. To add/modify the left nav of the original MUI docs, you had to modify no
less than three different source files. This template will automatically adjust the left-nav based upon app-routes.js
including n-levels deep.
Custom theme in the project. MUI is designed to be themable and comes with two nice themes, but it's not
immediately obvious how to activate a custom theme in context for all components. The Themes page now has three
themes and it defaults to the custom one, so if you remove the Themes page, it will start up with your theme rather
than one of the prebuilt ones. Just modify customBaseTheme.js. I also modified many components and pages to use the theme. There were many places where inline settings didn't honor theme colors and spacing.
Highcharts. There is an example chart page that uses Highcharts and react-highcharts.
Advanced Table. It includes a component that renders a table where you can click on the columns to accomplish sorting.
Note, that repo has two pages specific to Pendo (a company I'm working with). They won't render correctly unless you have permissions for Pendo, but you can easily remove those two page by removing the folder by that name and removing it's routes from app-routes.js. I plan to clean that up and move Pendo specific stuff into it's own repo, but it was just easier to have it here as examples.
Using Cmd 3.0.0.141, I have successfully generated a workspace and an Ext app in that workspace. The application builds correctly until I attempt to integrate the Bryntum Scheduler, where I encounter an error when I try to build:
"Failed to resolve dependency Sch.panel.SchedulerTree for file ExtCalendar.view.Tree"
the app is very simple at this point, uses Ext.application and follows the MVC pattern where I have a view defined "ExtCalendar.view.Tree" that extends 'Sch.panel.SchedulerTree". I also have models and stores that extend Bryntum classes as well, so I assume the compiler will trip over those as well, since it can't see the Sch namespace.
I've added a 'js' path to my app.json that points to the bryntum js file where 'Sch.panel.SchedulerTree' comes from. I've tried to run the 'refresh' command with the same results (Failed to resolve...). I've regenerated the bootstrap.js file manually using 'compile', but nothing from the Sch namespace ever gets added to it, despite the Brytum lib file being in the classpath.
What do I need to do in order to successfully run the 'build' command with libs like this?
Or, do I need to take a more granular approach using the 'compile' command?
With the help of the nice folks on the Sencha forums, I was able to resolve my build issues. The solution, for me, involved a shim. I added an external shim.js file to my index with as many //#require and //#define directives as needed in order to resolve the dependency issues.
According to the nice folks at Bryntum, once I upgrade from the free-trial version of the Bryntum Scheduler, I will be able to get rid of the shim and simply rely on the sencha.cfg classpath pointing at the Bryntum src.
Also, as an aside, the app.json file is not used in ExtJS apps, its inclusion in the generated files was a bug in build 141 of Cmd v3.
See this thread for more detail.