[wildfly-dev] Mixing org.jboss.as and org.wildfly packages

[Brian Stansberry]

> On Apr 3, 2017, at 10:16 AM, Dimitris Andreadis <dandread at redhat.com> wrote:
> 
> Be careful of backwards compatibility!
> 

Particularly with testsuite/shared in core. Best leave that alone.

Other testsuite modules shouldn’t be being used anywhere outside their own code base so breaking stuff is less of a concern.

>From Stuart’s original post I believe this is only about testsuite.

> On 03/04/2017 12:32, Stuart Douglas wrote:
>> I mean for maven modules in the Wildfly code base that were using the
>> org.jboss.as <http://org.jboss.as> package, and are now using a mix of
>> the two.
>> 
>> Stuart
>> 
>> On Mon, Apr 3, 2017 at 7:18 PM, Darran Lofthouse
>> <darran.lofthouse at jboss.com <mailto:darran.lofthouse at jboss.com>> wrote:
>> 
>>    Is this just for code added to existing testsuite projects or new
>>    projects as well?
>> 
>>    If the latter may be better to coordinate a suitable time with Kabir
>>    a change like this could be applied.
>> 
>>    Regards,
>>    Darran Lofthouse.
>> 
>> 
>> 
>>    On 03/04/17 02:45, Stuart Douglas wrote:
>> 
>>        Hi,
>> 
>>        So this is a minor issue, but it annoys me so I thought I would
>>        see what
>>        other people think about it. In the test suite I have noticed
>>        that some
>>        new code is being added under the org.wildfly package, even
>>        though all
>>        the existing code is still under org.jboss.as
>>        <http://org.jboss.as> <http://org.jboss.as>.
>> 
>>        I don't think this is a good idea, as it means there is two
>>        potential
>>        places to look for something, with no real reason why something
>>        is in a
>>        particular package other than the date it was added.
>> 
>>        I propose that we move all the org.wildfly code into
>>        org.jboss.as <http://org.jboss.as>
>>        <http://org.jboss.as> to keep everything consistent (moving
>>        everything
>>        to org.wildfly would also be an option, but it has implications for
>>        backporting and has the potential to create a lot more work).
>> 
>>        Does anyone have any objections to this? If not I will prepare
>>        some PR's.
>> 
>>        Stuart
>> 
>> 
>>        _______________________________________________
>>        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
>>        <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
>> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
JBoss by Red Hat