[jbosstools-dev] Unnecessary Dependencies

[Max Rydahl Andersen]

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev