[Dev] Crates

[Brett Wooldridge]

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


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