[Soa-tools-list] Re: [jbosstools-dev] Unnecessary Dependencies

[Max Rydahl Andersen]

Just to be clear, I want to separate out this functionality to a 
separate module, but AS is for me a completely ok location to have this 
for GA
since:

A) They all need AS adapter to work for the large majority of our users

B) It would result in AS adapter to not be downloadable in one piece as 
a zip (only update site would work)

C) Too close to GA

/max

>
>> 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
>>>
>>
>
> _______________________________________________
> Soa-tools-list mailing list
> Soa-tools-list at redhat.com
> https://www.redhat.com/mailman/listinfo/soa-tools-list