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
least.
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.
Will stuff depend on this (like the way common is an upstream for
many
components)?
Right now - no.. future ? maybe.
Does it depend on anything upstream from common?
It only depends on eclipse JDT stuff as it stands now.
/max
N
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
org.jboss.tools.jdt.debug.core/ui.
>
>
>>
>> my 0.02�.
>>
>> Regards,
>>
>> Fred Bricon
>>
>> On 21/07/2011 10:47, Max Rydahl Andersen wrote:
>>> Hi,
>>>
>>> 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
Eclipse JDT"
>>>
>>> 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 ?
>>>
>>> Thanks,
>>> /max
>>>
http://about.me/maxandersen
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>
> /max
>
http://about.me/maxandersen
>
>
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
/max
http://about.me/maxandersen