[arquillian-issues] [JBoss JIRA] Commented: (ARQ-136) Do not export dependency upon target container in all containers

Sat May 8 15:24:05 EDT 2010

    [ https://jira.jboss.org/jira/browse/ARQ-136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12529733#action_12529733 ] 

Andrew Lee Rubinger commented on ARQ-136:
-----------------------------------------

(02:24:47 PM) ALR at Freenode: aslak: What was wrong was the client (in this case, the examples) was not bringing in the AS depchain in import scope in depMgt.
(02:25:06 PM) ALR at Freenode: It cannot get this transitively through the jbossas-embedded-60 container
(02:25:11 PM) ALR at Freenode: As import is not transitive.
(02:25:16 PM) aslak: aa.. right
(02:25:23 PM) ALR at Freenode: But the more overarching problem:
(02:25:34 PM) ALR at Freenode: Is that we shouldn't be leaking out everything in compile scope.
(02:25:37 PM) ALR at Freenode: Because we did.
(02:25:56 PM) aslak: is test transitive ?
(02:25:57 PM) ALR at Freenode: And since import scope wasn't transitive, we missed out on the exclusions defined by depchain.
(02:26:01 PM) ALR at Freenode: aslak: No.
(02:26:10 PM) ALR at Freenode: aslak: It's not our job to define transitive deps.
(02:26:13 PM) aslak: that means we have to push it to the user
(02:26:21 PM) ALR at Freenode: Once APIs are locked, everything should play nice.
(02:26:23 PM) ALR at Freenode: ie:
(02:26:39 PM) ALR at Freenode: Using a specific version of Arquillian should not dictate a specific version of a target container.
(02:26:52 PM) ALR at Freenode: If that's the case, we're not helping users.
(02:26:59 PM) ALR at Freenode: We're actually limiting their ability to choose.
(02:27:06 PM) aslak: no, but a specific v. of a DeployableContainer will
(02:27:08 PM) ALR at Freenode: And leaking stuff onto their classpath in the process
(02:27:14 PM) ALR at Freenode: aslak: Nope.
(02:27:21 PM) ALR at Freenode: aslak: We can't do that either.
(02:27:29 PM) jharting [~jharting at r11de73.net.upc.cz] entered the room.
(02:27:35 PM) jharting left the room (quit: Client Quit).
(02:27:45 PM) ALR at Freenode: aslak: The client must make the dependencies upon their container.
(02:27:48 PM) aslak: i mean v. as in DeployableContainer impl
(02:27:56 PM) ALR at Freenode: aslak: I know.  We can't do that.
(02:28:50 PM) ALR at Freenode: The user must declare the dep on their target container.
(02:29:00 PM) aslak: ok........... maybe i'm not following but.. how do you propose you run a DeployableContainer that is build for Jboss 4 on a jboss 6 ?
(02:29:18 PM) ALR at Freenode: 4 and 6 are different APIs, so we should have different impls sure.
(02:29:34 PM) ALR at Freenode: Let's take AS 6.0.0.M2 vs. M3.
(02:29:39 PM) ALR at Freenode: They have similar APIs
(02:29:47 PM) ALR at Freenode: But very different runtime components.
(02:29:57 PM) ALR at Freenode: Or a better example is GFv3 vs. 3.0.1
(02:29:59 PM) ALR at Freenode: Same API.
(02:30:13 PM) aslak: that's what i'm saying. a deployable is limited to a specific v. of a target container. whether you want to make that implicit or not is different
(02:30:30 PM) ALR at Freenode: aslak: No, it's can't be limited.
(02:30:41 PM) ALR at Freenode: We abide by a container's deployment API.
(02:30:47 PM) aslak: yea, jboss m2 and m3 are different enought to need impl changes.. same with 5.0 to 5.1
(02:31:24 PM) ALR at Freenode: If the deployment API of the backing container changes, yes, we need to change too.
(02:31:26 PM) ALR at Freenode: BUT
(02:31:39 PM) ALR at Freenode: M2 and M3 aren't locked APIs.
(02:31:43 PM) ALR at Freenode: They're milestone releases.
(02:31:51 PM) ALR at Freenode: GFv3 vs. 3.0.1
(02:32:00 PM) ALR at Freenode: Should be the same Arquillian DeployableContainer impl
(02:32:09 PM) aslak: your not limiting the user by implicid defining the v. your saying, this is tested and build against this v. if you want to try it with a newer v. you may do so, but keep in mind that it might not work. use exclude and include your own
(02:32:33 PM) ALR at Freenode: aslak: I know you're trying to help the user.
(02:32:44 PM) ALR at Freenode:  But you're stepping into their responsibility/
(02:32:53 PM) ALR at Freenode: They must define their runtime CP.
(02:32:54 PM) ALR at Freenode: Not us.
(02:33:09 PM) ALR at Freenode: This is a symptom of Maven compile scope by default.
(02:33:30 PM) ALR at Freenode: They don't need the backing container for compilation, therefore we should not be exporting compile scope.
(02:33:38 PM) ALR at Freenode: If we do, then we leak out that version.
(02:33:39 PM) aslak: whats the point of a build system if you have to define all your dependencies ? :)
(02:33:49 PM) ALR at Freenode: aslak: To build.
(02:34:01 PM) ALR at Freenode: aslak: Don't mistake convenience for doing too much.
(02:34:08 PM) ALR at Freenode: Try to follow me here.
(02:34:18 PM) ALR at Freenode: It took me a long time to come around to understand this.
(02:34:31 PM) ALR at Freenode: We export GFv3.
(02:34:38 PM) ALR at Freenode: Say the user wants 3.0.1
(02:34:44 PM) ALR at Freenode: They try to override.
(02:35:03 PM) ALR at Freenode: But because we leak out GFv3 stuff, they get the transitive deps from the old version.
(02:35:13 PM) ALR at Freenode: Simultaneously with the stuff they override on their own.
(02:35:34 PM) ALR at Freenode: So any artifacts which may have moved GAV or whatever get duplicated.
(02:35:41 PM) ALR at Freenode: And on their classpath.
(02:35:55 PM) ALR at Freenode: Now the user needs to figure out exactly what the problem is (not easy BTW)
(02:36:01 PM) ALR at Freenode: And add exclusions all over the place.
(02:36:19 PM) ALR at Freenode: Or, we need to release a new Arquillian DeployableContainer impl set to the new GFv3 release
(02:36:30 PM) ALR at Freenode: Meaning we'd need a release cycle for each target container's release.
(02:36:38 PM) ALR at Freenode: An unmaintainable path.
(02:36:59 PM) ALR at Freenode: This lies at the heart of proper component development.
(02:37:08 PM) aslak: we might need that anyway, depending on how stable their apis are
(02:37:09 PM) ALR at Freenode: We rely on a locked API.
(02:37:25 PM) ALR at Freenode: And the user is free to define a runtime dependency on anything that's compatible with that API.
(02:37:54 PM) ALR at Freenode: Only if the target container changes their API in a non-back-compat way do we need to do a release.
(02:38:07 PM) ALR at Freenode: I see this in AS *all* the time.
(02:38:17 PM) ALR at Freenode: If any component comes in and changes its API
(02:38:24 PM) ALR at Freenode: It's cascading updates to all consumers.
(02:38:27 PM) ALR at Freenode: And a nightmare.
(02:38:45 PM) ALR at Freenode: ARQ-136 is the answer to avoid these problems.
(02:38:46 PM) jbossbot: [ARQ-136] Do not export dependency upon target container in all containers [Open, Blocker, Unassigned] http://jira.jboss.org/jira/browse/ARQ-136
(02:38:59 PM) ALR at Freenode: At the cost that users have to define the dependency upon their target container
(02:39:04 PM) ALR at Freenode: (Which they'd have to do anyway)
(02:39:12 PM) ALR at Freenode: And as you see in the EmbeddedAS case, they MUST do
(02:39:20 PM) ALR at Freenode: To get the exclusions from depchain in import scope.
(02:39:42 PM) ALR at Freenode: Sure, we can export stuff as we do now.  Resulting in version conflicts and confusion later.
(02:39:49 PM) ALR at Freenode: Because we only need the APIs to match.
(02:39:58 PM) ALR at Freenode: Not export the whole runtime dependency tree.
(02:40:03 PM) ALR at Freenode: There's a big difference.
(02:58:03 PM) ALR at Freenode: This IMO is Maven's fault BTW.
(02:58:19 PM) ALR at Freenode: transitive dependencies by default in compile scope is a like a good drug.
(02:58:22 PM) ALR at Freenode: It gets you hooked.
(02:58:27 PM) ALR at Freenode: And then ruins your life.

> Do not export dependency upon target container in all containers
> ----------------------------------------------------------------
>
>                 Key: ARQ-136
>                 URL: https://jira.jboss.org/jira/browse/ARQ-136
>             Project: Arquillian
>          Issue Type: Task
>          Components: GlassFish Containers, JBoss Containers, OpenEJB Containers
>    Affects Versions: 1.0.0.Alpha2
>            Reporter: Andrew Lee Rubinger
>            Priority: Blocker
>
> We currently export the dependency upon backing containers (ie. JBossAS, OpenEJB, GlassFish) from the Arquillian container impls.  Users should be responsible for placing these dependencies on their own (ie. they're not needed in compile scope).
> Mark the scope as "provided" in all container impl modules.

-- 
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