Re: [jbosstools-dev] Unnecessary Dependencies

Maybe showing the +/- of each scenario would make it more obvious: A) We keep the ESB to AS dependency: + Does not require module structure/dependency changes shortly before GA ++ if there is a bug in the shared code it will be fixed once and work for all - I have to download AS to get the shared functionality (but this is not a big minus if you use the updatesite since there would be a dependency) B) We copy code from AS to ESB: + ESB can be downloaded separately - Changes dependency changes shortly before GA (a small minus but it needs to be checked after all) -- if one fixes a bug in the copied code in ESB he also need to fix this where the code was copied from (i.e. which will be forgotten because we are all humans) - I have to download AS to get the ESB projects to actually deploy (but this is not a big minus if you use the updatesite since there would be a dependency) C) We share code between AS to ESB in a common core + ESB can be downloaded separately ++ if there is a bug in the shared code it will be fixed once and work for all - I have to download common core (but this is not a big minus if you use the updatesite since there would be a dependency) -- Require module structure/dependency changes shortly before GA So for me the copy option is the worst of all choices. Since it has a big minus (duplication of code), but no real benefits plus moving from A to C is easier then B to C. If ESB and AS did not have a natural dependency and the duplicated code was just simple - things would be different. It all depends on the context. Dependencies are not a bad thing - but yes, in general we should modularize our code so we don't get *unnatural* dependencies. /max > On 12-02-2009 06:34, Rob Stryker wrote: >> So today I decided to work on JBIDE-3772 and I create a workspace >> with just ESB projects. >> >> I see immediately that it requires XModel (bleh), but that's fine I >> guess. It provides a lot of functionality. I also see, however, that >> it requires as.classpath.core. >> >> Requiring XModel is maybe justifiable as it's "common" code. The >> requirement on as.classpath.core is just to make use of an Abstract >> classpath provider that's in there. >> >> I'm not trying to call any plugin or developer out here, but I'd >> like to suggest that we try to decouple our code as much as is >> possible. If you're just borrowing one or two classes with minimal >> dependencies, would it be better to copy that class? I think it >> would be better but I'd like to hear other's thoughts. > No, copy/paste of code that is doing more than just very simple > things should not just be copied. > > You don't tell what classpath provider you are copying so I can't see > what it does (and fisheye is down), but my guess is that it is the > classpth container > that manages the sourcecode and javadoc attachements - that is > excellent candidates for code to be shared. > > This does not mean you should not decouple your code, but decoupling > is much more than just avoiding plugin dependencies between our plugins. > i.e. if having ESB classpath containers and deployment being > dependent on AS plugin saves us from a lot of possibly maintanence > duplication then why bother > separating them when the only adapter and server in the world that > will work with ESB is our AS plugin...in other words ESB has (IMO) a > natural dependeny on AS > hence having common code in AS does not hurt anyone. > > If ESB one day can be deployed to other servers or the classpath > container start being used by other parts of our code that is not > 100% dependent on AS by nature then > separating those base classes out makes a lot of sense. > > /max > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev