> James CE Johnson wrote:
>
>>
>>... lots of common stuff like
>>
>>
>>
>> Then in weblogic:ejbdoclet you would have this:
>>
>>
>>... lots of common stuff like
>>
>>
>>
>> How do we avoid duplicating all of the common stuff (ejbdoclet
>> attributes and subtasks) in an easy to
> I guess I'm having trouble figuring out how you would do that cleanly
> without duplicating a lot of jelly script.
>
> In jboss:ejbdoclet you would have this:
>
>
>... lots of common stuff like
>
>
>
> Then in weblogic:ejbdoclet you would have this:
>
>
>... lots of common stuff l
> -Original Message-
> From: Brian Towles [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 31, 2003 5:57 PM
> To: Maven Developers List
> Subject: RE: EJB plugin modification
>
>
>
> On Thu, 2003-07-31 at 03:54, Michal Maczka wrote:
> > IMHO the correct w
> James CE Johnson wrote:
>
>>
>>... lots of common stuff like
>>
>>
>>
>> Then in weblogic:ejbdoclet you would have this:
>>
>>
>>... lots of common stuff like
>>
>>
>>
>> How do we avoid duplicating all of the common stuff (ejbdoclet
>> attributes and subtasks) in an easy to
On Thu, 2003-07-31 at 03:54, Michal Maczka wrote:
> IMHO the correct workflow which should be supported by ejb plugin looks
> like follows:
>
> a) gather all the files which will be packaged in ejb-jar in one place
> (equivalent of war:webapp)
> b) archive this directory (equivalent of war:war
James CE Johnson wrote:
>
>... lots of common stuff like
>
>
>
> Then in weblogic:ejbdoclet you would have this:
>
>
>... lots of common stuff like
>
>
>
> How do we avoid duplicating all of the common stuff (ejbdoclet attributes
> and subtasks) in an easy to maintain way?
>
>
>>
>> Do you want to have a jboss:ejbdoclet and a weblogic:ejbdoclet goal
>> when both of them are going to be 80% the same?
>>
>
> Yeap! I would like to see them as two separate projects.
I guess I'm having trouble figuring out how you would do that cleanly
without duplicating a lot of jelly
>
> Do you want to have a jboss:ejbdoclet and a weblogic:ejbdoclet goal when
> both of them are going to be 80% the same?
>
Yeap! I would like to see them as two separate projects.
AFAIK XDoclet team (I know this from mailing lists not from developers) is
not going to maintain as many plugin a
>>
>> a) Because it can generate code for multiple appservers it doesn't
>> make
>>sense to invoke it in a container-specific plugin.
>>
>
> IMHO it does make sense.
But my point is that the task is *mostly* the same for any
appserver. Its only when you add the subtasks that it gets appserve
> -Original Message-
> From: James CE Johnson [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 31, 2003 2:44 PM
> To: [EMAIL PROTECTED]
> Subject: RE: EJB plugin modification
>
> Hi Michal,
>
> My $.02 worth... I'm biased towards invoking xdoclet
Hi Michal,
My $.02 worth... I'm biased towards invoking xdoclet, however, which is a
slightly different focus than Brian (I think) so my replies may not be
100% compatible with yours.
> Hi Brian!
>
> I don't like the idea of making fatter ejb:plugin
> and putting there a logic which is particula
> From: Brian Towles [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 31, 2003 7:31 AM
> To: Maven Developers List
> Cc: [EMAIL PROTECTED]
> Subject: Re: EJB plugin modification
>
> Helps if I attach what I say im going to..
>
> On Thu, 2003-07-31 at 00:28, Brian
Helps if I attach what I say im going to..
On Thu, 2003-07-31 at 00:28, Brian Towles wrote:
> On Wed, 2003-07-30 at 17:56, James CE Johnson wrote:
> > 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
On Wed, 2003-07-30 at 17:56, James CE Johnson wrote:
> 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
>
> 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) a
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 o
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 ma
Heya,
> Howdy all
>
> I have been working a major change to the ejb plugin for better use
> internally on my stuff and what to get your feedback and gauge your
> interest in it.
>
> The current ejb plugin uses the jar task, with the main reasoning being
> that the ejbjar task could not import addi
Howdy all
I have been working a major change to the ejb plugin for better use
internally on my stuff and what to get your feedback and gauge your
interest in it.
The current ejb plugin uses the jar task, with the main reasoning being
that the ejbjar task could not import additional files (at leas
19 matches
Mail list logo
