Any reason you'd want to build this stuff SEPARATELY from the
Its not so much about build, but its about installation - thus separate features at
And that we don't ever want it to depend on common as long as common == xmodel which
for large part of our other dependencies.
Will stuff depend on this (like the way common is an upstream for
Right now - no.. future ? maybe.
Does it depend on anything upstream from common?
It only depends on eclipse JDT stuff as it stands now.
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