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

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

Any reason you'd want to build this stuff SEPARATELY from the common stuff?

Will stuff depend on this (like the way common is an upstream for many components)?

Does it depend on anything upstream from common?

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

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?

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

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