You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@etch.apache.org by "Rick Bolkey (rbolkey)" <rb...@cisco.com> on 2009/02/16 18:01:47 UTC
Etch Maven Plugin
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.
2) A user has a dependency containing an etch file, and wants to
generate a binding.
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.
Please let me know if you want any more details/description. I need to
run to a meeting.
Thanks
Rick
Richard R. Bolkey
Cisco Systems, Inc
d: +1-512-336-3322
e: rbolkey@cisco.com <ma...@cisco.com>
Re: Etch Maven Plugin
Posted by "scott comer (sccomer)" <sc...@cisco.com>.
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: etch-dev@incubator.apache.org
>> 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>
>
>
RE: Etch Maven Plugin
Posted by "Rick Bolkey (rbolkey)" <rb...@cisco.com>.
> From: Scott Comer (sccomer)
> Sent: Monday, February 16, 2009 12:44 PM
> To: etch-dev@incubator.apache.org
> 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>
Re: Etch Maven Plugin
Posted by scott comer <sc...@cisco.com>.
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.
>
RE: Etch Maven Plugin
Posted by "Rick Bolkey (rbolkey)" <rb...@cisco.com>.
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.
Re: Etch Maven Plugin
Posted by scott comer <sc...@cisco.com>.
inline.
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?
so what is the different action between these two?
>
>
> 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?
>
>
> Please let me know if you want any more details/description. I need to
> run to a meeting.
>
>
>
> Thanks
>
> Rick
>
>
>
> Richard R. Bolkey
>
> Cisco Systems, Inc
>
> d: +1-512-336-3322
>
> e: rbolkey@cisco.com <ma...@cisco.com>
>
>
>
>
>