interface files are always generated (interface files being all
ephemeral files). -w can restrict those to server or client. -w can also
be used to generate main or impl in addition. -w intf is ignored, since
intf is always on. -w all generates everything (impl, main, intf).
if you already have main and impl files, they won't be overwritten
unless you use -w force.
scott out
Rick Bolkey (rbolkey) wrote:
I'm just referring to the ephemeral files---being able to generate interfaces
and plumbing files (Base*, Remote*, Stub*, ValueFactory*) as separate compiler
steps (I thought the INTF what compiler option would do this, but it doesn't).
Motivations (these are very java specific, but I'm sure there are analogies in
other languages):
1) Many projects provide separate reference API (interfaces) and implementation
(stub* et al) packages to provide flexibility in implementation details or to
hide the implementation detail (forcing people to program to interfaces).
this is not supported for etch.
2) Assuming you should program to interfaces, they serve as the public API, and
are useful independently for testing by creating mock objects through libraries
like EasyMock or Mockito.
this is not always possible with etch, since some functions are only
available via the actual objects (_async, _transportBlah). but still,
programming to interfaces is good and that why etch generates separate
interfaces vs. remote, base, or impls.
3) My specific case, I have a service consisting of a number of mixin services,
and each is in their own package. For testing, I was considering a separate
package to launch the listener for each module. Obviously, that launcher needs
the entire binding for the service and mixins. So I ended up with a cycle ....
mixins require launcher (for testing) requires service (for full binding api)
requires mixins (for implementation). One way to break the cycle is to split
the binding as a separate package, which leads back to motivation (1) above.
this explanation doesn't help me. if you've mixed in a bunch of stuff,
you only start the listener (for the top level guy) once. you don't
start listeners for the mixed in guys.
So, this isn't a road blocker (thus minor priority), but I foresee developers
wanting this flexibility.
-----Original Message-----
From: Scott Comer (sccomer)
Sent: Monday, February 09, 2009 8:06 AM
To: [email protected]
Subject: Re: [jira] Created: (ETCH-60) Would be useful for an extra
what option that splits apart generating interfaces and their
supporting classes
not entirely sure what you mean. please explain perhaps with an
example.
etch compiler will already target generated ephemeral files to one
directory while user editable files go to another.
Richard Bolkey (JIRA) wrote:
Would be useful for an extra what option that splits apart generating
interfaces and their supporting classes
---------------------------------------------------------------------
----------------------------------------
Key: ETCH-60
URL: https://issues.apache.org/jira/browse/ETCH-60
Project: Etch
Issue Type: Improvement
Components: compiler
Affects Versions: 1.0.1, 1.0.0, 1.0.2
Reporter: Richard Bolkey
Priority: Minor
A what option on the compiler that could tell languages that support
interfaces to only generate the interface files or only the
implementation files would be helpful for separating those files into
different packages or creating mocks from the interfaces.
