[wildfly-dev] Package name
Ondrej Zizka
ozizka at redhat.com
Tue Jul 23 09:01:52 EDT 2013
I guess that depends on what will WildFly be in the future.
Will it become an umbrella project with subprojects with modules? ->
org.wildfly.<subproject>.<module>
Will it definitely remain just AS / platform? Both schemes possible
my2c, sorry if stating something obvious ;-)
Ondra
On 23.7.2013 14:15, Darran Lofthouse wrote:
> 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
>>
> _______________________________________________
> 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