After adding unweb.watermark to eggs, I get an endless series of starts in instance.log (Plone 4.1.2), but no service.
See buildout / fg at http://pastie.org/2776226
How can I investigate/fix this?
By adding that product in a vanilla Plone I've faced these two issues (depending on the versions of products used):
ConfigurationError: ('Unknown directive', u'http://namespaces.zope.org/tales', u'expressiontype')
or
AttributeError: type object 'DirectoryResource' has no attribute
'resource_factories'
In order to fix that issue you should extend your buildout like this:
[buildout]
...
extends =
...
http://svn.plone.org/svn/collective/unweb.watermark/trunk/versions.cfg
http://good-py.appspot.com/release/plone/4.1.2?dexterity=1.0
More info:
http://www.gossamer-threads.com/lists/zope/dev/230509
http://code.google.com/p/dexterity/issues/detail?id=165
Related
I've a kotlin spring boot project with org.hibernate:hibernate-validator:7.0.0.Final and org.glassfish:jakarta.el:4.0.1.
For testing validation constraints I create a javax.validation.Validator, like so:
val factory = Validation.buildDefaultValidatorFactory()
validator = factory.validator
This results in the following error: HV000183: Unable to initialize 'javax.el.ExpressionFactory'. Check that you have the EL dependencies on the classpath, or use ParameterMessageInterpolator instead. Which I find strange, since I included them per the instructions: https://hibernate.org/validator/documentation/getting-started/
If I combine org.hibernate:hibernate-validator:7.0.0.Final and org.glassfish:javax.el:3.0.0 it works, but it looks like 7.0.0.Final should not be used with javax.el, but with jakarta.el, without me knowing the reason why at the moment: https://in.relation.to/2021/01/06/hibernate-validator-700-62-final-released/
Any ideas on what I need to do to use hibernate-validator v7?
To avoid jar hell, I'd like to refer to a dependency relatively.
For example, when I add a dependency to "org.http4s" %% "https-circe" % "0.21.1":
cs resolve org.http4s:http4s-circe_2.12:0.21.1 | grep -i circe ⎈ eks-cluster-eu-west-1-dev/master
io.circe:circe-core_2.12:0.13.0:default
I'd like to add a dependency to "circe-literal" in the version, which was automatically resolved by SBT's mediator. In this example "0.13.0". Is this possible?
On one hand, you could add circe-literal with a wildcard version, and using the latest-compatible conflict manager would get a version of it that is compatible with circe-core. Sadly, one cannot, without resorting to the coursier plugin, specify conflict managers for a specific artifact.
If that is ok, with you, however, you should be able to specify this:
conflictManager := ConflictManager.latestCompatible
libraryDependencies += "io.circe" %% "circe-literal % "[0,)"
You'll have to use the ivy resolver to get that working, though.
dependencyResolution := sbt.librarymanagement.ivy.IvyDependencyResolution(ivyConfiguration.value)
Using that, I got exactly what you wanted:
[info] [SUCCESSFUL ] io.circe#circe-literal_2.12;0.13.0!circe-literal_2.12.jar (304ms)
I work on symfony project and I want to exclude some generated code from sonar analytics.
I want to exclude a folder named by this path: src/Application/Sonata.
I tried many possibilities with sonar exclusions but in vain:
sonar.exclusions=src/Application/Sonata/*
sonar.exclusions=src/Application/Sonata/**
sonar.exclusions=src/Application/Sonata/**/*
this is my sonar-project.properties file
# Required metadata
sonar.projectKey=project
sonar.projectName=project
sonar.projectVersion=0.1.3
# Description
sonar.projectDescription=project a base symphony 2
# Encoding of the source code
sonar.sourceEncoding=UTF-8
sonar.exclusions=src/Application/Sonata/**/* ,src/project/Resources/public/js/lib/**/*, src/project/Resources/public/js/jquery.validate.js
After many tests, i found the correct syntax of sonar.exclusions clause:
sonar.exclusions=src/Application/Sonata/**/*,src/Simuleo5BOBundle/Resources/public/js/lib/**/*,src/Simuleo5BOBundle/Resources/public/js/jquery.validate.js
Correctly setting exclusions from properties is difficult to get right, which is why it's not documented. Instead, you should use the UI to set your exclusions.
I'm playing with command model binding and I looked at the example github project and I have issues when using the dependency:
"org.scalatra" % "scalatra-data-binding" % "2.2.0-RC1"
Taking the example project code i.e.
abstract class TodosCommand[S](implicit mf: Manifest[S]) extends ModelCommand[S] with ParamsOnlyCommand
class CreateTodoCommand extends TodosCommand[Todo] {
val name: Field[String] = asType[String]("name").notBlank.minLength(3)
}
case class Todo(id: Integer, name: String, done: Boolean = false)
I am unable to compile when I use the command[CreateTodoCommand] method from the CommandSupport trait i.e.
scala: type arguments [au.com.xxx.sapi.seo.CreateTodoCommand] do not conform to method command's type parameter bounds [T <: SeoServlet.this.CommandType]
val cmd = command[CreateTodoCommand]
^
I'm not that clued up with Scala but I would assume that as ParamsOnlyCommand extends Command and there is this line in the command support trait, then there should be no issues:
type CommandType <: org.scalatra.databinding.Command
Any ideas why I am getting this issue?
Cheers, Chris.
It's very likely that the reason you're having problems is that we're still linking to an ancient example version, for which the docs no longer apply. I thought I'd caught all of the example projects in the docs and moved them into https://github.com/scalatra/scalatra-website-examples, but apparently I missed this one. Sorry for the hassle!
I'll see if I can fix this today sometime, and provide a compiling example. In the meantime, you might try updating all your Scalatra-related dependencies to the 2.2.0 release - and see if that fixes anything straight away.
The latest stable release of Scalatra is currently 2.2.1, but you'll need to be careful around commands as I remember #casualjim saying that he'd changed the way things worked to some extent between 2.2.0 and 2.2.1.
In Scalatra 2.2.1, "org.scalatra" %% "scalatra-commands" % "2.2.0" I have no issues. but I don't know scalatra-data-binding is also standalone.
If I provide a variable with an embedded space in the environment as follows:
environment =
CPPFLAGS="-D_GNU_SOURCE -I${openssl:location}/include"
I get this error:
ValueError: dictionary update sequence element #1 has length 1; 2 is required
Is this a bug? Is there a workaround?
It's a shortcoming in zc.recipe.cmmi; it cannot handle environment variables without spaces. There is a patch available in the bugtracker for the recipe.
I am not currently aware of a workaround for this other than applying the patch. You can apply the patch on existing eggs using the collective.recipe.patch recipe, which should work in this case too (untried):
[buildout]
parts =
patch-z.r.cmmi
yourcmmipart
[patch-z.r.cmmi]
recipe = collective.recipe.patch
egg = zc.recipe.cmmi <= 1.3.4
patch = patches/environ_section_trunk_r101308.patch
This assumes you have a patches suddirectory with the patch from the bug downloaded. The part needs to be listed before your cmmi part to be executed before that part (or you can fabricate a dependency).
An alternative solution is to just abuse the recipe's 'configure-command' like so:
[buildthis]
recipe = zc.recipe.cmmi
...
configure-command =
export CPPFLAGS="-D_GNU_SOURCE -I${openssl:location}/include";
./configure