make lazybones embeddable

[tbarker9]

if lazybones were embeddable, it could be used in other build tools.... such as gradle or grails. Relates to #62

[pledbrook]

I guess this shouldn't be too hard. Just need to focus on what LazybonesMain.main() should be doing.

[pledbrook]

Logging is something to be wary of. In other words, how to integrate Lazybones logging into Grails/Gradle/etc. That would probably mean switching to slf4j.

[tbarker9]

I don't think that is unreasonable, their libraries are tiny if I remember. This could improve adoption as well.... hell, maybe the maven zealots could use it to replace those god awful archetypes :smile:; by the next release or two (hell even now) we should have something considerably better.

[tbarker9]

I would assume we would have to split LazybonesMain.main() from a class that actually does all the work. I think this is almost already done since you split out the commands into separate classes. Maybe using lazybones in embedded mode means just using the commands? If that is the case, then all we need to do is use slf4j and deploy it as a jar to bintray.

[pledbrook]

I had a quick look. LazybonesMain currently consists of:

• Loading the user configuration file
• Parsing the arguments
• Initialising the logging
• Executing the relevant command

So it's already purely focused on the command-line execution aspects. I suspect we can make the commands themselves slightly easier to invoke from other tools, but that's all they really need to do.

I'll have to look at how Groovy's @SLF4J annotation determines which implementation to use. I guess the app can just include the slf4j-jdk14 adapter JAR. Of course the other thing that needs to happen is that the lazybones-*.jar needs to be published...and some other integration tests added.

[tbarker9]

I would vote to leave the logging almost as is and use slf4j-jdk14 adapter. As a first cut I would just get it usable and worry about refactoring the commands later, and of course write integrated tests to make sure the standalone commands work as expected.

[tbarker9]

Could we have a thin wrapper around the command line calls and fork runs of lazybones commands? The wrapper could be a jar that would download the lazybones distribution and delegate calls to it and log its output. This would help us continue to develop on lazybones as is without getting crazy, while allowing tools like griffon, grails and IDEs use it directly in their products without any dependency hell.

[shamoh]

+1 Our team would like to also integrate great lazybones tool to our command line developer console.

I would appreciate a public API to do following operations:

• list all projects from specified bintray repository
• option to create new project from different local templates cache (from our developer console)
• invoke create command programatically

Thanks.

[anorakgirl]

I would love this too! Is the lazybones-app as is available as a dependency somewhere? I am calling LazybonesMain.main() from within my (prototype) app at the moment so would be nice to have the dependency management.

[pledbrook]

@anorakgirl Not at the moment, sorry. It should be fairly easy to update the build to publish the JAR as well as the application distribution.

I doubt I will tackle this in the near future, but what I will do is push my current local refactoring branch to GitHub and discuss here what changes I'd like to see made and the current challenges.

[pledbrook]

You can find the initial work on the embeddable branch. The idea is to have a high level API based on LazybonesService that works in a similar way to the command line. The lower level API consists of:

• PackageSourceManager - represents a collection of repositories that contain Lazybones packages and the metadata associated with them.
• PackageSource - a repository for packages. By default this is a Bintray repository, but it may be possible to expand this later.
• PackageCache - handles the local Lazybones cache for packages.
• TemplateInstaller - installs a Lazybones package, given its location. Should handle sub-templates too.

The refactoring didn't seem terribly difficult until I started thinking about repositories and how to search them. Another significant factor is how to handle large repositories. The API currently allows you to fetch all templates from all repositories, but what if this reaches 10s of thousands or more? I'm guessing pagination should be added.

This then highlighted the weakness of the Bintray API. When listing all packages, you can't get much package information. Just the name really. But that's not particularly useful. Ideally you want to fetch latest version, other versions, descriptions, etc.

You have far more control when using Bintray's 'search' endpoint, but that requires an API key. It doesn't make sense to include that in the application though as it will be easily discovered. So I started thinking about an intermediate server app that sits between the Lazybones command line app and Bintray. That could hold the API key. At this point, I decided it was beginning to sound like a lot of work :smile:

Anyway, that's the current status.

[anorakgirl]

Sorry I somehow only just came across your reply, sorry for not even responding :( I'm not working on that project any more (and a bit snowed under), but it'd be nice to get chance to come back to this at some point.

[pledbrook]

@anorakgirl No worries. I've pushed an updated embeddable branch with the changes I made earlier this year. The broad outline of the API is in place. The devil is in the detail, and much of my time was spent on the unit tests for the API implementation. There's still plenty to do and I have very little time in the foreseeable future, so any help would be appreciated.

[jonbullock]

Oooh I'd be interested in this for JBake as well.