]
Pete Muir commented on JBSEAM-2199:
-----------------------------------
We really need to decide on a single policy for what is provided and what is optional.
Originally I went with "what's in jboss as 4.2 is marked as provided" but
I'm not sure this is a good policy. What you are after is (correct me if I'm
wrong) "what's in tomcat (6) is marked as provided". Perhaps this is
reasonable...
What I really really want is proper dependency profiles so we can build support for Tomcat
AND JBoss AS AND Glassfish AND... We can probably do this for projects which extend the
root pom at the moment.
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: