gwt-maven-plugin appends "-linux" when getting gwt-dev artifact - linux

I've been trying to get the gwt-maven-plugin to work for me. Hopefully someone can help me.
I'm using gwt-maven-plugin 1.2 and trying to get it to work with gwt 2.1.0.M3. We have a nexus repo at work and I've put the latest gwt jars there. The plugin fails when trying to download the gwt-dev jar.
The gwt-dev jar is located at 2.1.0.M3/gwt-dev-2.1.0.M3.jar
The plugin tries to download 2.1.0.M3/gwt-dev-2.1.0.M3-linux.jar.
I don't have a dependency anywhere on my pom for gwt-dev, the plugin takes care of that. How can I stop it from appending "-linux" to it? I'm aware that I could just change the name of the jar in my repo or set it up manually on my local machine, but I want to figure out how to get this working on nexus because we have several developers working on this at the same time.
Thanks!

You should upgrade your gwt-maven-plugin to version 1.2, which has some support for GWT-2.0.
As of GWT-2.0, the gwt-dev jars are no longer distributed separately per platform - a fact which the older versions of the gwt-maven-plugin are not aware.

I am having the same problem. Here's what worked for me, which I gleaned from this sample pom: http://code.google.com/p/google-web-toolkit/source/browse/trunk/samples/expenses/pom.xml
Add this to your plugin repos:
<pluginRepositories>
<pluginRepository>
<id>gwt-plugin-repo</id>
<url>http://google-web-toolkit.googlecode.com/svn/2.1.0.M3/gwt/maven</url>
<name>Google Web Toolkit Plugin Repository</name>
</pluginRepository>
</pluginRepositories>
Set your gwt-maven-plugin to 1.3.1.google
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>1.3.1.google</version>

i was trying to upgrade my project to gwt 2.1, and with the things that Bohemian said and with
<repository>
<id>googlecode</id>
<url>http://code.google.com/p/google-web-toolkit/source/browse/#svn/2.1.0/gwt/maven</url>
</repository>
i succeeded to do so.

Related

How to exclude package from the jar which is native?

I'm using avro-tools 1.9.2 in my project and due to some reason can't even update it. I see that avro-tools 1.9.2 using the old log4 1.x API natively (its not a transitive dependency instead its included natively in the jar itself), Is there any way to exclude package when using the jar file at runtime? I know its very unfair/weird questions. But I really need get going.
<dependency>
<groupId>org.apache.avro</groupId>
<artifactId>avro-tools</artifactId>
<version>1.9.2</version>
</dependency>

is possible remove Jhipster Dependencies in back? why is necessary?

is possible remove Jhipster Dependencies in back? why is necessary or recommended???
IF I REMOVE OF POM.XML appears different compilation errors.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>io.github.jhipster</groupId>
<artifactId>jhipster-dependencies</artifactId>
<version>${jhipster-dependencies.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<!-- jhipster-needle-maven-add-dependency-management -->
</dependencies>
</dependencyManagement>
Is it possible?
Yes but you have to import all the dependencies yourself although nothing very difficult because most of them are already provided as Spring Boot starters. Looking at effective pom with mvnw help:effective-pom could help.
Then you must import maven plugins configuration.
Finally, your project will still depend on jhipster-framework library unless you extract only the classes your project needs.
Is it recommended?
For long term, managing yourself your dependencies is a good thing because major libraries like Spring Boot, Hibernate, ... support old releases for quite a long time while JHipster team supports only current major release (currently 7.x) which usually means one year.
At the beginning of your project, you will probably want to be able to follow JHipster updates. Modifying the pom.xml will make updating generated code more difficult.
Once you have written much manual code, your project is probably already too difficult to update, so cutting the dependency with JHipster will be harmless.
I found it harder to remove dependency from JHipster frontend than from backend because for instance ng-jhipster has some dependencies on Bootstrap that require some effort to remove.

Using Liquibase with Azure SQL And Azure Active Directory Authentication

How can you use Liquibase with an Azure SQL database and Azure Active Directory Authentication? Specifically, I want to connect using ActiveDirectoryPassword authentication mode as documented here:
https://learn.microsoft.com/en-us/sql/connect/jdbc/connecting-using-azure-active-directory-authentication?view=sql-server-ver15#connecting-using-activedirectorypassword-authentication-mode
I cannot figure out how to call the Liquibase CLI to make this happen.
Is this possible?
I was able to get this to work. I am not very familiar with Java (we use Liquibase with a C# project), so I think some of the Java pieces tripped me up.
There were a few things I had to do to make this work:
I needed to add some properties to the URL I sent to Liquibase:
--url="jdbc:sqlserver://REDACTED.database.windows.net;databaseName=REDACTED;authentication=ActiveDirectoryPassword;encrypt=true;trustServerCertificate=true"
ActiveDirectoryPassword is what tells the driver to use the authentication mechanism I wanted. I also had to add encrypt=true and trustServerCertificate=true to avoid some SSL errors I was getting (from: https://learn.microsoft.com/en-us/sql/connect/jdbc/connecting-with-ssl-encryption?view=sql-server-ver15).
I needed the MSAL4J (Azure Active Directory) libraries in my classpath. I added them to the liquibase/lib directory so that the default Liquibase launcher scripts would add them for me. I got caught on this, too, because I needed to use Maven which we do not use. After downloading Maven, I used the copy-dependencies plugin to download the dependencies I needed.
mvn dependency:copy-dependencies
Here was the simple pom.xml I used:
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.mycompany.app</groupId>
<artifactId>my-app</artifactId>
<version>1</version>
<dependencies>
<dependency>
<groupId>com.microsoft.azure</groupId>
<artifactId>adal4j</artifactId>
<version>1.6.3</version>
</dependency>
</dependencies>
</project>
I also put these dependencies in the liquibase/lib directory so they were automatically included in the classpath. The instructions from Microsoft were helpful in leading me to the correct places:
https://learn.microsoft.com/en-us/sql/connect/jdbc/connecting-using-azure-active-directory-authentication?view=sql-server-ver15#connecting-using-activedirectorypassword-authentication-mode
Also, not sure it was required to meet my goal, but I upgraded to the latest Liquibase (3.8.7) and latest SQL Server drivers (8.2):
https://learn.microsoft.com/en-us/sql/connect/jdbc/download-microsoft-jdbc-driver-for-sql-server?view=sql-server-ver15

Does Hazelcast Openfire plugin allows SSL?

By default, after installation Openfire Hazelcast plugin has
<ssl enabled="false"/>
in its config file. My attempt to enable it broke clustering and Openfire log said that
java.lang.IllegalStateException: SSL/TLS requires Hazelcast Enterprise Edition
Is it correct, so there is no way to make Hazelcast plugins using SSL for communications between Openfire nodes?
Assuming that the Hazelcast Enterprise API is an extension of the Hazelcast API, it might be as simple as recompiling the Openfire Hazelcast plugin with a different Hazelcast dependency.
I did a quick test. The plugin compiles just fine after you swap the dependency on Hazelcast with a dependency on the 'enterprise' variant, like this (your version number might vary):
<dependencies>
<dependency>
<groupId>com.hazelcast</groupId>
<artifactId>hazelcast-enterprise</artifactId>
<version>3.10.6</version>
</dependency>
</dependencies>
<repositories>
<repository>
<id>hazelcast</id>
<url>https://dl.bintray.com/hazelcast/release/</url>
</repository>
</repositories>
Most of the Hazelcast configuration can be done in the XML file that's already accessible as a stand-alone file in Openfire. There's a good chance that you don't need any code modifications to get things configured in the way you want.
I am not sure if this has been attempted before but you can try the following:
download the enterprise version of Hazelcast and place the hazelcast jar in plugins folder of Openfire. I am not certain about the internals of Openfire but if there exists a maven configuration to import Hazelcast then modify that to load Hazelcast enterprise. Or if nothing else works then try renaming the Hazelcast jar from hazelcast-enterprise.jar to hazelcast.jar.
modify conf/hazelcast-local-config.xml to configure license key and security details SSL.
Fire away.
Here is a link to Openfire doc for Hazelcast plugin: https://www.igniterealtime.org/projects/openfire/plugins/2.4.0/hazelcast/readme.html#config
Please do update here if this works.
Support for TLS/SSL is not included in the open source version of Hazelcast, as the error message indicates it is part of the Enterprise Edition feature set.
https://hazelcast.com/product-features/security-suite/
Correct, purchasing the enterprise edition wouldn't help as far as I can tell. The Hazelcast (open source) plugin for Openfire is maintained by the folks at Ignite Realtime. They only support specific versions of Hazelcast as well.

hadoop aws versions compatibility

Is there any reference as to what sets of versions are compatible between aws java sdk, hadoop, hadoop-aws bundle, hive, spark?
For example, I know Spark is not compatible with hive versions above Hive 2.1.1
You cannot drop in a later version of the AWS SDK from what which hadoop-aws was built with and expect the s3a connector to work. Ever. That is now written down quite clearly in the S3A troubleshooting docs
Whatever problem you have, changing the AWS SDK version will not fix things, only change the stack traces you see.
This may seem frustrating, given the rate at which the AWS team push out a new SDK, but you have to understand that (a) the API often changes incompatibly between versions (as you have seen), and (b) every release introduces/moves bugs which end up causing problems.
Here is the 3.x timeline of things which broke on updates of the AWS SDK.
Move 1.11.86 and some tests hang under load.
Fix: move to 1.11.134 leading to logs are full of AWS telling us off for deliberatly calling abort() on a read.
Fix: move to 1.11.199 leading to logs full of stack traces.
Fix: move to 1.11.271 and shaded JAR pulls in netty unshaded.
Every upgrade of the AWS SDK JAR causes a problem, somewhere. Sometimes an edit to the code and recompile, most commonly: logs filling up with false-alarm messages, dependency problems, threading quirks, etc. Things which can take time to surface.
what you see when you get a hadoop release is not just an aws-sdk JAR which it was compiled against, you get a hadoop-aws JAR which contains the workarounds and fixes for whatever problems that release has introduced and which were identified in the minimum of 4 weeks of testing before the hadoop release ships.
Which is why, no, you shouldn't be changing JARs unless you plan to do a complete end-to-end retest of the s3a client code, including load tests. You are encouraged to do that, the hadoop project always welcomes more testing of our pre-release code, with the Hadoop 3.1 binaries ready to play with. But trying to do it yourself by changing JARs? Sadly, an isolated exercise in pain.
In Hadoop documentation, it is stated that by adding hadoop-aws JAR to the build dependencies; it will pull in a compatible aws-sdk JAR.
So, I created a dummy Maven project with these dependencies to download the compatible versions
<properties>
<!-- Your exact Hadoop version here-->
<hadoop.version>3.3.1</hadoop.version>
</properties>
<dependencies>
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-client</artifactId>
<version>${hadoop.version}</version>
</dependency>
<dependency>
<groupId>org.apache.hadoop</groupId>
<artifactId>hadoop-aws</artifactId>
<version>${hadoop.version}</version>
</dependency>
</dependencies>
Then, I checked my dependencies versions, used it in my project and it worked.

Resources