why introduce the idea of two use cases unless there is an actual
difference?
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.
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 i
didn't
get it. this is a necessarily resource recursive operation. asking the
programmer
to say seems wrong and fraught with confusion.
this begs the question: what are the sources and artifacts of a given
compile?
scott out
Rick Bolkey (rbolkey) wrote:
inline
From: Scott Comer (sccomer)
Rick Bolkey (rbolkey) wrote:
Hi all,
So I've been developing an etch plugin for maven. There are a few
use
cases I had in mind in developing the plugin, so I would like to
present
those as well as go over the general flow of the plugin. I'd
appreciate
some feedback as far as alternative use-cases that could fit within
the
scope of the plugin.
I had two use cases directly in mind.
1) A user has an etch file in their project, and wants to
generate
a binding.
a client or a service implementation?
2) A user has a dependency containing an etch file, and wants
to
generate a binding.
a reference client or service?
The plugin wraps all the command line parameters to the compiler, so I
believe that would be determined on the "what" parameter, unless I'm not
understanding the difference.
so what is the different action between these two?
Isn't a different action between the two use cases, step 2 below handles
them unseen (resolving to the a file within the project vs inside the
sandbox.
Use case #2 service the case if you want to publish an etch file in
an
artifact, and allow different projects to generate binding for it.
Right now the plugin consists of one goal that does the following:
1) Scans through all the compile time dependencies of a
project.
If a dependency contains an etch file, that file along with any
"txt"
files (for inclusions) are extracted to a temporary sandbox under
the
target directory.
2) Plugin then looks for the etch file specified in the plugin
in
the following locations. 1) as an absolute reference, 2) in
"src/main/etch", and 3) in the sandbox where we extracted all the
found
etch files.
3) Generate the binding based on the resolved etch file.
I think I would like to separate steps 1 and 2 above into separate
goals. Also, the plugin currently suppresses generation when it
detects
the binding has already been generated (this can be overridden using
a
"force" parameter.
not sure what you mean here. when / why would you want to suppress?
More of a speed concern. I noticed that my IDE was running the Maven
pre-compile lifecycles whenever I would refresh the project. The plugin
is bound to the generate-sources lifecycle (just like the
javacc-maven-plugin). So, I wanted a way to avoid having to scan
through all the artifacts and generate a binding every time I refreshed
the project, but I figured a 'force' parameter would be good to allow
the developer the option if they want that to happen.
