Community
Participate
Working Groups
Code Recommenders has to be associated to with a category for Juno p2 repository. For the moment, we put Code Recommenders' features under "General Purpose Tools" category. This category, however, seems not to be a good fit since our tools a tightly coupled to JDT. "Language Tools" targets complete language support, e.e., for Java, Ruby, C etc. Putting Code Recommenders in here seems to break the granularity of that category. I think a category like "Java Tools" describes best what we offer. But this does not exist. Where should we put Code Recommenders? Thanks, Marcel
I like the idea. We have a lot of tools which would fit into this category and it targets a very important class of users. "Java Development" seems to align better with the existing naming.
(In reply to comment #1) > I like the idea. We have a lot of tools which would fit into this category and > it targets a very important class of users. > "Java Development" seems to align better with the existing naming. I would like to avoid adding a category per language. If we start with Java, then others will follow and the category list will explode and defeat its purpose. I think you could simply add Code Recommenders to the 'Programming Languages' category. JDT is also in there.
If everyone is fine with that (i.e., no-one stands up), I'd move our feature(s) into this category. Two more questions: 1. What is the proposed feature granularity? We have various completion engines, code search client and an extended documentation platform. At the moment we have one feature for each tool - this would result in 7++ features at the end. I guess this would be too much. Grouping them into 1-3 features seems reasonable to me. How many features would be OK to add to Juno? 1, 3, 7? 2. Where should we put the 3rd party dependencies? Currently we have two features, one for dependencies to Orbit and one to dependencies that we did not (yet) publish there. Currently I added them to Juno w/o category. Is this the intended way to ensure that they are on the Juno update site?
(In reply to comment #3) > If everyone is fine with that (i.e., no-one stands up), I'd move our feature(s) > into this category. > Into what category? If you mean existing "Language Tools" I'd say fine, if you mean creating new "Java Tools" category then I'll stand up. :) Doesn't seem enough consensus for that. > Two more questions: > > 1. What is the proposed feature granularity? > We have various completion engines, code search client and an extended > documentation platform. At the moment we have one feature for each tool - this > would result in 7++ features at the end. I guess this would be too much. > Grouping them into 1-3 features seems reasonable to me. > How many features would be OK to add to Juno? 1, 3, 7? > There's no good answer other than "what would your users and adopters want?" It might depend on how "large" each feature was? Generally, the fewer the better (to make user's choices easier), as long as doesn't result in huge footprint or unwanted clutter. Also, _might_ interact with what adopters might want ... I have known of some cases where projects provide one (or a few) features for repository site, but that feature simply "includes" the fine grained features, in case adopters have a need for just one or two of the fine grained ones. > > 2. Where should we put the 3rd party dependencies? > Currently we have two features, one for dependencies to Orbit and one to > dependencies that we did not (yet) publish there. Currently I added them to > Juno w/o category. Is this the intended way to ensure that they are on the Juno > update site? I suspect you need to change your (main) features to "include" your third party dependencies? (But, I could be misunderstanding) As far as I know, that is the only way to make sure someone who installs your feature gets your third party dependencies? [This might be a question to ask on cross-project list, if it is more of a "how to" question.]. But, yes, in general, you can certainly put features (or even bundles) in the repo, without them being in a category. HTH
(In reply to comment #4) > (In reply to comment #3) > > If everyone is fine with that (i.e., no-one stands up), I'd move our feature(s) > > into this category. > > > > Into what category? If you mean existing "Language Tools" I'd say fine, if you > mean creating new "Java Tools" category then I'll stand up. :) Doesn't seem > enough consensus for that. I'm sorry, my answer was too short. I meant "If everyone is fine with Language Tools, I'd move our features into this category as proposed by Dani." > > > Two more questions: > > > > 1. What is the proposed feature granularity? > > How many features would be OK to add to Juno? 1, 3, 7? > > There's no good answer other than "what would your users and adopters want?" It > might depend on how "large" each feature was? Generally, the fewer the better > (to make user's choices easier), as long as doesn't result in huge footprint or > unwanted clutter. Also, _might_ interact with what adopters might want ... I > have known of some cases where projects provide one (or a few) features for > repository site, but that feature simply "includes" the fine grained features, > in case adopters have a need for just one or two of the fine grained ones. That sounds like having a "Juno Umbrella Feature" that subsumes all sub-features into one single feature. I'll create a such a feature for Juno. > > 2. Where should we put the 3rd party dependencies? > > I suspect you need to change your (main) features to "include" your third party > dependencies? Ok. It sounds like the common way how to do it. I'll add them to the features. I'm closing this bug as I think I know how to continue. Thanks for your help.
"Language Tools" -- > "Programming Languages"
> That sounds like having a "Juno Umbrella Feature" that subsumes all > sub-features into one single feature. I'll create a such a feature for Juno. Sounds good to me. JDT also only ships as one single feature.
