gildegoma / chef-sbt-extras Goto Github PK

• overkill ?
• it is actually not a big deal, if the referenced version is not frequently changed...

in 0.2.2:

• sbtopts template is not optional (missing only_if/not_if clause)
• optional attribute style is ugly, improve the way to trigger/configure optional templates.

With great help of:

• https://github.com/calavera/minitest-chef-handler
• https://github.com/opscode/test-kitchen

See also:

• https://github.com/jamie-ci HOT!? see https://github.com/fnichol/chef-rvm/blob/master/.jamie.yml
• http://nathenharvey.com/blog/2012/07/06/mvt-knife-test-and-travisci
• Test within a real Chef(-solo) run. Example: https://github.com/fnichol/chef-user/tree/master/test

Question raised after I saw this example: https://github.com/opscode-cookbooks/maven/blob/425d53f4618d472ec88c4308845461694584b588/.travis.yml#L5

I won't tackle dwijnand/sbt-extras#57 (comment) for milestone 0.3

See #20.

since typesafe.artifactoryonline.com was replaced with repo.typesafe.com, when the script attempts to get the launcher it 404's and fails

looks like this can be worked around in the meantime by overriding node['sbt-extras']['download_url']

Following expectations should be implemented:

• every lines of jvmopts and sbtopts
• SBT_OPTS and JVM_OPTS environment variables only should be exported for sbt group members

I saw some recipe that grepped on /etc/group or /etc/passwd to fetch such kind of information, but I would expect something more elegant...

This will be useful to set the HOME environment variable in the execute calls.

Goal: jvm and sbt arguments can be store in some global (system-wide) config files, instead of project-local own .sbtopts and .jvmopts

requires sbt-extras add-on (cherry pick from typesafe fork)

To be refactored:

• default recipe: sbtopts and jvmopts stuff can share code
• default recipe: create tmp_dir + execute sbt + delete tmp_dir
• fetch default sbt version from sbt-extras script code (or command).

specific run_list attributes of the platforms are not working.

1. first for static validation (foodcritic/tailor)
2. for BDD (#1)

Workaround introduced in e4f6521

1. Double check if problem exists, or is mine...
2. If problem, report it to sbt-extras main project

When fixed in some way, remove the workaround.

When preinstall matrix is configured for sbt 0.7 or 0.10, the recipe should skip it and log a warning, until #9 is implemented.

Introducing "latest" paulp/sbt-extras introduce following changes between cookbook 0.2.x and 0.3+:

Fixed for Milestone 0.3:

• Most important: dwijnand/sbt-extras#43 has been merged. Fixed in 37ef057
• sbt-launcher are now by default stored in ~/.sbt/launchers, which makes obsolete to share installed dependencies in /opt/sbt-like common directory.
• sbt and scala boot libraries are now stored only once 😄 It means that "pre-installation" can be strongly improved / extended, which is good for Travis CI!!! But note that with new "latest launcher" strategy, -sbt-create trick does not work anymore. As workaround we can create additional fake project/build.properties file

Planned for Milestone 0.4:

• Pending on dwijnand/sbt-extras#62

For now, I'll drop '-batch'. First step is to report the problem (and evaluate if we need a fix or not)

issue file to remind me to smash my rvm environment to check if still happen after full new Gem Bundle installation (without old stuff like Jamie CI or Test Kitchen 0.x)

If sbt-extras conflicts with typesafe-stack, which one do you recommend I use?

Also, please provide a best-practice example of running SBT, e.g. "sbt stage" on a project, from within an app's recipe.

Thank you!

Should we keep them as templates (and thus support all/many options as chef attributes), or go back to file instead of template strategy ?

-mem option does not exist anymore, should be replaced by something like -Xms128m -Xmx128m -XX:MaxPermSize=64m in default jvmopts

Improve chefspec examples?

see also #14

• The dynamic download/installation of default sbt-laucher is not yet idempotent.

I was trying to update the travis build on my own branch and could not do it even after several days trying.

Is this project dead? I came here because it is used in the build of another project

Can you list the config so i can try to replicate your old build?

If people are interested to persist 'boot' libraries in a common location (not in the project local files),the additional arg -sbt-boot could be used.

Looks like worst style, but after 0.3 milestone, there is no more need to be owner or group member of the sbt script. Hence the question (to be compared with other cookbook practices).

• Add chefignore file (example 1)
• -knife plugin- superseeded by https://github.com/sethvargo/stove to tag+publish in a same operation

OK:

The download of sbt own-scala dependencies work fine (one scala version per sbt version)

Problem:

The download of libraries of a specific scala version is not working... I'm not sure if it is possible to achieve it, with a dummy/empty project (created by -sbt-create option) ?

(Current) Conclusion

The 'scala' dimension of pre-install matrix (user-sbt-scala) is for now useless, only the sbt setup can be preinstalled.

After first quick search, I don't see how ohai library provides this information (à la Ansible facts). This could be used to dynamically adapt the JVM tunings...

Main Idea would consist in generalizing the code for

:arg_mem => node['sbt-extras']['sbtopts']['mem']

into something like

:arg_x => node['sbt-extras']['sbtopts']['x']

that would then dynamically fill the template placeholders.