>
> On Wed, 2003-07-30 at 13:59, James CE Johnson wrote:
> > >
> > > My main issue with the current ejb:ejb goal was that a completly
> > > seperate class/directory structure had to be setup in order to pull in
> > > the appropriate deployment descriptors (ejb-jar.xml, jboss.xml,
> > > jaws.xml) as well as any other files.
> >
> > Well, we're using xdoclet to generate all of those anyway so they end up
> > in target/xdoclet/whatever. I just set maven.ejb.src to look there rather
> > than its default src/ejb and I'm happy.
>
> Im actually using xdoclet as well but doesnt the maven.ejb.src have to
> point to the classes that are generated form the compile?
I *think* I've set maven.ejb.src to point to target/xdoclet/ejb where
the ejb-jar.xml and such are generated. (I'm at home now and can't
easily get to the source at the office.) However, I'm also doing a
maven:addPath after invoking ejbdoclet in order to add
target/xdoclet/java to the java:compile build path.
Erm... not sure that actually answered your question though...
> Im my case im
> trying to be flexable to allow a ejb jar and a non ejb jar to be
> generated from the same project. Not having to seperate compiled
> classes out from a single build location is a plus for me.
I agree. maven's mode of operation, however, is one artifact per
(sub)project. I generally try to work within that philosophy but there
are times when it doesn't work for me. For instance, in one subproject
we create foo.jar that contains the EJBs; foo.ear that contains foo.jar
and all of its dependencies; foo-client.jar that has only the classes
needed by clients of the ejb; foo-mock.jar that contains
mockdoclet-generated classes that other subprojects can use in their
unit tests. To me, that seems reasonable since all of the artifacts
come from the same set of sources and are, in some way, related.
>
> >
> > >
> > > As well the current ejb:ejb goal has no support for the vendor specific
> > > subtasks which do things like run ejbc for weblogic, setup various DB
> > > tasks for web sphere, and run rmic to create the rmi interfaces for some
> > > app servers.
> >
> > Good point.
> >
> > We're actually setup this way:
> >
> >
> > <goal name="ejb-compile" prereqs="ejb-ejbdoclet, java:compile"/>
> >
> > <goal name="ejb-resources" prereqs="java:jar-resources"/>
> >
> > <goal name="ejb-jar" prereqs="ejb-compile, ejb-resources, ejb:ejb"/>
> >
> > Our 'ejb-ejbdoclet' goal fires xdoclet's ejbdoclet task to generate
> > various things and wraps up with
> >
> > <path id="gen.java.compile.src.set"
> > location="${maven.build.dir}/xdoclet/java"/>
> >
> > <maven:addPath id="maven.compile.src.set"
> > refid="gen.java.compile.src.set"/>
> >
> > I suppose our use of xdoclet is similar to your use of ejbc.> On Wed, 2003-07-30
> > at 12:49, James CE Johnson wrote:
> > >
> > >> >
> > >> > -using the ejbjar task and all attributes
> > >> > -all attributes defineable via properties
> > >> > -ability to bundle pom defined ejb.bundle artifacts
> > >>
> > >> Don't forget ejb.manifest.classpath too.
> > >
> > > Yeah its doing manifest generation with the manifest class path same
> > > code for that part thats in the current version.
> > >
> > >>
> > >> > -ability to bundle other files based on support file sets defined in
> > >> properties
> > >> > -supports the dtd redirection of ejbjar
> > >>
> > >> That sounds cool. Be sure you have a mechanism for excluding files
> > >> from the final jarfile also. For instance, we have log4j.properties
> > >> end up in our target/classes (for good reasons) but, of course, we
> > >> don't want that to end up in the actual jarfile. (I posted a patch to
> > >> jira earlier today to enhance ejb:ejb to do exclusions.)
> > >
> > > The way the ant ejbjar tasks works it it pulls the nessesary files for
> > > the ejb by parsing a deployment descriptor (ejb-jar.xml) and only
> > > bundling the nessasary files and (configurably) the direct super
> > > classes/interfaces. The ability to add other files is provided by the
> > > <support> tag in the ejbjar task which is a fileset so you can pull in
> > > or exclude what ever you want.
> > >
> > >>
> > >> > First off is there any real interest in this as an enhancement to
> > >> the ejb plugin? It is a fair departure from the original design is
> > >> why im asking.
> > >>
> > >> We're using ejb:ejb quite happily as-is.
> >
>
> Not really, ejbc for weblogic gens the nessasary rmi stubs for an ejb.
> You still have to have the Home and Remote interfaces already droped
> (via hand or xdoclet) for it. WebSphere, iPlanet, and Jonas all have
> something simalar.
Ah. Not using ejbc so that's new information. We do use WebLogic though
so I'd really like to see what you've got when you're happy with it. I
gather pre-generating the rmi stubs gives you a boost at deployment?
Runtime?
>
> >
> > I think I like the idea of having separate (though related) goals for
> > invoking the code generators versus packaging up the results.
>
> These arnt really code generators, they are jar packagers for the most
> part. They generally are working creating compiled rmi stubs and
> bundling those into the generic ejb jar that the parent task of ejbjar
> creates. It also allows you to create ejb jars for multiple different
> application servers in one shot. Very usful when your trying to do
> builds for serveral different environments.
>
> They cant be sperated form the ejbjar ant task either. They are
> subtasks to it.
Ah. Gotcha. ( Drat, I didn't want to learn anything today! :)
>
>
> > I'm currently trying to factor out our special uses of xdoclet so that I
> > can contribute an ejb:xdoclet goal to the existing plugin. It sounds like
> > that may cooperate nicely with what you're doing also.
>
> This actually interests me a lot, just spent days trying to get my
> ejbdoclet working under maven (fscking webdoclet). Having it integrated
> into the ejb plugin might be very helpful
If I can, I'm going to "generalize" my existing ejb:ejbdoclet goal and
contribute it to the maven-ejb-plugin sometime tomorrow. I was going to
do it today but time got away from me. Like the changes you're proposing
I hope to have *everything* property-parameterized to make it easy for
folks to override the default behavior. We've only used it with jboss,
however, so there will clearly be gaps in my implmentation WRT other
appservers.
>
> >
> > >
> > > The ant ejbjar task has a lot of work put into it to allow it to offload
> > > and automate a lot of the ejb generation tasks. I just feel that this
> > > work should be leverages easily. Kinda what Maven is all about to me.
> >
> > No argument here :-)
> >
> > >
> > >
> > >> >
> > >> > Secondly, ejbjar has the ability to support generation of multiple
> > >> jars based off of diffrent deployment descriptors. It can do one
> > >> per bean with each bean having its own descriptior. It can do one
> > >> per bean from the main ejb-jar.xml file. It can do one jar with all
> > >> the beans and a single descriptor. And it can even do one jar per
> > >> bean based off of the name of the directory its in.
> > >>
> > >> That sounds like serious overkill. At least for the things we do here.
> > >> Of course, everybody has a different use-case :-)
> > >
> > >
> > > Yeah for me to. We only use jboss which has the simplest of cases for
> > > ejb generation, But one of the manin goals of Maven as I see it is to
> > > allow for virtually transparent usage of Ant without all of the
> > > build.xml. These capabilities are in Ant now, why not let the end user
> > > deside what level that want to take it to.
> > >
> > >>
> > >> >
> > >> > How should this sort of thing be supported under the deploy and
> > >> install mechanism? Is there any other plugin which faces this port
> > >> of problem i can use as a guide?
> > >
> > > Thanks
> > > -=Brian
> > >
> > >
> > > --
> > > Brian Towles <[EMAIL PROTECTED]>
> --
> Brian Towles <[EMAIL PROTECTED]>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
