[jbosstools-dev] Unnecessary Dependencies

[Snjezana Peco]

We need to take into consideration that the AbstractClasspathContainer, 
AbstractClasspathContainerInitializer, ClasspathDecorations and 
ClasspathDecorationsManager classes are also being used in the WS and 
portlet plugins.

Snjeza

Rob Stryker wrote:
> Perhaps a more articulate way to explain my point is that copying the 
> code is the best solution because
>
> 1) It does not make real "code" changes before release. IE if this 
> code which has been stable for months continues to be stable, there's 
> no problem.
> 2) It severs an unnecessary dependency, thus allowing users to use a 
> deployment method of their choosing (project archives, ant)
> 3) It does not make big structural changes by introducing a new module 
> or some such.
> 4) It provides a stop-gap to the proper solution (new common code 
> area) once structural changes are permitted.
>
> 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
>>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev