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