I was trying to create package of legacy electron app using electron-packager but got an error like below. I have search several questions in stackoverflow with no luck.
electron-packager . MyApp --platform=win32 --arch=x64 --no-prune --overwrite --ignore=/node_modules
Packaging app for platform win32 x64 using electron v3.1.13
Cannot read property 'info' of undefined
Below are the installed package in the project:
+-- electron-builder#20.44.4
+-- electron-json-storage#4.1.6
+-- electron-packager#15.5.2
+-- electron-winstaller#3.0.4
+-- electron#3.1.13
+-- history#4.9.0
+-- macaddress#0.2.9
+-- moment#2.29.4
+-- node-sass#4.14.1
+-- rc-tooltip#3.7.3
+-- react-bootstrap#1.6.6
+-- react-dom#16.8.4
+-- react-redux#6.0.1
+-- react-router-dom#4.3.1
+-- react-router#4.3.1
+-- react-scripts#2.1.5
+-- react#16.8.3
`-- redux#4.0.1
electron-packager#15.5.2 caused the same issue for me. A slight downgrade to electron-packager#15.5.1 made it working again!
Same here, electron-packager#15.5.2 caused the same issue for me.
From my side, I upgraded to electron-packager#16.0.0 to made it working again.
I did not find a related issue on GitHub.
In the end I change tools and follow according to electron documentation about application packaging. I change to electron-forge and follow the steps. It works better than packager.
Related
At the moment I'm trying to link my Rust library with my Java project with JNI.
When I build my Rust library with cargo build there are no errors. My code works!
My problem is the interface between Java and Rust. When I run my Java project with InteliJ there appears this error message:
OpenJDK 64-Bit Server VM warning: You have loaded library /home/.../Encoding/libs/poc which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c <libfile>', or link it with '-z noexecstack'.
Exception in thread "main" java.lang.UnsatisfiedLinkError: cannot read file data: Is a directory
at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
at java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2445)
at java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2501)
at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2700)
at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2630)
at java.base/java.lang.Runtime.load0(Runtime.java:768)
at java.base/java.lang.System.load(System.java:1837)
at com.example.Main.<clinit>(Main.java:16)
My next step was to compile my Rust library with execstack with the following command:
cargo build --verbose -Z build-std=core,alloc -c link-args=-znoexecstack
Another method for me was to add this arguments to my Cargo.toml:
[lib]
link-args = ["-z", "noexecstack"]
When I try to build my Rust library now, these arguments will be ignored:
$ cargo build
warning: unused manifest key: lib.link-args
Compiling poc v0.1.0 (/home/.../Encoding/libs/poc)
Finished dev [unoptimized + debuginfo] target(s) in 1.50s
Now I hope that anyone of you can help me with my problem. I would be very thankful!
Maybe this is also interesting: my project structure
Encoding
|-- libs
|-- poc
|-- src
|-- lib.rs
|-- cargo.toml
|-- src
|-- main/java/org/example
|-- Main.java
|--target
|-- ...
|-- pom.xml
As described I tried following commands
cargo build --verbose -Z build-std=core,alloc -c link-args=-znoexecstack
cargo build with [lib] -> link-args = ["-z", "noexecstack"]
And I need this to run my Java project without the risk of an executable stack!
this is the first time i ask a question on stackoverflow, so i apologize in advance if i write something strange and thanks everyone for the help.
I have implemented a modular solution based on Asp.Net MVC 5, TypeScript 2.2.0 and Angular 4.0.0 compiled with Webpack 3.0.0.
It has a Main application (MVC) that must host external Modules that are other MVC applications with own backend Web Apis and own Angular components.
My goal is to compile and deploy single module without having source code of others Modules or Main app source code, but using just compiled bundles and definitely types.
In this way i can deploy only my module (bundle.js and dlls) in append to the main application.
The process should be:
Compile Main App
Deploy on Server
Compile Module1
Copy bin dll on Main App bin
Copy Module1 js bundle on Main App scripts folder
and so on...
I'm just able with webpack to compile single module and resolve same names using last generated "records.json" file.
The problem is when i want to use a component of other module. I have to import class using d.ts generated from other module:
/// <reference path="../../../typings/module1.d.ts" />
import { HttpWrapperService } from "Module1/App/http-wrapper/http-wrapper.service";
But when Webpack encounter import statement it can't resolve module because there is no source code of http-wrapper.service, and return this error:
Module not found: Error: Can't resolve 'Module1/App/http-wrapper/http-wrapper.service' in 'C:\svn\AngularApp\Module2\App\users'
How can i tell to Webpack to resolve the module name imported from d.ts using "records.json" file?
Maybe with a plugin?
Solution has a structure like this:
Root
|--- Main (MVC App)
| |
| |--- Manifest.js
| |--- Vendor.js (bundle of all third party libraries like Angular or jQuery)
| |--- Polyfills.js
| |--- App.js (bundle of main app)
|
|--- typings
| |
| |--- app.d.ts
| |--- module1.d.ts
| |--- module2.d.ts
|
|--- Module1
| |
| |--- App
| |
| |--- http-wrapper
| |
| |--- http-wrapper.service.ts
|
|--- Module2
|
|--- App
|
|--- users
|
|--- users.component.ts
|--- users.service.ts
I have installed electron and electron-packager, all of them in global mode. When I build my app electron-packager searchs the local electron module. How forcing electron-packager to use the global electron module that I have installed?
The short answer is that what you have described isn't the way you "should" use electron-packager. Normally, the intent is that you are building a local package (exe or such) under the project directory you are working on. For example, an electron/angular project building on a Windows platform might have the following kind of structure:
C:.
+---ClientSide
¦ +---index.html
¦ +---app
¦ ¦ +---app.component.ts
¦ ¦ +---app.module.ts
¦ ¦ +---main.ts
¦ ¦ +---AppContent/
¦ ¦ +---help/
¦ +---Styles
¦ +---test
¦ +---AppContent/
+---dist/
+---edist
| \---Application-win32-ia32 [*location of binary source for the install]
+---Installer
+---Application/
gulpfile.js
karma.conf.js
main.js
package.json
README.md
webpack.config.js
In this kind of scenario, the package.json file typically contains reference to both packages, as in:
.. .. ..
"devDependencies": {
"#angular/animations": "4.4.4",
"#angular/common": "4.4.4",
"#angular/compiler": "4.4.4",
.. .. ..
.. .. ..
"electron": "1.7.9",
"electron-packager": "9.1.0",
.. .. ..
Then within your local gulpfile.js you would typically include a call to run the packager that refers to the local version of electron. Something like:
'use strict';
... ...
var packager = require('electron-packager');
var electronPackage = require('electron/package.json');
var pkg = require('./package.json');
// pull the electron version from the package.json file
var electronVersion = electronPackage.version;
... ...
var opts = {
name: pkg.name,
platform: 'win32',
arch: 'ia32', // ia32, x64 or all
dir: './', // source location of app
out: './edist/', // destination location for app os/native binaries
ignore: config.electronignore, // don't include these directories in the electron app build
icon: config.icon,
asar: {unpackDir: config.electroncompiled}, // compress project/modules into an asar blob but don't use asar to pack the native compiled modules
overwrite: true,
prune: true,
electronVersion: electronVersion , // Tell the packager what version of electron to build with
appCopyright: pkg.copyright, // copyright info
appVersion: pkg.version, // The version of the application we are building
win32metadata: { // Windows Only config data
CompanyName: pkg.authors,
ProductName: pkg.name,
FileDescription: pkg.description,
OriginalFilename: pkg.name + '.exe'
}
};
// Build the electron app
gulp.task('build:electron', function (cb) {
console.log('Launching task to package binaries for ' + opts.name + ' v' + opts['appVersion']);
packager(opts, function (err, appPath) {
console.log(' <- packagerDone() ' + err + ' ' + appPath);
console.log(' all done!');
cb();
});
});
If you don't want to build the same version of electron that as is present locally, you can change that parameter to whatever version of electron you'd like packager to use. As in, replacing this line of code:
// pull the electron version from the package.json file
var electronVersion = electronPackage.version;
With something like this:
// Use a specific electron version
var electronVersion = '1.7.8';
If you are going to run electron-packager from the command line, you have all the same options available as I've shown here in the API options. You can see the full list of options in their online github user docs . In your case, if you are using command line then use the "--electron-version" switch to set the electron version you wish.
I'm writing a cordova ios plugin, I managed to set the plugin.xml file correctly in order to work and import my plugin inside the project with
cordova plugin add myplugin --searchpath=path/to/my/plugin --save
command. What I'd like to do now is to group all the plugin files inside a folder.
For example, having these 2 files (snippet from plugin.xml)
...
<source-file src="src/ios/MyPlugin.m" />
<source-file src="src/ios/MyPlugin.h" />
...
I'd like to group them under MyPlugin folder, inside the iOS project Plugins folder:
MY_PROJECT
|-- www/
|-- Staging/
|-- Classes/
|-- Plugins/
| |-- MyPlugin/ <!-- HERE -->
| | |-- MyPlugin.m
| | |-- MyPlugin.h
| |-- SomeOtherPlugin.m
| |-- Foo.h
|-- Other Sources/
|-- Resources/
|-- Framework/
|-- Products/
Right now, cordova's CLI plugin manager seems to throw any plugin file inside the Plugins folder, despite the plugin they belong to.
Is there anything equivalent to Android's target-dir attribute for iOS? Any hint?
Thanks in advance
First , based on the official document : ios also support <source-file src="src/ios/MyPlugin.m" target-dir="xxxxx"/> , however cordova just copy the file to "xxxxx" folder in the file system , which could not be reflected to Xcode project structure.
Actually what you want is to specify "Group" for ios source file , while
unfortunately , currently it seems cordova doesn't support it
My project has two modules, lib and lib-api, with the following responsibilities
lib-api - a pure java module that only contains interface files
lib - an android library
and I'd like to jenkins publish both modules (as jars) to an internal artifactory server for other projects to be able consume.
Using the Jenkins Artifactory Plugin, I was able to publish jars for both modules to artifactory, but my other project that depends on lib fails to build with the following gradle error
Could not find com.mygroup:lib-api:1.0.0-SNAPSHOT
My setup
Build scripts
lib-api/build.gradle
apply plugin: 'java'
apply plugin: 'maven-publish'
group = 'com.mygroup'
version = project.version
publishing {
publications {
api(MavenPublication) {
from components.java
}
}
}
lib/build.gradle
apply plugin: 'com.android.library'
apply plugin: 'com.github.dcendents.android-maven'
android { ... }
dependencies {
compile project(':lib-api')
}
group = 'com.mygroup'
version = project.version
Jenkins Artifactory plugin config
Gradle-Artifactory Integration
Publish artifacts to Artifactory
Publish Maven descriptors
Use Maven compatible patterns
Invoke Gradle script
Use Gradle Wrapper
Tasks: clean assemble -x preDexDebug -x preDexDAT -x preDexRelease
Result in Artifactory repo
+-- libs-snapshot-local
| +-- com
| | +-- mygroup
| | | +-- lib
| | | | +-- 1.0.0-SNAPSHOT
| | | | | `-- lib-1.0.0-20150508-1.jar
| | | | | `-- lib-1.0.0-20150508-1.pom
| | | | | `-- maven-metadata.xml
| | | | `-- maven-metadata.xml
| | | +-- lib-api
| | | | +-- 1.0.0-SNAPSHOT
| | | | | `-- lib-1.0.0-20150508-1.jar
Question
My understanding is that artifactory/gradle should be smart enough to resolve -SNAPSHOT into the latest timestamped snapshot and that seems to be borne out by the fact that it manages to resolve lib whether I specify latest.integration or 1.0.0-SNAPSHOT
How can I get gradle to resolve this transitive snapshot dependency from artifactory? Or get the artifactory plugin to publish the jar in such a way that gradle can resolve it?
Working theory
I noticed that the lib-api folder doesn't have a maven-metadata.xml file and the snapshot version folder doesn't have one either... or pom file. I suspect this might be the issue.
Artifactory's Jenkins plugin uses the gradle artifactory plugin under the hood for jobs that have Gradle-Artifactory integration enabled. According to the gradle artifactory plugin docs the plugin ID changes depending on whether you are using the new (maven-publish) or old (maven) publishing mechanism.
Could this be the issue? Is the Artifactory plugin applying the wrong plugin ID, perhaps because it is making it's decision based on the android library module?
tl;dr Switching to the old maven plugin for gradle fixed it.
My lib-api/build.gradle now looks like this
apply plugin: 'java'
apply plugin: 'maven'
group = 'com.mygroup'
version = project.version
ext.artifactId = project.name.toLowerCase()
project.archivesBaseName = project.artifactId
uploadArchives {
repositories {
mavenDeployer {
pom.artifactId = project.artifactId
}
}
}
Note: According to the gradle docs for the maven plugin, pom.artifactId must be explicitly defined if you've set archivesBaseName. That may have been the underlying issue with my previous configuration, but I did not go back and test it.