I'm trying to use sbt-web and sbt-js-engine in particular to resolve my dependencies with npm instead of webjars.
My problem is that the dependencies are not copied in the target/web/public/main/lib folder during the web-stage task as it is the case using webjar.
I used the sample project from sbt-js-engine to make my tests. With this project, I expect to find the console-browserify dependency from the package.json file in the target/web/public/main/lib folder, but it is not.
Maybe I'm completely misunderstanding something ?
I've had a similar problem myself when trying to pulling some test dependencies with npm. after a few hour searching for a solution I ended up just writing a task in my build.sbt to move the directories manually: (May not be the best solution but a work around)
lazy val copy_node_modules = taskKey[Unit]("Copys the node_module to the test target dir")
copy_node_modules := {
val node_modules = new File("node_modules")
val target = new File("target/web/public/main/public/lib/")
IO.copyDirectory(node_modules,target,true, true)
}
addCommandAlias("get_npm_deps", ";web-assets:jseNpmNodeModules;copy_node_modules")
then you can use "get_npm_deps" to pull in the npm based dependencies
Related
I tried to check for answers in https://junit.org/junit5/docs/current/user-guide/#advanced-topics.
The code works fine for package selection if we want to disocver in same package or down package but it is unable to search for tests if the tests are present in some other package in other module.
Code -->
LauncherDiscoveryRequestBuilder.request()
.selectors(
selectPackage("com")
)
.filters(
TagFilter.includeTags(tag)
)
.configurationParameters(map).build();
Use Classdir and selectClasspathRoots(Collections.singleton(Paths.get(classdir.toURI()))) method to pass in selectors to discover tests in entire directory. If tests are present in other module , they will be discovered too.
Use below for Classdir
File classdir = new File("Project Path\ProjectName\target\*");
All the tests present in target folder will be discovered.
I have a Gradle build where a large JSON configuration is bundled into a package for later upload onto a server. Sometimes when changes are made to the file, the file is not valid any more and thus fails to upload on the server.
I would like to find this earlier by adding a validate-step in the Gradle build.
When looking around I could not find a documented way to do this, I saw the project gradle-json-validator which looks promising, but there is no documentation whatsoever, so I am not sure how this can be used...
Any hint on gradle-json-validator or any other way to validate a JSON file as part of the Gradle build steps?
From source, it would seem, the usage would be:
buildscript {
repositories {
jcenter()
}
dependencies {
classpath 'cz.alenkacz.gradle:json-validator:0.9.9'
}
}
apply plugin: 'cz.alenkacz.gradle.jsonvalidator'
The plugin doesn't seem to have an extension to do configuration. But seems to use jsonSchema and targetJsonFile as input schema and file-to-validate. I would try setting them at the root level of build.gradle
validateJson.jsonSchema = new File('/path/to/schema')
validateJson.targetJsonFile = new File('/path/to/jsonFile')
and the task to run is:
gradle validateJson
I have improved the readme file in the repository with proper usage example.
Hope that helps. https://github.com/alenkacz/gradle-json-validator
This is the code i'm using to update the file.
File metadata = generateFileMetadata(fileId, thumbnail, properties);
return mService.files().update(fileId, metadata, generateFileContents())
.setFields("id, name, appProperties")
.execute();
This code generates a
java.lang.IllegalArgumentException.
at com.google.api.client.repackaged.com.google.common.base.Preconditions.checkArgument(Preconditions.java:111)
at com.google.api.client.util.Preconditions.checkArgument(Preconditions.java:37)
at com.google.api.client.googleapis.media.MediaHttpUploader.setInitiationRequestMethod(MediaHttpUploader.java:872)
at com.google.api.client.googleapis.services.AbstractGoogleClientRequest.initializeMediaUpload(AbstractGoogleClientRequest.java:237)
at com.google.api.services.drive.Drive$Files$Update.<init>(Drive.java:3163)
at com.google.api.services.drive.Drive$Files.update(Drive.java:3113)
Using breakpoints I could see that the String passed to the setInitiationRequestMethod is PATCH (not POST or PUT):
public MediaHttpUploader setInitiationRequestMethod(String initiationRequestMethod) {
Preconditions.checkArgument(initiationRequestMethod.equals(HttpMethods.POST)
|| initiationRequestMethod.equals(HttpMethods.PUT));
this.initiationRequestMethod = initiationRequestMethod;
return this;
}
this is what i have in my build.gradle
compile 'com.google.android.gms:play-services-identity:8.4.0'
compile('com.google.api-client:google-api-client-android:1.21.0') {
exclude group: 'org.apache.httpcomponents'
}
compile('com.google.apis:google-api-services-drive:v3-rev11-1.21.0') {
exclude group: 'org.apache.httpcomponents'
}
if I remove the file content (generateFileContents()) I'm able to update the metadata just fine.
How do I solve this?
I ran into this bug while writing a Drive REST API integration for an Android app (with Android Studio/Gradle). Since I'm not particularly experienced with Android's build system, resolving the issue cost me a few hours. Maybe this helps somebody with the same problem:
Clone the google-api-java-client repo from GitHub https://github.com/google/google-api-java-client
Install Maven https://maven.apache.org/run-maven/ (e.g. brew install maven on OSX)
On the command line, change into the google-api-client sub dir of the repo you cloned above
Run mvn clean install
This will produce a subdir called target in the google-api-client directory
In there, find google-api-client-1.22.0-SNAPSHOT.jar, rename it to google-api-client-1.21.00.jar (the renaming is probably not needed)
Drop the .jar in the libs folder of your android project
Tell Gradle to ignore the google-api-client dependency of the libraries you use, in my case this was:
compile('com.google.api-client:google-api-client-android:1.21.0') {
exclude group: 'org.apache.httpcomponents'
exclude module: 'google-api-client'
}
compile('com.google.apis:google-api-services-drive:v3-rev14-1.21.0') {
exclude group: 'org.apache.httpcomponents'
exclude module: 'google-api-client'
}
Add the Jackson dependency again, in case you miss it now. Do the same with other google-api-java-client dependencies if you need them.
compile('com.google.http-client:google-http-client-jackson2:1.21.0'){
exclude group: 'org.apache.httpcomponents'
}
Build your project, update(...) should now work.
Make a note to scrap these changes once Google has updated the library.
Take a look at the current commit of the google-api-java-client.
Unfortunately the fix was not released yet (fix on 21 Nov 2015 vs release on 19 Nov 2015), so you may have to build locally the project (with maven for instance)
The MediaHttpUploader javadocs suggests that it will only be used for HttpMethods#POST, and HttpMethods#UPDATE. Using update, based on the Files resource, indicates its using a PATCH method - leading to the IllegalArgumentException.
The overridden update method should only be used if you're uploading media content.
I have the same exception in a Desktop application.
Instead, using the Drive Api V2, the update goes well.
I'm documenting an internal REST API written ini Scala, unfortunately we are not able to integrate Swagger, so for now we are going with an in-house solution for the doc generator.
I would like to generate a JSON-Schema to show how the response is when getting our resources. I'm just wondering if there is any shortcut to do this by taking advantage of the case classes already modeled.
The autoschema project is able to export JSON schema from Scala case classes. You can use it as follows:
case class MyType(myValue: Int)
AutoSchema.createSchema[MyType]
The Maven artifact seems to be no longer available but it is an SBT project available on Github so you can either copy the sources, build a Jar or add it as a dependency with SBT by putting in your build.sbt the following:
lazy val autoschemaProject =
ProjectRef(uri("https://github.com/coursera/autoschema.git"), "autoschema")
lazy val root = (project in file(".")).dependsOn(autoschemaProject)
I tested this with SBT 0.13.7. Notice that autoschema has its own dependencies (mainly play-json 2.3.2) so you might need to change their versions to avoid version conflicts with you own project dependencies.
As #mziccard stated, autoschema is the way to go. However, it's been a while since there has been some activity on the main repository. I took some time to fork it and update its dependencies and deprecated code (work that was done in other forks, I simply combined it). It is now published in maven central under my fork:
https://github.com/sauldhernandez/autoschema
You can use it by putting this in build.sbt:
libraryDependencies += "com.sauldhernandez" %% "autoschema" % "1.0.0"
I have a module. Inside it, I'd like to access data from my parent application's package.json file. What's the best practice way to do that?
I've done this the janky way by going up 2 levels and requiring the file (or using the nconf configuration loader).
var appdir = path.resolve(__dirname, '../../');
nconf.file('app', path.join(appdir, 'package.json'));
But that seems like it could break easily.
Also I heard about pkginfo, it will automatically grab info from my own module's package.json, but I'm looking to get data from the parent application's.
Thanks for any help!
EDIT: I suppose another way of asking is, how can I get the application's path (instead of the module path) ?
You can use
require.main.require './package'
But it'll work only if your parent application's file is in a root of it's directory.
You can also wrap it into try ... catch and add ../ to path till you find package.json.
You can read more about accessing main module here http://nodejs.org/api/modules.html#modules_accessing_the_main_module
Adding to pcru's approach, this should work:
function loadMainPackageJSON(attempts) {
attempts = attempts || 1;
if (attempts > 5) {
throw new Error('Can\'t resolve main package.json file');
}
var mainPath = attempts === 1 ? './' : Array(attempts).join("../");
try {
return require.main.require(mainPath + 'package.json');
} catch (e) {
return loadMainPackageJSON(attempts + 1);
}
}
var packageJSON = loadMainPackageJSON();
Keep in mind that this will get you the main module, which something you think is what you want , but if you're building a command line tool like I was, what you really want is to get the package.json exactly two folders above where you were installed if your tool is meant to be installed locally and called with npm run-script
As mentioned in Determine project root from a running node.js application , one of the easiest ways to get to your application path is using process.cwd(), provided you have the discipline to always start your main js program from the same directory. i.e. node app/main.js and cd app && node main.js will give different results.
Another way could be to recursively follow the references to module.parent, then read out module.filename when module.parent is undefined. This also presupposes some knowledge about your app. It won't work if the location of the main script relative to the package.json could vary. I.e. you must know if the main script is in the root of the app directory, or maybe in some sort of 'bin', 'app', or 'lib' dir. However, once you find the top-level module, you could try to locate the closest package.json using the same algorithm pkginfo uses to find the package.json for the current file.