Consider the following command which runs flawlessly using bash:
java -classpath bin:lib/* FunctionalTests.TestRunner
The classes are in bin, jars are in lib, main() is in bin/FunctionalTests/TestRunner:
.
├── bin
├── lib
│ ├── commons-collections-3.2.1.jar
│ ├── commons-httpclient-3.1.jar
│ ├── commons-io-2.1.jar
│ ├── commons-lang-2.4.jar
│ ├── commons-logging-1.1.1.jar
│ └── ...
└── src
When the same command runs with zsh, the output is:
zsh: no matches found: ./bin:./lib/*
Any ideas?
It boils down to another pair of quotes:
java -classpath "bin:lib/*" FunctionalTests.TestRunner
Hope it helps someone in the future.
Try to use something like this to add every .jar in the classpath:
CP=bin
for i in lib/*.jar
do
CP=$CP:${i}
done
java -classpath $CP FunctionalTests.TestRunner
Related
I'm trying to follow the the README.md for grpc-java's TLS example, https://github.com/grpc/grpc-java/tree/master/examples/example-tls. It states that running
../gradlew installDist
This creates the scripts hello-world-tls-server, hello-world-tls-client, in the build/install/example-tls/bin/ directory that run the example. The example requires the server to be running before starting the client.
However, after replacing the gRPC version 1.36.0-SNAPSHOT by 1.35.0 everywhere in the examples directory and running that command, the build/install/examples/bin directory contains no such scripts:
~/D/S/g/examples (master)> tree build/install/examples/bin
build/install/examples/bin
├── compressing-hello-world-client
├── compressing-hello-world-client.bat
├── hedging-hello-world-client
├── hedging-hello-world-client.bat
├── hedging-hello-world-server
├── hedging-hello-world-server.bat
├── hello-world-client
├── hello-world-client.bat
├── hello-world-server
├── hello-world-server.bat
├── retrying-hello-world-client
├── retrying-hello-world-client.bat
├── retrying-hello-world-server
├── retrying-hello-world-server.bat
├── route-guide-client
├── route-guide-client.bat
├── route-guide-server
└── route-guide-server.bat
0 directories, 18 files
In my local repository, I've changed this line, https://github.com/grpc/grpc-java/blob/1b23cf4f39ab26728336edbda8bb6af22dfe0a01/examples/example-tls/build.gradle#L58, to
startScripts.enabled = true
However, after running ./gradlew installDist again, the expected start scripts are still nowhere to be found. I've perused the documentation on CreateStartScripts, https://docs.gradle.org/current/dsl/org.gradle.jvm.application.tasks.CreateStartScripts.html, but I don't immediately see what's amiss. Any idea why no start scripts are created for the TLS example?
The documentation recommends to checkout a git tag:
You are strongly encouraged to check out a git release tag, since there will already be a build of grpc available
❯ git checkout v1.35.0
❯ cd examples/example-tls
❯ ../gradlew installDist
Then you'll be able to find the binaries in build/install/example-tls/bin:
❯ tree build/install/example-tls/bin
build/install/example-tls/bin
├── hello-world-tls-client
├── hello-world-tls-client.bat
├── hello-world-tls-server
└── hello-world-tls-server.bat
I'm having some issues creating unit tests for my Puppet control repository.
I mostly work with roles and profiles with the following directory structure:
[root#puppet]# tree site
site
├── profile
│ ├── files
│ │ └── demo-website
│ │ └── index.html
│ └── manifests
│ ├── base.pp
│ ├── ci_runner.pp
│ ├── docker.pp
│ ├── gitlab.pp
│ ├── logrotate.pp
│ └── website.pp
├── role
│ └── manifests
│ ├── gitlab_server.pp
│ └── nginx_webserver.pp
Where do I need to place my spec files and what are the correct filenames?
I tried placing them here:
[root#puppet]# cat spec/classes/profile_ci_runner_spec.rb
require 'spec_helper'
describe 'profile::ci_runner' do
...
But I get an error:
Could not find class ::profile::ci_runner
The conventional place for a module's spec tests is in the module, with the spec/ directory in the module root. So site/profile/spec/classes/ci_runner_spec.rb, for example.
You could consider installing PDK, which can help you set up the structure and run tests, among other things.
In Drupal 7 I use
drush-patchfile
to automatically implements patches when installing/updating module via drush. But in DDEV I don't know how to extend existing drush with drush-patchfile
As you can see on https://bitbucket.org/davereid/drush-patchfile section Installation, I need to clone the repository into
~/.drush
directory and that will append it to existing drush.
On another project without DDEV, I've already done that with creating new docker image file
FROM wodby/drupal-php:7.1
USER root
RUN mkdir -p /home/www-data/.drush && chown -R www-data:www-data /home/www-data/;
RUN cd /home/www-data/.drush && git clone https://bitbucket.org/davereid/drush-patchfile.git \
&& echo "<?php \$options['patch-file'] = '/home/www-data/patches/patches.make';" \
> /home/www-data/.drush/drushrc.php;
USER wodby
But I'm not sure how to do that in DDEV container.
Do I need to create a new service based on drud/ddev-webserver or something else?
I've read documentation but not sure in what direction to go.
Based on #rfay comment, here solution that works for me (and with little modification can works for other projects).
I've cloned repo outside of docker container; for example, I've cloned into
$PROJECT_ROOT/docker/drush-patchfile
Create custom drushrc.php in the $PROJECT_ROOT/.esenca/patches folder (you can choose different folder)
<?php
# Location to the patch.make file. This should be location within docker container
$options['patch-file'] = '/var/www/html/.esenca/patches/patches.make';
Add following hooks into $PROJECT_ROOT/.ddev/config.yaml
hooks:
post-start:
# Copy drush-patchfile directory into /home/.drush
- exec: "ln -s -t /home/.drush/ /var/www/html/docker/drush-patchfile"
# Copy custom drushrc file.
- exec: "ln -s -t /home/.drush/ /var/www/html/.esenca/patches/drushrc.php"
Final project structure should looks like
.
├── .ddev
│ ├── config.yaml
│ ├── docker-compose.yaml
│ ├── .gitignore
│ └── import-db
├── docker
│ ├── drush-patchfile
│ │ ├── composer.json
│ │ ├── patchfile.drush.inc
│ │ ├── README.md
│ │ └── src
├── .esenca
│ └── patches
│ ├── drushrc.php
│ └── patches.make
├── public_html
│ ├── authorize.php
│ ├── CHANGELOG.txt
│ ├── COPYRIGHT.txt
│ ├── cron.php
│ ├── includes
│ ├── index.html
│ ├── index.php
│ ├── INSTALL.mysql.txt
│ ├── INSTALL.pgsql.txt
│ ├── install.php
│ ├── INSTALL.sqlite.txt
│ ├── INSTALL.txt
│ ├── LICENSE.txt
│ ├── MAINTAINERS.txt
│ ├── misc
│ ├── modules
│ ├── profiles
│ ├── README.txt
│ ├── robots.txt
│ ├── scripts
│ ├── sites
│ │ ├── all
│ │ ├── default
│ │ ├── example.sites.php
│ │ └── README.txt
│ ├── themes
│ ├── Under-Construction.gif
│ ├── update.php
│ ├── UPGRADE.txt
│ ├── web.config
│ └── xmlrpc.php
└── README.md
At the end start ddev envronment
ddev start
and now you can use drush-patchfile commands within web docker container.
You can ddev ssh and then sudo chown -R $(id -u) ~/.drush/ and then do whwatever you want in that directory (~/.drush is /home/.drush).
When you get it going and you want to do it repetitively for every start, you can encode the instructions you need using post-start hooks: https://ddev.readthedocs.io/en/latest/users/extending-commands/
Please follow up with the exact recipe you use, as it may help others. Thanks!
I'm having trouble to import a generated package with Intellij, however without any changes to the default settings it works on Eclipse.
Here is my architechture:
├── build.properties
├── pom.xml
├── README.md
├── src
│ ├── main
│ │ ├── java
│ │ └── mypackage
│ └── test
└── target
├── classes
│ └── mypackage
| └── generated
├── generated-sources
├── generated-test-sources
├── APP.jar
└── test-classes
I have most of my classes in com.mypackage however some of them are generated in
└── target
├── classes
└── mypackage
named as com.mypackage.generated and i have to use these classes in com.mypackage:
├── src
├── main
├── java
└── mypackage
However intellij cannot resolve symbol generated when I'm doing
import com.mypackage.generated
I tried to make it work by looking at the project structure/modules/dependencies menu but it seems to be for external modules. How can I do this ?
Actually it was very simple, I only was about marking classes as sources root. I don't know why marking generated as sources root did not work.
So I have:
buildSrc/
├── build.gradle
└── src
├── main
│ ├── groovy
│ │ └── build
│ │ ├── ExamplePlugin.groovy
│ │ └── ExampleTask.groovy
│ └── resources
│ └── META-INF
│ └── gradle-plugins
│ └── build.ExamplePlugin.properties
└── test
└── groovy
└── build
├── ExamplePluginTest.groovy
└── ExampleTaskTest.groovy
Question:
It seems like build.ExamplePlugin.properties maps directly to the build.ExamplePlugin.groovy. Is this the case? Seems terribly inefficient to have only one property in the file. Does it have to be fully qualified, i.e. does the name have to exactly match the full qualification of the class?
Now in the example, I see:
project.pluginManager.apply 'build.ExamplePlugin'
...however if I have that in my test, I get an error to the effect that the simple task the plugin defines, is already defined.
Why bother with test examples that require 'apply' when that is inappropriate for packaging?