[jboss-jira] [JBoss JIRA] Commented: (JBEE-15) Break all EEl apis into separately versioned subprojects

[ https://jira.jboss.org/jira/browse/JBEE-15?page=com.atlassian.jira.plugin... ] John Casey commented on JBEE-15: -------------------------------- Just diving in here... :) There are two concerns about where the spec version goes in the ID, from what I can tell: 1. if you include it in the artifactId, such as with servlet-api_2.5_spec, then you can have problems with servlet-api_2.5_spec and servlet-api_2.4_spec landing side-by-side in a lib/ folder. This would mean you'd have to add the appropriate exclude to _all_ dependencies that depend on servlet-api_2.4_spec in order to keep it out of builds. 2. If you include the spec version the artifact version, as with servlet-api-spec:2.5-1.0 (where 2.5 is the spec version, and 1.0 is the jboss release version of that spec), the there could be some confusion in Maven WRT handling version ranges. I'm not thinking of a specific case where I've seen this fall down, just knowing version ranges and non-typical versions (not x.y.z and similar) are a bit of a hot spot for problems in Maven. IMO, if you're likely to hit a major bump in the road in terms of Maven functionality not living up to expectations either way, then the second approach is much simpler to fix in a Maven 2.x release because it doesn't require changing the POM syntax. In the first approach, to achieve a global exclude for servlet-api_2.4_spec would require adding a new XML section to the POM that is outside of any specific dependency, and applies to the dependency sub-graph of all project dependencies. This isn't really approachable until after Maven 3.0 GA. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira