Isn't .example already like ".play" ? At least i am using this. A template for "wrapping" projects would be useful.
Also, we found the coupling of template name + project name + BSN too tight at times: When using .provider for example, you really lose the ability to use sub-bundles in a meaningful way (or you end up with names like provider.provider). Overwriting the BSN totally confuses bndtools.. As always, its a power-play between convenience and flexibility. Toni *Toni Menzel* *www.rebaze.de <http://www.rebaze.de/> | www.rebaze.com <http://www.rebaze.com/> | @rebazeio <https://twitter.com/rebazeio>* On Fri, Jul 1, 2016 at 8:29 AM, Paul F Fraser <[email protected]> wrote: > Hi Peter, > > Do you think a .play extension might be useful for the case where .test > and .application are not suitable. > > For example I am working on some swing bundles and start with the empty > template and then I "play" with the gui's. > > It could be considered a temp bundle in most cases. > > Perhaps it could be like a .application without the REST stuff. > > Paul > > > On 28/06/2016 6:08 PM, Peter Kriens wrote: > > I agree that we’re missing some suffixes. I do it the same way as you do, > create an empty project and then copy and adapt some random bnd file. > > I have identified the following suffixes: > > .lib, .util a bundle where the API === > implementation. E.g. ASM > > Any more ideas? > > Future OSGi enRoute templates should use the new template system. (I need to > convert the existing to this model.) > > Kind regards, > > Peter Kriens > > > > On 28 jun. 2016, at 09:47, Paul F Fraser <[email protected]> > <[email protected]> wrote: > > Hi, > > I have not seen any suggestion for naming "utility" and "non-component > support bundles" in the EnRoute docs. > > Would it be best to just create bundles using the empty template and handle > it that way, without any special bundle naming? > > What is the different use case(s) for using the adapter type name, > considering the functionality is the same as provider? > > Regards > > Paul Fraser > > _______________________________________________ > OSGi Developer Mail > [email protected]https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail > [email protected]https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
