[Dev] Crates

Tue Jul 17 01:40:52 CDT 2007

It must be the legacy sweep which is tripping me up.  I pulled
org.ziptie.client.scheduler out of the client crate, and put it into a
stubs.crate.  I then changed the build.xml (locally) to build the
stubs.crate, but I didn¹t tell the build of the client.crate anything about
the org.ziptie.client.scheduler bundle or the stubs.crate.  I was expecting
a compilation failure, but didn¹t get one.  Am I correct in assuming that
was because of the sweep?

Thanks
-Brett

On 7/17/07 1:36 AM, "Leo Bayer" <lbayer at alterpoint.com> wrote:

> The "sweep" of the directory is there for legacy reasons and can easily be
> removed without adverse effects.  Previously the dependencies were sorted out
> based on what the build discovered and placed in a "dependency-feature".  This
> is no longer necessary and is no longer done.
> 
> But still, the dependencies you speak of still should be explicit.  Whether
> the bundle dependency is through a package import or a require the dependency
> should still be listed in the crate.
> 
> Again the "client" crate /is/ the stub crate.  It should have no dependencies
> on the server (yet contain code generated from the server interfaces).  The
> "UI" bundle can nicely be explicitly dependent on the requisite "client"
> bundle.
> 
>  - Leo
> 
> 
> -----Original Message-----
> From: dev-bounces at ziptie.org on behalf of Brett Wooldridge
> Sent: Tue 7/17/2007 1:18 AM
> To: ZipTie Development List
> Subject: Re: [Dev] Crates
> 
> I didn¹t understand how it was possible for ziptie-dist, when processing
> client-bundles, to possibly see bundles not defined in it¹s set of bundles
> OR the target platform.  However, looking at the code of the task itself it
> appears we just sweep up everything in the directory above the build (i.e.
> all bundles) and put them in the resolution path for compilation.  IMHO is
> this a lot worse than what you called ³injected dependencies².  These are
> ³coincidental dependencies².  Injected dependencies would at least be
> explicit.  There is no guarantee that the client bundles aren¹t happily
> resolving classes exported by server bundles, but which have no way of being
> present on the client at runtime.  The compilation will succeed but the
> execution will fail.
> 
> I would much rather see a strict build in which only bundles specified to
> ziptie-dist combined with the bundles from the target platform are present
> for resolution.  In the case of the stub bundles and the client bundles, the
> stub bundles would have to explicity defined to the ziptie-dist task
> performing the client bundle build, or picked up via inter-crate dependency
> (the client crate defining a depenency on the stubs crate).  It was my
> assumption that it was doing this, which is perhaps the cause of the
> misunderstanding of the original question.
> 
> -Brett
> 
> On 7/17/07 12:44 AM, "Leo Bayer" <lbayer at alterpoint.com> wrote:
> 
>> > The build doesn't support injected dependencies and I don't think it
>> should.
>> >
>> > Assuming that "client" bundles aren't the same as "ui" bundles (the
>> difference
>> > between o.z.client and o.z.ui).
>> > Currently the client bundles contain the stubs (that is their purpose) so
>> > there shouldn't be a build classpath issue.  The UI bundles can either
>> > directly depend on the client bundles or use a Pacakge-Import, it really
>> > doesn't matter.
>> >
>> > If you need to include a crate in the build you just add it to the list of
>> > crates/features/plugins to build in the component.properties.
>> >
>> >  - Leo
>> >
>> >
>> > -----Original Message-----
>> > From: dev-bounces at ziptie.org on behalf of Brett Wooldridge
>> > Sent: Tue 7/17/2007 12:42 AM
>> > To: ZipTie Development List
>> > Subject: Re: [Dev] Crates
>> >
>> > So is there something that I need to do to get the bundles defined in the
>> > ³stubs crate² into the (build) classpath of the ³client bundles²?  The stub
>> > bundles are external to the client bundles in the same way that the target
>> > platform bundles are.  Except we have a way to specify the target platform
>> > to the ziptie-dist and task.  I don¹t know how to specify additional
>> > non-target platform bundles to ziptie-dist so the client build doesn¹t fail
>> > with unresolved classes.
>> >
>> > Clear?
>> >
>> > -Brett
>> >
>> > On 7/17/07 12:35 AM, "Leo Bayer" <lbayer at alterpoint.com> wrote:
>> >
>>>> >> > I'm not sure what the question is.  As far as the build is concerned a
>>> >> crate
>>>> >> > is just a list of bundles.
>>>> >> > Once the build reads the crate to see which bundles it declares it
>>>> doesn't
>>> >> do
>>>> >> > anything with crates again (except for some stuff for versioning but
that
>>> >> is
>>>> >> > another story).
>>>> >> >
>>>> >> >  - Leo
>>>> >> >
>>>> >> >
>>>> >> > -----Original Message-----
>>>> >> > From: dev-bounces at ziptie.org on behalf of Brett Wooldridge
>>>> >> > Sent: Mon 7/16/2007 11:55 PM
>>>> >> > To: ZipTie Development List
>>>> >> > Subject: [Dev] Crates
>>>> >> >
>>>> >> > Leo,
>>>> >> >   Ed was asking about a separate ³crate² definition for Axis generated
>>>> >> > client stubs (org.ziptie.client.adapters, org.ziptie.client.scheduler,
>>>> >> > etc.).  I think we talked about it last week.  The build order would
go:
>>>> >> >
>>>> >> > Server crate
>>>> >> > Stub crate
>>>> >> > Client crate
>>>> >> >
>>>> >> > If I remember correctly, ³inter-crate² dependencies are not handled
>>>> right
>>>> >> > now.  So I don¹t know what needs to happen to make the ³client crate
>>>> build²
>>>> >> > see the bundles generated by the ³stub crate build².  Is this a
>>>> >> > straightforward change to the crate builder?  As I¹m starting to add
more
>>>> >> > SOAP stub generation I¹m wanting to get this build stuff where it¹s
>>>> going
>>> >> so
>>>> >> > I don¹t have to revisit it too soon.  Thoughts?
>>>> >> >
>>>> >> > -Brett
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> >
>>>> >> > _______________________________________________
>>>> >> > Dev mailing list
>>>> >> > Dev at ziptie.org
>>>> >> > http://mailman.ziptie.org/listinfo/dev
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Dev mailing list
>> > Dev at ziptie.org
>> > http://mailman.ziptie.org/listinfo/dev
> 
> 
> 
> 
> 
> _______________________________________________
> Dev mailing list
> Dev at ziptie.org
> http://mailman.ziptie.org/listinfo/dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ziptie.org/pipermail/dev/attachments/20070717/d3d0ffb5/attachment-0001.html 