How to solve collective.js.jqueryui versioning for both Plone 4.2 and 4.3 - plone

I have an addon which I want to update to be compatible with Plone4.3, but which should remain functional when Plone4.2 users do an upgrade.
The readme says this:
For Plone 3 you need version 1.7.x of this package
Plone < 4.3 Use version < 1.9
How can I configure this kind of version-specific dependency in setup.py?

Actually it's c.js.jqueryui which should pin the Plone-versions in their tag-releases, IMHO.
So you should contact the authors probably.
To be consequent, you should add 'Products.CMFPlone' as a dependency, too, but I don't know what is best practice here.
Anyway, to answer your question, here is a possibilty to distinct, whether we have a Plone-3 or not:
In your setup.py add at the top
import glob
# BBB: Append Plone-3-specific version-pinnings
# to `install_requires`, in case third-party-eggs
# do not specify their requirement-versions.
# Assumes, Plone-eggs are in the same directory
# as this egg, which is given, if fetched of pypi.
# Otherwise assumes, you know how to tweak
# buildout and pin versions yourself.
# Collect P3-eggs in eggs-directory:
plone3_eggs = glob.glob('../Products.CMFPlone-3*')
# Found something?
if len(plone3_eggs) > 0:
# Expects `install_requires=[ ... ] + plone3_requires,`
# in setup-method below, to take effect:
plone3_requires = [
'collective.js.jqueryui<=1.7',
# Add more P3-pins here.
]
And install_requires in the setup-method, gets this:
install_requires= [
'setuptools',
'collective.js.jqueryui',
] + plone3_requires,

Related

SBT: describe external dependency relative to another (transitive) dependency?

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)

SonarQube: sonar.exclusions parameter cannot exclude a folder

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.

Play 2.1 ConfigFactory.parseFile fails on substitution

In application.conf (in Play 2.0.4, sbt 0.11.3) I could use following substitutions:
app {
major = 0
minor = 1
revision = 62
date = 0127
version = ${app.major}.${app.minor}.${app.revision}.${app.date}
}
After upgrade to Play 2.1.0 and sbt 0.12.2 and using this suggestion for Build.scala,
val conf = ConfigFactory.parseFile(new File("conf/application.conf"))
I get error when I do play clean:
Caused by: com.typesafe.config.ConfigException$NotResolved: need to call resolve() on root config; tried to get value type on an unresolved substitution: ConfigSubstitution(${app.major}"."${app.minor}"."${app.revision}"."${app.date})
at com.typesafe.config.impl.ConfigSubstitution.valueType(ConfigSubstitution.java:54)
at com.typesafe.config.impl.DefaultTransformer.transform(DefaultTransformer.java:15)
at com.typesafe.config.impl.SimpleConfig.findKey(SimpleConfig.java:118)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.java:135)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.java:140)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.java:108)
at com.typesafe.config.impl.SimpleConfig.find(SimpleConfig.java:146)
at com.typesafe.config.impl.SimpleConfig.getString(SimpleConfig.java:188)
at ApplicationBuild$.<init>(Build.scala:12)
at ApplicationBuild$.<clinit>(Build.scala)
Based on Play Configuration documentation this kind of substitution should be supported:
Implementations must take care, however, to allow objects to refer to
paths within themselves. For example, this must work:
bar : { foo : 42,
baz : ${bar.foo}
} Here, if an implementation resolved all substitutions in bar as part of resolving the substitution ${bar.foo}, there would be a
cycle. The implementation must only resolve the foo field in bar,
rather than recursing the entire bar object.
Any ideas how to fix this?
Your syntax is correct. It seems that you actually need to call resolve() as the error message says, to resolve substitutions. I guess in 2.0.x the play framework did this and provided a config that was already resolved this way. Now that the config API is used directly it needs to be resolved manually.
Add a call to resolve() in this line:
val conf = ConfigFactory.parseFile(new File("conf/application.conf")).resolve()
AFAIK, my understanding of the doc is that you should use something like:
app {
major = 0
minor = 1
revision = 62
date = 0127
version = ${major}.${minor}.${revision}.${date}
}
I did not test it...
And maybe it worked under 2.0.4 because of a bug ?

Log rotation with Plone

The log rotation for Plone product installation would be a nice feature. What are the current best practices regarding the log rotation integration into Plone?
I found this article: http://encolpe.wordpress.com/2010/06/17/how-to-get-log-files-rotate-in-zope-with-buildout/ but as there are no documentation on plone.org I'd like to ping the community for the good known best practices not to fill up their hard disks.
ZConfig has support for the standard library RotatingFileHandler and TimedRotatingFileHandler. Taking an example from the ZConfig tests:
<eventlog>
<logfile>
path /path/to/file.log
level debug
when D
interval 3
old-files 11
</logfile>
</eventlog>
This will roll over the logs every three days, keeping 11 old files.
You place these config snippets your buildout using the event-log-custom/access-log-custom parameters in your instance recipe. plone.recipe.zope2instance
Similar to what Laurence said above but keeps size under 10mb and saves only 1 old file.
<eventlog>
level INFO
<logfile>
path /path/to/plone4/var/log/client1.log
max-size 10mb
old-files 1
</logfile>
</eventlog>
plone.recipe.zope2instance can generate this now. For example, you can specify the following options:
event-log-max-size = 10mb
event-log-old-files = 3
Here's what we do, it's simple but works:
In your buildout you add this part:
[logrotate]
recipe = collective.recipe.template
input = ${buildout:directory}/templates/logrotate.conf
output = ${buildout:directory}/etc/logrotate.conf
And in templates/logrotate.conf
rotate 4
weekly
create
compress
delaycompress
missingok
${buildout:directory}/var/log/instance1.log ${buildout:directory}/var/log/instance1-Z2.log {
sharedscripts
postrotate
/bin/kill -USR2 $(cat ${buildout:directory}/var/instance1.pid)
endscript
}
${buildout:directory}/var/log/instance2.log ${buildout:directory}/var/log/instance2-Z2.log {
sharedscripts
postrotate
/bin/kill -USR2 $(cat ${buildout:directory}/var/instance2.pid)
endscript
}
Add whatever other log rotations you need. Then it's about linking /etc/logrotate.conf to the generated file.
Mikko, you should ask me directly ;)
My blog article is still good and this feature is still undocumented in Zope2. It can be used with Plone 4 and Plone 5. The extension iw.rotatelogs was designed for Plone 3 only.
Using logrotate is not fine because it doesn't handle the case of logwriting during the rotation. It can make your instance crash silently and writing logs in RAM until your restart the instance.
I've been using iw.rotatezlogs since at least early Plone 3 very successfully. I see from your link that I should no longer need iw.rotatezlogs.
I don't like to rely on logrotate, since it's not usable on the one Windows server I have to deploy to.
As near as I can tell, the pure-zope solution (which I stil haven't tested) doesn't do logfile compression (at least I can't see it in ZConfig/components/logger/handlers.xml which is where I think it should be defined), so I suspect I'll be staying with iw.rotatezlogs.

Bug in zc.recipe.cmmi?

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

Resources