Latest?

[eugene yokota]

Hi,

I wanted to update my g8 template to point everyone to Sonatype public, and got confused about what the latest giter8 is.

First 0.3.0 plugin didn't work, so I went to ls.implicitly and typed in giter8:

- http://ls.implicit.ly/n8han/giter8#giter8-plugin

It says addSbtPlugin("net.databinder.giter8" % "giter8-plugin" % "0.4.0"). That didn't work.

Next, I went to check Sonatype public, etc, and figured out that it's likely 0.3.2.

The readme says 0.3.1.

-eugene

[Nathan Hamblen]

ls.implict.ly is right about giter8 and wrong about giter8-plugin. I
guess I synced up both when I shouldn't have.

This has always been a question with giter8 and other projects that have
a corresponding plugin: should the plugin version number match the
projects? Often they have different development cycles, and for good reasons

Complicating this is the fact that I am not set up to publish to the new
plugins repository and will not have time to do that before nescala. So,
I can't publish an 0.4.x giter8-plugin the normal way. We are in limbo.

Since source dependencies seem to work well enough for plugins (e.g.,
Mads and pamflet-plugin) I'm inclined to switch over to that for giter8.
This will allow it to have more fluid releases. Like, right now.

We could update the readme pretty easily, and the g8 template. ls will
still have the wrong information. Perhaps Doug would be interested in
adding an option to say that a plugin is distributed as a source
dependency only, so that he can provide appropriate sample code.

Nathan

[eugene yokota]

Thanks to conscript, the users of g8 app shouldn't have to worry too much about the version

unless something breaks. `g8 --version` doesn't tell which version they are on,

so that's an issue on its own.

The plugin users on the other hand need to be aware since they manually type in the version number.

Normally I'd expect some implied relationship when a pulgin is named after a project,

like pamflet-plugin 0.4.0 will make a pamflet using 0.4.0 engine.

But giter8-plugin doesn't share anything, so it might not matter much as long as it's documented.

I have access to the sbt community plugins repo, if that's where you want to 

publish the plugin. I'm ok with source dep too in this case.

I like using plugins as library to make another plugin, so generally I prefer having the jar.

-eugene

[Nathan Hamblen]

On 02/29/2012 04:04 PM, eugene yokota wrote:
> Thanks to conscript, the users of g8 app shouldn't have to worry too
> much about the version
> unless something breaks. `g8 --version` doesn't tell which version
> they are on,
> so that's an issue on its own.

Yeah. Conscript needs to do something to make it easy to answer version
correctly. I am the worst offender for not actually reporting a version.
I've never implemented it!

> The plugin users on the other hand need to be aware since they
> manually type in the version number.
> Normally I'd expect some implied relationship when a pulgin is named
> after a project,
> like pamflet-plugin 0.4.0 will make a pamflet using 0.4.0 engine.
> But giter8-plugin doesn't share anything, so it might not matter much
> as long as it's documented.

Yeah. It sucks to publish new binaries that are exactly the same just to
keep the versions in sync, but it is confusing. Another nice thing about
tags is we can push many tags for exactly the same HEAD.

> I have access to the sbt community plugins repo, if that's where you
> want to
> publish the plugin. I'm ok with source dep too in this case.
> I like using plugins as library to make another plugin, so generally I
> prefer having the jar.

Right, and if this plugin is a source dependency then yours has to be
one too, which you don't want.

How about this: giter8-plugin changes its documentation to recommend use
as a source dependency, and I'll make an effort to push tags that
correspond to the giter8 versions. However, you can take over publishing
the artifacts that you want to use as a library from other plugins. You
can publish them however and whenever you want. And if the community
repo won't let you publish them under the net.databinder groupId (I
wouldn't mind, obviously) you can use a different one. I don't think it
matters that much what the groupId is, as long as it's documented.

Nathan

[eugene yokota]

On Wednesday, February 29, 2012 10:13:03 PM UTC-5, n8han wrote:

How about this: giter8-plugin changes its documentation to recommend use
as a source dependency, and I'll make an effort to push tags that
correspond to the giter8 versions.

+1

 

However, you can take over publishing
the artifacts that you want to use as a library from other plugins. You
can publish them however and whenever you want.

this sounds good too.

-eugene

 

[n8han]

I was hoping to get this sorted out this weekend, and I could really use giter8-plugin it for testing the Unfiltered templates I'm working on, the situation is worse than I remembered.

giter8 doesn't have a library project and the plugin doesn't depend on the app, it just implements its own templating. This was not a big deal it was just a call to StringTemplate / Scalasti, but now that templates are more powerful the plugin is in no position to apply them correctly.

To fix this we need to factor template generation out of the app and into a library. I have no idea what dragons lurk there and won't have time to find out until after nescala. Another thing I would like to do, at the same time, is make template preview part of the app itself, so you could run `g8` in the base of a template project to check it out.

For now the only option is to push untested templates to a testing branch and use that handy `--branch` option you added.

Nathan