----- Original Message ----- > >>
> >> * Using <support> means every file that one puts in the <support>
> >> fileset ends up in every EJB .jar file
>
> >Yep. It isn't ideal. I'm not sure the best way to have a task which
> >processes multiple beans but which allows the <support> classes
> >to vary by bean.
>
> Yes, I realised that if I did think this was "the end of the world" I
could
> always use the <include><exclude> mechanism to filter by deployment
> descriptor and write a separate <ejbjar><support/></ejbjar> for each bean
or
> group of beans to limit the repetition. Probably worthwhile on a truly
> largescale project with a *lot* of classes.
>
tedious to say the least and defeats the benefits of the ejbjar task's
ability to process a number of beans. :-)
> I know its mentioned in the documentation in the preamble, but I don't
think
> the docs explicitly state that these elements are supported on ejbjar? At
> least, they're not listed alongside the <dtd> element etc?
True. The examples I think make it pretty clear but an explicit statement
would be good.
>
> OK, it should be possible to use the <depend> code to find the closure
> of support classes to make the resulting ejb-jar "whole".
>
> Is this something you intend to pursue? ant being able to build JARs that
> are "as slim as possible" for you would be something worth shouting from
the
> rooftops.
Yes, I will look at it when I finish some other experiments.
>
> The problem I see is whether you'd want ot include the Home and Remote
> interfaces of other beans. While these might be requires to make things
> compile, automatically including them could lead people down the wrong
path
> conceptually. As the Sun documentation points out, its entirely valid to
> create a pair of ejbs, or a much more complex cycle, which are circularly
> dependent on each other. At this point the concept of trying to deploy
one
> of the ejbs in the cycle without the others becomes meaningless. You can
> break the cycle in order to get things deployed, but it'll never run
right.
> In this case, it makes more sense to indicate to people that they should
> build a .jar with all of the mutally dependent beans in it than it does
to
> include only the Home and Remote interfaces merely to make it compile.
Yes, or some other warning which says the other bean should be included in
the jar.
About your ejbreport concept - I like that. How about giving the task a
whole stack of deployment descriptors and it finds some optimal way of
packaging this up into deployable units, combining the deployment
descriptors where possible. Probably too automated :-)
I'm going to give the <support> stuff a lot more thought.
Conor
