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(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jbosstools-dev
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio