[jbosstools-dev] Unnecessary Dependencies

[Max Rydahl Andersen]

>
> Also i simply disagree with you that "duplication of code" is a bigger 
> downside than "decoupling". This is simply a value judgement. There's 
> no book or guide that can prove you or I right. It'd be interesting to 
> find out what the rest of JBoss thinks about duplication vs decoupling 
> when you don't yet have time to add a new core / common module. The 
> fact is you can always refactor it out to common code later.
That is *not* true. It is always easier to factor out common code later 
if the code is actual common - if they are separate it gets harder to 
ensure they are still the same.
> You keep mentioning the update site and how easy it is to add things, 
> but we're neglecting that users may actually want to control their dev 
> environment and customize what plugins go in and don't go in, and may 
> still want their tools to work even if they remove some parts. For a 
> project that has a download page that offers piecemeal downloads (a la 
> carte), to not even make a basic attempt at it is ridiculous.
Which parts would he be able to remove if there are declared dependencies ?
> And finally, if you were to really look at the classes, there's not a 
> whole lot to them. All it is is a container where you give it a folder 
> and it adds those to a classpath. It's pretty basic code. It's not 
> some novel algorithm or crazy logic.
I'm still waiting for a pointer to what classes they are ;) (maybe they 
are now in the jira after anonsvn got back...will need to look)

/max
>
> Max Rydahl Andersen wrote:
>> 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
>>
>