9:13 p.m.
Max:
There is no "natural dependency" between ESB and AS Tools. Seriously.
Zero. the ESB tools are some editors and a project type. The AS Tools
are a way to deploy it.
In B) The issue is not that you need to download AS Tools to get it to
*deploy*. The issue is that you need to download AS Tools to even
create the project and get it to compile.
Let's not neglect the usecase that a user may just want the project
creation tools and editors for ESB and may want to do all their
deployment via ant scripts or export actions (or better yet, project
archives). Boom. No natural dependency. At all.
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