<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div>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></div>
I am still in favor of having packages named same as modules.<br></div>In case of extensions that would be<br><br>org.wildfly.extension.<name-of-extension><br><br></div>if it goes for core functionality it can use org.wildfly namespace (for package & module name)<br>
<br></div>only question that remains is what do we do with maven groupId<br></div>I would go with group id<br></div>For core:<b>org.wildfly</b><br></div></div></div>For extensions: <b>org.wildfly.extension</b><br><br></div>
That way we can also have clean distinction on what is core server and what are extensions.<br><br></div>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></div>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><div><div><div><div><div><div><div><div><br></div></div></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 29, 2013 at 9:13 PM, Tomaž Cerar <span dir="ltr"><<a href="mailto:tomaz.cerar@gmail.com" target="_blank">tomaz.cerar@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>So <br>org.wildfly.extension.<name> <br></div>would be better fit after all.<br><br><br></div>
<div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 29, 2013 at 8:34 PM, Brian Stansberry <span dir="ltr"><<a href="mailto:brian.stansberry@redhat.com" target="_blank">brian.stansberry@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
<div><div><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" target="_blank">tomaz.cerar@gmail.com</a><br>
>> <mailto:<a href="mailto:tomaz.cerar@gmail.com" target="_blank">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" target="_blank">david.lloyd@redhat.com</a> <mailto:<a href="mailto:david.lloyd@redhat.com" target="_blank">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" target="_blank">wildfly-dev@lists.jboss.org</a> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">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" target="_blank">wildfly-dev@lists.jboss.org</a> <mailto:<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">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>
</div></div><span><font color="#888888">Brian Stansberry<br>
Principal Software Engineer<br>
JBoss by Red Hat<br>
</font></span><div><div>_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">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>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>