geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From anita kulshreshtha <a_kuls...@yahoo.com>
Subject Re: Questions about the packaging plugin
Date Mon, 10 Apr 2006 14:05:47 GMT
Jacek, and others
   I have been thinking about what to include in the plan.xmls that
will provide an overview of the dependencies needed by a configuration.
Earlier I was leaning towards only listing the direct dependencies, but
that would not be a great documentation! For example in system
configuration in addition to listing
1. geronimo-kernel,    
2. geronimo-system, and
3. geronimo-common
   we should also list mx4j, log4j, commons-logging, and cglib. Maven1
list is very close to this. 
    To achieve this the config's pom.xml would only include 1, 2, 3. If
a configuration has been declared as a parent, i.e. it has
geronimo.import set in project.xml, it will be added as a dependency
with 'provided' scope. Thus the plan.xml will not include its
dependencies. If someone wanted to know what dependencies are needed by
the parent, one must look up parent's plan.xml. I will be testing this
next with j2ee-server.   
    The geronimo-gbean-deployer (boot) configuration is a special case.
It will not be listed as <import> in the plans (same as Maven1). To
avoid listing its dependency, it could be added as a plugin dependency.

    If this is the right approach, we can proceed forward with the
conversion of the rest of the configurations. It involves following
steps:
1. Carefully prune the dependencies in the modules. I have done few and
are included in the patch. 
2. A dependency of type 'car' with geronimo.import set goes to pom.xml.
3. geronimo-gbean-deployer (see configs/j2ee-system/pom.xml).
4. Add only geronimo-* dependencies from the project.xml to pom.xml.
5. Use scope as 'provided' in modules (see specs in util/pom.xml) to
avoid a dependency from appearing in a car.
      I am using the above set of dependencies to construct the
classloader for packaging the car. Maven1 is using the same set. Some
of this is likely to change when we actually test the packaging with
the new repository. 
   I am updating the patches to accomplish this. 
   More comments inline..

--- Jacek Laskowski <jacek@laskowski.net.pl> wrote:

> On 4/6/06, anita kulshreshtha <a_kulshre@yahoo.com> wrote:
> > Dain,
> >   Thanks! I need to sort out the dependencies anyway. IIUC,
> currently
> > we are including the dependencies referenced by the plans, i.e. the
> > ones needed  by GBeans. We are including few extra ones. The maven
> > transitive dependency list is very large compared to what we add
> > currently. I think we should only add the dependencies needed for
> the
> > GBeans.For example if we have a GBean :
> > <gbean name="ConfigurationManager"
> >
>
class="org.apache.geronimo.kernel.config.EditableConfigurationManagerImpl">
> >     we should add geronimo-kernel as a dependency.
> 
> Hi,
> 
> I don't know whether it works or not, but I've come up with a weird
> idea. I've been struggling with it for a while and since I could not
> yet test it out I'll describe it here.
> 
> The idea boils down to using the scope - provided - for all our
> modules' dependencies. I do mean 'all'. As transitive dependency
> mechanism doesn't apply in this case  (when the scope is 'provided'),
> it sets up Maven2 not to download other transitive dependencies and
> it
>  *might* mimic the work of M1 that only downloads the dependencies
> listed in the pom (project.xml). We could list all of the
> dependencies
> in the parent pom as compile (default) and override some in the
> modules.
> 
> The caveat is that we will likely duplicate/do the work Maven2 could
> do for us, i.e. maintain the transitive dependencies, but once we
> have
> migrated to M2, we could think about it again how to work it out.
> It's
> a kind of a workaround to finish the migration.
> 
> Does it really seem to be 'weird'? Could it work?
    This should work too. Since we are waiting for the repo, we could
spend some time pruning the dependencies in the modules. We can start
converting the configs as described above and make sure that the
dependency list from m1 and m2 is same. If needed I can submit the
patch to display the list used in m1.

Thanks
Anita
> 
> > Anita
> 
> Jacek
> 
> --
> Jacek Laskowski
> http://www.laskowski.org.pl
> 


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

Mime
View raw message