M5 spin status :: no aggregate or JBDS installers available yet; many bot and non-UI test failures, plus one inter-build compilation failure
by Nick Boldt
Since turning on the stable branch jobs, here's what's borked...
https://issues.jboss.org/browse/JBIDE-10349
Still trying to get a clean stable_branch aggregate build (and then JBT
builds too) - last time the aggregate failed due to missing Central,
OTDT, and OpenShift (hadn't spun clean yet).
---
Details:
- hibernate : test failure in org.hibernate.eclipse.console.test
- jbpm : test failure in org.jboss.tools.jbpm.convert.test
- jsf : test failure in org.jboss.tools.jsf.vpe.jsf.test
- maven : 15 bot test failures (same failures in trunk) ... should these
just be turned off and only run locally / manually?
- struts : COMPILE FAILED - upstream bits missing? "The import
org.jboss.tools.jst.web.validation cannot be resolved."
---
There are also a few jobs for which the latest build failed, but at
least we have one good build since branching. This suggests we're having
some stability issues w/ a few Jenkins slaves, but at least we're
getting clean spins when the server is quiet(er).
= archives : aborted build? [Dec 4 ok]
= birt : failed to find usage bits (poor timing between builds) [Dec 4 ok]
= seam : no more locks failure [Dec 4 ok]
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
2 weeks, 1 day
Re: [jbosstools-dev] JBoss Nexus Repository Indexer
by Max Rydahl Andersen
> I have been working on https://issues.jboss.org/browse/JBIDE-9309.
> The Source Lookup plugin uses the Nexus indexer to find a source file for a maven artifact.
> The problem happens when I try to debug JBoss AS 7.1 CR1 (or CR1b).
> JBoss AS 7.1.CR1 contains the jbossjts-4.16.0.Final.jar module (the org.jboss.jbossts:jbossjts:4.16.0.Final maven artifact). This artifact exists in the JBoss Maven repository (https://repository.jboss.org/nexus/content/groups/public-jboss), but the Nexus indexer includes this artifact up to version 4.16.0.Beta1. See the attached screenshot.
> There are several jars that aren't included in the indexer. It is possible that m2e doesn't read the indexer properly.
>
> How frequently does this indexer refresh?
Are you asking how often jboss.org refresh their index or how often m2e refresh their index?
I assume your are asking about jboss.org's ?
Thus i've cc'ed in Paul Gier which should know the answer to this.
Paul - how often do we run the jboss repo indexer?
It's used by tools to lookup artifacts thus when they aren't present then things aren't found…
/max
http://about.me/maxandersen
14 years, 1 month
Re: [jbosstools-dev] JBT/JBDS Target Platform for Beta1 -- time to update?
by Denis Golovin
It looks like we really need two target platforms. Minimal based on sr1 to compile against and maximal to run with. Maximal also can be used to assemble JBDS. I remember Max already raised this issue earlier, didn't he?
Denis
Rob Cernich <rcernich(a)redhat.com> wrote:
>> It is all about right version range in manifest. IMO it should be
>> open range with version from Indigo SR0. Now in most cases dev's
>> just use SR1 and when new dependency added pde adds it as open range
>> with lower version from SR1.
>>
>> Denis
>
>Agreed. Developers should be actively selecting the dependency version. It also helps to do a little research to see when a specific feature became available, as this may allow for backward compatibility (e.g. the SwitchYard plugins are fully compatible, although untested, with Eclipse JEE 3.6).
>
>It's probably too much to ask for existing dependencies, but as new dependencies are added, developers should actively select the version required. For existing dependencies, at a minimum, the "release" identifier should be replaced with a "0" unless a specific patch release is required.
>
>Best,
>Rob
14 years, 1 month
Re: [jbosstools-dev] JBT/JBDS Target Platform for Beta1 -- time to update?
by Denis Golovin
It is all about right version range in manifest. IMO it should be open range with version from Indigo SR0. Now in most cases dev's just use SR1 and when new dependency added pde adds it as open range with lower version from SR1.
Denis
Denis Golovin <dgolovin(a)exadel.com> wrote:
>I fixed couple test plugins and now trunk is fine with SR1, but still cannot be compiled against SR0.
>
>Denis
>
>Max Rydahl Andersen <max.andersen(a)redhat.com> wrote:
>
>>I think what Denis is saying is that many more than the plugins that relate to JBIDE-9853 is bumped.
>>
>>That's the problem.
>>
>>i.e. none of our plugins have problems running on SR0 on almost any platform just because SWT 86_64 has a runtime issue when starting up.
>>
>>/max
>>
>>On Jan 28, 2012, at 24:54, Nick Boldt wrote:
>>
>>> That's because there are bug fixes in SR1 on which we depend.
>>>
>>> For example, https://issues.jboss.org/browse/JBIDE-9853
>>>
>>> On 01/27/2012 02:22 PM, Denis Golovin wrote:
>>>> On 01/27/2012 01:13 AM, Max Rydahl Andersen wrote:
>>>>> +1
>>>>>
>>>>> But I would like to make clear this does *not* mean our code should
>>>>> have hard plugin dependencies on
>>>>> SR2.
>>>>>
>>>>> Still much better if our code install and runs from SR0 and upwards.
>>>> Which is not the case right now. Simple test below fails on as component
>>>>
>>>> 1. Download
>>>> http://download.jboss.org/jbosstools/updates/target-platform_3.3.indigo/e...
>>>>
>>>> 2. cd to svn workspace with trunk version
>>>> 3. mvn clean install -Dmaven.test.skip -Dmaven.repo.local=.repository1/
>>>> -Djbosstools-target-site=jar:file///path-to-tp/e370-wtp330.target.zip\!/
>>>>
>>>> Denis
>>>>
>>>>>
>>>>> /max
>>>>>
>>>>> On Jan 26, 2012, at 21:19, Nick Boldt wrote:
>>>>>
>>>>>> OK, but bear in mind I'll still have to do it again after the SR2
>>>>>> bits are actually in the can.
>>>>>>
>>>>>> Pencilling this in for Monday, barring other +1/-1 comments.
>>>>>>
>>>>>> On 01/26/2012 02:22 PM, Len DiMaggio wrote:
>>>>>>> I'd vote for doing this early - in other words next week. It sounds
>>>>>>> like
>>>>>>> it's unlikely that there will be a major issue, but if there is a
>>>>>>> problem it's better to find it sooner.
>>>>>>>
>>>>>>>
>>>>>>> --Len
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>> *From: *"Nick Boldt"<nboldt(a)redhat.com>
>>>>>>> *To: *external-exadel-list(a)redhat.com, "jbds-pm-list"
>>>>>>> <jbds-pm-list(a)redhat.com>, jbosstools-dev(a)lists.jboss.org
>>>>>>> *Sent: *Thursday, January 26, 2012 10:20:39 AM
>>>>>>> *Subject: *JBT/JBDS Target Platform for Beta1 -- time to update?
>>>>>>>
>>>>>>> About a month ago, I created a new Target Platform [1], [2] for use
>>>>>>> with
>>>>>>> our trunk builds so we'd be using the latest from Eclipse.org as they
>>>>>>> move toward SR2.
>>>>>>>
>>>>>>> On Jan 20, the first release candidate (RC1) for Eclipse Indigo SR2 was
>>>>>>> dropped. There are 3 more planned on Feb 3, 10 and 17, with GA on Feb
>>>>>>> 24. Chances are there will be little to no changes between now and
>>>>>>> their GA.
>>>>>>>
>>>>>>> Would next week be a good time to bump up the TPs to newer content? Or
>>>>>>> should we wait until closer to the Feb 16 code freeze? Bear in mind
>>>>>>> we'll want to update AGAIN before we drop Beta1 so that the bits public
>>>>>>> on eclipse.org will match exactly those against which we built.
>>>>>>>
>>>>>>> Note too that changing the TP DURING a QE cycle will guarantee a respin
>>>>>>> is needed.
>>>>>>>
>>>>>>> [1]
>>>>>>> http://download.jboss.org/jbosstools/updates/target-platform_3.3.indigo.S...
>>>>>>>
>>>>>>> [2]
>>>>>>> http://www.qa.jboss.com/binaries/RHDS/updates/jbds-target-platform_3.3.in...
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Nick Boldt :: JBoss by Red Hat
>>>>>>> Productization Lead :: JBoss Tools& Dev Studio
>>>>>>> http://nick.divbyzero.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Len DiMaggio (ldimaggi(a)redhat.com)
>>>>>>> JBoss by Red Hat
>>>>>>> 314 Littleton Road
>>>>>>> Westford, MA 01886 USA
>>>>>>> tel: 978.392.3179
>>>>>>> cell: 781.472.9912
>>>>>>> http://www.redhat.com
>>>>>>> http://community.jboss.org/people/ldimaggio
>>>>>>>
>>>>>>> <http://www.redhat.com>
>>>>>>>
>>>>>> --
>>>>>> Nick Boldt :: JBoss by Red Hat
>>>>>> Productization Lead :: JBoss Tools& Dev Studio
>>>>>> http://nick.divbyzero.com
>>>>>>
>>>>> /max
>>>>> http://about.me/maxandersen
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>> http://nick.divbyzero.com
>>> _______________________________________________
>>> jbosstools-dev mailing list
>>> jbosstools-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>>
>>>
>>
>>/max
>>http://about.me/maxandersen
>>
>>
>>
>
>_______________________________________________
>jbosstools-dev mailing list
>jbosstools-dev(a)lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/jbosstools-dev
14 years, 1 month
Re: [jbosstools-dev] JBT/JBDS Target Platform for Beta1 -- time to update?
by Denis Golovin
I fixed couple test plugins and now trunk is fine with SR1, but still cannot be compiled against SR0.
Denis
Max Rydahl Andersen <max.andersen(a)redhat.com> wrote:
>I think what Denis is saying is that many more than the plugins that relate to JBIDE-9853 is bumped.
>
>That's the problem.
>
>i.e. none of our plugins have problems running on SR0 on almost any platform just because SWT 86_64 has a runtime issue when starting up.
>
>/max
>
>On Jan 28, 2012, at 24:54, Nick Boldt wrote:
>
>> That's because there are bug fixes in SR1 on which we depend.
>>
>> For example, https://issues.jboss.org/browse/JBIDE-9853
>>
>> On 01/27/2012 02:22 PM, Denis Golovin wrote:
>>> On 01/27/2012 01:13 AM, Max Rydahl Andersen wrote:
>>>> +1
>>>>
>>>> But I would like to make clear this does *not* mean our code should
>>>> have hard plugin dependencies on
>>>> SR2.
>>>>
>>>> Still much better if our code install and runs from SR0 and upwards.
>>> Which is not the case right now. Simple test below fails on as component
>>>
>>> 1. Download
>>> http://download.jboss.org/jbosstools/updates/target-platform_3.3.indigo/e...
>>>
>>> 2. cd to svn workspace with trunk version
>>> 3. mvn clean install -Dmaven.test.skip -Dmaven.repo.local=.repository1/
>>> -Djbosstools-target-site=jar:file///path-to-tp/e370-wtp330.target.zip\!/
>>>
>>> Denis
>>>
>>>>
>>>> /max
>>>>
>>>> On Jan 26, 2012, at 21:19, Nick Boldt wrote:
>>>>
>>>>> OK, but bear in mind I'll still have to do it again after the SR2
>>>>> bits are actually in the can.
>>>>>
>>>>> Pencilling this in for Monday, barring other +1/-1 comments.
>>>>>
>>>>> On 01/26/2012 02:22 PM, Len DiMaggio wrote:
>>>>>> I'd vote for doing this early - in other words next week. It sounds
>>>>>> like
>>>>>> it's unlikely that there will be a major issue, but if there is a
>>>>>> problem it's better to find it sooner.
>>>>>>
>>>>>>
>>>>>> --Len
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> *From: *"Nick Boldt"<nboldt(a)redhat.com>
>>>>>> *To: *external-exadel-list(a)redhat.com, "jbds-pm-list"
>>>>>> <jbds-pm-list(a)redhat.com>, jbosstools-dev(a)lists.jboss.org
>>>>>> *Sent: *Thursday, January 26, 2012 10:20:39 AM
>>>>>> *Subject: *JBT/JBDS Target Platform for Beta1 -- time to update?
>>>>>>
>>>>>> About a month ago, I created a new Target Platform [1], [2] for use
>>>>>> with
>>>>>> our trunk builds so we'd be using the latest from Eclipse.org as they
>>>>>> move toward SR2.
>>>>>>
>>>>>> On Jan 20, the first release candidate (RC1) for Eclipse Indigo SR2 was
>>>>>> dropped. There are 3 more planned on Feb 3, 10 and 17, with GA on Feb
>>>>>> 24. Chances are there will be little to no changes between now and
>>>>>> their GA.
>>>>>>
>>>>>> Would next week be a good time to bump up the TPs to newer content? Or
>>>>>> should we wait until closer to the Feb 16 code freeze? Bear in mind
>>>>>> we'll want to update AGAIN before we drop Beta1 so that the bits public
>>>>>> on eclipse.org will match exactly those against which we built.
>>>>>>
>>>>>> Note too that changing the TP DURING a QE cycle will guarantee a respin
>>>>>> is needed.
>>>>>>
>>>>>> [1]
>>>>>> http://download.jboss.org/jbosstools/updates/target-platform_3.3.indigo.S...
>>>>>>
>>>>>> [2]
>>>>>> http://www.qa.jboss.com/binaries/RHDS/updates/jbds-target-platform_3.3.in...
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Nick Boldt :: JBoss by Red Hat
>>>>>> Productization Lead :: JBoss Tools& Dev Studio
>>>>>> http://nick.divbyzero.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Len DiMaggio (ldimaggi(a)redhat.com)
>>>>>> JBoss by Red Hat
>>>>>> 314 Littleton Road
>>>>>> Westford, MA 01886 USA
>>>>>> tel: 978.392.3179
>>>>>> cell: 781.472.9912
>>>>>> http://www.redhat.com
>>>>>> http://community.jboss.org/people/ldimaggio
>>>>>>
>>>>>> <http://www.redhat.com>
>>>>>>
>>>>> --
>>>>> Nick Boldt :: JBoss by Red Hat
>>>>> Productization Lead :: JBoss Tools& Dev Studio
>>>>> http://nick.divbyzero.com
>>>>>
>>>> /max
>>>> http://about.me/maxandersen
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>> http://nick.divbyzero.com
>> _______________________________________________
>> jbosstools-dev mailing list
>> jbosstools-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>>
>
>/max
>http://about.me/maxandersen
>
>
>
14 years, 1 month
Fwd: [wtp-dev] WTP repo to be non-greedy for Juno M5
by Max Rydahl Andersen
changes at eclipse.org which might affect us - at least for Juno.
…and I wonder if we are publishing greedy or non-greedy at the moment for our sites?
Begin forwarded message:
> From: David M Williams <david_williams(a)us.ibm.com>
> Subject: [wtp-dev] WTP repo to be non-greedy for Juno M5
> Date: January 23, 2012 22:16:32 GMT+01:00
> To: wtp-dev(a)eclipse.org
> Reply-To: "General discussion of project-wide or architectural issues." <wtp-dev(a)eclipse.org>
>
>
>
> [I have sent a similar note to "cross project" list, but in case anyone
> follows wtp-dev, but not cross-project list, I'll repeat it here.]
>
> WTP has updated to a Juno based p2 publisher so the repository it produces
> will treat optional dependencies as "non greedy".
>
> See bug 247099 [1] and the p2 Publisher wiki [2] for some history and
> details on this issue of greedy vs. non-greedy requirements.
>
> The change in WTP build was documented in bug 369171 [3].
>
> In short, p2 assumes greedy='true' if it is not specified and in the past
> the publisher did not specify it, so there have been many cases in the past
> where users and adopters get things installed that they did not want or
> need. Plus, it would depend on which repo was "pointed to" or what was
> available in that repo at the time of the install, making installs
> indeterminate. Rather than change the way p2 works (which would have had
> compatibility issues) it was decided to change the way the p2 publisher
> works.
>
> Most of the time, this change will be nothing but goodness ... and does not
> change WTP itself ... but I'm giving this notice since the change in the
> repo metadata does have the potential to "break" someone downstream ... or,
> at least, not work as expected.
>
> Potentially it could effect builds, if you use p2 to fetch pre-reqs and if
> you really required some optional thing, but did not specify it
> explicitly, you might have been getting it "by accident" before, due to a
> bundle having it as an optional dependencies.
>
> The more likely impact would be in distribution packages or user installs
> which might have the same issue, of wanting something they got before "by
> accident" but would not now be installed, unless explicitly specified in a
> feature.
>
> The fix, if any required, in most cases will be to add some missing
> optional item to your feature; sometimes it would be an existing feature,
> but
> often might be a new feature, in order to let users or adopters decide if
> they want that optional thing or not.
>
> If you do encounter an issue where this change effects your project or
> adoptions, especially in a negative way, please leave a note in bug 369171
> so we
> understand unanticipated impacts.
>
> Thanks,
>
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=247099
> [2] http://wiki.eclipse.org/Equinox/p2/Publisher
> [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=369171
>
>
> _______________________________________________
> wtp-dev mailing list
> wtp-dev(a)eclipse.org
> https://dev.eclipse.org/mailman/listinfo/wtp-dev
/max
http://about.me/maxandersen
14 years, 1 month
JBIDE-10668 - minor tweak to target platform to get newer Eclipse platform bits
by Nick Boldt
Due to an oversight, I downloaded an updated version of Eclipse 3.7.2M
in December but did not include it in the requirements mirror.
As such, we composite
3.7.2.M20111201-1437/plugins/com.jcraft.jsch_0.1.41.v201101211617.jar
instead of
3.7.2.M20111214-1406/plugins/com.jcraft.jsch_0.1.44.v201101211721.jar
However, while the target platform already includes the newer of the
two, respinning the TP will likely pull in new Eclipse features that
changed between Dec 1 and Dec 14.
So, to avoid Max yelling at me again for making a seemingly trivial
update to the TP without prior announcement, I'm making a prior
announcement before making a seemingly trivial update to the TP.
I'll be bumping up the version of Eclipse in the TP from the Dec 1 level
to the Dec 14 level some time before Monday (eg., tomorrow or over the
weekend).
Objections? Please file them here or in JBIDE-10668.
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
14 years, 1 month
Need to find a better solution than taking latest trunk and push to examples site
by Max Rydahl Andersen
Hi,
Today Fred was experimenting with changing project examples for some improvements in B1.
That included renaming some categories which he changed, committed to svn trunk and then later today
I got 1,2,3 and now 4 mails about examples being broken in M5.
Why ?
Because we have some automatic update script running that takes whatever is latest in trunk and pushes to the examples site.
We really need to find a better solution for this!
I say *disable* the job and have it only update at controlled times - not automatically.
Anything that needs to use it should have a flag/property to override the urls needed to do local testing.
But I know that does not scale well - anyone with a bright idea on how to fix this better ?
/max
http://about.me/maxandersen
14 years, 1 month