[ANN] trapperkeeper-webserver-jetty9 v0.9.0 security release

[Chris Price]

We're planning on doing an offiicial 1.0 release of both trapperkeeper[1]
and trapperkeeper-webserver-jetty9[2] in the not-too-distant future, and in
that announcement e-mail we can highlight some of the new features that
have been added over the last few months.  However, due to the recent
"poodle" security vulnerability announcement, we wanted to go ahead and
send out a heads-up that we've done a v0.9.0 release of
trapperkeeper-webserver-jetty9.  This release addresses the security
vulnerability in the SSLv3 protocol by configuring Jetty to only accept
TLSv1, TLSv1.1, or TLSv1.2 connections by default.

Note that in older versions of trapperkeeper-webserver-jetty9, you can
specify your preferred list of SSL protocols via the `ssl-protocols`
setting[3], but if you upgrade to v0.9.0 then it'll be taken care of by
default.

A more comprehensive 1.0 announcement will be coming in the next month or
two.

[1] https://github.com/puppetlabs/trapperkeeper
[2] https://github.com/puppetlabs/trapperkeeper-webserver-jetty9
[3]
https://github.com/puppetlabs/trapperkeeper-webserver-jetty9/blob/master/doc/jetty-config.md#ssl-protocols

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] trapperkeeper, trapperkeeper-webserver-jetty9 1.0.0

[Chris Price]

Hi!

We are excited to announce the 1.0.0 release of trapperkeeper and
trapperkeeper-webserver-jetty9.  Now that Puppet Labs is shipping several
production apps built on the framework and we consider the API to be
stable, we decided to bump the version number to 1.0.0 and ensure that we
adhere to semantic versioning principles in future releases.

Trapperkeeper[1] is a Clojure framework for hosting long-running
applications and services. You can think of it as a sort of "binder" for
Ring applications and other modular bits of Clojure code.

It's based on the excellent Prismatic graph[2] library, and manages life
cycles and dependencies of service components that make up your
application.  It provides some built-in functionality for loading
configuration from config files on disk (and supports several different
config formats), and uses clojure protocols to define the contracts between
different services in your system.  It was designed to be compatible with
Stuart Sierra's 'reloaded' workflow, and also includes several test utility
functions / macros to make it easy to write comprehensive integration
tests.  For more info, check out our wiki[3], where you'll find lots of
documentation and a sample web application.

We've also released version 1.0.0 of trapperkeeper-webserver-jetty9[4],
which is a trapperkeeper service that provides a Jetty9 web server
(surprise!) and functions for adding your web apps to the server.  It
supports adding multiple web apps (you can mount them at different URL
paths in the same server), which helps allow you to keep your code more
modular.  It's primarily intended for running Ring applications, but it
also supports running Java servlets, applications from WAR files, and
configuring certain URL paths to be reverse-proxied via Jetty's
ProxyServlet.  You can configure tons of things about the server via the
config files: plaintext vs HTTPS ports, configure SSL via pem file paths,
open multiple HTTPS ports with different certificate configurations, and
even change the URL paths at which your web apps will be mounted without
modifying your code (via the "web routing service"[5]).

Getting started with trapperkeeper and trapperkeeper-webserver-jetty9 is as
simple as:

$ lein new trapperkeeper my.namespace/project-name
$ cd project-name
$ lein test
$ lein tk

We hope you find it useful!  Please feel free to jump on to #trapperkeeper
on Freenode if you have any questions or suggestions.

The projects are on clojars at puppetlabs/trapperkeeper and
puppetlabs/trapperkeeper-webserver-jetty9.  (Special thanks to technomancy
for helping me fix an initial corrupt deploy of 1.0.0 that I flubbed!)

[1] Trapperkeeper github repo: https://github.com/puppetlabs/trapperkeeper
[2] Prismatic plumbing/graph library: https://github.com/Prismatic/plumbing
[3] Trapperkeeper github wiki:
https://github.com/puppetlabs/trapperkeeper/wiki
[4] tk-jetty9 github repo and docs:
https://github.com/puppetlabs/trapperkeeper-webserver-jetty9
[5] tk-jetty9 webrouting service docs:
https://github.com/puppetlabs/trapperkeeper-webserver-jetty9/blob/master/doc/webrouting-service.md

Grand plans for future releases:

* Provide a mechanism for services to validate their configuration data at
startup, and fail fast with a user-friendly error message if the config is
invalid
* Support other configuration data sources (besides just file-based config)
* Provide notification hooks for config changes
* ???
* Profit

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] trapperkeeper-jetty9 v1.2.0

[Chris Price]

Hi!  Just wanted to let everyone know that we recently released a new
version of trapperkeeper-webserver-jetty9 to clojars.  The new version is
v1.2.0.

https://clojars.org/puppetlabs/trapperkeeper-webserver-jetty9

It's a feature release; there are a few new config options, but the most
significant change is that it bumps us up from a build of Jetty 9.1.x that
was about a year and a half old, to a much newer version (9.2.8).

The motivation for this was that we had a customer reporting a really
nasty, low-level Jetty race condition that could cause the server to end up
in a hung / deadlocked / unresponsive state after experiencing sustained
high load.  We were eventually able to reproduce the behavior in a test
environment and confirm that the newer version of Jetty fixes the issue.

We've also seen a marked improvement in startup time, which is a fairly big
deal for us since we spin up and shut down Jetty dozens and dozens of times
during the tests for our various trapperkeeper applications.  We have some
more targeted performance testing scheduled, but no results yet... but so
far, it seems quite a bit faster.

If you're interested in the gory details, see the CHANGELOG:

https://github.com/puppetlabs/trapperkeeper-webserver-jetty9/blob/master/CHANGELOG.md#120

Thanks!
Chris

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Puppet Labs and Trapperkeeper

[Chris Price]

We published a follow-up post this morning, with a lot more detail on the 
Clojure side of things:

https://puppetlabs.com/blog/clojure-nerds-puppet-labs-application-services

On Sunday, April 13, 2014 6:48:10 PM UTC-7, Walter Heck wrote:
>
> As a non-clojure user, but a Puppet expert (ahum ;) ) I wrote a blog post 
> about this announcement that might be interesting for some folks here. I'd 
> also love to see comments on the post itself if I have drawn any wrong 
> conclusions:
> http://www.olindata.com/blog/2014/04/clojure-outsiders-investigation
>
> On Sunday, 13 April 2014 16:24:28 UTC+2, Brendan Younger wrote:
>>
>> I just saw that there's a library called TrapperKeeper 
>> https://github.com/puppetlabs/trapperkeeper from the folks at Puppet 
>> Labs.  It looks to be a more opinionated and complete version of Stuart 
>> Sierra's Component library https://github.com/stuartsierra/component, in 
>> that it explicitly pays attention to things like logging configuration and 
>> JBoss support.
>>
>> Brendan Younger
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Puppet Labs and Trapperkeeper

[Chris Price]

Yep, you've pretty much nailed it... the design was heavily inspired by the
OSGi service registry, but we didn't really have a need for most of the
other functionality that OSGi offers.  So we basically just came up with a
way to describe services via Clojure protocols, and then we wire them
together with Prismatic graph (thanks, Prismatic!).  Hope folks find it
useful!


On Mon, Apr 14, 2014 at 9:24 PM, Mike Haney  wrote:

> Great timing on the new blog post.  I'm ramping up on my first "real"
> clojure app, and have been planning to use Component for this piece.  I
> read the first blog post yesterday and it sounded interesting, but I've
> pretty much locked down the stack I'm going to use (you can evaluate
> libraries forever, but at some point you just have to stop looking and pick
> one to go with).
>
> But after reading the new post, I think it's worth taking a look at
> Trapperkeeper.  Even if I don't switch now, if all goes well I would like
> to turn this app into a larger SaS offering, possibly multi-tenant, and I
> could see something like Trapperkeeper helping there.
>
> I get the distinct impression you have some former OSGI users on your
> team?  This reminds me a lot of the service registry in OSGI.  And I don't
> mean that as an insult - the service registry was the best part, it was all
> the other crap that made it painful to use (particularly anything from
> eclipse, which ruined OSGI in my opinion, but that's another rant).
>
> Anyway, this looks like something that could be useful in many cases, and
> thank you for open-sourcing it.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

java6 vs java7

[Chris Price]

Recently a few co-workers and I have been discussing options related to
compiling a few tiny Java libraries that some of our Clojure libraries
depend on.  We realized that we should be explicitly setting the Java
source/target version for jars that we publish to clojars/maven central.
 Now we're trying to decide which version of Java to target.  We'd like to
target Java 7, but don't want to preclude people from using our OSS
libraries if there are large numbers of folks still on Java 6...

So, I'm curious... does anyone have any rough idea what the breakdown is
between production Clojure apps running on Java 7 vs. Java 6?  It *feels*
like Clojure is being used most frequently for SaaS-type applications, and
in those kinds of environments the developers/administrators can be pretty
prescriptive about JRE version, so maybe many/most folks are on Java 7
already?

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: java6 vs java7

[Chris Price]

Thanks!  I hadn't seen that survey, and it's tremendously helpful.

On Monday, April 28, 2014 11:48:17 AM UTC-7, Alex Miller wrote:
>
> The State of Clojure survey last year saw 75% using Java 7 and 19% on Java 
> 6.
>
>
> http://cemerick.com/2013/11/18/results-of-the-2013-state-of-clojure-clojurescript-survey/
>
>
> On Monday, April 28, 2014 12:56:51 PM UTC-5, Chris Price wrote:
>>
>> Recently a few co-workers and I have been discussing options related to 
>> compiling a few tiny Java libraries that some of our Clojure libraries 
>> depend on.  We realized that we should be explicitly setting the Java 
>> source/target version for jars that we publish to clojars/maven central. 
>>  Now we're trying to decide which version of Java to target.  We'd like to 
>> target Java 7, but don't want to preclude people from using our OSS 
>> libraries if there are large numbers of folks still on Java 6... 
>>
>> So, I'm curious... does anyone have any rough idea what the breakdown is 
>> between production Clojure apps running on Java 7 vs. Java 6?  It *feels* 
>> like Clojure is being used most frequently for SaaS-type applications, and 
>> in those kinds of environments the developers/administrators can be pretty 
>> prescriptive about JRE version, so maybe many/most folks are on Java 7 
>> already?
>>  
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: clojure.test parameterized tests

[Chris Price]

I have been curious about this too.  I was playing around with it a few 
weeks ago and came up with this:

https://github.com/cprice404/clj-shared-test-sandbox/blob/master/test/shared_tests_foo/core_test.clj

Which is pretty gross; it uses `binding` + a dynamic var in the shared test 
namespace, and then it calls `clojure.test/run-tests` from inside of a 
`deftest`.  I'm sure there's got to be a better way, but that was as far as 
I got in the small amount of time that I was able to spend on it.

On Thursday, May 1, 2014 5:58:51 PM UTC-7, Brian Craft wrote:
>
> I have a number of tests that I would like to run against different 
> implementations of a protocol. In clojure.test there doesn't appear to be a 
> way to parameterize a test over the implementations. Is there a good way to 
> do this?
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Community Interest in a Clojure Application Config Library, using Zookeeper?

[Chris Price]

I'm interested!  One of the things on the wish list for trapperkeeper is to 
make our current configuration service swappable--currently it only 
supports files, but I'd really like to be able to swap in a database-backed 
config or zookeeper-based implementation.  When we get some time to work on 
something like that it'd be great to be able to consider building it to use 
an existing library.

On Tuesday, May 20, 2014 2:33:05 PM UTC-7, Thomas Steffes wrote:
>
> Hey folks,
>
> At Room Key we're using Apache Zookeeper and a home-grown clojure library 
> called drcfg for real-time application configuration management. We're 
> debating open-sourcing drcfg and are trying to gauge community interest in 
> such a tool. 
>
> We think it's got great usage semantics, basically you just def an atom in 
> any namespace where you'd like a variable that can be changed in real-time 
> on a running system. When you define the atom, you can also provide 
> defaults to fall back to if zookeeper is unavailable, a validator to be run 
> on any value when a change is attempted (to prevent invalid configuration 
> data), as well as some meta-data about the variable.
>
> We've also got a web UI we use to change configuration data, but that 
> would likely be released separate of drcfg itself.
>
> If anyone's interested, could you reply to this post? I can provide more 
> information as well if need be.
>
>
> -Thomas Steffes @ Room Key
>
>
>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Community Interest in a Clojure Application Config Library, using Zookeeper?

[Chris Price]

On Wednesday, May 21, 2014 11:14:28 AM UTC-7, mlimotte wrote:
>
> I wrote a ZooKeeper based config system at Climate Corporation.  I also 
> found that there is a need to trigger some action when a config value 
> changes, and went with a simple callback solution.  I do like the idea of 
> tying this to Stuart's Component lifecycle model; although I think you 
> would also need the callback option for legacy code.
>
> Another feature that was important to us was overrides for development. 
>  When you start a system locally in dev mode, you probably don't want it to 
> use the production (or even QA environment) config.  So we allow overrides 
> in a local file.
>
> A few other features that we support, and I would like to see in a generic 
> open-source solution:
>

Is this library open source? 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Puppet Labs and Trapperkeeper

[Chris Price]

Thanks!

No concrete plans around any sort of hot code swapping for now.  That gets 
into lots of classloader stuff that, to be honest, seems like it adds a lot 
of complexity that we'd like to avoid.  Also, we are deploying all of our 
apps as uberjars for the time being, so we don't have a concrete use case 
for swapping out an individual service jar for now.

I'd love to see trapperkeeper be able to support this kind of thing for 
users who are interested in it, but I'd envision that a lot of the 
implementation would be done as a separate, optional TK service that 
wouldn't be mandatory for users who didn't feel they needed to introduce 
the extra complexity.  (There'd probably be a few changes necessary to the 
core framework to support such a service, though.)

I think it would be fairly easy to write a notification/restart service 
that could drop into the existing framework today, for things like 
reloading a service when configuration changes.  Loading up new code for a 
running service would be more challenging.  Anyway, it's something that 
we're definitely keeping in mind and would be interested in hearing ideas 
about how it might look, but no concrete plans.

Next few things on our list are: making the jetty9 service support multiple 
jetty instances (e.g. to support running two web apps on two different 
ports, with different SSL configurations), a new service that allows you to 
configure all of your web routes in a single place, and some plumbing work 
to improve the way we're currently interacting with Prismatic Graph.


On Friday, May 30, 2014 6:40:02 AM UTC-7, Sarwar Bhuiyan wrote:
>
> I really like it. It reminds me of OSGi Declarative Services where we use 
> the @Reference to inject stuff in. Also the init, start, and stop are 
> really nice in keeping with the OSGi component interface without all its 
> other baggage. Keep it up.
>
> I was wondering if you had any ideas on solving the zero-downtime 
> deployment/redeployment problem? In OSGi, individual bundles can be updated 
> individually and that could in effect be used to do some form of 
> zero-downtime deployments in the sense that only the services that need to 
> restart will restart based on the dependency tree. Of course, it might not 
> work for all cases and we might need some form of rolling restarts as well. 
> Just wondering if you had any ideas or plans around that for Trapperkeeper.
>
> Thank you.
>
> Sarwar
>
> On Tuesday, April 15, 2014 4:55:09 PM UTC+1, Chris Price wrote:
>>
>> Yep, you've pretty much nailed it... the design was heavily inspired by 
>> the OSGi service registry, but we didn't really have a need for most of the 
>> other functionality that OSGi offers.  So we basically just came up with a 
>> way to describe services via Clojure protocols, and then we wire them 
>> together with Prismatic graph (thanks, Prismatic!).  Hope folks find it 
>> useful!
>>
>>
>> On Mon, Apr 14, 2014 at 9:24 PM, Mike Haney  wrote:
>>
>>> Great timing on the new blog post.  I'm ramping up on my first "real" 
>>> clojure app, and have been planning to use Component for this piece.  I 
>>> read the first blog post yesterday and it sounded interesting, but I've 
>>> pretty much locked down the stack I'm going to use (you can evaluate 
>>> libraries forever, but at some point you just have to stop looking and pick 
>>> one to go with).
>>>
>>> But after reading the new post, I think it's worth taking a look at 
>>> Trapperkeeper.  Even if I don't switch now, if all goes well I would like 
>>> to turn this app into a larger SaS offering, possibly multi-tenant, and I 
>>> could see something like Trapperkeeper helping there.
>>>
>>> I get the distinct impression you have some former OSGI users on your 
>>> team?  This reminds me a lot of the service registry in OSGI.  And I don't 
>>> mean that as an insult - the service registry was the best part, it was all 
>>> the other crap that made it painful to use (particularly anything from 
>>> eclipse, which ruined OSGI in my opinion, but that's another rant).
>>>
>>> Anyway, this looks like something that could be useful in many cases, 
>>> and thank you for open-sourcing it.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>

[ANN] `comidi`: a committee approach to defining HTTP routes

[Chris Price]

Hiya.


We really like the syntax of compojure for defining HTTP routes, but have
had some trouble with use cases where we'd really like to be able to
introspect the route tree, and aren't able to do so because the nested
functions are pretty opaque.

After spending some time trying to workaround that, and giving up, we
decided to look into bidi, which has been awesome.  The data-driven route
tree is really, really useful.

However, a wholesale port of all of our existing apps directly from
compojure to bidi seemed daunting.  Enter `comidi`:

https://github.com/puppetlabs/comidi

This is a small library that uses bidi to build up route trees, but
provides a compojure-like syntax for defining the routes, and uses
compojure's "render" capabilities to support flexible syntax for specifying
your individual handlers for each route.

We've also got a related project that integrates comidi with our
Trapperkeeper framework and the dropwizard metrics library, to give you
middleware that will automatically track request metrics for each route in
your bidi/comidi route tree.

This is all a work in progress: notably, we had built up some prismatic
schemas around the route structures, but since the latest release of bidi
ships with its own schemas, we'll probably try to upgrade to that and
reconcile the differences soon.

We also have some plans for improving the ability to wrap middleware around
the route tree at various levels, and to look into some ring-swagger
integration soon.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] trapperkeeper-metrics, trapperkeeper-status, et al

[Chris Price]

Howdy.  Just wanted to send out some info about a few new services we've
open-sourced for use with our Trapperkeeper service framework recently.

trapperkeeper-metrics:
https://github.com/puppetlabs/trapperkeeper-metrics

This service manages configuration and life cycle of a MetricRegistry (from
https://github.com/dropwizard/metrics), so that you can easily manage
metrics across all of your TK services.

trapperkeeper-status:
https://github.com/puppetlabs/trapperkeeper-status

This service gives you a simple API to register a 'status' callback for all
of your other TK services.  It also provides a simple web endpoint for
exposing all of the status information for all of your services; when a
user hits the 'status' HTTP endpoint, all of your registered callbacks are
called.  The callbacks need only return a map of status information, and
the status service will handle the aggregation / presentation of all of the
data over HTTP.  Useful for monitoring / health checks / etc.

To see an updated list of some of the other recent projects we've released
related to Trapperkeeper, have a look at the updated README:

https://github.com/puppetlabs/trapperkeeper#related-projects

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] `comidi`: a committee approach to defining HTTP routes

[Chris Price]

On Wednesday, July 1, 2015 at 12:57:01 PM UTC+1, Dan Kersten wrote:
>
> Regarding the "Whats next" in the README:
>
> *looking into swagger integration. I could swear I found some bidi-swagger 
> bindings somewhere a while back, but am not finding them at the moment*
>
> Could you perhaps be thinking of the Yada swagger integration? 
> http://yada.juxt.pro/user-guide.html#Swagger yada.swagger is designed to 
> be used with bidi.
>
> https://github.com/juxt/yada/blob/master/src/yada/swagger.clj
>

Maybe so!  Will definitely look that over before doing anything else.  
Appreciate the link!

 

>
>
> On Wed, 1 Jul 2015 at 10:45 Chris Price  > wrote:
>
>> Hiya.
>>
>>
>> We really like the syntax of compojure for defining HTTP routes, but have 
>> had some trouble with use cases where we'd really like to be able to 
>> introspect the route tree, and aren't able to do so because the nested 
>> functions are pretty opaque.
>>
>> After spending some time trying to workaround that, and giving up, we 
>> decided to look into bidi, which has been awesome.  The data-driven route 
>> tree is really, really useful.
>>
>> However, a wholesale port of all of our existing apps directly from 
>> compojure to bidi seemed daunting.  Enter `comidi`:
>>
>> https://github.com/puppetlabs/comidi
>>
>> This is a small library that uses bidi to build up route trees, but 
>> provides a compojure-like syntax for defining the routes, and uses 
>> compojure's "render" capabilities to support flexible syntax for specifying 
>> your individual handlers for each route.
>>
>> We've also got a related project that integrates comidi with our 
>> Trapperkeeper framework and the dropwizard metrics library, to give you 
>> middleware that will automatically track request metrics for each route in 
>> your bidi/comidi route tree.
>>
>> This is all a work in progress: notably, we had built up some prismatic 
>> schemas around the route structures, but since the latest release of bidi 
>> ships with its own schemas, we'll probably try to upgrade to that and 
>> reconcile the differences soon.
>>
>> We also have some plans for improving the ability to wrap middleware 
>> around the route tree at various levels, and to look into some ring-swagger 
>> integration soon.
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] `comidi`: a committee approach to defining HTTP routes

[Chris Price]

On Wednesday, July 1, 2015 at 4:35:35 PM UTC+1, Daniel Jomphe wrote:
>
> Chris, this is definitely interesting. Quickly pluggable metrics & swagger 
> & trapperkeeper componentization sure are useful integrations.
>
> Doing a quick review, it surprised me a bit how many dependencies you 
> brought into comidi 
> <https://github.com/puppetlabs/comidi/blob/master/project.clj> 
> [dependencies].
>

I *believe* that the only "real" deps there are the bidi/compojure ones, 
and that the rest are just there to try to resolve transitive dependency 
conflicts (we use lein's :pedantic? flag).  I will double-check that, 
though.
 

> This looks more like a pragmatic, compromise integration library than a 
> pure new offer (just like you said you need at Puppet Labs).
>

That's definitely a fair characterization!
 

> Nevertheless, since you deviate from Compojure's API, I was very surprised 
> to still see you depend on it. And then I remind myself that you're in 
> there for meaningful, but quick, wins.
>

The compojure dependency is because I still found Compojure's "rendering" 
capabilities to be really useful, and didn't want to re-invent them.  But 
it is a compromise to have a dependency on both, to be sure.
 

>
> There was a discussion between most of the authors of the popular routing 
> libraries when Silk was introduced, including bidi's Malcolm, which came to 
> be very interesting too.
> When you titled `comidi` as being "a committee approach to defining HTTP 
> routes", I wondered if you were following up to that discussion. Here's a 
> link I kept to the middle of it 
> <https://groups.google.com/forum/#!searchin/clojure/silk$20bidi/clojure/D95anPmhNhU/X7P53cGbfZMJ>
>  [discussion].
>

Yes, I did read that discussion before working on this stuff.  In an ideal 
world or with a greenfield application, I think we might have just used 
bidi or silk directly (and, it is a goal of mine to try to make sure that 
our metrics stuff will work on plain-ole-bidi routes just as well as it 
does on comidi routes), but we have a *lot* of existing services built 
using compojure.  In order to be able to re-use our metrics stuff across 
all of those existing services, the only realistic option was to try to 
make it as simple as possible to migrate from a compojure route structure 
to a bidi-backed one.
 

> In any case, thanks for contributing to this field.
>

np, thanks for the feedback! 

>
> [dependencies]: 
> https://github.com/puppetlabs/comidi/blob/master/project.clj
> [discussion]: 
> https://groups.google.com/forum/#!searchin/clojure/silk$20bidi/clojure/D95anPmhNhU/X7P53cGbfZMJ
>
> On Wednesday, July 1, 2015 at 5:45:40 AM UTC-4, Chris Price wrote:
>>
>> Hiya.
>>
>>
>> We really like the syntax of compojure for defining HTTP routes, but have 
>> had some trouble with use cases where we'd really like to be able to 
>> introspect the route tree, and aren't able to do so because the nested 
>> functions are pretty opaque.
>>
>> After spending some time trying to workaround that, and giving up, we 
>> decided to look into bidi, which has been awesome.  The data-driven route 
>> tree is really, really useful.
>>
>> However, a wholesale port of all of our existing apps directly from 
>> compojure to bidi seemed daunting.  Enter `comidi`:
>>
>> https://github.com/puppetlabs/comidi
>>
>> This is a small library that uses bidi to build up route trees, but 
>> provides a compojure-like syntax for defining the routes, and uses 
>> compojure's "render" capabilities to support flexible syntax for specifying 
>> your individual handlers for each route.
>>
>> We've also got a related project that integrates comidi with our 
>> Trapperkeeper framework and the dropwizard metrics library, to give you 
>> middleware that will automatically track request metrics for each route in 
>> your bidi/comidi route tree.
>>
>> This is all a work in progress: notably, we had built up some prismatic 
>> schemas around the route structures, but since the latest release of bidi 
>> ships with its own schemas, we'll probably try to upgrade to that and 
>> reconcile the differences soon.
>>
>> We also have some plans for improving the ability to wrap middleware 
>> around the route tree at various levels, and to look into some ring-swagger 
>> integration soon.
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be pa

[ANN] trapperkeeper-webserver-jetty9 v1.4.0 : initial support for websockets

[Chris Price]

Today we did a new release of puppetlabs/trapperkeeper-webserver-jetty9 to
clojars.  trapperkeeper-webserver-jetty9 is the main webserver component
for use with our "trapperkeeper" service framework.

The new release is version 1.4.0, and it includes some initial support for
websockets.

We're calling this feature 'experimental' for now, just to give us a little
wiggle room to make minor tweaks to the API in a subsequent release after
we get some mileage on this, but we've been using the code in-house for a
while now so we are expecting it to be suitable for production use.

For the gory details, see:

https://github.com/puppetlabs/trapperkeeper-webserver-jetty9#add-websocket-handler

trapperkeeper-webserver-jetty9 on clojars:

https://clojars.org/puppetlabs/trapperkeeper-webserver-jetty9

trapperkeeper-webserver-jetty9 source code:

https://github.com/puppetlabs/trapperkeeper-webserver-jetty9

trapperkeeper docs:

https://github.com/puppetlabs/trapperkeeper/wiki

trapperkeeper source code:

https://github.com/puppetlabs/trapperkeeper

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

lein: managing versions of common deps / soliciting assistance on PR review

[Chris Price]

Hi,

As the number of Clojure projects at our company has increased, we've ended
up running into more and more frequent issues where lein's "pedantic" is
alerting us to conflicting versions of transitive dependencies.  Up until
now we've been managing this by surgically updating the lists of
dependencies / exclusions in each project until everything matches up, but
that's kind of like a giant game of whack-a-mole and has left us vulnerable
to situations where we're unwittingly running a bunch of our CI jobs
against a different version of some of our dependencies than the versions
that we end up including in our final builds.

I'm curious how often this has been coming up for others, and whether or
not anyone has found a solution or workaround for it that they are really
happy with.

I've seen a couple of cool things that people have put out there, e.g.:

https://github.com/achin/lein-parent
https://github.com/walmartlabs/shared-deps

Both of these seem to be taking an approach somewhat similar to Maven's own
solution, which is the "parent pom" / project inheritance[1] approach
(along with the "managedDependencies" section of a pom file).  Given that,
and given that lein's dependency management is already built on top of
Maven, I've been wondering if it would make sense to try to bring in
support for parent projects and managed dependencies as first-class
constructs in leiningen.

E.g.:

(defproject my-parent-project "1.0.0"
  :description "Parent project"
  :managed-dependencies [[clj-time "0.10.0"]
 [core.async "1.0"]])

Then you could have child projects foo and bar:

(defproject foo "1.0.0"
   :parent-project [my-parent-project "1.0.0"]
   :dependencies [[clj-time]
[some-other-dep "2.0.0"]])
(defproject bar "1.0.0"
   :parent-project [my-parent-project "1.0.0"]
   :dependencies [[core.async]
[yet-another-dep "3.0.0"]])

In this example, foo would automatically get the correct version of
clj-time from the parent, but would not drag in core.async at all.
Likewise, bar would get the correct version of core.async but would not
drag in clj-time. When you wanted to bump to a newer version of clj-time or
core.async across all of your projects, you'd just update the parent
project.

I'd be really curious to hear whether there are other people out there who
would find this useful, or if we're just doing something wrong :)

If there is some level of interest in this I'd be happy to work on PRs for
it; I've already done a fair amount of exploration.  In fact, I've already
put together one PR against cemerick/pomegranate to add support there for
Maven's "managedDependencies", which I think would be a pre-req for getting
any of the rest of this into leiningen:

https://github.com/cemerick/pomegranate/pull/73

If there are other folks out there who think this might be useful, I'd be
grateful for any feedback or review on the above PR.

Definitely still very interested to hear what other solutions people may
have come up with for this, though.

[1]
https://maven.apache.org/guides/introduction/introduction-to-the-pom.html#Project_Inheritance

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] trapperkeeper 1.3.0 - with support for restarts via HUP

[Chris Price]

Today we released puppetlabs/trapperkeeper v1.3.0 to clojars.

Trapperkeeper[1] is a Clojure framework for hosting long-running
applications and services. You can think of it as a sort of "binder" for
Ring applications and other modular bits of Clojure code.

The major change in the release is support for HUP signal handling; if you
send your TK process a HUP signal, it will gracefully stop and restart all
of your TK services without needing to restart the entire JVM process.
Note that if you plan to use this feature, it's important to ensure that
your services clean up after themselves properly during a `stop`, or you
may be subject to memory leaks when the services are restarted.

Also note that this release introduces a dependency on core.async.  This is
not used in any public APIs, but I thought it was worth mentioning since it
is a significant new dependency.

This release also bumps our raynes.fs dependency to 1.4.6, as we received
some feedback from users that the older version of raynes that we were
using was causing dependency conflicts.

For more info see the CHANGELOG[2], docs[3], and associated jira
tickets[4,5]

[1] Trapperkeeper github repo: https://github.com/puppetlabs/trapperkeeper
[2] CHANGELOG:
https://github.com/puppetlabs/trapperkeeper/blob/master/CHANGELOG.md#130

[3] Trapperkeeper github wiki:
https://github.com/puppetlabs/trapperkeeper/wiki
[4] Trapperkeeper HUP support Jira ticket:
https://tickets.puppetlabs.com/browse/TK-202
[5] raynes.fs dependency upgrade ticket:
https://tickets.puppetlabs.com/browse/TK-315

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] trapperkeeper-webserver-jetty9 v1.5.1 released

[Chris Price]

Today we did a new release of puppetlabs/trapperkeeper-webserver-jetty9 to
clojars.  trapperkeeper-webserver-jetty9 is the main webserver component
for use with our "trapperkeeper" service framework.

The new release is version 1.5.1, and it includes a fix for a memory leak
that would be triggered if you restart your application via Trapperkeeper's
recently-added support for HUP signals (added in TK 1.3.0).

trapperkeeper-webserver-jetty9 on clojars:

https://clojars.org/puppetlabs/trapperkeeper-webserver-jetty9

trapperkeeper-webserver-jetty9 source code:

https://github.com/puppetlabs/trapperkeeper-webserver-jetty9

trapperkeeper docs:

https://github.com/puppetlabs/trapperkeeper/wiki

trapperkeeper source code:

https://github.com/puppetlabs/trapperkeeper

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: leiningen dependency management

[Chris Price]

We run into this sort of thing quite a bit.  Our solution so far has been:

1. Always use `:pedantic? :abort` in the project file.  It can be annoying, 
but we've found that's much better to get annoying errors about version 
conflicts at build time than to get cryptic failures at runtime, such as 
the one that you described with schema.
2. Any time `:pedantic?` surfaces a conflicting transitive dependency 
between two libraries, we add an explicit dependency for the transitive 
dependency to resolve the conflict.  We usually have a section at the top 
of our dependencies list reserved for these transitive dependency 
resolutions, with some comments around it explaining that these aren't 
"normal" dependencies.  Doing it this way seems to give us more warning 
when new versions of upstream libraries come into use, whereas 
`:exclusions` is more likely to silently ignore those situations.

I've also been hacking on support for "managedDependencies" 
(https://github.com/technomancy/leiningen/issues/2067), which would allow 
you to specify common dependency versions in a parent project file and 
hopefully eliminate some of the dependency-version-whack-a-mole that seems 
to creep in when you start working with a large number of libraries.

On Friday, April 8, 2016 at 12:36:50 PM UTC-7, Sven Richter wrote:
>
> Hi,
>
> I have a library A that I use in project B. Now, library A makes use of 
> plumatics schema, as well as project B. I wonder what the best practice is 
> here. 
> Include schema in library A's dependencies? Or only declare a 
> dev-dependency on schema in library A?
>
> If I declare a dev-dependency I require every project that depends on 
> library A to include schema as a dependency, otherwise it will not work (I 
> have seen that with database libs for instance). I find that a bit unlucky, 
> because one might end up referring a lot of libs that other libraries 
> depend on.
>
> Or, include it as a direct dependency in library A. But then strange 
> things may happen as I had it with schema. Library A included schema v 
> 1.0.5 and project B schema v 1.0.3. 
> Now when I executed code in project B I had a weird schema error saying 
> that something in the schema is wrong, during compile time. In the end it 
> turned out that I have to require schema v 1.0.5 in project B too to make 
> it work. This is even more troublesome, as I make every project, that 
> depends on my library, depend on a transitive dependency in a specific 
> version.
>
> Looking at gradle for instance there is a configuration called 
> 'providedCompile' which means it is used for compilation of the library, 
> but not a transitive dependency if I include that library. Is there 
> something similar for leiningen?
>
> Best Regards,
> Sven
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: clojure.spec explain feedback

[Chris Price]

On Monday, June 27, 2016 at 12:45:07 PM UTC-7, Brent Millare wrote:
>
> I'm playing with clojure.spec (alpha7) to validate a data structure 
> storing information about workout history using the following code:
>
 

>
> The problem is that when using s/explain on an invalid input where the 
> error is near the leaves, the error message points at the root of the data 
> structure, which is not as useful.
>
> (s/explain
>  ::history
>  {[2015 6 31] {:chinups [(->rep_scheme 0 13)
>  (->rep_scheme :x 13)]
>:l-sit [(->duration 0 0 10)]}
>   [2016 6 31] {:chinups [(->rep_scheme 0 13)
>  (->rep_scheme 0 14)]
>:l-sit [(->duration 0 0 10)]}})
>
> val: {[2015 6 31] {:chinups [#v.scratch.lift_tracker.rep_scheme{:weight 0, 
> :repetitions 13} #v.scratch.lift_tracker.rep_scheme{:weight :x, 
> :repetitions 13}], :l-sit [#v.scratch.lift_tracker.duration{:hours 0, 
> :minutes 0, :seconds 10}]}, [2016 6 31] {:chinups 
> [#v.scratch.lift_tracker.rep_scheme{:weight 0, :repetitions 13} 
> #v.scratch.lift_tracker.rep_scheme{:weight 0, :repetitions 14}], :l-sit 
> [#v.scratch.lift_tracker.duration{:hours 0, :minutes 0, :seconds 10}]}} 
> fails spec: :v.scratch.lift-tracker/history predicate: (coll-checker (tuple 
> :v.scratch.lift-tracker/date :v.scratch.lift-tracker/workout))
>
> Is there a built in way to automatically recurse the sub-components to 
> identify the problematic scope?
>

I filed an issue about the error messaging for `map-of`: 
http://dev.clojure.org/jira/browse/CLJ-1946 ; might be worth adding a 
note/vote to that.
 

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [ANN] Leiningen 2.7.0

[Chris Price]

The hope for the managed-dependencies stuff is to be able to use it in 
combination with a "parent project" definition, to consolidate version 
numbers for common dependencies.  The support for this will be released in 
the lein-parent[1] plugin, hopefully soon (once the corresponding PR[2] is 
merged), and then once that has some mileage on it it might be worth adding 
some of those capabilities in to core leiningen.

[1] https://github.com/achin/lein-parent
[2] https://github.com/achin/lein-parent/pull/6



On Thursday, August 25, 2016 at 3:06:40 AM UTC-7, Rick Moynihan wrote:
>
> Many, many thanks for this release!
>
> Also the manged-dependencies feature looks like it might be super useful.
>
> R.
>
> On 25 August 2016 at 01:03, Jean Niklas L'orange  > wrote:
>
>> Greetings, fellow Clojurians!
>>
>> I am happy to announce Leiningen 2.7.0! This release contains mostly
>> bugfixes, but two major new improvements were added. There is now a
>> PowerShell version of `lein.bat`, and `:managed-dependencies` has been
>> added to Leiningen.
>>
>> Both improvements should be considered to be in beta, but please try
>> them out and report bugs you find in the GitHub issue tracker. The
>> rationale for `:managed-dependencies` can be found at [1].
>>
>> To replace `lein.bat` with the PowerShell equivalent, download
>> `lein.cmd` [2] and `lein.ps1` [3] in its stead, and run as usual. If
>> you end up with an error related to `Invoke-WebRequest`, then it may
>> be a result of an old version of PowerShell, which seems to be
>> resolved by installing the Windows Management Framework 4.0 [4].
>>
>> The full list of significant user changes:
>>
>> * Add PowerShell script for Windows users. (Brian Lalonde)
>> * Run `:prep-tasks` before `lein test`, so generated test namespaces
>>   will be tested. (Martin Reck)
>> * Better error message when attempting to do `lein run` without
>>   `project.clj`. (Eduardo Seabra Silva)
>> * Add support for `:managed-dependencies`. (Chris Price)
>> * Provide the current clojars certificate. (Toby Crawley)
>> * Add `*eval-print-dup*` to evaluate forms passed to
>>   `eval-in-leiningen` with `*print-dup*`. (Eduardo Seabra Silva)
>> * Update bash completions. (Zack Dever)
>> * Respect `:scm :dir` in `lein vcs` commands. (Ian Kerins)
>> * Improve whitespace handling from `JVM_OPTS`. (Stephen Nelson)
>> * Catch and handle fixture errors during `lein test`. (Alex Hall)
>> * Fix a bug where spaces in directory names on Windows caused crashes.
>>   (Leon Mergen, Tobias Kiertscher, Jean Niklas L'orange)
>> * Fix a bug where `lein search` would take forever downloading
>>   clojars.org. (Paul Dorman)
>> * Retain user defined private repositories when building jars,
>>   uberjars and deploy. (Rick Moynihan)
>> * Honor whitelist settings when `lein javac` is called via `lein jar`.
>>   (Chris Price)
>> * `lein vsc push` for git will now only push branch-related tags.
>>   (Łukasz Klich)
>>
>> Those who have manually installed Leiningen can run `lein upgrade` to
>> pull down 2.7.0. `lein downgrade 2.6.1` will back it down to the
>> previous version if you run into any issues. Keep in mind that the
>> PowerShell script was introduced in this release, hence there are no
>> downgrade candidates for it right now.
>>
>> We have had lots of contributors help out making this release happen,
>> and I'd especially like to thank Chris Price (cprice404) and Florian
>> Anderiasch (winks) for their help with this release.
>>
>> [1]: 
>> https://github.com/technomancy/leiningen/blob/stable/doc/MANAGED_DEPS.md
>> [2]: 
>> https://raw.githubusercontent.com/technomancy/leiningen/stable/bin/lein.cmd
>> [3]: 
>> https://raw.githubusercontent.com/technomancy/leiningen/stable/bin/lein.ps1
>> [4]: 
>> http://social.technet.microsoft.com/wiki/contents/articles/21016.how-to-install-windows-powershell-4-0.aspx
>>
>> -- Jean Niklas
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To

Re: [ANN] Leiningen 2.7.0

[Chris Price]

On Mon, Aug 29, 2016 at 8:22 PM, Ning Sun  wrote:

> There is a minor issue in code example of
> https://github.com/technomancy/leiningen/blob/stable/doc/MANAGED_DEPS.md#
> lein-parent-projects,
> where `inherits` should be `inherit`.
>

Whoops!  Thanks for pointing that out.  I just updated it.



>
>
>
> On 08/25/2016 08:03 AM, Jean Niklas L'orange wrote:
> > Greetings, fellow Clojurians!
> >
> > I am happy to announce Leiningen 2.7.0! This release contains mostly
> > bugfixes, but two major new improvements were added. There is now a
> > PowerShell version of `lein.bat`, and `:managed-dependencies` has been
> > added to Leiningen.
> >
> > Both improvements should be considered to be in beta, but please try
> > them out and report bugs you find in the GitHub issue tracker. The
> > rationale for `:managed-dependencies` can be found at [1].
> >
> > To replace `lein.bat` with the PowerShell equivalent, download
> > `lein.cmd` [2] and `lein.ps1` [3] in its stead, and run as usual. If
> > you end up with an error related to `Invoke-WebRequest`, then it may
> > be a result of an old version of PowerShell, which seems to be
> > resolved by installing the Windows Management Framework 4.0 [4].
> >
> > The full list of significant user changes:
> >
> > * Add PowerShell script for Windows users. (Brian Lalonde)
> > * Run `:prep-tasks` before `lein test`, so generated test namespaces
> >   will be tested. (Martin Reck)
> > * Better error message when attempting to do `lein run` without
> >   `project.clj`. (Eduardo Seabra Silva)
> > * Add support for `:managed-dependencies`. (Chris Price)
> > * Provide the current clojars certificate. (Toby Crawley)
> > * Add `*eval-print-dup*` to evaluate forms passed to
> >   `eval-in-leiningen` with `*print-dup*`. (Eduardo Seabra Silva)
> > * Update bash completions. (Zack Dever)
> > * Respect `:scm :dir` in `lein vcs` commands. (Ian Kerins)
> > * Improve whitespace handling from `JVM_OPTS`. (Stephen Nelson)
> > * Catch and handle fixture errors during `lein test`. (Alex Hall)
> > * Fix a bug where spaces in directory names on Windows caused crashes.
> >   (Leon Mergen, Tobias Kiertscher, Jean Niklas L'orange)
> > * Fix a bug where `lein search` would take forever downloading
> >   clojars.org. (Paul Dorman)
> > * Retain user defined private repositories when building jars,
> >   uberjars and deploy. (Rick Moynihan)
> > * Honor whitelist settings when `lein javac` is called via `lein jar`.
> >   (Chris Price)
> > * `lein vsc push` for git will now only push branch-related tags.
> >   (Łukasz Klich)
> >
> > Those who have manually installed Leiningen can run `lein upgrade` to
> > pull down 2.7.0. `lein downgrade 2.6.1` will back it down to the
> > previous version if you run into any issues. Keep in mind that the
> > PowerShell script was introduced in this release, hence there are no
> > downgrade candidates for it right now.
> >
> > We have had lots of contributors help out making this release happen,
> > and I'd especially like to thank Chris Price (cprice404) and Florian
> > Anderiasch (winks) for their help with this release.
> >
> > [1]:
> > https://github.com/technomancy/leiningen/blob/stable/doc/MANAGED_DEPS.md
> > [2]:
> > https://raw.githubusercontent.com/technomancy/leiningen/
> stable/bin/lein.cmd
> > [3]:
> > https://raw.githubusercontent.com/technomancy/leiningen/
> stable/bin/lein.ps1
> > [4]:
> > http://social.technet.microsoft.com/wiki/contents/
> articles/21016.how-to-install-windows-powershell-4-0.aspx
> >
> > -- Jean Niklas
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To post to this group, send email to clojure@googlegroups.com
> > Note that posts from new members are moderated - please be patient with
> > your first post.
> > To unsubscribe from this group, send email to
> > clojure+unsubscr...@googlegroups.com
> > For more options, visit this group at
> > http://groups.google.com/group/clojure?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> > Groups "Clojure" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> > an email to clojure+unsubscr...@googlegroups.com
> > <mailto:clojure+unsubscr...@googlegroups.com>.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google