I followed the following tutorial: https://www.lagomframework.com/documentation/1.4.x/java/GettingStartedMaven.html
Point 3 mentioned:
Enter the number that corresponds with
com.lightbend.lagom:maven-archetype-lagom-java (at time of writing,
the number 1, and the only one available). Maven prompts you for the
version.
The problem is that Maven did not prompt me for a version, and used 1.1.0-RC1 by default. This version builds properly, although there are also minor errors popping up in the standard out like the one here:
Point 4 mentions:
Enter the number corresponding with the version of Lagom you want to
use. We recommend using the current stable release).
Current stable release version is 1.4.6.
I've tried modifying my Maven pom.xml manually since I didn't receive the prompt and tried rebuilding:
<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<lagom.version>1.4.6</lagom.version> <!-- Changed here -->
<play.version>2.5.4</play.version>
<conductr.lib.name>lagom10-conductr-bundle-lib_2.11</conductr.lib.name>
</properties>
But building with lagom:runAllresults in error:
1.4.6 should be a stable release. Are there dependencies that also require updates that I have to take care of when using this version?
Thanks!
Never mind, I followed the following tutorial and it works fine:
https://www.lagomframework.com/blog/introducing-maven-support.html
Related
My repo in github show the following alert :
Dependabot cannot update ssri to a non-vulnerable version. The latest possible version that can be installed is 6.0.1 because of the following conflicting dependencies:
terser-webpack-plugin#2.3.8 requires ssri#^7.0.0 via cacache#13.0.1
webpack#4.46.0 requires ssri#^6.0.1 via a transitive dependency on
cacache#12.0.4
The earliest fixed version is 8.0.1.
As far as I known, I should update the root package (which is terser-webpack-plugin) in package.json to a newer version, but how to determine the minimum version that can support the non-vulnerable version of the dependency (in this case ssri 8.0.1) since I don't want to update to a too high version and risk breaking things. I am thinking of manually checking through all the release version of terser-webpack-plugin, but it's very tedious and seem wrong to check like that. Any suggestions ?
To speed up the process and save installing each version and its associated dependency tree, we can use npm-remote-ls (https://stackoverflow.com/a/26005786/2815338)
Firstly get the list of available versions:
> npm view terser-webpack-plugin versions
[
'1.0.0', '1.0.1', '1.0.2', '1.1.0', '1.2.0',
...
Then run npm-remote-ls for each version after your current one and filter on the relevant dependency, e.g.
> npm-remote-ls terser-webpack-plugin#3.0.0 | grep ' ssri#'
??? ?????? ssri#8.0.1
??? ??? ??? ?????? ssri#6.0.2
In this case terser-webpack-plugin#5.0.0 is the first with only fixed versions of ssri (8.0.1), and 5.1.0 appears to not include ssri at all, presumably due to webpack no longer depending on cacache.
N.B. the question marks appear to be due to encoding of characters that npm-remote-ls uses to display a tree structure. You could also use Select-String in PowerShell, but this appears to show different (incorrect) characters instead.
I get this error trying to use a github repository as a dependency using elm-install
Problem in dependency repo_name/package_name 1.0.0
The elm-package.json constraints of 'repo_name/package_name' are probably
letting too much stuff through.
What does this exactly mean?
(This answer courtesy of #ilias at Elm Slack channel)
It means that Elm couldn't compile the sources for that package in the context of your package.
Imagine for a minute I'm making a package my-fancy-package, and I have a dependency on a package foo/bar. So in my-fancy-package/elm-package.json, I could have a dependency like "foo/bar": "1.0.0 <= v < 2.0.0". Now, perhaps the most recent version of foo/bar while I'm developing my-fancy-package is 1.5.0. And in version 1.5.0, a new function was added that does exactly what I need in my-fancy-package, so I start using that function. The core issue is that there currently is no automated way to test that a package actually works with all the allowed versions of its dependencies. So now my-fancy-package says it depends on foo/bar at any version between 1.0.0 and 2.0.0, while in reality, it really needs to be at least 1.5.0 because I'm using a function from that package.
Now, imagine you're developing an application, and you're using foo/bar at version 1.2.3. According to the semver ranges of my-fancy-package, that means you should be able to use it, but if you were to actually try it, you'd receive this error: my-fancy-package is stating it is compatible with foo/bar#1.2.3 while it really needs 1.5.0.
The reason the error message doesn't simply say "it failed to compile" is because all the published packages are compiled before publishing. The most common reason for a package failing to compile in some context is that its dependencies aren't "accurate": they're letting too much stuff through.
In case of elm-install and packages from github, it's harder to say - it could actually be broken package.
Another common cause for this error is a rather silly one - conflicting definitions of infix operators. The associativity and precedence of infix ops can only be defined "globally", so if there are 2 packages that define the same infix operator, that could become a problem
We had been using version 0.11.0 of angular-bootstrap from npmjs. It appears that version is no longer available on npmjs. From the commands below does this mean that someone actually unpublished the older packages?
prompt:~$ npm view angular-bootstrap time
{ modified: '2015-01-12T06:48:54.881Z',
created: '2014-01-29T21:54:32.213Z',
'0.0.1': '2014-01-29T21:54:37.589Z',
'0.0.2': '2014-01-29T22:03:08.814Z',
'0.0.3': '2014-01-29T22:51:49.998Z',
'0.0.4': '2014-02-11T15:14:17.078Z',
'0.11.0': '2014-06-24T07:06:56.435Z',
'0.13.0-SNAPSHOT': '2014-12-02T13:05:43.151Z',
'0.12.0': '2015-01-12T06:46:41.986Z' }
prompt:~$ npm view angular-bootstrap versions
0.12.0
I agree, the package seems to have been unpublished. You can still access it from the github history, as follows:
$ npm install "angular-ui/bootstrap#0.11.0"
(note that you may not need quoting, but some shells will interpret the # as a comment-begin character.) You can also use this syntax in dependencies inside package.json
If you have a project in production that depends on this, you should probably make a fork of the angular-ui/bootstrap repository and point towards that.
(I had some difficulty making this work on Windows, but it looks like you're on a Unixy system, so you should be fine.)
Ticket discussing this and the future is at https://github.com/angular-ui/bootstrap/issues/1636
After installing the newly released IJ14 Community Edition - the quasiquotes (which had been working on IJ13) popped up on the radar.
Is there an IJ setting to enable this?
BTW this is a maven build (and works in 13.1 just fine!). Here is the section of the build related to the quasiquotes. I have not seen any mention of the plugin not working properly in 14, but input here would be appreciated.
<!-- The following plugin is required to use quasiquotes in Scala 2.10 and is used
by Spark SQL for code generation. -->
<compilerPlugins>
<compilerPlugin>
<groupId>org.scalamacros</groupId>
<artifactId>paradise_${scala.version}</artifactId>
<version>${scala.macros.version}</version>
</compilerPlugin>
</compilerPlugins>
UPDATE I just installed the 14.0.1 update from 11/11/14. This time I tried Intellij Ultimate : but Quasiquotes are still not working.
UPDATE I have opened a JIRA with JetBrains. https://youtrack.jetbrains.com/issue/IDEA-133993
I think there is a workaround to get it running:
You have to go to the IntelliJ settings, to the "Scala Compiler" and add a plugin: "/home/YOURUSERNAME/.m2/repository/org/scalamacros/paradise_2.10.4/paradise_2.10.4-2.0.1.jar"
The problem involves the paradise plugin that provides support for quasiquotes with scala 2.10. It is not working in IJ14 presently.
UPDATE The following is new info on the building with Spark page
https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark#ContributingtoSpark-IntelliJ
"Rebuild Project" can fail the first time the project is compiled, because generate source files are not automatically generated. Try clicking the "Generate Sources and Update Folders For All Projects" button in the "Maven Projects" tool window to manually generate these sources.
Compilation may fail with an error like "scalac: bad option: -P:/home/jakub/.m2/repository/org/scalamacros/paradise_2.10.4/2.0.1/paradise_2.10.4-2.0.1.jar". If so, go to Preferences > Build, Execution, Deployment > Scala Compiler and clear the "Additional compiler options" field. It will work then although the option will come back when the project reimports. If you try to build any of the projects using quasiquotes (eg., sql) then you will need to make that jar a compiler plugin (just below "Additional compiler options"). Otherwise you will see errors like:
/Users/irashid/github/spark/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/expressions/codegen/CodeGenerator.scala
Error:(147, 9) value q is not a member of StringContext
Note: implicit class Evaluate2 is not applicable here because it comes after the application point and it lacks an explicit result type
q"""
^
It's s not q:
val x = 5.0
println(s"$x.toInt")
I loaded spark up in Intellij 13 and the macro paradise backport of quaisquotes still shows an error, I don't see how intellij would be able to support this syntax as it's a compiler plugin:
I've got a problem with "javax.el.CompositeELResolver" which is used by TomEE's "javaee-api-6.0-5.jar".
Version information and svn-repository here:
http://mvnrepository.com/artifact/org.apache.geronimo.specs/geronimo-el_2.2_spec/1.0.2
Source of class CompositeELResolver here:
http://svn.apache.org/viewvc/geronimo/specs/tags/geronimo-el_2.2_spec-1.0.2/src/main/java/javax/el/CompositeELResolver.java?view=log
In the "invoke" method I get a null pointer exception because the for-loop iterates through the whole resolvers-array which has got fields with value "null". I suppose this is not avoidable because of the "add" method that doubles the array size if required but does not initialize any values. Shouldn't there be a check if the resolver is "null" in the "invoke" method before using it?
For comparison I ran my application with another javax.el implementation and it's working properly:
<dependency>
<groupId>javax.el</groupId>
<artifactId>el-api</artifactId>
<version>2.2</version>
</dependency>
Am I wrong with my supposition?
I found a similar-sounding issue here:
https://issues.apache.org/bugzilla/show_bug.cgi?id=50293
Is it possible that multi-threading causes my problem?
Solved.
TomEE uses version 1.0.2 of http://mvnrepository.com/artifact/org.apache.geronimo.specs/geronimo-el_2.2_spec
The bug is fixed in version 1.0.4
Based on the fixed geronimo el spec 1.0.4 version it is easy to fix the javaee-api-6.0-5.jar package.
Just download the newest jar file from here http://mvnrepository.com/artifact/org.apache.geronimo.specs/geronimo-el_2.2_spec/1.0.4
and change the javax.el package in javaee-api-6.0-5.jar with the files comes from geronimo el 2.2 spec 1.0.4 jar files
I did it using mc under linux browse the content and copy from one to another. And I tested and works perfect.
Of course you can do it with jar utils as well :-)
It was strange for me that this problem did not exist in 32 bit windows environment but only in 64 bit linux environment. Anyhow the fix solves the problem.
Hope that there will be a javaee-api-6.0-6.jar soon :-)