Re: [wildfly-dev] Package name

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 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 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 sounds to me same as 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 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&gt; wrote: