11:01 a.m.
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/m...
>> 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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev