incubator-etch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "scott comer (sccomer)" <scco...@cisco.com>
Subject Re: Etch Maven Plugin
Date Tue, 17 Feb 2009 15:02:48 GMT
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>
>
>   

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message