[wildfly-dev] Package name
Tomaž Cerar
tomaz.cerar at gmail.com
Mon Jun 17 16:18:50 EDT 2013
For what?
core? or extensions, or both?
in any case for me org.wildfly.as.* reads as 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>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> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20130617/8eed3ab2/attachment-0001.html
More information about the wildfly-dev
mailing list