Hi all, This is an important question for us. Nick and I are now convinced that .target files are not the panacea to drive dependency management at build time. It adds a lot of additional steps and it does not work that easily in the Maven way. We are thinking of some alternatives way to provide a "dependency" repository that would contain only the necessary stuff for you to work on your component. Then we'll just manage this repository instead of a .target file, it should make our daily work better and remove lot of complexity. See https://issues.jboss.org/browse/JBIDE-10915 and comments starting from here https://issues.jboss.org/browse/JBIDE-11157?focusedCommentId=12676643&... for more details/debate. So we more and more think this .target file is useless, and we'd like to get rid of it (uselessness is bad). But before that, we'd like to know whether some of you do use the generated .target file. If yes, we'll have to think on a better way to make everyone happy. So if you use .target file, raise your hand! -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

Noone uses it right now since it is not set up as it should be afaik I would/want to use it if we enable slide planner mode on it so the dependencies becomes *deterministic*. They aren't now.

And then I would like to get target files that I can apply in eclipse - but the current one is just too big/slow to work.

Using an updatesite would not help on that either afaik.

/max On Mar 14, 2012, at 3:55 PM, Mickael Istria wrote: > Hi all, > > This is an important question for us. > Nick and I are now convinced that .target files are not the panacea to drive dependency management at build time. It adds a lot of additional steps and it does not work that easily in the Maven way. We are thinking of some alternatives way to provide a "dependency" repository that would contain only the necessary stuff for you to work on your component. Then we'll just manage this repository instead of a .target file, it should make our daily work better and remove lot of complexity. > See https://issues.jboss.org/browse/JBIDE-10915 and comments starting from here https://issues.jboss.org/browse/JBIDE-11157?focusedCommentId=12676643&... for more details/debate. > > So we more and more think this .target file is useless, and we'd like to get rid of it (uselessness is bad). But before that, we'd like to know whether some of you do use the generated .target file. If yes, we'll have to think on a better way to make everyone happy. So if you use .target file, raise your hand! > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev

I agree with Max. It would be nice if a target file were available. Right now, the developer must manage his own target platform. This is compounded by the fact that the base "test" plugins are not available directly from a p2 repository (update site) and must be downloaded and installed separately.

As far as the slowness, I believe you only pay that when you setup or update your target platform (as the new dependencies are downloaded and updated). Same price you pay when updating your local target platform. This would be a really nice feature as it makes it easy to setup a development workspace; saves you from having to find all the dependencies yourself.

----- Original Message ----- > > Noone uses it right now since it is not set up as it should be afaik > > I would/want to use it if we enable slide planner mode on it so the > dependencies becomes *deterministic*. They aren't now. > > And then I would like to get target files that I can apply in eclipse > - but the current one is just too big/slow to work. > > Using an updatesite would not help on that either afaik. > > /max > > On Mar 14, 2012, at 3:55 PM, Mickael Istria wrote: > >> Hi all, >> >> This is an important question for us. >> Nick and I are now convinced that .target files are not the panacea >> to drive dependency management at build time. It adds a lot of >> additional steps and it does not work that easily in the Maven >> way. We are thinking of some alternatives way to provide a >> "dependency" repository that would contain only the necessary >> stuff for you to work on your component. Then we'll just manage >> this repository instead of a .target file, it should make our >> daily work better and remove lot of complexity. >> See https://issues.jboss.org/browse/JBIDE-10915 and comments >> starting from here >> https://issues.jboss.org/browse/JBIDE-11157?focusedCommentId=12676643&... >> for more details/debate. >> >> So we more and more think this .target file is useless, and we'd >> like to get rid of it (uselessness is bad). But before that, we'd >> like to know whether some of you do use the generated .target >> file. If yes, we'll have to think on a better way to make everyone >> happy. So if you use .target file, raise your hand! >> -- >> Mickael Istria >> Eclipse developer at JBoss, by Red Hat >> My blog - My Tweets >> _______________________________________________ >> 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 >

Sorry. Let me clarify, when I say target platform, I would also include the JBoss plugins. Having an all inclusive target file allows me to checkout a specific project and work on it, without having to root out the specific project dependencies, which then means either installing them into a local target platform or checking out their source, then repeating for any missing dependencies of the dependencies, and so on. I may end up having to checkout half of JBT (or installing everything into a local target) just to work on a simple, segregated feature. At least having a target file automates the process (even if it does take a while to download everything). ----- Original Message ----- > > > On 03/14/2012 01:21 PM, Rob Cernich wrote: >> I agree with Max. It would be nice if a target file were >> available. Right now, the developer must manage his own target >> platform. This is compounded by the fact that the base "test" >> plugins are not available directly from a p2 repository (update >> site) and must be downloaded and installed separately. > > Target Platform exists as a zip and an exploded site: > http://download.jboss.org/jbosstools/updates/target-platform_3.3.indigo.SR2/ > (for building anything in JBoss Tools Core -- download the zip, > unpack > it, and use it thus: `mvn clean install > -Dlocal.site=file:///path/to/unzipped/site/ -Plocal.site` or use that > site to install into your Eclipse for use w/ PDE) > > It's also a unified.target file if you prefer: > > http://anonsvn.jboss.org/repos/jbosstools/trunk/build/target-platform/ > > Tests: https://issues.jboss.org/browse/JBIDE-11077 (coming soon) > >> As far as the slowness, I believe you only pay that when you setup >> or update your target platform (as the new dependencies are >> downloaded and updated). Same price you pay when updating your >> local target platform. >> >> This would be a really nice feature as it makes it easy to setup a >> development workspace; saves you from having to find all the >> dependencies yourself. > > *cough* http://eclipsesource.com/en/yoxos/ ? */cough* > > (latest Yoxos 5.5 includes Eclipse 3.7.2: > http://eclipsesource.com/blogs/2012/02/26/yoxos-5-5-and-eclipse-3-7-2/) > >> >> ----- Original Message ----- >>> >>> Noone uses it right now since it is not set up as it should be >>> afaik >>> >>> I would/want to use it if we enable slide planner mode on it so >>> the >>> dependencies becomes *deterministic*. They aren't now. >>> >>> And then I would like to get target files that I can apply in >>> eclipse >>> - but the current one is just too big/slow to work. >>> >>> Using an updatesite would not help on that either afaik. >>> >>> /max >>> >>> On Mar 14, 2012, at 3:55 PM, Mickael Istria wrote: >>> >>>> Hi all, >>>> >>>> This is an important question for us. >>>> Nick and I are now convinced that .target files are not the >>>> panacea >>>> to drive dependency management at build time. It adds a lot of >>>> additional steps and it does not work that easily in the Maven >>>> way. We are thinking of some alternatives way to provide a >>>> "dependency" repository that would contain only the necessary >>>> stuff for you to work on your component. Then we'll just manage >>>> this repository instead of a .target file, it should make our >>>> daily work better and remove lot of complexity. >>>> See https://issues.jboss.org/browse/JBIDE-10915 and comments >>>> starting from here >>>> https://issues.jboss.org/browse/JBIDE-11157?focusedCommentId=12676643&... >>>> for more details/debate. >>>> >>>> So we more and more think this .target file is useless, and we'd >>>> like to get rid of it (uselessness is bad). But before that, we'd >>>> like to know whether some of you do use the generated .target >>>> file. If yes, we'll have to think on a better way to make >>>> everyone >>>> happy. So if you use .target file, raise your hand! >>>> -- >>>> Mickael Istria >>>> Eclipse developer at JBoss, by Red Hat >>>> My blog - My Tweets >>>> _______________________________________________ >>>> 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 >>> >> > > -- > Nick Boldt :: JBoss by Red Hat > Productization Lead :: JBoss Tools& Dev Studio > http://nick.divbyzero.com >

I agree with Max. It would be nice if a target file were available. Right now, the developer must manage his own target platform. This is compounded by the fact that the base "test" plugins are not available directly from a p2 repository (update site) and must be downloaded and installed separately. As far as the slowness, I believe you only pay that when you setup or update your target platform (as the new dependencies are downloaded and updated). Same price you pay when updating your local target platform. This would be a really nice feature as it makes it easy to setup a development workspace; saves you from having to find all the dependencies yourself. ----- Original Message ----- > > Noone uses it right now since it is not set up as it should be afaik > > I would/want to use it if we enable slide planner mode on it so the > dependencies becomes *deterministic*. They aren't now. > > And then I would like to get target files that I can apply in eclipse > - but the current one is just too big/slow to work. > > Using an updatesite would not help on that either afaik. > > /max > > On Mar 14, 2012, at 3:55 PM, Mickael Istria wrote: > >> Hi all, >> >> This is an important question for us. >> Nick and I are now convinced that .target files are not the panacea >> to drive dependency management at build time. It adds a lot of >> additional steps and it does not work that easily in the Maven >> way. We are thinking of some alternatives way to provide a >> "dependency" repository that would contain only the necessary >> stuff for you to work on your component. Then we'll just manage >> this repository instead of a .target file, it should make our >> daily work better and remove lot of complexity. >> See https://issues.jboss.org/browse/JBIDE-10915 and comments >> starting from here >> https://issues.jboss.org/browse/JBIDE-11157?focusedCommentId=12676643&... >> for more details/debate. >> >> So we more and more think this .target file is useless, and we'd >> like to get rid of it (uselessness is bad). But before that, we'd >> like to know whether some of you do use the generated .target >> file. If yes, we'll have to think on a better way to make everyone >> happy. So if you use .target file, raise your hand! >> -- >> Mickael Istria >> Eclipse developer at JBoss, by Red Hat >> My blog - My Tweets >> _______________________________________________ >> 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 >

the slowness I see from target is that tycho (at least until 0.13) was much slower against .target than others. I haven't had time do mvn builds often enough to see how it works in 0.14. but thats why we created updatesites zips to begin with to make that faster. /max On Mar 14, 2012, at 6:21 PM, Rob Cernich wrote: > I agree with Max. It would be nice if a target file were available. Right now, the developer must manage his own target platform. This is compounded by the fact that the base "test" plugins are not available directly from a p2 repository (update site) and must be downloaded and installed separately. > > As far as the slowness, I believe you only pay that when you setup or update your target platform (as the new dependencies are downloaded and updated). Same price you pay when updating your local target platform. > > This would be a really nice feature as it makes it easy to setup a development workspace; saves you from having to find all the dependencies yourself. > > ----- Original Message ----- >> Noone uses it right now since it is not set up as it should be afaik >> >> I would/want to use it if we enable slide planner mode on it so the >> dependencies becomes *deterministic*. They aren't now. >> >> And then I would like to get target files that I can apply in eclipse >> - but the current one is just too big/slow to work. >> >> Using an updatesite would not help on that either afaik. >> >> /max >> >> On Mar 14, 2012, at 3:55 PM, Mickael Istria wrote: >> >>> Hi all, >>> >>> This is an important question for us. >>> Nick and I are now convinced that .target files are not the panacea >>> to drive dependency management at build time. It adds a lot of >>> additional steps and it does not work that easily in the Maven >>> way. We are thinking of some alternatives way to provide a >>> "dependency" repository that would contain only the necessary >>> stuff for you to work on your component. Then we'll just manage >>> this repository instead of a .target file, it should make our >>> daily work better and remove lot of complexity. >>> See https://issues.jboss.org/browse/JBIDE-10915 and comments >>> starting from here >>> https://issues.jboss.org/browse/JBIDE-11157?focusedCommentId=12676643&... >>> for more details/debate. >>> >>> So we more and more think this .target file is useless, and we'd >>> like to get rid of it (uselessness is bad). But before that, we'd >>> like to know whether some of you do use the generated .target >>> file. If yes, we'll have to think on a better way to make everyone >>> happy. So if you use .target file, raise your hand! >>> -- >>> Mickael Istria >>> Eclipse developer at JBoss, by Red Hat >>> My blog - My Tweets >>> _______________________________________________ >>> 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 >> _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

> Noone uses it right now since it is not set up as it should be afaik > > I would/want to use it if we enable slide planner mode on it so the dependencies becomes *deterministic*. They aren't now. Depends on what you mean by deterministic.

Currently, the script that allows you to turn a .target file into an update site can run in two modes: * useLatest=true (get whatever versions of the listed IUs are available on the upstream sites) and

* useLatest=false (use exactly the versions of IUs listed in the .target file)

Does that not meet both the need to resolve a TP on disk from the explicit versions listed, or to update it from the latest in the requirements mirror? (eg., when it's time to move from SR1 to SR2)

> And then I would like to get target files that I can apply in eclipse - but the current one is just too big/slow to work. How would you propose bifurcating them? What features would be in what chunks? Maven bucket? SOA bucket? Teiid bucket? Need some idea how to break this into smaller pieces.

> Using an updatesite would not help on that either afaik. An update site w/ all the featureless plugins referenced by a top-level feature which would provide a way to easily install the whole site into your Eclipse either by hand or via p2.director script? Yes, yes it would.

> /max > > On Mar 14, 2012, at 3:55 PM, Mickael Istria wrote: > >> Hi all, >> >> This is an important question for us. >> Nick and I are now convinced that .target files are not the panacea to drive dependency management at build time. It adds a lot of additional steps and it does not work that easily in the Maven way. We are thinking of some alternatives way to provide a "dependency" repository that would contain only the necessary stuff for you to work on your component. Then we'll just manage this repository instead of a .target file, it should make our daily work better and remove lot of complexity. >> See https://issues.jboss.org/browse/JBIDE-10915 and comments starting from here https://issues.jboss.org/browse/JBIDE-11157?focusedCommentId=12676643&... for more details/debate. >> >> So we more and more think this .target file is useless, and we'd like to get rid of it (uselessness is bad). But before that, we'd like to know whether some of you do use the generated .target file. If yes, we'll have to think on a better way to make everyone happy. So if you use .target file, raise your hand! >> -- >> Mickael Istria >> Eclipse developer at JBoss, by Red Hat >> My blog - My Tweets >> _______________________________________________ >> 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

Right, I forget you're downstream from JBoss Tools Core. This usecase is being considered here:

For me it looks like the speed is up again

> Right, I forget you're downstream from JBoss Tools Core. This usecase is > being considered here: > note: when we start splitting up our giant repo into smaller parts many more will be downstream of "core" so this challenge is not limited to the likes of switchyard. Its actually already a problem today if you just want to develop on the mvn plugins - you also need to check out the code for everything else to build it. /max

without it the dependencies/target platforms are not resolved deterministically. And just to be clear what I mean with deterministic is that if our TP says org.x.z.y-1.2.3 and the update site only have org.x.z.y-1.2.4 the build *must* fail. It doesn't if the other p2 metadata features/plugin's allows 1.2.4 in its set.

>> without it the dependencies/target platforms are not resolved >> deterministically. >> >> And just to be clear what I mean with deterministic is that if our >> TP >> says org.x.z.y-1.2.3 >> and the update site only have org.x.z.y-1.2.4 the build *must* >> fail. >> >> It doesn't if the other p2 metadata features/plugin's allows 1.2.4 >> in >> its set. > > Let's keep in mind that the plugin/feature being built determines > the versions of its dependencies (not sure how fuzzy this gets > when specifying package dependencies), so it shouldn't matter what > the TP says as it is _not_ the definitive source. The build > should fail if the plugin requires v1.2.3 and only 1.2.4 is > available. Yes of course, but plugins doesn't require v1.2.3 it has a range.

We use the .target file to ensure that range is deterministic between builds. > I'd also question why ..x release would break a build. The minor > version should be updated if the API changes. Of course, we > sometimes use non-public API or unreleased API, so these things > can happen. When they do, the plugin with the dependency needs to > be updated to require 1.2.3 as the maximum supported version. Yes - which is where multiple .target files becomes relevant to test such cases.

> Remember, the user can be installing these into any platform that > supports the requirements of the plugins/features being installed. Yes - but thats a separate case. > Target platform is a guideline, not a rule (with the exception for > package dependencies above, but, if the plugin is version > dependent, it should be specifying a version dependency > somewhere). Target platform is the way to specify what build and test against. Thus it is the deciding factor when building and ensuring consistency an we know what we build against. Testing should then be run against updatesites that has minimum and maximum versions and here using it against "real world" updatesites such as eclipse.org etc. /max

TODAY: .target files list all the IUs (feature and plugin) and the "target platform sites" are generated from that listing via XSLT transform to p2.mirror script (uses: maven, ant, xslt). Ant script also provides round-tripping in that the generated site is used to update the .target files w/ the new versions of IUs.

FUTURE: .target files list only top-level "virtual" features, which can be maintained w/ no effort - file never changes unless the URL of the TP site changes (eg., moving from SR0 to SR1 to SR2) or new "virtual" features need to be added (eg., new collections of features added when a new component is added or a new dependency stack is needed, like when we had to add git).

I'll just clarify my requirements/use case, just so there's no ambiguity: 1. Install Eclipse (plugin development, JEE, classic, whatever; knowing I need PDE). 2. Set target platform. 3. Check out a JBT project (e.g. m2e) 4. It compiles. 5. I can run and debug.

Currently, step 4 fails because the target does not include JBoss features/plugins. Setting up a manual target fails because test plugins do not reside in a repository. These have all been discussed at length. I just wanted to summarize my wants (obviously, there is no need since I'm already developing :) ). Best, Rob ----- Original Message ----- > TODAY: > > .target files list all the IUs (feature and plugin) and the "target > platform sites" are generated from that listing via XSLT transform to > p2.mirror script (uses: maven, ant, xslt). Ant script also provides > round-tripping in that the generated site is used to update the > .target > files w/ the new versions of IUs. > > FUTURE: > > .target files list only top-level "virtual" features, which can be > maintained w/ no effort - file never changes unless the URL of the TP > site changes (eg., moving from SR0 to SR1 to SR2) or new "virtual" > features need to be added (eg., new collections of features added > when a > new component is added or a new dependency stack is needed, like when > we > had to add git). > > "target platform sites" are generated using feature.xml + nearly > empty > site.xml to define the collections of features/plugins for the site. > Maintenance can be done the same way that other component / aggregate > sites are done AND we introduce the notion of "ranges of supported > IUs" > AND the idea of being able to combine smaller mini-TPs into larger > ones, > rather than just having one big TP for JBT and another for JBDS. > > N > > On 03/15/2012 12:22 PM, Max Rydahl Andersen wrote: >> Okey, so after reading/hearing about all the concerns I think i >> might have an answer. >> >> Nick/Mistria's concern is that they want to build updatesites >> easily and claim >> building it from .target file is too much overhead, but i'm not >> sure why that is. >> >> My guess is the format of the file is problematic or !? >> >> But afaik they want to build from feature+site.xml instead. >> >> And Denis/Rob/Me would like to have a .target file for various >> reasons (deterministic, >> reproducibility and ease of use for target platform in PDE). >> >> >> Thus my suggestion is: >> >> 1) feature/site.xml is used for building the TP updatesites AND for >> creating matching .target file. >> >> 2) This .target file gets committed and version into what is today >> called targetplatform (if multiple target platforms it should be >> release under different name/versions) >> >> Now both sides are happy. >> >> Only two concerns I can see right now is: >> >> A) #1 above must not result in additional "virtual" features being >> present in the updatesites - whatever features used to define the >> TP is purely an implementation detail. Is that doable? >> >> B) the feature.xml/site.xml is just an ease of use - the .target >> file used in #2 is still the thing that should be used for >> limiting the versions so p2/tycho is deterministic. >> >> Makes sense? >> >> Complaints/other ideas? >> >> /max >> > > -- > Nick Boldt :: JBoss by Red Hat > Productization Lead :: JBoss Tools & Dev Studio > http://nick.divbyzero.com >

But in current state if you also need sources, it is DIY.

TODAY: .target files list all the IUs (feature and plugin) and the "target platform sites" are generated from that listing via XSLT transform to p2.mirror script (uses: maven, ant, xslt). Ant script also provides round-tripping in that the generated site is used to update the .target files w/ the new versions of IUs. FUTURE: .target files list only top-level "virtual" features, which can be maintained w/ no effort - file never changes unless the URL of the TP site changes (eg., moving from SR0 to SR1 to SR2) or new "virtual" features need to be added (eg., new collections of features added when a new component is added or a new dependency stack is needed, like when we had to add git).

"target platform sites" are generated using feature.xml + nearly empty site.xml to define the collections of features/plugins for the site. Maintenance can be done the same way that other component / aggregate sites are done AND we introduce the notion of "ranges of supported IUs" AND the idea of being able to combine smaller mini-TPs into larger ones, rather than just having one big TP for JBT and another for JBDS.

N On 03/15/2012 12:22 PM, Max Rydahl Andersen wrote: > Okey, so after reading/hearing about all the concerns I think i might have an answer. > > Nick/Mistria's concern is that they want to build updatesites easily and claim > building it from .target file is too much overhead, but i'm not sure why that is. > > My guess is the format of the file is problematic or !? > > But afaik they want to build from feature+site.xml instead. > > And Denis/Rob/Me would like to have a .target file for various reasons (deterministic, > reproducibility and ease of use for target platform in PDE). > > > Thus my suggestion is: > > 1) feature/site.xml is used for building the TP updatesites AND for creating matching .target file. > > 2) This .target file gets committed and version into what is today called targetplatform (if multiple target platforms it should be release under different name/versions) > > Now both sides are happy. > > Only two concerns I can see right now is: > > A) #1 above must not result in additional "virtual" features being present in the updatesites - whatever features used to define the TP is purely an implementation detail. Is that doable? > > B) the feature.xml/site.xml is just an ease of use - the .target file used in #2 is still the thing that should be used for limiting the versions so p2/tycho is deterministic. > > Makes sense? > > Complaints/other ideas? > > /max >

I mean sources for TP, not for JBT. As Max suggested before in different thread there should be at least two target platforms: 1. Runtime TP w/o sources 2. Development TP w/ sources

First is used for builds, because it is smaller. Second is for using in eclipse with PDE as a target platform to let developers run and debug the code without requiring to install everything in development environment. I personally have Eclipse SDK, M2E, subversive and Xml Editing Features installed in my development environment.

https://svn.jboss.org/repos/jbosstools/workspace/dgolovin/new-releng what we use now in concord. We just build target-platform and use generated installations as target platform in PDE. It gives us latest version of eclipse rt and sources. We use "installation" target type because PDE in this case doesn't copy bundles to .workspace, it just use direct paths to files in installation (this is not supported by tycho).

On 03/15/2012 10:53 AM, Mickael Istria wrote: > On 03/15/2012 06:47 PM, Denis Golovin wrote: > > But in current state if you also need sources, it is DIY. >

> You can follow this bug: https://issues.jboss.org/browse/JBIDE-8838 > It will probably be closed within a dew days.

> -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat > My blog - My Tweets

> _______________________________________________ > 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

Instead of having multiple TP (one for each need), what about having a very few well-established update-sites and let people create their own TP with it?

For example an AS developer may want the sources of JMX in is TP, whereas a "Usage" developer won't care.