etch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Bolkey (rbolkey)" <>
Subject RE: Etch Maven Plugin
Date Mon, 16 Feb 2009 19:47:19 GMT
> From: Scott Comer (sccomer)
> Sent: Monday, February 16, 2009 12:44 PM
> To:
> Subject: Re: Etch Maven Plugin
> why introduce the idea of two use cases unless there is an actual
> difference?

There is a difference in the intention of the developer.  They have
their own etch source file, or they want it from somewhere else (a
dependency).  Which is also why I should probably split the plugin into
three goals instead of having one all encompassing goal as I have
mentioned. One goal that compiles, one that retrieves .etch source from
dependencies, and a third that encompasses both.

> i see the two use cases being:
> 1) i want to do what i'm doing and publish a .etch file.
> 2) i want to do what i'm doing and consume a .etch file.

The plugin would only deal with (2) above.  (1) would simply be
producing a package containing resource files, and maven can do that
without the need of an extra plugin.

> that is, developer or consumer. as a developer or consumer i may
> be making a listener, a client, or both.
> as to the optimization point:
> the maven plugin should not invoke the compiler if the etch built
> artifacts are up
> to date with the .etch source. maybe that's what you were saying, but
> didn't
> get it. this is a necessarily resource recursive operation. asking the
> programmer
> to say seems wrong and fraught with confusion.

That's basically it.  Similar the javacc plugin, the ephemeral files
that etch creates are placed under the target directory by default, and
thus will be removed whenever a user cleans their project.  If the user
hasn't cleaned the project, no need to regenerate.

> this begs the question: what are the sources and artifacts of a given
> compile?

May need to define those terms better for me within this scope.  But
sources are just the .etch and .txt files.  Artifacts (want to be
careful with that term because Maven uses the term artifact to describe
dependencies at times, and I don't think we're doing so)  are "what"ever
binding (client,server,listener,etc) that the plugin parameter

Here's an example plugin configuration using the defaults:


Here's a verbose one overriding all the defaults:


View raw message