On 07/21/2011 12:32 PM, Max Rydahl Andersen wrote:
> Any reason you'd want to build this stuff SEPARATELY from the common stuff?
Its not so much about build, but its about installation - thus separate features at
OK, so it could be part of "common" rather than needing a new module
(and three new jobs).
And that we don't ever want it to depend on common as long as
common == xmodel which aren't necessary
for large part of our other dependencies.
But it could still be built as part of the "common" module, even if it's
all new feature(s).
> Will stuff depend on this (like the way common is an upstream for
Right now - no.. future ? maybe.
Given things already depend on common, this to me says it could be in
common and things could just depend on (common+this).
> Does it depend on anything upstream from common?
It only depends on eclipse JDT stuff as it stands now.
Common only depends on tests module atm. So both pieces (JDT new stuff &
existing common stuff) have minimal upstream deps within JBT.
I'd say regardless of the feature/plugin namespace you select (eg.,
o.j.t.jdt, as Denis +1'd), I can't see any compelling reason to create a
new module for this.
Therefore, let's put it in the common module. So say we all?
> On 07/21/2011 07:56 AM, Max Rydahl Andersen wrote:
>>> Unfortunately, I don't see any other practical solution.
>>> +1 for a new JDT module
>>> I would add plugins / features for JBIDE-8972 under the
>>> org.jboss.tools.jdt.classpath namespace
>> I would suggest org.jboss.tools.jdt.core/ui as the plugin name and then if
necessary package names under that.
>> Snjezana's could fit in there too or if necessary
>>> my 0.02�.
>>> Fred Bricon
>>> On 21/07/2011 10:47, Max Rydahl Andersen wrote:
>>>> Snjezana have been working on https://issues.jboss.org/browse/JBIDE-8548
(easy Attach to Remote debugger)
>>>> and Fred is about to work on https://issues.jboss.org/browse/JBIDE-8972
(copy classpath library to project)
>>>> which both are things that actually should exist/be contributed to
Eclipse JDT at some point.
>>>> The question is where do we put them today ?
>>>> Looking at existing modules putting it in common under a new plugin named
org.jboss.tools.common.jdt.* is probably the best fit,
>>>> but since common is also much more than that its not the best - its
actually mostly related to xmodel than anything else - and
>>>> I could see the interest in installing these JDT features without having
to require all of xmodel and its editors extensions installed.
>>>> The alternative I see is creating a new module (sigh) named jdt with
org.jboss.tools.jdt.* as its base and
>>>> we create a matching feature named "JBoss Tools JDT - Extensions for
>>>> I'm leaning to the JDT module approach, but since i'm really not
a fan of adding more and more modules without
>>>> a good reason I would like to hear if anyone has convincing arguments for
or against this move ?
>>>> jbosstools-dev mailing list
>>> jbosstools-dev mailing list
>> jbosstools-dev mailing list
> Nick Boldt :: JBoss by Red Hat
> Productization Lead :: JBoss Tools& Dev Studio
> jbosstools-dev mailing list
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio