hmmm. i'd prefer inline, but it is getting too messy:
inputs and outputs:
if foo.etch mixes in bar.etch and bar.etch include snort.etchinc (the
official suffix for
etch include files, btw, though any suffix works), those are all inputs. but
there is no way to know that list without compiling foo.etch. you cannot
really
optimize etch activities without knowing that list. a compiler option
could be
added to write a file which contains a list of compiler options, inputs, and
outputs for a given compile. the maven plugin could then decide whether
anything
needed to be done based on that list. or, perhaps, the etch compiler
itself could use
the list to decide if anything needed to be done. then the ant builds
and ide integration
could benefit, as well.
etch -a .foo.dep ...
if foo.dep exists (in the output directory specified by -d) and if all
the compiler
options were the same and the inputs were present and unchanged and the
outputs
were present and newer than the inputs, do nothing.
acquiring sources
i've always wanted to be able to say something like this:
etch ... -I
http://svn.apache.org/repos/asf/incubator/etch/releases/release-1.0.2
services/ns/NameService.etch
and have etch know how to search that public repository for inputs.
you'd still
want it to keep a local shadow copy of everything that it found, much
like maven.
certainly there is some duplication / overlap with what maven does, but
i cannot
see how maven could do this for me in their current model. again, if
etch does it
then all build systems and ides can share in the fun.
of course, there could / should be a way to search a repository of
publish interfaces
by fully qualified service name
(org.apache.etch.services.ns.NameService) instead
of by path. where? how? who?
scott out
Rick Bolkey (rbolkey) wrote:
From: Scott Comer (sccomer)
Sent: Monday, February 16, 2009 12:44 PM
To: [email protected]
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
i
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
specifies.
Here's an example plugin configuration using the defaults:
<plugin>
<groupId>org.apache.etch</groupId>
<artifactId>etch-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>etch</goal>
</goals>
</execution>
</executions>
<configuration>
<sourceFile>Foo.etch</sourceFile>
</configuration>
</plugin>
Here's a verbose one overriding all the defaults:
<plugin>
<groupId>org.apache.etch</groupId>
<artifactId>etch-maven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>etch</goal>
</goals>
</execution>
</executions>
<configuration>
<sourceFile>foo/Foo.etch</sourceFile>
<outputDirectory>${project.build.directory}/generated-sources/etch2</out
putDirectory>
<what>SERVER,CLIENT,MAIN</what>
<ignoreGlobalWordsList>false</ignoreGlobalWordsList>
<ignoreLocalWordsList>false</ignoreLocalWordsList>
<userWordsList>src/main/etch/Test5WordsList.kwd</userWordsList>
<includePath>src/main/etch/include</includePath>
<ignoreIncludePath>false</ignoreIncludePath>
<mixinOutputDirectory>${project.build.directory}/generated-sources/etch-
mixin</mixinOutputDirectory>
<noMixinArtifacts>false</noMixinArtifacts>
<noFlattenPackages>false</noFlattenPackages>
<quiet>false</quiet>
<binding>csharp</binding>
<templateOutputDirectory>${project.build.directory}/generated-sources/et
ch-template
</templateOutputDirectory>
<home>${env.ETCH_HOME}</home>
<testing>false</testing>
<sourceDirectory>${basedir}/src/main/etch</sourceDirectory>
<sandboxDirectory>${project.build.directory}/etch-sandbox2</sandboxDirec
tory>
</configuration>
</plugin>
