[jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-2199) remove javax.servlet:servlet-api and javax.el:el-api as hard dependencies in Maven 2

[Norman Richards (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBSEAM-2199?page=all ]

Norman Richards updated JBSEAM-2199:
------------------------------------

    Fix Version/s: 2.0.1.GA
                       (was: 2.0.0.GA)

> remove javax.servlet:servlet-api and javax.el:el-api as hard dependencies in Maven 2
> ------------------------------------------------------------------------------------
>
>                 Key: JBSEAM-2199
>                 URL: http://jira.jboss.com/jira/browse/JBSEAM-2199
>             Project: JBoss Seam
>          Issue Type: Task
>          Components: Core
>    Affects Versions: 2.0.0.GA
>            Reporter: Dan Allen
>         Assigned To: Pete Muir
>             Fix For: 2.0.1.GA
>
>   Original Estimate: 30 minutes
>  Remaining Estimate: 30 minutes
>
> I feel that both the javax.servlet:servlet-api and javax.el:el-api dependencies should always be declared at provided (or optional). Currently, the hard dependencies are as such:
> javax.servlet:servlet-api - debug, pdf, remoting, ioc
> javax.el:el-api - core, debug, mail, pdf, ui
> The provided scope, as you know, will be available for compile and tests, but not deployed. Personally I feel that provided is the best choice because optional forces developers to add it as a dependency when it is likely they will need it to compile. The JSF POM files uses provided for the javax.servlet:servlet-api dependency, so perhaps we should follow suit.
> Basically, if the user wants to include a library that is part of Java EE 5 in their project as a deployment dependency (compile or runtime), then they can comfortably add it. Otherwise,they are forced to use a barrage of exclusions to get it booted. As it stands now the JSF libraries are not included by default, so it stands to reason that the servlet and EL APIs are also out. It is very easy for someone to include a build profile in their project that throws these artifacts in for an older spec deployment.
> Of course, this brings up the point that Maven 2 is really lame in how it does exclusions. Wouldn't it be nice just to say "I never want this artifact, I don't care what you say". Nope, let's just do it the hard way (says the Maven 2 folks), it is more fun.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira