[jbosstools-dev] Unnecessary Dependencies

[Max Rydahl Andersen]

> WHY are people reaching into other unrelated plugins and using classes 
> and adding unnecessary dependencies?!
Because AS is a *natural* thing to depend on.
> If so many people are doing this, then the code *should* be in a 
> common area!  There is ZERO reason that we should be reaching into 
> unrelated plugins and adding dependencies. This is absolutely disgusting.
Then why did you decided to copy the code instead of modularizing it ?

Snjezana's info just makes it even more important to not create 
duplication and instead keep it as it is (because it has *extremely* 
little impact) and this is something to do after GA *properly*.

>
> If everyone just starts reaching into each others plugins and using 
> code without permission or some type of process, then before you know 
> it we get spaghetti linkages and cyclical dependencies and all sorts 
> of things. We can NOT just go around adding dependencies for this kind 
> of stuff!
Of course - but having our WS and ESB stuff depend on AS core is not a 
big issue is it ?
> I would never reach into Denny's code or Grid's code or VPE code or 
> any other code without careful consideration to how the dependencies 
> will be affected... as should everyone else.
It was discussed on the mailing list and jira. Of course I want to fix 
this - but again, duplicating the code is the *worst* choice of all 
possible options.
> We need to have a clear process as to what types of projects are 
> allowed to depend on others and when. This type of lawlessness is 
> horrific.
>
> As far as I can see it, if someone else has some code you want to use, 
> the process should be done in this order:
> 1) if you already depend on the plugin, go ahead and use it the class.
> 2) If you have no reason to depend on it, try to copy or abstract the 
> code into a common area, and use it there.
> 3) If other difficulties make it so you cannot copy or abstract the 
> code into a common area, then copy  it into your own plugin
> 4) Only as a last resort do you go about adding dependencies.
And before you even start copying you raise it on the mailing list if a 
new module/plugin needs creating...
> I'm quite certain Max will disagree with me, but my point is, you 
> cannot just go extending classes in other plugins without looking at 
> how it will affect the dependency tree. We're heading down a dangerous 
> road where plugins just willy-nilly link up with each other and can't 
> be extricated. This is not professional at all.
It is not professional to create double maintenance either.

This is not a new issue, have been known for a long time but AS is not a 
*big* dependency and completely ok since all of those modules only work 
with AS adapter.

Could it be improved, yes sure. Should it be fixed now - no, it does not 
hurt anyone afaik and we are too close to GA to start restructuring 
plugin dependencies IMO.

/max
>
> Snjezana Peco wrote:
>> 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
>>
>