[jbosstools-dev] Included features considered harmful (AS, BPEL, jBPM & JSF, please read)

[Nick Boldt]

Rob:

You could also look at the update site from Beta1 as a zip, and compare 
that to the update site (or zip) you create locally after applying your 
fixes to your features. I heartily recommend using Beyond Compare (from 
scootersoftware.com) for doing these comparisons as it can be configured 
to ignore dates/times and simply compare file sizes, then file contents. 
It can also recurse into zips and jars and compare those contents too. 
It's diff on steroids - even does image compares and 3-way compares.

If anything is missing, you have a potential problem. However, as long 
as the no-longer-included stuff can be found on an upstream composite 
site [1] and can be aggregated [2], [3] then you should be fine.

[1] http://download.jboss.org/jbosstools/builds/staging/_composite_/trunk/
[2] http://download.jboss.org/jbosstools/updates/nightly/core/trunk/
[3] http://download.jboss.org/jbosstools/updates/webtools/indigo/

Because AS Tools gets aggregated into TWO sites -- the main JBT Core 
site [2] and the smaller Webtools site (used by WTP) [3], you need to 
build both of these locally and test installing from them to ensure you 
get everything you expect.

To build locally, look in this pom.xml [4] for instructions.

[4] http://anonsvn.jboss.org/repos/jbosstools/trunk/build/aggregate/pom.xml

cd ~/trunk/build/aggregate; mvn clean install -f webtools-site/pom.xml


On 03/21/2012 05:00 AM, Max Rydahl Andersen wrote:
>
> On Mar 21, 2012, at 8:47 AM, Rob Stryker wrote:
>
>> I'm ASTools component lead, but I didn't set up the dependencies / plugins initially... I just continued whatever practice was in place without thinking much on it.  I don't know of any issues that require inclusion in this component, and as far as I know it's always been this way.
>
> in the past we did not have fully mirrored eclipse dependencies - we do now and thus its not that much required anymore to have the "inclusion" specified.
>
>> It seems dependency should be fine, but I'll need to test post-build to ensure nothing is broken. Honestly I'm not even sure how to test aside from a normal smoke test, since I'm uncertain of what kind of use cases might break from this change. I'm not very familiar on the exact osgi / eclipse rules governing this.
>>
>> Are there any pro-tips on what use cases might be broken by this?
>
> it affects the generated updatesite zip and how p2 behaves when installing from updatesite.
>
> so check installation from those two and see if there are differences when using them (i.e. disable "check other sites" to be sure you aren't just seeing eclipse fetching the dependencies from elsewhere)
>
> /max
>
>>
>> On 03/20/2012 07:19 PM, Mickael Istria wrote:
>>> On 03/20/2012 11:33 AM, Max Rydahl Andersen wrote:
>>>> either open a jira for these modules with a patch or send the fisheye changeset here when done so its easy to look at.
>>> Issue created. If you are concerned, please watch it: https://issues.jboss.org/browse/JBIDE-11358
>>>
>>> --
>>> Mickael Istria
>>> Eclipse developer at JBoss, by Red Hat
>>> My blog - My Tweets
>>>
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>>
>>> jbosstools-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

-- 
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com