[jbosstools-dev] RFE: JDT module or put in common ?

Max Rydahl Andersen max.andersen at redhat.com
Thu Jul 21 12:32:11 EDT 2011


> 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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>> 
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>> 
>> /max
>> http://about.me/maxandersen
>> 
>> 
>> 
>> 
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

/max
http://about.me/maxandersen






More information about the jbosstools-dev mailing list