You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jason Dillon <ja...@planet57.com> on 2007/01/11 20:22:07 UTC

meta-modules to group dependencies

Anyone have any oppinon on creating meta-modules to group  
dependencies that are commonly used together?

For example, in most places where xmlbeans is a dep, so is stax, as in:

     <dependency>
         <groupId>xmlbeans</groupId>
         <artifactId>xbean</artifactId>
     </dependency>

     <dependency>
         <groupId>stax</groupId>
         <artifactId>stax-api</artifactId>
     </dependency>

We could create a meta-module, which simply defines these as  
dependencies, then use the meta-module as a dependency to simplify  
some of the commonly used dependencies.

This could also be used to allow better support for picking up  
versions of dependencies when we build the CTS server for TCK  
testing.  For example, right now we have to include versions for  
openejb and yoko in the CTS build:

    <dependency>
         <groupId>org.apache.openejb</groupId>
         <artifactId>openejb-core</artifactId>
         <version>2.3-incubating-SNAPSHOT</version>
     </dependency>

     <dependency>
         <groupId>org.apache.openejb</groupId>
         <artifactId>openejb-corba</artifactId>
         <version>2.3-incubating-SNAPSHOT</version>
     </dependency>

     <dependency>
         <groupId>org.apache.openejb</groupId>
         <artifactId>openejb-yoko</artifactId>
         <version>2.3-incubating-SNAPSHOT</version>
     </dependency>

     <dependency>
         <groupId>org.apache.yoko</groupId>
         <artifactId>yoko-core</artifactId>
         <version>1.0-incubating-M2-SNAPSHOT</version>
     </dependency>

     <dependency>
         <groupId>org.apache.yoko</groupId>
         <artifactId>yoko-spec-corba</artifactId>
         <version>1.0-incubating-M2-SNAPSHOT</version>
     </dependency>

     <dependency>
         <groupId>org.apache.yoko</groupId>
         <artifactId>yoko-rmi-spec</artifactId>
         <version>1.0-incubating-M2-SNAPSHOT</version>
     </dependency>

     <dependency>
         <groupId>org.apache.yoko</groupId>
         <artifactId>yoko-rmi-impl</artifactId>
         <version>1.0-incubating-M2-SNAPSHOT</version>
     </dependency>

IMO it would be better if there was some module in the server build  
which had these dependencies so that CTS always gets built with the  
correct version.

  * * *

Anyways, just a thought... meta-modules might help reduce some  
dependency configuration by centralizing dependency groupings.

Any thoughts?

--jason

Re: meta-modules to group dependencies

Posted by David Jencks <da...@yahoo.com>.
simplicity and lack of repetition is very good but..... I wonder if  
we already have these in the configs?
On Jan 11, 2007, at 11:22 AM, Jason Dillon wrote:

> Anyone have any oppinon on creating meta-modules to group  
> dependencies that are commonly used together?
>
> For example, in most places where xmlbeans is a dep, so is stax, as  
> in:
>
>     <dependency>
>         <groupId>xmlbeans</groupId>
>         <artifactId>xbean</artifactId>
>     </dependency>
>
>     <dependency>
>         <groupId>stax</groupId>
>         <artifactId>stax-api</artifactId>
>     </dependency>

This is kinda a terrible example because stax-api should be a  
dependency of xmlbeans.  One of these days I will push on that some  
more...

>
> We could create a meta-module, which simply defines these as  
> dependencies, then use the meta-module as a dependency to simplify  
> some of the commonly used dependencies.
>
> This could also be used to allow better support for picking up  
> versions of dependencies when we build the CTS server for TCK  
> testing.  For example, right now we have to include versions for  
> openejb and yoko in the CTS build:
>
>    <dependency>
>         <groupId>org.apache.openejb</groupId>
>         <artifactId>openejb-core</artifactId>
>         <version>2.3-incubating-SNAPSHOT</version>
>     </dependency>
>
>     <dependency>
>         <groupId>org.apache.openejb</groupId>
>         <artifactId>openejb-corba</artifactId>
>         <version>2.3-incubating-SNAPSHOT</version>
>     </dependency>
>
>     <dependency>
>         <groupId>org.apache.openejb</groupId>
>         <artifactId>openejb-yoko</artifactId>
>         <version>2.3-incubating-SNAPSHOT</version>
>     </dependency>
>
>     <dependency>
>         <groupId>org.apache.yoko</groupId>
>         <artifactId>yoko-core</artifactId>
>         <version>1.0-incubating-M2-SNAPSHOT</version>
>     </dependency>
>
>     <dependency>
>         <groupId>org.apache.yoko</groupId>
>         <artifactId>yoko-spec-corba</artifactId>
>         <version>1.0-incubating-M2-SNAPSHOT</version>
>     </dependency>
>
>     <dependency>
>         <groupId>org.apache.yoko</groupId>
>         <artifactId>yoko-rmi-spec</artifactId>
>         <version>1.0-incubating-M2-SNAPSHOT</version>
>     </dependency>
>
>     <dependency>
>         <groupId>org.apache.yoko</groupId>
>         <artifactId>yoko-rmi-impl</artifactId>
>         <version>1.0-incubating-M2-SNAPSHOT</version>
>     </dependency>
>
> IMO it would be better if there was some module in the server build  
> which had these dependencies so that CTS always gets built with the  
> correct version.

Can we use the openejb-yoko config for this purpose?  I don't recall  
what we're building that needs all these dependencies.  My thought  
for about a year has been that we should group modules by the configs  
they are used in, so "later" "more advanced" modules can pull in all  
the dependencies they need from the config rather than depending on  
individual jars.  For most of the build we can't really do that  
without a lot of rearranging but for the tck we know the configs are  
all available already.


>
>  * * *
>
> Anyways, just a thought... meta-modules might help reduce some  
> dependency configuration by centralizing dependency groupings.
>
> Any thoughts?
>

Do you have some examples of meta modules that couldn't be taken care  
of by using the already existing configs?

thanks
david jencks

> --jason


Re: meta-modules to group dependencies

Posted by Jason Dillon <ja...@planet57.com>.
It may or may not be in the dependencies pom... depends on if its a  
native m2 artifact or if its configured in the right scope.

--jason


On Jan 11, 2007, at 4:11 PM, Matt Hogstrom wrote:

> That would certainly help people understand why dependencies are  
> there and how they are related.  Although, shouldn't the  
> dependencies be in the poms already?  So if XMLBeans needed Stax  
> they would have already declared that and it could be derived  
> transitively?
>
> On Jan 11, 2007, at 2:22 PM, Jason Dillon wrote:
>
>> Anyone have any oppinon on creating meta-modules to group  
>> dependencies that are commonly used together?
>>
>> For example, in most places where xmlbeans is a dep, so is stax,  
>> as in:
>>
>>     <dependency>
>>         <groupId>xmlbeans</groupId>
>>         <artifactId>xbean</artifactId>
>>     </dependency>
>>
>>     <dependency>
>>         <groupId>stax</groupId>
>>         <artifactId>stax-api</artifactId>
>>     </dependency>
>>
>> We could create a meta-module, which simply defines these as  
>> dependencies, then use the meta-module as a dependency to simplify  
>> some of the commonly used dependencies.
>>
>> This could also be used to allow better support for picking up  
>> versions of dependencies when we build the CTS server for TCK  
>> testing.  For example, right now we have to include versions for  
>> openejb and yoko in the CTS build:
>>
>>    <dependency>
>>         <groupId>org.apache.openejb</groupId>
>>         <artifactId>openejb-core</artifactId>
>>         <version>2.3-incubating-SNAPSHOT</version>
>>     </dependency>
>>
>>     <dependency>
>>         <groupId>org.apache.openejb</groupId>
>>         <artifactId>openejb-corba</artifactId>
>>         <version>2.3-incubating-SNAPSHOT</version>
>>     </dependency>
>>
>>     <dependency>
>>         <groupId>org.apache.openejb</groupId>
>>         <artifactId>openejb-yoko</artifactId>
>>         <version>2.3-incubating-SNAPSHOT</version>
>>     </dependency>
>>
>>     <dependency>
>>         <groupId>org.apache.yoko</groupId>
>>         <artifactId>yoko-core</artifactId>
>>         <version>1.0-incubating-M2-SNAPSHOT</version>
>>     </dependency>
>>
>>     <dependency>
>>         <groupId>org.apache.yoko</groupId>
>>         <artifactId>yoko-spec-corba</artifactId>
>>         <version>1.0-incubating-M2-SNAPSHOT</version>
>>     </dependency>
>>
>>     <dependency>
>>         <groupId>org.apache.yoko</groupId>
>>         <artifactId>yoko-rmi-spec</artifactId>
>>         <version>1.0-incubating-M2-SNAPSHOT</version>
>>     </dependency>
>>
>>     <dependency>
>>         <groupId>org.apache.yoko</groupId>
>>         <artifactId>yoko-rmi-impl</artifactId>
>>         <version>1.0-incubating-M2-SNAPSHOT</version>
>>     </dependency>
>>
>> IMO it would be better if there was some module in the server  
>> build which had these dependencies so that CTS always gets built  
>> with the correct version.
>>
>>  * * *
>>
>> Anyways, just a thought... meta-modules might help reduce some  
>> dependency configuration by centralizing dependency groupings.
>>
>> Any thoughts?
>>
>> --jason
>>
>
> Matt Hogstrom
> matt@hogstrom.org
>
>


Re: meta-modules to group dependencies

Posted by Matt Hogstrom <ma...@hogstrom.org>.
That would certainly help people understand why dependencies are  
there and how they are related.  Although, shouldn't the dependencies  
be in the poms already?  So if XMLBeans needed Stax they would have  
already declared that and it could be derived transitively?

On Jan 11, 2007, at 2:22 PM, Jason Dillon wrote:

> Anyone have any oppinon on creating meta-modules to group  
> dependencies that are commonly used together?
>
> For example, in most places where xmlbeans is a dep, so is stax, as  
> in:
>
>     <dependency>
>         <groupId>xmlbeans</groupId>
>         <artifactId>xbean</artifactId>
>     </dependency>
>
>     <dependency>
>         <groupId>stax</groupId>
>         <artifactId>stax-api</artifactId>
>     </dependency>
>
> We could create a meta-module, which simply defines these as  
> dependencies, then use the meta-module as a dependency to simplify  
> some of the commonly used dependencies.
>
> This could also be used to allow better support for picking up  
> versions of dependencies when we build the CTS server for TCK  
> testing.  For example, right now we have to include versions for  
> openejb and yoko in the CTS build:
>
>    <dependency>
>         <groupId>org.apache.openejb</groupId>
>         <artifactId>openejb-core</artifactId>
>         <version>2.3-incubating-SNAPSHOT</version>
>     </dependency>
>
>     <dependency>
>         <groupId>org.apache.openejb</groupId>
>         <artifactId>openejb-corba</artifactId>
>         <version>2.3-incubating-SNAPSHOT</version>
>     </dependency>
>
>     <dependency>
>         <groupId>org.apache.openejb</groupId>
>         <artifactId>openejb-yoko</artifactId>
>         <version>2.3-incubating-SNAPSHOT</version>
>     </dependency>
>
>     <dependency>
>         <groupId>org.apache.yoko</groupId>
>         <artifactId>yoko-core</artifactId>
>         <version>1.0-incubating-M2-SNAPSHOT</version>
>     </dependency>
>
>     <dependency>
>         <groupId>org.apache.yoko</groupId>
>         <artifactId>yoko-spec-corba</artifactId>
>         <version>1.0-incubating-M2-SNAPSHOT</version>
>     </dependency>
>
>     <dependency>
>         <groupId>org.apache.yoko</groupId>
>         <artifactId>yoko-rmi-spec</artifactId>
>         <version>1.0-incubating-M2-SNAPSHOT</version>
>     </dependency>
>
>     <dependency>
>         <groupId>org.apache.yoko</groupId>
>         <artifactId>yoko-rmi-impl</artifactId>
>         <version>1.0-incubating-M2-SNAPSHOT</version>
>     </dependency>
>
> IMO it would be better if there was some module in the server build  
> which had these dependencies so that CTS always gets built with the  
> correct version.
>
>  * * *
>
> Anyways, just a thought... meta-modules might help reduce some  
> dependency configuration by centralizing dependency groupings.
>
> Any thoughts?
>
> --jason
>

Matt Hogstrom
matt@hogstrom.org