I'm trying to follow Travel Demo - for developers # https://documentation.magnolia-cms.com/display/DOCS56/Travel+Demo+-+for+developers
as suggested I've cloned project
build it with skipped checkstyle option (already feel weird if I can't build project without undocumented tricks)
Build succeed, but I have no clue what to do with it:
There no war files, only jars.
I know about training-developer-project bundle which I was able to build and run on local Tomcat
What I would like to do is:
install Travel Demo project in blank magnolia web app maven project which I generated with maven archetype
Clarification: My idea was not just to install travel-demo as dependency but make it a part of my study project.
Update #Ducaz035: Running mvn -e -X clean install gives errors in checkstyle plugin:
[INFO] Starting audit...
C:\Magnolia_dev\demo-projects\community\magnolia-travel-demo\src\test\java\info\magnolia\demo\travel\model\NavigationAreaModelTest
.java:48: Missing a Javadoc comment.
C:\Magnolia_dev\demo-projects\community\magnolia-travel-demo\src\test\java\info\magnolia\demo\travel\setup\SetupDemoRolesAndGroups
TaskTest.java:54: Missing a Javadoc comment.
C:\Magnolia_dev\demo-projects\community\magnolia-travel-demo\src\test\java\info\magnolia\demo\travel\setup\TravelDemoModuleVersion
HandlerTest.java:75: Missing a Javadoc comment.
Audit done.
[INFO] There are 3 errors reported by Checkstyle 6.1.1 with magnolia-build-resources/checkstyle.xml ruleset.
[ERROR] src\test\java\info\magnolia\demo\travel\model\NavigationAreaModelTest.java[48] (javadoc) JavadocType: Missing a Javadoc co
mment.
[ERROR] src\test\java\info\magnolia\demo\travel\setup\SetupDemoRolesAndGroupsTaskTest.java[54] (javadoc) JavadocType: Missing a Ja
vadoc comment.
[ERROR] src\test\java\info\magnolia\demo\travel\setup\TravelDemoModuleVersionHandlerTest.java[75] (javadoc) JavadocType: Missing a
Javadoc comment.
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Magnolia Travel Demo (parent pom) .................. SUCCESS [ 4.489 s]
[INFO] Magnolia Travel Demo Module ........................ FAILURE [ 34.003 s]
You have to put in into the webapp, you are talking about the bundle so add the travel-demo to it as maven dependency. Alternative you can drop the jar to /libs folder and Magnolia will it pick up automatically. For more detail please check
https://documentation.magnolia-cms.com/display/DOCS55/Installing+a+module
Cheers,
Related
I published some libraries using sbt publishLocal it worked and published to my ~/.ivy2/local dir.
I then have a project that depends on these libraries but sbt update can't find them.
specifically, my project has these dependencies:
lazy val myDependencies = commonDependencies ++ Seq(
"my.corp" %% "lib1" % "1.0.1-SNAPSHOT" withSources () withJavadoc (),
"my.corp" %% "lib2" % "2.0.2-SNAPSHOT" withSources () withJavadoc ()
)
sbt update has this error:
[error] (services / update) lmcoursier.internal.shaded.coursier.error.FetchError$DownloadingArtifacts: Error fetching artifacts:
[error] file:////home/myuser/.ivy2//local/my.corp/lib1_2.12/1.0.1-SNAPSHOT/jars/lib1.jar: not found: /home/myuser/.ivy2//local/my.corp/lib1_2.12/1.0.1-SNAPSHOT/jars/lib1.jar
[error] file://///home/myuser/.ivy2//local/my.corp/lib2_2.12/2.0.2-SNAPSHOT/jars/lib2.jar: not found: /home/myuser/.ivy2//local/my.corp/lib2_2.12/2.0.2-SNAPSHOT/jars/lib2.jar
when I look in the dir I can see the published jars but their name has the scala version appended, which is why the update resolving fails, I think :
$ ls /home/myuser/.ivy2/local/my.corp/lib1_2.12/1.0.1-SNAPSHOT/jars
lib1_2.12.jar lib1_2.12.jar.md5 lib1_2.12.jar.sha1
$ ls /home/myuser/.ivy2/local/my.corp/lib2_2.12/2.0.2-SNAPSHOT/jars
lib2_2.12.jar lib2_2.12.jar.md5 lib2_2.12.jar.sha1
If I publish to a repo for real I can resolve the libs.
Does anyone know the sbt incantation to fix this? ;-)
Cheers
Karl
Update:- I think coursier is the problem, not sure how to tell it to look for lib2_2_12.jar. Could it have a bad cached reference?
Caused by: lmcoursier.internal.shaded.coursier.cache.ArtifactError$NotFound: not found: /home/myuser/.ivy2/local/my.corp/lib2_2.12/2.0.2-SNAPSHOT/jars/lib2.jar
Update:-
disabling coursier worked
from the sbt REPL I can run
sbt:my-project> set ThisBuild / useCoursier := false
and then
sbt:my-project> update
and that worked, but setting it back to true update failed again, so this looks like a coursier issue.
Update:
coursier fetch from the command line worked!!
coursier fetch my.corp::lib1:1.0.1-SNAPSHOT --no-default -r central -r ivy2Local
downloaded the transitive dependencies and found my jar in my local ivy2 dir
so this is back to looking like an sbt - coursier interaction issue
I've just now run into this and after lots of diffs between an older working version and this non-working version I figured out that it is the withSources() that triggers the bug in sbt and/or coursier.
I need some help installing a non-release branch of Corda for doing some testing with the TokenSDK. I must be doing something wrong because I am getting errors in IntelliJ.
OS: Tested on Windows 10 & Ubuntu 18.04.3 LTS
I am following the steps from the documentation: link
Step 1) Clone the Corda Repository:
git clone https://github.com/corda/corda.git
Step 2) Checkout the specific branch I need:
git checkout release/os/4.3
Step 3) Opening the constants.properties file I see:
cordaVersion=4.3-SNAPSHOT
gradlePluginsVersion=5.0.4
Step 4) Clone the Gradle Plugins repository:
git clone https://github.com/corda/corda-gradle-plugins.git
Step 5) Checkout the tag listed in the constants.properties file:
git checkout release/5.0.4
Step 6) Install the Gradle Plugins locally (run from the corda-gradle-plugins folder):
gradlew install
Step 7) Publish Corda to my local Maven repository (run from the corda folder):
gradlew install
Step 8) Download the Java template:
git clone https://github.com/corda/cordapp-template-java.git
Step 9) Open the java template in IntelliJ and setup the Project SDK, import module etc.
Step 10) Open the root build.gradle file and change:
corda_release_version = '4.1'
corda_gradle_plugins_version = '4.0.45'
to:
corda_release_version = '4.3-SNAPSHOT'
corda_gradle_plugins_version = '5.0.4'
After gradle refreshes I get the following errors:
No signature of method: org.gradle.api.internal.provider.DefaultPropertyState.convention() is applicable for argument types: (java.lang.String) values: [co.paralleluniverse]
Open File
"Open File" is a link that takes me to this line in the root build.gradle file:
apply plugin: 'net.corda.plugins.quasar-utils'
More Errors:
Caused by: org.gradle.api.internal.plugins.PluginApplicationException: Failed to apply plugin [id 'net.corda.plugins.quasar-utils']
Caused by: org.gradle.api.reflect.ObjectInstantiationException: Could not create an instance of type net.corda.plugins.QuasarExtension_
Caused by: groovy.lang.MissingMethodException: No signature of method: org.gradle.api.internal.provider.DefaultPropertyState.convention() is applicable for argument types: (java.lang.String) values: [co.paralleluniverse]
Am I missing a step or doing one incorrectly?
Since Corda4.3, Corda has moved onto a quarterly release schedule. I am confident that we will bring the features to the community as soon as possible. Please stay tuned with us at https://www.corda.net/
I am getting errors when I try to stage my application using sbt clean compile stage:
[error] Not a valid command: stage
[error] Not a valid project ID: stage
[error] Expected ':' (if selecting a configuration)
[error] Not a valid key: stage
[error] stage
[error] ^
I have done this hundreds of times on other machines without a problem. I have SBT 0.13.5 -- has anyone seen this before? I have read this other post, but I'm not on Heroku. Thanks.
After the comments above I realized that you just wanted to have stage command without bringing the entire Play foo in.
The stage command is part of sbt-native-packager that:
The goal [of the plugin] is to be able to bundle up Scala software built with SBT for native packaging systems, like deb, rpm, homebrew, msi.
One of the features of the sbt-native-packager plugin is the stage command that
> help stage
Create a local directory with all the files laid out as they would be in the final distribution.
Just add the following to project/plugins.sbt to have the plugin available in the project (after the comment of Muki the example uses the latest version 1.0.0-M1 with the autoplugin feature):
addSbtPlugin("com.typesafe.sbt" % "sbt-native-packager" % "1.0.0-M1")
You will also have to add the following to build.sbt:
enablePlugins(JavaAppPackaging)
And that's it! You're all set now.
Execute stage.
> stage
[info] Packaging /Users/jacek/dev/sandbox/command-build-scala/target/scala-2.10/command-build-scala_2.10-0.1-SNAPSHOT-sources.jar ...
[info] Done packaging.
[info] Updating {file:/Users/jacek/dev/sandbox/command-build-scala/}command-build-scala...
[info] Wrote /Users/jacek/dev/sandbox/command-build-scala/target/scala-2.10/command-build-scala_2.10-0.1-SNAPSHOT.pom
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[info] Packaging /Users/jacek/dev/sandbox/command-build-scala/target/scala-2.10/command-build-scala_2.10-0.1-SNAPSHOT-javadoc.jar ...
[info] Done packaging.
[info] Packaging /Users/jacek/dev/sandbox/command-build-scala/target/scala-2.10/command-build-scala_2.10-0.1-SNAPSHOT.jar ...
[info] Done packaging.
[success] Total time: 0 s, completed Nov 5, 2014 2:55:55 PM
After lots of digging, I found out 'stage' is implemented by a plugin from the Play framework, which I do use in my other projects and explains why sbt was accepting the stage command.
In SBT I create a new config, called katebush, as follows:
lazy val KateBush: Configuration = config("katebush")
When I try to run katebush:compile I get an error. That's what I expect.
> katebush:compile
[error] No such setting/task
[error] katebush:compile
[error] ^
Now I extend Compile in my config definition, and I expect to pick up the compile from the inherited scope.
lazy val KateBush: Configuration = config("katebush") extend Compile
Except it doesn't work:
> katebush:compile
[error] No such setting/task
[error] katebush:compile
[error] ^
But if I add in the defaults to the config (in build.sbt) so it looks as follows:
lazy val KateBush: Configuration = config("katebush") extend Compile
inConfig(KateBush)(Defaults.compileSettings)
it works fine:
> katebush:compile
[info] Updating {file:/Users/jacek/sandbox/so-25596360/}so-25596360...
[info] Resolving org.fusesource.jansi#jansi;1.4 ...
[info] Done updating.
[success] Total time: 0 s, completed Aug 31, 2014 11:35:47 PM
So, my question is, what exactly does extend for a configuration do?
DISCLAIMER I've got a rather basic understanding of the config concept of sbt.
tl;dr Extending a configuration is solely to inherit the dependencies groups not settings.
From the sources of final case class Configuration:
def extend(configs: Configuration*) = Configuration(name, description, isPublic, configs.toList ::: extendsConfigs, transitive)
By default, extendsConfigs is Nil as can be seen in the sbt.Configurations object:
def config(name: String) = new Configuration(name)
that resolves to (note Nil)
def this(name: String) = this(name, "", true, Nil, true)
In sbt.IvySbt.toIvyConfiguration:
import org.apache.ivy.core.module.descriptor.{ Configuration => IvyConfig }
and that's where the support of the config concept ends in sbt and Ivy steps in. That's where you'd have to look at the documentation of Ivy.
But before that read Advanced configurations example where it says:
This is an example .scala build definition that demonstrates using Ivy
configurations to group dependencies.
That's the beginning of the explanation. Ivy configurations are to group dependencies and extending a configuration is to extend the grouping.
From the official documentation of Ivy about the conf element:
a configuration is a way to use or construct a module.(...)
a module may need some other modules and artifacts only at build time, and some others at runtime. All those differents ways to use or build a module are called in Ivy module configurations.
Reading along you can find the answer to your question (that I'm myself yet to digest, too):
A configuration can also extend one or several other ones of the same
module. When a configuration extends another one, then all artifacts
required in the extended configuration will also be required in the
configuration that extends the other one. For instance, if
configuration B extends configuration A, and if artifacts art1 and
art2 are required in configuration A, then they will be automatically
required in configuration B. On the other hand, artifacts required in
configuration B are not necessarily required in configuration A.
This notion is very helpful to define configurations which are similar
with some differences.
At the bottom of the page, there's the Examples section with an example with runtime config that has "runtime will be composed of all dependencies, all transitively, including the dependencies declared only in compile."
With this, you can now understand the config concept in sbt as a dependencies groups and what's grouped in Compile is available in Runtime as its definition looks as follows:
lazy val Runtime = config("runtime") extend (Compile)
I have just had to figure this out, so I thought this was worth clarifying. The configuration has to be added to the project for delegation to the extended configuration to occur:
lazy val KateBush: Configuration = config("katebush") extend Compile
lazy val root = (project in file(".")).configs(KateBush)
will work fine. If you
inspect katebush:compile
then you can view the delegation chain:
...
[info] Delegates:
[info] katebush:compile
[info] compile:compile
[info] *:compile
[info] {.}/katebush:compile
[info] {.}/compile:compile
[info] {.}/*:compile
[info] */katebush:compile
[info] */compile:compile
[info] */*:compile
...
I'd like to configure Typesafe Activator and it's bundled tooling not to use my user home directory - I mean ~/.activator (configuration?), ~/.sbt (sbt configuration?) and especially ~/.ivy2, which I'd like to share between my two OSes.
Typesafe "documentation" is of little help.
Need help for both Windows and Linux, please.
From Command Line Options in the official documentation of sbt:
sbt.global.base - The directory containing global settings and plugins (default: ~/.sbt/0.13)
sbt.ivy.home - The directory containing the local Ivy repository and artifact cache (default: ~/.ivy2)
It appears that ~/.activator is set and used in the startup scripts and that's where I'd change the value.
It also appears (in sbt/sbt.boot.properties in activator-launch-1.2.1.jar) that the value of ivy-home is ${user.home}/.ivy2:
[ivy]
ivy-home: ${user.home}/.ivy2
checksums: ${sbt.checksums-sha1,md5}
override-build-repos: ${sbt.override.build.repos-false}
repository-config: ${sbt.repository.config-${sbt.global.base-${user.home}/.sbt}/repositories}
It means that without some development it's only possible to change sbt.global.base.
➜ minimal-scala activator -Dsbt.global.base=./sbt -Dsbt.ivy.home=./ivy2 about
[info] Loading project definition from /Users/jacek/sandbox/sbt-launcher/minimal-scala/project
[info] Set current project to minimal-scala (in build file:/Users/jacek/sandbox/sbt-launcher/minimal-scala/)
[info] This is sbt 0.13.5
[info] The current project is {file:/Users/jacek/sandbox/sbt-launcher/minimal-scala/}minimal-scala 1.0
[info] The current project is built against Scala 2.11.1
[info] Available Plugins: sbt.plugins.IvyPlugin, sbt.plugins.JvmPlugin, sbt.plugins.CorePlugin, sbt.plugins.JUnitXmlReportPlugin
[info] sbt, sbt plugins, and build definitions are using Scala 2.10.4
If you want to see under the hood, you could query for the current values of the home directories for sbt and Ivy with consoleProject command (it assumes you started activator with activator -Dsbt.global.base=./sbt -Dsbt.ivy.home=./ivy2):
> consoleProject
[info] Starting scala interpreter...
[info]
import sbt._
import Keys._
import _root_.sbt.plugins.IvyPlugin
import _root_.sbt.plugins.JvmPlugin
import _root_.sbt.plugins.CorePlugin
import _root_.sbt.plugins.JUnitXmlReportPlugin
import currentState._
import extracted._
import cpHelpers._
Welcome to Scala version 2.10.4 (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_60).
Type in expressions to have them evaluated.
Type :help for more information.
scala> appConfiguration.eval.provider.scalaProvider.launcher.bootDirectory
res0: java.io.File = /Users/jacek/sandbox/sbt-launcher/minimal-scala/sbt/boot
scala> appConfiguration.eval.provider.scalaProvider.launcher.ivyHome
res1: java.io.File = /Users/jacek/.ivy2
Iff you're really into convincing Activator to use sbt.ivy.home, you have to change sbt/sbt.boot.properties in activator-launch-1.2.2.jar. Just follow the steps:
Unpack sbt/sbt.boot.properties out of activator-launch-1.2.2.jar.
jar -xvf activator-launch-1.2.2.jar sbt/sbt.boot.properties
Edit sbt/sbt.boot.properties and replace ivy-home under [ivy].
ivy-home: ${sbt.ivy.home-${user.home}/.ivy2}
Add the changed sbt/sbt.boot.properties to activator-launch-1.2.2.jar.
jar -uvf activator-launch-1.2.2.jar sbt/sbt.boot.properties
With the change, -Dsbt.ivy.home=./ivy2 works fine.
scala> appConfiguration.eval.provider.scalaProvider.launcher.bootDirectory
res0: java.io.File = /Users/jacek/sandbox/sbt-launcher/minimal-scala/sbt/boot
scala> appConfiguration.eval.provider.scalaProvider.launcher.ivyHome
res1: java.io.File = /Users/jacek/sandbox/sbt-launcher/minimal-scala/ivy2
I was experimenting with this today. After a while, it seems to me like this could be the best thing to do:
Windows:
setx _JAVA_OPTIONS "-Duser.home=C:/my/preferred/home/"
Linux:
export _JAVA_OPTIONS='-Duser.home=/local/home/me'
Then you should be good to go for any Java Program that wants to store data in your home directory.
As an addition to Jacek's answer, another way that worked for me to set the .ivy2 directory was to use the sbt ivyConfiguration task. It returns configuration settings related to ivy, including the path to the ivy home (the one which defaults to ~/.ivy2).
Simply add these few lines to the build.sbt file in your project :
ivyConfiguration ~= { originalIvyConfiguration =>
val config = originalIvyConfiguration.asInstanceOf[InlineIvyConfiguration]
val ivyHome = file("./.ivy2")
val ivyPaths = new IvyPaths(config.paths.baseDirectory, Some(ivyHome))
new InlineIvyConfiguration(ivyPaths, config.resolvers, config.otherResolvers,
config.moduleConfigurations, config.localOnly, config.lock,
config.checksums, config.resolutionCacheDir, config.log)
}
It returns a new ivy configuration identical to the original one, but with the right path to the ivy home directory (here ./.ivy2, so it'll be located just next to the build.sbt file). This way, when sbt uses the ivyConfiguration task to get the ivy configuration, the path to the .ivy2 directory will be the one set above.
It worked for me using sbt 0.13.5 and 0.13.8.
Note: for sbt versions 0.13.6 and above, the construction of the InlineIvyConfiguration needs an additional parameter to avoid being flagged as deprecated, so you might want to change the last line into :
new InlineIvyConfiguration(ivyPaths, config.resolvers, config.otherResolvers,
config.moduleConfigurations, config.localOnly, config.lock,
config.checksums, config.resolutionCacheDir, config.updateOptions, config.log)
(note the additional config.updateOptions)
I had that same problem on Mac. I erased the directory in user home directory named .activator and all related folder. After that run activator run command on terminal. Activator download all of the folder which I deleted. Than problem solved.