[wildfly-dev] Package name
Jason Greene
jason.greene at redhat.com
Mon Jun 17 16:00:43 EDT 2013
IMO we should have gone with org.wildfly.as.*
On Jun 17, 2013, at 2:27 PM, Tomaž Cerar <tomaz.cerar at 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 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 at 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 at 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 at gmail.com
> >> <mailto:tomaz.cerar at 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 at redhat.com <mailto:david.lloyd at 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>.<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 at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
> >> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >> >
> >>
> >>
> >> --
> >> - DML
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at 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
More information about the wildfly-dev
mailing list