[ https://jira.jboss.org/jira/browse/ARQ-136?page=com.atlassian.jira.plugin... ] Andrew Lee Rubinger commented on ARQ-136: ----------------------------------------- (02:24:47 PM) ALR@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@Freenode: It cannot get this transitively through the jbossas-embedded-60 container (02:25:11 PM) ALR@Freenode: As import is not transitive. (02:25:16 PM) aslak: aa.. right (02:25:23 PM) ALR@Freenode: But the more overarching problem: (02:25:34 PM) ALR@Freenode: Is that we shouldn't be leaking out everything in compile scope. (02:25:37 PM) ALR@Freenode: Because we did. (02:25:56 PM) aslak: is test transitive ? (02:25:57 PM) ALR@Freenode: And since import scope wasn't transitive, we missed out on the exclusions defined by depchain. (02:26:01 PM) ALR@Freenode: aslak: No. (02:26:10 PM) ALR@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@Freenode: Once APIs are locked, everything should play nice. (02:26:23 PM) ALR@Freenode: ie: (02:26:39 PM) ALR@Freenode: Using a specific version of Arquillian should not dictate a specific version of a target container. (02:26:52 PM) ALR@Freenode: If that's the case, we're not helping users. (02:26:59 PM) ALR@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@Freenode: And leaking stuff onto their classpath in the process (02:27:14 PM) ALR@Freenode: aslak: Nope. (02:27:21 PM) ALR@Freenode: aslak: We can't do that either. (02:27:29 PM) jharting [~jharting(a)r11de73.net.upc.cz] entered the room. (02:27:35 PM) jharting left the room (quit: Client Quit). (02:27:45 PM) ALR@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@Freenode: aslak: I know. We can't do that. (02:28:50 PM) ALR@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@Freenode: 4 and 6 are different APIs, so we should have different impls sure. (02:29:34 PM) ALR@Freenode: Let's take AS 6.0.0.M2 vs. M3. (02:29:39 PM) ALR@Freenode: They have similar APIs (02:29:47 PM) ALR@Freenode: But very different runtime components. (02:29:57 PM) ALR@Freenode: Or a better example is GFv3 vs. 3.0.1 (02:29:59 PM) ALR@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@Freenode: aslak: No, it's can't be limited. (02:30:41 PM) ALR@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@Freenode: If the deployment API of the backing container changes, yes, we need to change too. (02:31:26 PM) ALR@Freenode: BUT (02:31:39 PM) ALR@Freenode: M2 and M3 aren't locked APIs. (02:31:43 PM) ALR@Freenode: They're milestone releases. (02:31:51 PM) ALR@Freenode: GFv3 vs. 3.0.1 (02:32:00 PM) ALR@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@Freenode: aslak: I know you're trying to help the user. (02:32:44 PM) ALR@Freenode: But you're stepping into their responsibility/ (02:32:53 PM) ALR@Freenode: They must define their runtime CP. (02:32:54 PM) ALR@Freenode: Not us. (02:33:09 PM) ALR@Freenode: This is a symptom of Maven compile scope by default. (02:33:30 PM) ALR@Freenode: They don't need the backing container for compilation, therefore we should not be exporting compile scope. (02:33:38 PM) ALR@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@Freenode: aslak: To build. (02:34:01 PM) ALR@Freenode: aslak: Don't mistake convenience for doing too much. (02:34:08 PM) ALR@Freenode: Try to follow me here. (02:34:18 PM) ALR@Freenode: It took me a long time to come around to understand this. (02:34:31 PM) ALR@Freenode: We export GFv3. (02:34:38 PM) ALR@Freenode: Say the user wants 3.0.1 (02:34:44 PM) ALR@Freenode: They try to override. (02:35:03 PM) ALR@Freenode: But because we leak out GFv3 stuff, they get the transitive deps from the old version. (02:35:13 PM) ALR@Freenode: Simultaneously with the stuff they override on their own. (02:35:34 PM) ALR@Freenode: So any artifacts which may have moved GAV or whatever get duplicated. (02:35:41 PM) ALR@Freenode: And on their classpath. (02:35:55 PM) ALR@Freenode: Now the user needs to figure out exactly what the problem is (not easy BTW) (02:36:01 PM) ALR@Freenode: And add exclusions all over the place. (02:36:19 PM) ALR@Freenode: Or, we need to release a new Arquillian DeployableContainer impl set to the new GFv3 release (02:36:30 PM) ALR@Freenode: Meaning we'd need a release cycle for each target container's release. (02:36:38 PM) ALR@Freenode: An unmaintainable path. (02:36:59 PM) ALR@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@Freenode: We rely on a locked API. (02:37:25 PM) ALR@Freenode: And the user is free to define a runtime dependency on anything that's compatible with that API. (02:37:54 PM) ALR@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@Freenode: I see this in AS *all* the time. (02:38:17 PM) ALR@Freenode: If any component comes in and changes its API (02:38:24 PM) ALR@Freenode: It's cascading updates to all consumers. (02:38:27 PM) ALR@Freenode: And a nightmare. (02:38:45 PM) ALR@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@Freenode: At the cost that users have to define the dependency upon their target container (02:39:04 PM) ALR@Freenode: (Which they'd have to do anyway) (02:39:12 PM) ALR@Freenode: And as you see in the EmbeddedAS case, they MUST do (02:39:20 PM) ALR@Freenode: To get the exclusions from depchain in import scope. (02:39:42 PM) ALR@Freenode: Sure, we can export stuff as we do now. Resulting in version conflicts and confusion later. (02:39:49 PM) ALR@Freenode: Because we only need the APIs to match. (02:39:58 PM) ALR@Freenode: Not export the whole runtime dependency tree. (02:40:03 PM) ALR@Freenode: There's a big difference. (02:58:03 PM) ALR@Freenode: This IMO is Maven's fault BTW. (02:58:19 PM) ALR@Freenode: transitive dependencies by default in compile scope is a like a good drug. (02:58:22 PM) ALR@Freenode: It gets you hooked. (02:58:27 PM) ALR@Freenode: And then ruins your life. -- 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

[ https://jira.jboss.org/browse/ARQ-136?page=com.atlassian.jira.plugin.syst... ] Aslak Knutsen reassigned ARQ-136: --------------------------------- Assignee: Aslak Knutsen -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/browse/ARQ-136?page=com.atlassian.jira.plugin.syst... ] Aslak Knutsen closed ARQ-136. ----------------------------- Alpha-2 published -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira