[wildfly-dev] Package name
Darran Lofthouse
darran.lofthouse at jboss.com
Tue Jul 23 08:15:35 EDT 2013
Where did we get to on this discussion - it looks like we had quite a
bit of support for 'org.wildfly.as', no conclusion seemed to be reached
and code is now using 'org.wildfly.extension'.
Regards,
Darran Lofthouse.
On 17/06/13 21:18, Tomaž Cerar wrote:
> 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 at redhat.com
> <mailto:jason.greene at redhat.com>> wrote:
>
> IMO we should have gone with org.wildfly.as.*
>
> On Jun 17, 2013, at 2:27 PM, Tomaž Cerar <tomaz.cerar at gmail.com
> <mailto: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
> <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 at gmail.com <mailto: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 <mailto: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>
> > >> <mailto: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>
> <mailto: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>
> > >> <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>
> <mailto: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>
> <mailto: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 <mailto:wildfly-dev at lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> >
> > _______________________________________________
> > 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
>
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
More information about the wildfly-dev
mailing list