Re: [wildfly-dev] Package name

For what? core? or extensions, or both? in any case for me org.wildfly.as.* reads as org.as.as <http://org.as.as> but that might be just me :-) On Mon, Jun 17, 2013 at 10:00 PM, Jason Greene <jason.greene(a)redhat.com <mailto:jason.greene@redhat.com>> wrote: IMO we should have gone with org.wildfly.as.* On Jun 17, 2013, at 2:27 PM, Tomaž Cerar <tomaz.cerar(a)gmail.com <mailto:tomaz.cerar@gmail.com>> wrote: > I am reviving this thread as I think we have still don't have *definitive* guideline on how packages & modules should be named. > > I am still in favor of having packages named same as modules. > In case of extensions that would be > > org.wildfly.extension.<name-of-extension> > > if it goes for core functionality it can use org.wildfly namespace (for package & module name) > > only question that remains is what do we do with maven groupId > I would go with group id > For core:org.wildfly > For extensions: org.wildfly.extension > > That way we can also have clean distinction on what is core server and what are extensions. > > I am reviving this discussion after chat I had with Eduardo over the weekend on how new functionality for EE extension should be organized. > > as logging of #wildfly-dev doesn't work i am pasting transcript here: > ----------- > emmartins: "Also we should not use org.wildfly.as <http://org.wildfly.as> package given that wildfly already implies application server so if anything then org.wildfly.concurrent or even better org.wildfly.extension.ee.concurrent" > just logged to chat on this > +ctomc: sure > org.wildfly.as <http://org.wildfly.as> is in anycase a no-go > emmartins: y, that was settled > +ctomc: given that org.wildfly already impls app server :) > but this conncurent stuff? > emmartins: well, not truly the "as" > +ctomc: this is part of ee extension isn't it? > emmartins: thought I saw Jason saying that wildfly could be used for stuff not in the as code base > +ctomc: where? > emmartins: for instance stuff like a reusable api > that's really my doubt > will these continue to use org.jboss instead > +ctomc: afaik the only non-as stuff that should be using org.wildfly ware external projects that are really tightly coupled to wildfly > like jandex > for instance > emmartins: well, probably metadata could be considered also similar > ejb client > +ctomc: yup > but that really tightly coupled to AS in any case > hardly usable outside of it > in general there are few cases but not much > emmartins: to me the "as" would be a safe extension point to future usages > +ctomc: threre should bo no non-as stuff using org.wildfly package > and org.wildfly.as <http://org.wildfly.as> sounds to me same as > org.as.as <http://org.as.as> :) > bit reduntant ;) > emmartins: asas is a cool name > means wings in portuguese > +ctomc: given that we are not top level project we could go one package up ;) > he he he > asas, nice :D > in any case > emmartins: red bull da-te asas > red bull gives you wings > ;) > +ctomc: wildfly is in general split in two parts > core & extensions > emmartins: and modules > +ctomc: modules are dependancies > so not really matter from source code point of view > emmartins: but I agree to leave these ones untagged as modules, never know what's the future of it > +ctomc: so basicly core should be using org.wildfly.<name-of-functionality> packe > extensnios should be org.wildfly.extension.<extensnion-name>.<whatever> > yeah module names that existed before should not be renamed > only new ones should go under new "package" name > emmartins: in this case I already agreed with brian and jason, org.wildfly.ee.concurrent in package, I guess brian also agreed yesterday with same as module name > +ctomc: does not like it :( > +ctomc: i talked with brian about this at judcon (as he was writing your reply) > emmartins: oh really? lol > +ctomc: yeah i was insisting on rename of packages :) > he just commented on it > i didn't have laptop with me > i think confiusion is based on what exactly is this code part of > is this part of core or extensnio > is this is part of EE extension > or ee subsystem if you like > then imho it should not use org.wildfly.ee <http://org.wildfly.ee> > as that would imply that ee is part of core wildfly which we all know it is not > emmartins: being honest, this code was made for both threads and ee > +ctomc: given that we want to release wildfly "core" distribtion sometime in future > emmartins: but I reverted my opinion of using also threads > +ctomc: threads are part of core > so that is why i ask if this is part of extensnio or not ;) > emmartins: but then dmlloyd considers ee is already wrapping too much functionality > +ctomc: and concurrent apis are also bit general so i am not really sure what it should be > emmartins: this concurrent is truly EE only > +ctomc: so i would move it to different package > emmartins: that's the reason why I gave up of reusing threads to manage the low levels resources i.e. thread pools > +ctomc: but I will leave it to others as this case is bit on the edge > emmartins: I guess the big question is, do we break ee now, or do we add again more stuff, stuff that is this case is already done 100% independent, has its own big unit testsuite (250), etc > +ctomc: break as in spliting package? or break as in break into many extensions? > emmartins: I was thinking single extension + independent functionality modules > +ctomc: that makes sense > and if we plan to do that, we should do it asap > emmartins: well, as long as EE module exports functionality submodules > it can be broken anytime > +ctomc: true > but it is easier to split it when you have new functionality > and in this case you could have new module that would be in new namespace as it is new functinailty > emmartins: to split now would mean to consider ee as just a parent maven module? > +ctomc: but still retain old module names for older stuff > basicly yeah > emmartins: ee/core , ee/concurrency > +ctomc: jpa already does that > emmartins: vs ee + ee-concurrency > ok, I think we captured all the point of views of this arguing > emmartins: you know what's the next step > +ctomc: i know ;) > emmartins: :) > copy paste into wildfly-dev mail list > ---- > > > > On Mon, Apr 29, 2013 at 9:13 PM, Tomaž Cerar <tomaz.cerar(a)gmail.com <mailto:tomaz.cerar@gmail.com>> wrote: > So > org.wildfly.extension.<name> > would be better fit after all. > > > > > On Mon, Apr 29, 2013 at 8:34 PM, Brian Stansberry <brian.stansberry(a)redhat.com <mailto:brian.stansberry@redhat.com>> wrote: > Keep in mind that an extension can define more than one subsystem, and a > module can define more than one extension. > > As an example of the latter, org.jboss.as.connector:main uses 3 lines in > the META-INF/services/org.jboss.as.controller.Extension file to define 3 > extension impls. Each of those registers a single subsystem. > > That same thing could have been done differently by having a single > Extension impl that registered 3 subsystems. If that had been done, the > extension impl would not fit nicely in an org.wildfly.subsystem.<blah> > package. > > On 4/29/13 9:18 AM, David M. Lloyd wrote: > > I guess. Keeping in mind that eventually extensions will (possibly) be > > loaded by assembled module name, so they may have to change again at > > some point. > > > > On 04/29/2013 09:16 AM, Tomaž Cerar wrote: > >> probably same should also apply to module names. > >> > >> so we would have org.wildfly.subsystem.<name> > >> > >> > >> On Mon, Apr 29, 2013 at 4:09 PM, Tomaž Cerar <tomaz.cerar(a)gmail.com <mailto:tomaz.cerar@gmail.com> > >> <mailto:tomaz.cerar@gmail.com <mailto:tomaz.cerar@gmail.com>>> wrote: > >> > >> Sounds ok, > >> > >> probably having org.wildfly.extension.<> > >> > >> that would too much :) > >> > >> > >> > >> On Mon, Apr 29, 2013 at 4:07 PM, David M. Lloyd > >> <david.lloyd(a)redhat.com <mailto:david.lloyd@redhat.com> <mailto:david.lloyd@redhat.com <mailto:david.lloyd@redhat.com>>> wrote: > >> > >> Maybe do: > >> > >> org.wildfly.subsystem.<blah> > >> > >> because there will be wildfly stuff which isn't subsystems and which > >> might have names that conflict. I'd even suggest > >> "org.wildfly.as.subsystem..." but that might be too much. > >> > >> On 04/29/2013 08:58 AM, Tomaž Cerar wrote: > >> > Hi, > >> > > >> > What should be package name for new stuff being added to WildFly? > >> > > >> > org.wildfly.<subsystem-name> > >> > or > >> > org.wildfly.as <http://org.wildfly.as> <http://org.wildfly.as> > >> <http://org.wildfly.as>.<subsystem-name> > >> > or something else? > >> > > >> > I would go for org.wildfly.<subsystem-name> > >> > > >> > > >> > > >> > this mostly applies to new subsystems and as we agreed we > >> won't rename > >> > packages for existing code until it break compatibility. > >> > > >> > > >> > > >> > -- > >> > tomaz > >> > > >> > > >> > _______________________________________________ > >> > wildfly-dev mailing list > >> > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> > >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > > >> > >> > >> -- > >> - DML > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> <mailto:wildfly-dev@lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>> > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > >> > >> > > > > > > > -- > Brian Stansberry > Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev