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?
for this.
org.jboss.tools.common.jdt.feature is thus now born; starting with a jdt.debug.* plugin.
/max
N
>
> /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
>
>
>
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com