m2: geronimo-packaging-plugin

[anita kulshreshtha <a_...@yahoo.com>]

David J,
   This is one of goals from the packaging plugin. I
need some insight into this :
<goal name="car:prepare-plan" description="Add
dependencies to a plan and process with velocity">
<car:dependencies artifacts="${pom.artifacts}"
targetDir="${geronimo.packaging.buildDir}"
sourceDir="${geronimo.packaging.srcDir}"
planFile="${geronimo.packaging.planFile}"
targetFile="${geronimo.packaging.buildFile}"
context="${context}"/>
</goal>
    Is this still needed?

Thanks
Anita

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: m2: geronimo-packaging-plugin

[anita kulshreshtha <a_...@yahoo.com>]

David,
    Thanks! more comments inline..

--- David Jencks <da...@yahoo.com> wrote:

> 
> On Mar 21, 2006, at 7:13 AM, anita kulshreshtha
> wrote:
> 
> > David J,
> >    This is one of goals from the packaging plugin.
> I
> > need some insight into this :
> > <goal name="car:prepare-plan" description="Add
> > dependencies to a plan and process with velocity">
> > <car:dependencies artifacts="${pom.artifacts}"
> > targetDir="${geronimo.packaging.buildDir}"
> > sourceDir="${geronimo.packaging.srcDir}"
> > planFile="${geronimo.packaging.planFile}"
> > targetFile="${geronimo.packaging.buildFile}"
> > context="${context}"/>
> > </goal>
> >     Is this still needed?
> 
> In principle, yes.  It may be necessary to hard-code
> the dependencies/ 
> imports until the transitive dependencies of all
> modules are further  
> stabilized.
    IIUC, you are saying that when all the transitive
dependencies are sorted out, maven would give us the
correct set of artifacts for constructing the
classloader. I think that the packaging-plugin will
always be needed to map geronimo concepts, e.g. import
and include to maven dependencies. I am using
geronimo-gbean-deployer and j2ee-system configs as an
example to figure out what needs to be done. Is there
a better approach? 
I agree with your earlier comments
http://issues.apache.org/jira/browse/GERONIMO-1677#action_12370672
    I need to think how all this ties together. Is
there any work being done on the DAGclassloader? 
> 
> This is likely to have a problem similar to the
> dependency plugin,  
> but I haven't thought through whether or not it
> actually does :-)  I  
> would start by including all dependencies and
> sorting them into  
> imports and dependencies based on their type. 
    Since none of the configs have geronimo.include
property. I might be able to get away by using
type=car for geronimo.import and use scope(provided?)
somehow to get the right dependencies. But eventually
we will have to deal with includes. 
 If
> this gets too far  
> from what the  m1 plugin generates we could check in
> the dependencies/ 
> imports from the m1 output and revisit this when we
> merge 1.1 into  
> trunk.
     If there is an urgency to move to m2, we could
check in all the things
dependencies/imports/geronimo-service.xml. I would
like to know more about the work being done in 1.1 and
  its availability.

Thnaks
Anita
> 
> thanks
> david jencks
> 
> >
> > Thanks
> > Anita
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> protection around
> > http://mail.yahoo.com
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: m2: geronimo-packaging-plugin

[David Jencks <da...@yahoo.com>]

On Mar 21, 2006, at 7:13 AM, anita kulshreshtha wrote:

> David J,
>    This is one of goals from the packaging plugin. I
> need some insight into this :
> <goal name="car:prepare-plan" description="Add
> dependencies to a plan and process with velocity">
> <car:dependencies artifacts="${pom.artifacts}"
> targetDir="${geronimo.packaging.buildDir}"
> sourceDir="${geronimo.packaging.srcDir}"
> planFile="${geronimo.packaging.planFile}"
> targetFile="${geronimo.packaging.buildFile}"
> context="${context}"/>
> </goal>
>     Is this still needed?

In principle, yes.  It may be necessary to hard-code the dependencies/ 
imports until the transitive dependencies of all modules are further  
stabilized.

This is likely to have a problem similar to the dependency plugin,  
but I haven't thought through whether or not it actually does :-)  I  
would start by including all dependencies and sorting them into  
imports and dependencies based on their type.  If this gets too far  
from what the  m1 plugin generates we could check in the dependencies/ 
imports from the m1 output and revisit this when we merge 1.1 into  
trunk.

thanks
david jencks

>
> Thanks
> Anita
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com