[jboss-as7-dev] Automatically generate AS7 module.xml files from maven poms?

David Bosschaert david at redhat.com
Fri Dec 17 12:01:19 EST 2010


In my case it was a direct dependency in a module that existed in the 
pom.xml but not in the module.xml.

I'm getting slightly nervous when a dependency or code change to a 
module in some build system A (the bare component) requires me to go to 
a completely different build system B (AS 7) to make sure that they're 
in sync.

I don't have all the answers to your questions, but just as a parallel, 
in the case of the Maven Bundle Plugin [1], it adds the definition of 
exports and imports to the pom, which is clearly a parallel to the Path 
filtering that you're mentioning. It's done in a plugin configuration 
section. I'm pretty sure that the other mismatches that you're 
mentioning could be handled in a similar manner.

Stuff still needs to be declared and specified, but at least it will be 
in a single place...

Cheers,

David

On 17/12/2010 15:07, Jason T. Greene wrote:
> It might be a reasonable thing to generate a descriptor from a pom as a
> starting point. However, they are not really one-to-one, so the majority
> case will require alterations. Various reasons include:
>
> 1. Maven doesn't really separate runtime deps from compile time deps
> properly (only workable way is "provided", which is rarely used).
> 2. Our core modules (e.g. javax.*) are not represented in maven
> 3. Transitive deps in maven are usually wrong (only a "bom" approach
> leads to "correct" deps)
> 4. While a slot could be an artifact version, that's not the best
> approach (you want a slot to be a compatibility group, not a minor
> version so that updates are easy)
> 5. Path filtering can't be represented.
>
> Although, isn't your problem more of the AS dependencies being out of
> sync with a pom's transitive dep? If so the same problem exists with the
> maven BOM approach that we use. (AS redefines all deps using a BOM to
> avoid broken/wrong deps)
>
> On 12/17/10 6:23 AM, Kabir Khan wrote:
>> I've been working on a maven plugin to create extra modules for tests, so what you describe would certainly be possible. The maven plugin/dependency api is pretty nice to work with. Once I've got my forked surefire plugin working, I can take a look if the general consensus is that we should go with something like this
>> On 17 Dec 2010, at 12:47, David Bosschaert wrote:
>>
>>> Hi all,
>>>
>>> Today I was looking at a module.xml somewhere down
>>>
>>> http://github.com/jbossas/jboss-as/blob/master/build/src/main/resources/modules
>>> and found out that a problem I was facing was caused by a dependency in
>>> there being out of sync with the dependencies of the pom that defines
>>> the original module.
>>>
>>> So I was thinking, since there is a 1-1 mapping between the poms and
>>> modules would it make sense to automatically generate the module.xml
>>> files from the poms rather then having them in git. I realize that there
>>> is extra information in some cases that needs to go into the module.xml
>>> file but that information could be added to the pom in some form [1].
>>> Otherwise this might become a bit of a maintenance nightmare IMHO...
>>>
>>> Or is this already happening somewhere in a way that I'm not aware of?
>>>
>>> Cheers,
>>>
>>> David
>>>
>>> [1] The maven-bundle-plugin does something similar for OSGi bundles:
>>> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>




More information about the jboss-as7-dev mailing list