[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2199) remove javax.servlet:servlet-api and javax.el:el-api as hard dependencies in Maven 2
7:18 p.m.
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.0.GA
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
7:24 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2199) remove javax.servlet:servlet-api and javax.el:el-api as hard dependencies in Maven 2
[ http://jira.jboss.com/jira/browse/JBSEAM-2199?page=comments#action_12385597 ]
Dan Allen commented on JBSEAM-2199:
-----------------------------------
Here is what should _not_ be included in the deployment archive (WAR file, for example) if
you were to just add all of the seam dependencies in a single project
javax.servlet:servlet-api
javax.servlet:jsp-api (this one is already handled correctly)
javax.faces:jsf-api (this is still left in a couple of places)
javax.faces:jsf-impl (this is handled correctly)
javax.el:el-api
You can check by doing:
1. mvn archetype:create -DgroupId=com.example -DartifactId=seamdeptest
-DarchetypeArtifactId=maven-archetype-webapp
2. add seam dependencies as recommended
3. mvn clean package
4. ls -l target/seamdeptest/WEB-INF/lib
Look for offending artifacts.
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.0.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
9:59 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-2199) remove javax.servlet:servlet-api and javax.el:el-api as hard dependencies in Maven 2
[ 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
11:24 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2199) remove javax.servlet:servlet-api and javax.el:el-api as hard dependencies in Maven 2
[ http://jira.jboss.com/jira/browse/JBSEAM-2199?page=comments#action_12385624 ]
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:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:58 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2199) remove javax.servlet:servlet-api and javax.el:el-api as hard dependencies in Maven 2
[ http://jira.jboss.com/jira/browse/JBSEAM-2199?page=comments#action_12385628 ]
Dan Allen commented on JBSEAM-2199:
-----------------------------------
I am getting pretty savvy at Maven 2 profiles, so I can likely help with ideas if we have
a clear goal in mind.
My feeling about provided vs optional is this:
optional - this library is needed if you use a fringe feature of the module, but it is
very likely that you can use the module without needing this on the classpath. For
instance, you can use seam core without using jboss rules, but if you do venture there,
you will need to add it as a dependency. It's a not a forced requirement. You are
conscience of your dependency on it.
provided - this is something that is part of the Java EE 5 specification (since JBoss Seam
is officially targeted at Java EE 5 and above). If it is included in the archive, things
will break. Break being the key word. This doesn't mean JBoss and it doesn't mean
Tomcat, though I would say more like Glassfish or the cross-breed of Glassfish and JBoss.
Candidates include JSF, Servlet API, JSP API, EL, JPA API. Hibernate would NOT be on this
list since it is not expected to be on the app server. I would make Hibernate an optional
dependency, which still saves the user from JBoss breakage.
I think the difference is pretty clear. If Tomcat is missing a library, then that means
the developer has to add it to their POM as a compile-time dependency (so it is bundled).
That's an okay thing to do...we want to be more on the conservative side than over
including. Nothing is uglier than a POM file with more exclusions than dependencies. (If
you want to see the result of this, just add Appfuse to your POM. Your bundled archive is
30MB+)
I know it sucks that Maven 2 doesn't have a better way of breaking down dependencies.
But I feel like my proposal can get us by with the best possible solution for the time
being. The follow up needs to be with the Maven 2 people to explain to them that we are
trying to use their tool and it just isn't covering the critical cases needed by a
framework like JBoss Seam (I'm not saying get rid of it, just improve it). We need to
hold their hand to the fire.
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
10:23 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Updated: (JBSEAM-2199) remove javax.servlet:servlet-api and javax.el:el-api as hard dependencies in Maven 2
[ http://jira.jboss.com/jira/browse/JBSEAM-2199?page=all ]
Pete Muir updated JBSEAM-2199:
------------------------------
Component/s: Build
(was: Core)
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: Build
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
9:39 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-2199) remove javax.servlet:servlet-api and javax.el:el-api as hard dependencies in Maven 2
[ http://jira.jboss.com/jira/browse/JBSEAM-2199?page=comments#action_12387378 ]
Pete Muir commented on JBSEAM-2199:
-----------------------------------
Other artifacts I noticed that are provided by the EE 5 spec AND provided in JBoss AS
4.2:
javax.mail:mail
javax.xml.ws:jaxws-api
javax.jws:jsr181-api
javax.ejb:ejb-api
javax.xml.soap:saaj-api
javax.jms:jms
javax.annotation:jsr250-api
javax.transaction:jta
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: Build
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
9:53 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Resolved: (JBSEAM-2199) remove javax.servlet:servlet-api and javax.el:el-api as hard dependencies in Maven 2
[ http://jira.jboss.com/jira/browse/JBSEAM-2199?page=all ]
Pete Muir resolved JBSEAM-2199.
-------------------------------
Resolution: Done
I've also added notes based on Dan's paragraph to the poms.
Dan, Matthew, please review, I'm interested on your thoughts.
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: Build
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
6:25 p.m.
New subject: [jbossseam-issues] [JBoss JIRA] Closed: (JBSEAM-2199) remove javax.servlet:servlet-api and javax.el:el-api as hard dependencies in Maven 2
[ http://jira.jboss.com/jira/browse/JBSEAM-2199?page=all ]
Pete Muir closed JBSEAM-2199.
-----------------------------
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: Build
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
6262
days inactive
6293
days old
8 comments
3 participants
participants (3)
-
Dan Allen (JIRA) -
Norman Richards (JIRA)
-
Pete Muir (JIRA)