I'm just wondering if the app supports mssql. I found datasource configuration for H2 and PostgreSQL but non for other datasources supported by Quarkus.
Optaweb-employee-rostering is a rich example application that shows how the employee rostering problem can be solved with OptaPlanner. As such, users are expected to take inspiration from it and change the app as they need.
If you want to try the app with MS SQL, replace a JDBC driver dependency:
https://github.com/kiegroup/optaweb-employee-rostering/blob/main/optaweb-employee-rostering-backend/pom.xml#L81-L84
and change the Quarkus profile:
https://github.com/kiegroup/optaweb-employee-rostering/blob/main/optaweb-employee-rostering-backend/src/main/resources/application.properties#L24-L28
The Quarkus profile can be activated during the build by specifying the quarkus.profile maven property, e.g.:
mvn clean install -Dquarkus.profile=postgres
Related
I'm currently developing a (Laravel) package on Gitlab, and i want to automate testing using its CI/CD pipeline.
The problem
I already know ho to set up a pipeline in Gitlab, but what i want to achieve is to automate testing against different versions of the same dependancy, in order to keep checking compatibility with old version and add checking with upcoming new ones.
The case
My Laravel package is not so complex right now and don't use some particular nor specific Laravel features, so i would like to keep it compatible with te more versions of laravel possible: i would trigger different testing stages in my pipeline to run my tests against laravel 5.6, 5.7, 5.8, 6, 7, and 8.
The question
How do i trigger different testing stages using different laravel/framework versions?
When downloading dependancies composer will go for the latest version available if i define it with '^', so which files do i have to edit?
Ok, i've analyzed the problem a bit more, and made some considerations about it.
I'm writing not to properly answer my question, since i hope someone will eventually came up with a better solution/idea, but to just share some toughts with everyone is facing the same problem.
First: since i'm developing a package for Laravel i cannot declare laravel as dependancy for it, production nor develop, it is my laravel project that need to declare my package as a dependancy.
Second: to test my package compatibility with laravel i'm using orchestra/testbench as a dev-dependancy, and as for its documentation every release target a single and precise Laravel version, so if i want to test my package against different Laravel version i need to test it with different orchestra/testbench releases.
Third: the only dependancy my package has is just php 7.3, so i can easily test against this and subsequent version using Gitlab pipeline and creating a job for each php version that use a docker image with the correct php version and the last composer one.
Conclusion
It is not trivial nor straight to test a Laravel package against different Laravel version.
The only idea i came up with, but not tried since i gave it up aj just test php versions (for now) is to make a branch for each Laravel version i want to test with and update its composer.json dev-dependancy with the correct orchestra/testbench release.
Than i can execute php tests on my features branch merge request, and in case of success merge the develop branch on each "laravel branch" and execute on those the laravel compatibility test.
At last, if every laravel branch pass its tests, or at least the ones i decide to keep deevelopment/support active for, i can merge the develop branch on the master.
I'm not goig for it
I decided to avoid all of this since i'm not quite sure on how implement all of this on the pipeline, and i strongly think that it just adds mantainence burden to this project.
So i just keep the php jobs to check against different php versions, this way i just need to copy/paste a job definition in my gitlab-cy.yml file and change the docker image version accordingly to the new php version to test against.
We're using Worklight 6.1.0.0 / WebSphere 8.0.0.2 (ND/aix).
This seemed pretty close to my question too, but for version 6.0.
I've successfully done uninstall/install to our worklight console war package. However, there is some extra work on re-deploying adapters and such. I was looking for a way to just update the console. Among the ant tasks there is a target 'minimal-update', which sounds like what I'm looking for (is it?). However when all other pieces fell into place, I have an error for mapping the datasources:
ADMA0007E: A validation error occurred in task Mapping resource references to resources. The Java Naming and Directory Interface (JNDI) name is not specified for resource reference jdbc/WorklightDS in module Worklight with EJB name .
Contents of the 'minimal-update' task is pretty much the same as for 'install'.
I tried that as update from websphere admin console (but i should use the ant task - right?), that gave me a wizard screen to map jdbc/WorklightDS from package to jdbc/WorklightDS on server. This left me wondering how could I tell this using the ant task.
The ant target minimal-update of the sample configuration files documented at http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/topic/com.ibm.worklight.deploy.doc/devref/c_ant_tasks_sample_config_files.html is meant to update a WAR file already deployed (and not uninstalled). In particular, on WAS, it assumes that the JNDI datasources are in place.
If you have uninstalled the WAR file, you should use the target install instead, provided that your databases were created for Worklight 6.1.
If they were created for a previous version of worklight you must upgrade their schema as well running the target 'databases' (and if it's a production installation, you might want to read all the steps in detail at http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/topic/com.ibm.worklight.upgrade.doc/devenv/c_upgrade_to_srvr610_in_production_env.html )
I have an IntelliJ project with several modules. Some of the modules should be run as servers. For every server (module), I have a run configuration.
Can I bundle those run configurations together, so I don't need to click run or stop five times?
If it matters, the project is fully mavenized.
The previously accepted answer does not work for running multiple servers or any scripts which do not terminate. However, now you can use the Compound run configuration to execute multiple non-terminating servers simultaneously. It looks like this:
Steps to get it working:
Create the individual run configurations
Create a new compound configuration
Choose the desired individual run configurations.
Run the new Compound configuration.
Go to the intellij documentation.
All the individual configs will run simultaneously - perfect for servers and other threads which do not exit!
NOTE: Even the MultiRun plugin recommends using Compound on their GitHub page.
More info in the IDEA documentation.
Update
This now is possible (despite the fact that the issues #CrazyCoder linked to are still open as of this date). In Intellij 12, you can "Run Another Configuration" before launch when you're in "Edit Configurations". Here's a screenshot:
Check out this Multirun plugin.
And yes, I found it following CrazyCoder's link, so props to him again!
I found that 'Compound' sorted all modules alphabetically and launched them in that order. This could be a problem if there are modules with dependencies. If there is a way to override that sorting, I could not find it.
I am using the paid version of IntelliJ 2020.2
I wanted a simple thing - Start my Spring Boot application and then start my Angular application. I tried the 'Run Another Configuration' way and it did not work. I faced the same issue as faced by #AxelFontaine.
The Multirun plugin solved my problem. I did have to restart the IDE twice - once to update it after plugin installed and the second time because there was an error saving some configuration. But since then its working just as expected. This is very helpful as I can work on the UI and see the changes immediately and similarly the Spring dev tools lets me change code and it reloads immediately. This plugin is very very helpful.
Third-party libraries are often included by the appliation server you are deploying to and class with the ones included by your application. So far I have dealt with this in the simplest and hackiest way possible: removing the libraries on the app server.
In our case it is ok, noone is relying on the app server to provide them with any libraries. But if I were running my app along with lots of other peoples app, which again might depend on the libraries included by the application server, this would not be a solution.
How is this supposed to be solved (cleanly)? How are you doing it?
An example of a problem might be this:
you build an jax-rs application using cxf, hibernate and jackson, and deploy to glassfish 2.1.1. glassfish supplies the asm 3.1 library, but this causes clashes with hibernate using an incompatible 1.5 version. similarly the application needs jackson 1.8.2 (due to a bug fix), but glassfish 2.1.1 ships with version 0.9. BOOM. Any way of fixing this other than simply removing offending libraries?
consider using :
asadmin deploy --libraries ...
This is really annoying: my java web-application deployed on Windows Tomcat runs perfectly. When application is deployed to Linux HSQLDB starts throwing exeptions about bad SQL grammar and syntax of elementary SQL statements. Like "DROP TABLE Test IF EXISTS" "IF EXISTS" is an error or "double" type is not supported. I tested with hsql 2.1.0 and hsql 1.8.1 - same errors.
My brain is in real stackoverflow. Am I struggling with a known issue?
P.S.
After further investigation it shows that my web-application of Linux suddenly switches to DBCP of Tomcat instead of using DBCP in the WEB-INF/lib
HSQLDB does not run differently in Linux. It is possible that an earlier version Jar is in Tomcat's classpath in Linux. In this situation, classes from the early jar may be picked up.
It is possible to add a test to your app to detect the existence of early version Jars.
For example DatabaseMetaData#getDriverVersion() will report the version of the jar.
I appologize for the question. The cause of the problem had nothing to do with HSQL database. The datasource was created using Spring and I was using th same name for teh datasource bean in two different places.