Non-core Spring schemas/handlers overwritten by core schemas/handlers

[Developer Dude]

This is just to make sure I am not missing something, and maybe to get another take on this problem.

My post in the Spring Security forum where the response has been 'So? Deal with it'.

http://forum.springsource.org/showthread.php?t=77930

The problem is that the schema and namespace handlers are defined in two files that always have the same name. If you build a standalone app jar with ANT, that contains multiple Spring projects, one project can overwrite these files put into the same place in the jar. The solution seems to be using the one large Spring jar that contains all the schema/namespace mappings for core Spring projects (beans, etc.).

However, if you use a non-core project, say Spring Security, then those schema/namespaces are either overwritten by the core schema mappings, or they in turn overwrite the core mappings. There is no mapping files I can find that contain all mappings for all Spring projects. The result is that trying to run the jar from the command line results in an exception that the namespace handler for Spring Security cannot be found.

Therefore, I would have to build and maintain them manually - which is not a good solution for various reasons I should not have to go into.

How do others handle this problem?

Are the Spring devs aware of this problem?

Is there a simple solution that works with ANT? I need it to work regardless of IDE, in ANT, so the fatjar plugin for Eclipse is not a solution.

Am I missing something simple here?

Thanks.

[Developer Dude]

There seems to be a related Jira issue entered last year. Last entry about ten days ago. If I read this correctly this is an issue that is not yet resolved, not assigned and is a major priority?

http://jira.codehaus.org/browse/MASS...#action_190636

<edit> Ooops - this is against Maven, not Spring </edit>

[Developer Dude]

There is also the problem where someone needs to use two core jars with schema/namespace mappings, but doesn't want to include the 'big' all-encompassing Spring jar because that is either inefficient, or maybe (?) they was to use a different version of one of the core Spring jars.

[Developer Dude]

http://article.gmane.org/gmane.comp....ork.user/10205

http://www.mysticcoders.com/blog/200...in-and-spring/