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

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.

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.

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.

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

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

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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev

> 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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>>> >>> >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> > _______________________________________________ Soa-tools-list mailing list Soa-tools-list(a)redhat.com https://www.redhat.com/mailman/listinfo/soa-tools-list

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