[wildfly-dev] Package name

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

[wildfly-dev] Package name

Tomaž Cerar-2
Hi,

What should be package name for new stuff being added to WildFly?

org.wildfly.<subsystem-name>
or
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Package name

David Lloyd-2
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>.<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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Package name

Tomaž Cerar-2
Sounds ok,

probably having org.wildfly.extension.<>

that would too much :)


On Mon, Apr 29, 2013 at 4:07 PM, David M. Lloyd <[hidden email]> 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>.<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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Package name

Tomaž Cerar-2
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 <[hidden email]> wrote:
Sounds ok,

probably having org.wildfly.extension.<>

that would too much :)



On Mon, Apr 29, 2013 at 4:07 PM, David M. Lloyd <[hidden email]> 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>.<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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Package name

Filippe Costa Spolti
In reply to this post by Tomaž Cerar-2
I think that org.wildfly.as sounds good..


2013/4/29 Tomaž Cerar <[hidden email]>
Hi,

What should be package name for new stuff being added to WildFly?

org.wildfly.<subsystem-name>
or
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev




--
Atenciosamente,
______________________________________
Filippe Costa Spolti
Bacharel em Sistemas de Informação
Linux User n°515639 - http://counter.li.org/
[hidden email]
(34)9679-2388

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Package name

David Lloyd-2
In reply to this post by Tomaž Cerar-2
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 <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Sounds ok,
>
>     probably having org.wildfly.extension.<>
>
>     that would too much :)
>
>
>
>     On Mon, Apr 29, 2013 at 4:07 PM, David M. Lloyd
>     <[hidden email] <mailto:[hidden email]>> 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
>          > [hidden email] <mailto:[hidden email]>
>          > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>          >
>
>
>         --
>         - DML
>         _______________________________________________
>         wildfly-dev mailing list
>         [hidden email] <mailto:[hidden email]>
>         https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>


--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Package name

Darran Lofthouse
In reply to this post by Filippe Costa Spolti
Are we going to have other things that use 'org.wildfly' that are not a
part of the application server?

Regards,
Darran Lofthouse.


On 29/04/13 15:17, Spolti wrote:

> I think that org.wildfly.as <http://org.wildfly.as> sounds good..
>
>
> 2013/4/29 Tomaž Cerar <[hidden email] <mailto:[hidden email]>>
>
>     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>.<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
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> --
> Atenciosamente,
> ______________________________________
> Filippe Costa Spolti
> Bacharel em Sistemas de Informação
> Linux User n°515639 - http://counter.li.org/
> [hidden email] <mailto:[hidden email]>
> (34)9679-2388
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Package name

Jaikiran Pai
Hopefully not. Else we'll be back to "JBoss is not just JBoss AS" situation.

I think leaving out the ".as" part from the package name might be a good
idea, since it's redundant given that wildfly itself represents the AS.

-Jaikiran
On Monday 29 April 2013 07:49 PM, Darran Lofthouse wrote:

> Are we going to have other things that use 'org.wildfly' that are not a
> part of the application server?
>
> Regards,
> Darran Lofthouse.
>
>
> On 29/04/13 15:17, Spolti wrote:
>> I think that org.wildfly.as <http://org.wildfly.as> sounds good..
>>
>>
>> 2013/4/29 Tomaž Cerar <[hidden email] <mailto:[hidden email]>>
>>
>>      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>.<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
>>      [hidden email] <mailto:[hidden email]>
>>      https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>>
>> --
>> Atenciosamente,
>> ______________________________________
>> Filippe Costa Spolti
>> Bacharel em Sistemas de Informação
>> Linux User n°515639 - http://counter.li.org/
>> [hidden email] <mailto:[hidden email]>
>> (34)9679-2388
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Package name

jtgreene
Administrator
Thats a good point. Although I think we probably want to reuse the WildFly name for AS sub projects so that every little project we have doesn't have to spend months going through the painful process of coming up with a name and legally clearing it.

On Apr 29, 2013, at 9:29 AM, Jaikiran Pai <[hidden email]> wrote:

> Hopefully not. Else we'll be back to "JBoss is not just JBoss AS" situation.
>
> I think leaving out the ".as" part from the package name might be a good
> idea, since it's redundant given that wildfly itself represents the AS.
>
> -Jaikiran
> On Monday 29 April 2013 07:49 PM, Darran Lofthouse wrote:
>> Are we going to have other things that use 'org.wildfly' that are not a
>> part of the application server?
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>> On 29/04/13 15:17, Spolti wrote:
>>> I think that org.wildfly.as <http://org.wildfly.as> sounds good..
>>>
>>>
>>> 2013/4/29 Tomaž Cerar <[hidden email] <mailto:[hidden email]>>
>>>
>>>     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>.<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
>>>     [hidden email] <mailto:[hidden email]>
>>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>>
>>> --
>>> Atenciosamente,
>>> ______________________________________
>>> Filippe Costa Spolti
>>> Bacharel em Sistemas de Informação
>>> Linux User n°515639 - http://counter.li.org/
>>> [hidden email] <mailto:[hidden email]>
>>> (34)9679-2388
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Package name

Brian Stansberry
In reply to this post by David Lloyd-2
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 <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>      Sounds ok,
>>
>>      probably having org.wildfly.extension.<>
>>
>>      that would too much :)
>>
>>
>>
>>      On Mon, Apr 29, 2013 at 4:07 PM, David M. Lloyd
>>      <[hidden email] <mailto:[hidden email]>> 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
>>           > [hidden email] <mailto:[hidden email]>
>>           > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>           >
>>
>>
>>          --
>>          - DML
>>          _______________________________________________
>>          wildfly-dev mailing list
>>          [hidden email] <mailto:[hidden email]>
>>          https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Package name

Tomaž Cerar-2
So
org.wildfly.extension.<name>
would be better fit after all.




On Mon, Apr 29, 2013 at 8:34 PM, Brian Stansberry <[hidden email]> 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 <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>      Sounds ok,
>>
>>      probably having org.wildfly.extension.<>
>>
>>      that would too much :)
>>
>>
>>
>>      On Mon, Apr 29, 2013 at 4:07 PM, David M. Lloyd
>>      <[hidden email] <mailto:[hidden email]>> 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
>>           > [hidden email] <mailto:[hidden email]>
>>           > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>           >
>>
>>
>>          --
>>          - DML
>>          _______________________________________________
>>          wildfly-dev mailing list
>>          [hidden email] <mailto:[hidden email]>
>>          https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Package name

Tomaž Cerar-2
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 <[hidden email]> wrote:
So
org.wildfly.extension.<name>
would be better fit after all.




On Mon, Apr 29, 2013 at 8:34 PM, Brian Stansberry <[hidden email]> 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 <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>      Sounds ok,
>>
>>      probably having org.wildfly.extension.<>
>>
>>      that would too much :)
>>
>>
>>
>>      On Mon, Apr 29, 2013 at 4:07 PM, David M. Lloyd
>>      <[hidden email] <mailto:[hidden email]>> 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
>>           > [hidden email] <mailto:[hidden email]>
>>           > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>           >
>>
>>
>>          --
>>          - DML
>>          _______________________________________________
>>          wildfly-dev mailing list
>>          [hidden email] <mailto:[hidden email]>
>>          https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>
>>
>
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Package name

jtgreene
Administrator
IMO we should have gone with org.wildfly.as.*

On Jun 17, 2013, at 2:27 PM, Tomaž Cerar <[hidden email]> 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 <[hidden email]> wrote:
> So
> org.wildfly.extension.<name>
> would be better fit after all.
>
>
>
>
> On Mon, Apr 29, 2013 at 8:34 PM, Brian Stansberry <[hidden email]> 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 <[hidden email]
> >> <mailto:[hidden email]>> wrote:
> >>
> >>      Sounds ok,
> >>
> >>      probably having org.wildfly.extension.<>
> >>
> >>      that would too much :)
> >>
> >>
> >>
> >>      On Mon, Apr 29, 2013 at 4:07 PM, David M. Lloyd
> >>      <[hidden email] <mailto:[hidden email]>> 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
> >>           > [hidden email] <mailto:[hidden email]>
> >>           > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>           >
> >>
> >>
> >>          --
> >>          - DML
> >>          _______________________________________________
> >>          wildfly-dev mailing list
> >>          [hidden email] <mailto:[hidden email]>
> >>          https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >>
> >>
> >
> >
>
>
> --
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Package name

Tomaž Cerar-2
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 <[hidden email]> wrote:
IMO we should have gone with org.wildfly.as.*

On Jun 17, 2013, at 2:27 PM, Tomaž Cerar <[hidden email]> 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 <[hidden email]> wrote:
> So
> org.wildfly.extension.<name>
> would be better fit after all.
>
>
>
>
> On Mon, Apr 29, 2013 at 8:34 PM, Brian Stansberry <[hidden email]> 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 <[hidden email]
> >> <mailto:[hidden email]>> wrote:
> >>
> >>      Sounds ok,
> >>
> >>      probably having org.wildfly.extension.<>
> >>
> >>      that would too much :)
> >>
> >>
> >>
> >>      On Mon, Apr 29, 2013 at 4:07 PM, David M. Lloyd
> >>      <[hidden email] <mailto:[hidden email]>> 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
> >>           > [hidden email] <mailto:[hidden email]>
> >>           > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>           >
> >>
> >>
> >>          --
> >>          - DML
> >>          _______________________________________________
> >>          wildfly-dev mailing list
> >>          [hidden email] <mailto:[hidden email]>
> >>          https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>
> >>
> >>
> >
> >
>
>
> --
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Package name

Darran Lofthouse
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 <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     IMO we should have gone with org.wildfly.as.*
>
>     On Jun 17, 2013, at 2:27 PM, Tomaž Cerar <[hidden email]
>     <mailto:[hidden email]>> 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
>     <[hidden email] <mailto:[hidden email]>> wrote:
>      > So
>      > org.wildfly.extension.<name>
>      > would be better fit after all.
>      >
>      >
>      >
>      >
>      > On Mon, Apr 29, 2013 at 8:34 PM, Brian Stansberry
>     <[hidden email] <mailto:[hidden email]>>
>     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
>     <[hidden email] <mailto:[hidden email]>
>      > >> <mailto:[hidden email] <mailto:[hidden email]>>>
>     wrote:
>      > >>
>      > >>      Sounds ok,
>      > >>
>      > >>      probably having org.wildfly.extension.<>
>      > >>
>      > >>      that would too much :)
>      > >>
>      > >>
>      > >>
>      > >>      On Mon, Apr 29, 2013 at 4:07 PM, David M. Lloyd
>      > >>      <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>> 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
>      > >>           > [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>      > >>           > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      > >>           >
>      > >>
>      > >>
>      > >>          --
>      > >>          - DML
>      > >>          _______________________________________________
>      > >>          wildfly-dev mailing list
>      > >> [hidden email]
>     <mailto:[hidden email]>
>     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>      > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      > >>
>      > >>
>      > >>
>      > >
>      > >
>      >
>      >
>      > --
>      > Brian Stansberry
>      > Principal Software Engineer
>      > JBoss by Red Hat
>      > _______________________________________________
>      > wildfly-dev mailing list
>      > [hidden email] <mailto:[hidden email]>
>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >
>      >
>      > _______________________________________________
>      > wildfly-dev mailing list
>      > [hidden email] <mailto:[hidden email]>
>      > 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Package name

Ondrej Zizka
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 <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>      IMO we should have gone with org.wildfly.as.*
>>
>>      On Jun 17, 2013, at 2:27 PM, Tomaž Cerar <[hidden email]
>>      <mailto:[hidden email]>> 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
>>      <[hidden email] <mailto:[hidden email]>> wrote:
>>       > So
>>       > org.wildfly.extension.<name>
>>       > would be better fit after all.
>>       >
>>       >
>>       >
>>       >
>>       > On Mon, Apr 29, 2013 at 8:34 PM, Brian Stansberry
>>      <[hidden email] <mailto:[hidden email]>>
>>      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
>>      <[hidden email] <mailto:[hidden email]>
>>       > >> <mailto:[hidden email] <mailto:[hidden email]>>>
>>      wrote:
>>       > >>
>>       > >>      Sounds ok,
>>       > >>
>>       > >>      probably having org.wildfly.extension.<>
>>       > >>
>>       > >>      that would too much :)
>>       > >>
>>       > >>
>>       > >>
>>       > >>      On Mon, Apr 29, 2013 at 4:07 PM, David M. Lloyd
>>       > >>      <[hidden email] <mailto:[hidden email]>
>>      <mailto:[hidden email] <mailto:[hidden email]>>> 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
>>       > >>           > [hidden email]
>>      <mailto:[hidden email]>
>>      <mailto:[hidden email]
>>      <mailto:[hidden email]>>
>>       > >>           > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>       > >>           >
>>       > >>
>>       > >>
>>       > >>          --
>>       > >>          - DML
>>       > >>          _______________________________________________
>>       > >>          wildfly-dev mailing list
>>       > >> [hidden email]
>>      <mailto:[hidden email]>
>>      <mailto:[hidden email]
>>      <mailto:[hidden email]>>
>>       > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>       > >>
>>       > >>
>>       > >>
>>       > >
>>       > >
>>       >
>>       >
>>       > --
>>       > Brian Stansberry
>>       > Principal Software Engineer
>>       > JBoss by Red Hat
>>       > _______________________________________________
>>       > wildfly-dev mailing list
>>       > [hidden email] <mailto:[hidden email]>
>>       > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>       >
>>       >
>>       > _______________________________________________
>>       > wildfly-dev mailing list
>>       > [hidden email] <mailto:[hidden email]>
>>       > 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Package name

Tomaž Cerar-2

On Tue, Jul 23, 2013 at 3:01 PM, Ondrej Zizka <[hidden email]> wrote:
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


WildFly *IS* application server and not name for new community.

this is exact debate we had earlier in this thread.

only projects that are almost part of AS are allowed to use org.wildfly, like jandex but not other projects.

org.jboss is stil the golden standard for jboss community projects

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] Package name

Darran Lofthouse
So what is the agreed package naming convention where org.wildfly is
used?  ;-)

Regards,
Darran Lofthouse.




On 24/07/13 14:06, Tomaž Cerar wrote:

>
> On Tue, Jul 23, 2013 at 3:01 PM, Ondrej Zizka <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     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
>
>
>
> WildFly *IS* application server and not name for new community.
>
> this is exact debate we had earlier in this thread.
>
> only projects that are almost part of AS are allowed to use org.wildfly,
> like jandex but not other projects.
>
> org.jboss is stil the golden standard for jboss community projects
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev