I've been trying to figure out how to create a gx:Track with the current version of the Java API for KML. Even though JAK claims to support the latest 2.2 extensions, the kml22gx.xsd that is packaged with the source code does not match the actual latest.
Can someone detail the build process for taking new XSD's and generating a new jak?
I got the jar from someone on Google Groups, here it is: https://drive.google.com/file/d/0B1Y3FuLhrOkHdDRNNTlpaGJuQTg/edit?usp=sharing
(PS I may have made some little changes)
Related
I have an application, which needs to be tested using in-house developed python automation. Originally, the application was developed using Swagger 2.x spec. Now it is migrated to use Open API 3.x
When it was on Swagger 2.x spec, I used to use swagger-codegen-cli-2.4.21.jar to generate the python client libraries, which we eventually consumed to write our automation. With the 2.4.21 jar we could disable the client side validation (configuration.py)
But after moving to OpenAPI 3.x, I am not able to use 2.4.21 jar because its not supported. So I used 3.0.36 jar to generate the python client libraries. But this doesn't have the option to disable the client side validation (in configuration.py). This is actually creating lot of problems because we are getting ValueErrors during GET calls.
I see that there are some discussions happened on the same, but none of them are conclusive enough that it is actually fixed in 3.x
https://github.com/OpenAPITools/openapi-generator/pull/4137
https://github.com/swagger-api/swagger-codegen/issues/5530
https://github.com/swagger-api/swagger-codegen/pull/9717
So I need help to understand whether this is still a open issue (or) it is fixed in some 3.x release..? If its not fixed yet, is there a workaround to overcome this issue..?
As of now, we are commenting all the ValueErrors to get around the issue, but this is not recommended because we lose the validation capability during POST calls.
On python-nextgen (latest Python generator) it is not implemented (you can indicate which type of validation can be skipped using disabled_client_side_validations when creating the configuration object, maybe works for you?).
The configuration object also includes a property client_side_validation which seems to be intended for this purpose but at the moment there is no implementation.
The only option at the moment is to keep it or remove it for all operations.
We are looking for solution to export the data to excel in Vaadin application.
I have downloaded Vaadin excel exporter from GitHub https://github.com/bonprix/vaadin-excel-exporter which sounds to be a very useful utility but I am getting the error below when I am compiling vaadin-excel-exporter-demo project.
<vaadin.version>8.0.6</vaadin.version>
Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project vaadin-excel-exporter-demo: Compilation failure: Compilation failure:
[ERROR] /C:/Java/Vaadin/VaadinProjetcs/vaadin-excel-exporter-master/vaadin-excel-exporter-master/vaadin-excel-exporter-demo/src/main/java/org/vaadin/addons/excelexporter/demo/DemoUI.java:[12,61] package org.vaadin.addons.excelexporter.configuration.builder does not exist
I've tried mvn clean and also delete the full .m2/repository local repository
Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile (default-compile)
After searching on different forums it looks like maybe this add-on is missing from Maven repo. I have tried version 2.1 and LATEST.
<artifactId>vaadin-excel-exporter</artifactId>
<packaging>jar</packaging>
<!--version>2.1-SNAPSHOT</version-->
<version>LATEST</version>
<name>Excel Exporter</name>
So I have two questions.
Has anybody had the same problem wih this tool and/or maybe can explain what i am doing wrong.
If this tool is not maybe available anymore can anyone please share the tool which I can use to export the grid data to Excel. I am new with Vaadin so providing the code examples will be highly appreciated
Thanks
Alex
If you look at the add-on through Vaadin directory, you'll find the necessary additions to your pom.xml in the Maven section of the sidebar. In this case, like Erik said in the comments, you are likely missing
<repository>
<id>vaadin-addons</id>
<url>https://maven.vaadin.com/vaadin-addons</url>
</repository>
The directory page also includes code samples for using the component after you get the dependencies fixed, as well as other information about the add-on. I haven't tested whether the demo within GitHub works, but the add-on itself should be usable in your project regardless. The newest version published through the directory is 2.0.
If you want to compile the add-on locally rather than use it through the add-on repository, you need to first successfully compile the add-on module, and then use the exact version configured in the pom.xml. Currently the master branch seems to be using <version>2.1-SNAPSHOT</version>.
I moved to Bolt 4 (from Bolt 3.7) and would like to implement front-end user to give them access to private contents of the website. Previously, I used the extension BoltAuth/Auth, which worked like a charm.
Now in Bolt 4, there is no easy way like in Bolt 3.x to install an extension from the back-end page. I found out I could use composer to do so, but I run in the following problem:
> composer require "boltauth/auth:3.0.1"
[InvalidArgumentException]
Could not find a matching version of package boltauth/auth. Check the package
spelling, your version constraint and that the package is available in a stability
which matches your minimum-stability (stable).
Either I do something wrong, or the extension is not compatible with Bolt 4.1.
Could someone tell me if there is a way to make this extension work? Or alternatives for front-end user management?
EDIT: I'm now using the bolt/users extension as it can be used to add a ROLE_MEMBERS and let users login for the frontend.
Yes, unfortunately the architecture for plugins (mainly driven by the move from Silex to Symfony) changed completely between 3.x and 4.x and it's not really feasible to release new 4.x compatible versions.
So for now there won't likely be updates to BoltAuth. It may be worth joining the Slack community and seeing if any other developers are working on 4.x compatible solutions to the client login scenarios.
I am trying to query Cassandra using Apache Drill. The only connector I could find is here:
http://www.confusedcoders.com/bigdata/apache-drill/sql-on-cassandra-querying-cassandra-via-apache-drill
However this does not build. It comes up with an artifact not found error. I also had another developer who is more versed in these tools take a stab at it, but he also had no luck.
I tried contacting the developer of the plugin I referenced, but the blog does not work and won't let me post comments. Has anyone got this plugin to work (if so how?) or is there another plugin or method I can use to connect apache drill to Cassandra? If anyone could show me how to connect an execute a simple SQL query that would be much appreciated.
I looked at the latest Cassandra storage plugin patch and the latest apache drill source. The drill code has changed and the patch can no longer be applied.
I then manually took the patch apart (it id mostly diff output). Most of the patch was new classes which I could easily add to the latest drill source tree. Most of the other updates were easy to insert into the current source. There were two specific classes that required some minor code modifications/extensions. I rebuilt the distribution from the modified source and installed the drill servers it on a 3 node cluster. The Cassandra schema failed to initialize properly throwing a null pointer exception one of the new classes. This leads me to believe that the (latest) modifed storage plugin is incompatible with the latest version of Cassandra. Since the author of the original storage plugin is unreachable and no one else is stepping up to support the code, this is a dead horse. Beat it if you must.
I was the author of the patch written a year back. Could not get it merged into Drill then, and later got occupied with other stuffs :(
With so many changes to Drill internals, I am not sure what amount of welding would be needed at this point to get it working. Please use the code just as a reference for writing a Drill storage plugin.
Have added this banner on top of the blog post to save fellow developer's hours.
I don't know if anyone is still interested in this topic but I've been experimenting with this plugin and got it to work with Drill 1.18-SNAPSHOT. Here is a link to my branch with this code: 1. My plan is to submit this as a PR for Drill, but it still needs some work. This code will successfully query Cassandra 3.11.5 (latest stable version).
I have a XPage application where I use JavaMail in one of my managed beans. Currently I have added the jar-file C:\Programme\IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jarto the build-path of the manged bean. This works well. But now I want to use a newer version of JavaMail as the Domino server uses version 1.3 but I need version 1.4.x.
I have downloaded the new JavaMail jar-files from Oracle. In Domino Designer (version 9) I add this jar-file to the new design element "Code / Jars" and remove the old jar-files from the build path.
My managed bean is still compiling and running as desired, but if I check the version the bean is using it reports still version 1.3. To check the version number I use the debug property of JavaMail and it's reporting version 1.3 to the domino server console.
Is there a way to tell the domino server to use the jar-files in the application (i.e. the nsf) and not his own? Is there another approach to update the JavaMail version?
The reason I want to use a newer version of JavaMail is as follows: I want to read mails from an imap server with ssl. To avoid the problem of importing ssl-certificates I simply want to trust all hosts. This can be be done via MailSSLSocketFactory, but this is only available since version 1.4.2. Therefore I want to use a newer version of JavaMail.
Another reason I want to use a newer version is as follows: the method "getSortedMessages" of "IMAPFolder" is only available since version 1.4.4. (and so are some other features of JavaMail).
This may be a little too late for you... I think the right approach may be to include the jar file as an OSGi plugin.
I have spent some time to figure out how to do that - and recently succeeded :-) I have described the steps to perform to make this work in two articles. The first is about wrapping a JAR into a plug-in: http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/ - the second is about deployment (and there is a link in the first one).
/John
You can solve the problem by creating an OSGi plug-in that supersedes the one that sports the JavaMail library: com.ibm.designer.lib.javamail.
In order to do that do the following:
Create an OSGi plugin whose id is com.ibm.designer.lib.javamail (Dalsgaard's tutorial on how to do it)
Set its version to a higher number than the one the Domino server is shipped with (to know the version type tell http osgi ss com.ibm.designer.lib.javamail). As of now using 9.0.1.qualifier should be fine
Deploy the plugin either through an update site or by directly copying it under the domino\workspace\applications\eclipse\plugins folder.
Restart the HTTP service. The higher version - the one you created - will now be used
I've got the same problem here, but found a solution. Be warned, this is not the best answer but it will work. Simply download the latest javamail jar here and rename the jar file to 'mail.jar'. Just replace the current file in IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jar with this file. Quit the http task and restart it. The code will now work with the latest version.