[jbosstools-dev] Significant change to location of astools API

[Rob Stryker]

No full packages were renamed.

org.jboss.ide.eclipse.as.core.server was moved into the as.wtp.core 
plugin with the same package.

org.jboss.ide.eclipse.as.core.util had about 90% of its classes moved 
into the as.wtp.core plugin witht eh same package.

Some classes or interfaces, such as ServerAttributeHelper or 
IModulePathFIlter, were moved into the official api packages.

In positive news, we have a yellow build on astools for the first time 
in a LONG time, with only 5 remaining test failures, so it's good to see 
that this move has finally helped push the component in the right 
direction.

On 09/19/2012 10:35 PM, Max Rydahl Andersen wrote:
> what are the packages/class that are being removed/changed ?
>
> /max
>
> On 19 Sep 2012, at 04:57, Rob Stryker <rstryker at redhat.com> wrote:
>
>> Hi All:
>>
>> Regarding JBIDE-11729, JBIDE-11645, JBIDE-12613, and others, I've pushed in a significant file move in astools. For the most part, logic and package names were not changed. There are a few examples where they did change, though. I've done my best to do a usage scan and verify that nobody is using the old classes, but it's     possible I missed one.
>>
>> So what was done exactly?  Basically, because plugins were depending on as.core to use some interface or utility method, an installation of their component would drag in as.core, all our runtime and server types, but NOT the full implementation of as7, due to declarative services.
>>
>> What I've done here is I've moved a large number of interfaces and utility classes from as.core into as.wtp.core plugin. as.core depends on, and re-exports, as.wtp.core, so users depending on the old interfaces should not be affected.
>>
>> In general, what this means is that if a component, like seam, requires ALL of astools to be included if seam-tools are installed, then seam-tools needs to require the astools all-inclusive feature. Depending on plugins alone is NOT enough.
>>
>> If however you JUST need api access, the interfaces or common utility methods, to provide support (but not a full dependency) for astools, then you can depend only on o.j.ide.eclipse.as.wtp.core plugin.
>>
>> Now, I'm not sure how this works in teh build system to be honest, so I'm looking for advice from Nick / Mistria. Does the as.wtp.core/ui plugins need their own low-level feature? Or can other components simply depend on the single plugins?
>>
>> Either way, if you are writing code for a component, and find you want to extend astools or make use of astools support in some way, you have a decision to make. Do you need all of ASTools installed? Or do you only need access to the api / interfaces.
>>
>> If you are only requiring the interfaces, you should depend only on o.j.ide.eclipse.as.wtp.core. If you find that the plugin is missing something that you believe should live there, then you should put in an api request to me to move the code, utility, or extension point from as.core into as.wtp.core. Simply depending on as.core by yourself and using the internal api will lead to problems.
>>
>> What problems, you ask? Well, if you depend on as.core but do NOT depend on the full astools feature, someone installing your component from an update site will get your component + as.core, which includes a half-complete jboss-7 server adapter.
>>
>> So... basically after this recent commit, it is now up to component owners to decide if they need all of astools or just the api. If you THINK you just need api, but many of the classes you need are still in as.core, send me an email and we can discuss it, but it might just be the case that you're forced to require all of astools until the situation can be fixed.
>>
>> As always, I'm here for any questions.
>>
>> - Rob
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev