Hibernate tools component build failures
by Denis Golovin
Dima,
could you take care of hibernate tools compilation errors. It's been
failing since May 30th. Looks like internal API was changed between Dali
releases.
[WARNING] The requested profile "unified.site" could not be activated because it does not exist.
[ERROR] Failed to execute goal org.sonatype.tycho:maven-osgi-compiler-plugin:0.10.0:compile (default-compile) on project org.jboss.tools.hibernate.jpt.core: Compilation failure: Compilation failure:
[ERROR] /qa/hudson_ws/workspace/jbosstools-3.3_trunk.component--hibernatetools/sources/plugins/org.jboss.tools.hibernate.jpt.core/src/org/jboss/tools/hibernate/jpt/core/internal/context/java/HibernateJavaQueryContainerImpl.java (at line 309):[-1,-1]
[ERROR] public Iterator<JavaQuery> queries() {
[ERROR] ^^^^^^^^^
[ERROR] The method queries() of type HibernateJavaQueryContainerImpl must override or implement a supertype method
[ERROR]
[ERROR] /qa/hudson_ws/workspace/jbosstools-3.3_trunk.component--hibernatetools/sources/plugins/org.jboss.tools.hibernate.jpt.core/src/org/jboss/tools/hibernate/jpt/core/internal/context/java/AbstractHibernateNamedQueryImpl.java (at line 25):[-1,-1]
[ERROR] public class AbstractHibernateNamedQueryImpl<T extends HibernateQueryAnnotation> extends AbstractJavaQuery<T>
Thanks
Denis
14 years, 5 months
JBT 3.2.1.CR1 / JBDS 4.1.0.CR1 status
by Nick Boldt
CR1 status: GREEN!
----
Aside from some builds that have failed for no good reason (and are
being respun to prove to me it's no good reason, just a Hudson snafu or
swimlane problem), we're essentially ready for CR1.
Found a minor (and probably intermittent) test failure
(https://issues.jboss.org/browse/JBIDE-9043) but I've set that for CR2.
Looks like JBT and JBDS builds are all blue, except for these respins [0]:
* examples,
* maven,
* seam (used to have 362 tests but last good build only had 294 [1])
* smooks,
* struts,
* teiid 7.4,
* continuous (all-in-one compilation test), and
* tests (all-in-one all tests)
[0]
http://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Stable_Br...
[1]
http://hudson.qa.jboss.com/hudson/view/DevStudio/view/DevStudio_Stable_Br...
So, we should be good to go tomorrow after the
US-morning/Europe-afternoon status meeting to declare a build for QE.
The usual URLs for nightlies are in play, but after that declaration
I'll move stuff into a stable folder so it won't disappear & QE can
begin testing, and we'll reopen for CR2 work.
Cheers,
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
14 years, 5 months
Re: [jbosstools-dev] .drl code completion broken in latest drools ?
by Max Rydahl Andersen
> Luckily Drools 5.2.x is also on codefreeze ;)
>
> We released Drools 5.2.0.CR1 last Friday, and final should be released end of this week.
> So I would recommend these as stable tags, preferring 5.2.0 final if that can still make it in, but the differences should be minimal.
5.2.0.CR1 is what we can take in for our CR1 (building today/tonight) - we will have a CR2 where we can drag in your final.
Currently it seems we are picking it up from your hudson jobs directly - I assume that is the wrong place then ;)
Are you and Nick synced on where he should take bits from and what builds to use ?
/max
>
> Kris
>
> Max Rydahl Andersen wrote:
>>> I've just tested this with the Drools 5.2.CR1 release and snapshot and I cannot reproduce this.
>>> Do you know what version of Drools currently is integrated?
>>>
>>
>> The version you last told us to integrate with ? :)
>>
>> Looking at hudson it says we are picking up Drools 5.2-SNAPSHOT
>> which sounds very wrong considering we are in codefreeze since yesterday!!.
>>
>> Brian/Kris ? Which release should we be using for the upcoming release ?
>>
>> /max
>>
>>
>>> Kris
>>>
>>> Max Rydahl Andersen wrote:
>>>
>>>> Kris,
>>>>
>>>> https://issues.jboss.org/browse/JBIDE-8820
>>>>
>>>> Worked in previous versions - now it stopped.
>>>>
>>>> Is this something that is limited to a very specific use case or
>>>> something that is fixed so we don't have to keep this regression around ?
>>>>
>>>> /max
>>>> http://about.me/maxandersen
>>>>
>>>>
>>>>
>>>>
>>
>> /max
>> http://about.me/maxandersen
>>
>>
>>
>>
/max
http://about.me/maxandersen
14 years, 5 months
Re: [jbosstools-dev] .drl code completion broken in latest drools ?
by Max Rydahl Andersen
> I've just tested this with the Drools 5.2.CR1 release and snapshot and I cannot reproduce this.
> Do you know what version of Drools currently is integrated?
The version you last told us to integrate with ? :)
Looking at hudson it says we are picking up Drools 5.2-SNAPSHOT
which sounds very wrong considering we are in codefreeze since yesterday!!.
Brian/Kris ? Which release should we be using for the upcoming release ?
/max
>
> Kris
>
> Max Rydahl Andersen wrote:
>> Kris,
>>
>> https://issues.jboss.org/browse/JBIDE-8820
>>
>> Worked in previous versions - now it stopped.
>>
>> Is this something that is limited to a very specific use case or
>> something that is fixed so we don't have to keep this regression around ?
>>
>> /max
>> http://about.me/maxandersen
>>
>>
>>
>>
/max
http://about.me/maxandersen
14 years, 5 months
CODE FREEZE IN EFFECT for JBT 3.2.x and JBDS 4.0.x
by Nick Boldt
Maintenance branch code freeze will remain in effect until we get a
build available for 3.2.1.CR1 / 4.1.0.CR1 for QE - hopefully no more
than a couple days.
Trunk remains open for 3.3.0.M2 / 5.0.0.M2 development, using the new
Indigo RC2/RC3 target platform. Code freeze should be mid-June in prep
for M2 QE & release.
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
14 years, 5 months
Re: [jbosstools-dev] jBPM 3 jPDL plugin version rollback in branch
by Nick Boldt
Perfect. Then I'm happy with jbpm 3.3.x in the JBT3.2.x stream, and jbpm
3.4.x in the JBT3.3.x stream.
Make sure you update BOTH feature.xml / manifest.mf AND the accompanying
pom.xml files, too.
If you need a tool to check if you've forgotten any, use this:
cd ~/trunk/jbpm/; ~/trunk/build/util/checkPOMvsManifest.sh -v
(flags: -v = verbose, -q = quiet, -d = debug)
Nick
On 05/30/2011 01:15 PM, Koen Aers wrote:
> The version contained in JBT 3.2.0.GA is 3.3.0 so it will indeed impact
> only bleeding edge people who cannot "upgrade".
>
> Regards,
> Koen
>
> Op 30-mei-11, om 17:57 heeft Nick Boldt het volgende geschreven:
>
>> As long as the version released in JBT 3.2.0.GA was not 3.4.0, then this
>> change shouldn't impact any actual users (just maybe some QE folks
>> who'll have to uninstall before they can "upgrade" from 3.4 to 3.3).
>>
>> If, however, the version of jBPM 3 jPDL released in 3.2.0.GA was 3.4.0,
>> then you're screwed and can't backlevel.
>>
>> N
>>
>> On 05/30/2011 07:10 AM, Koen Aers wrote:
>>> Nick,
>>>
>>> With the resolution of JBIDE-8956 the version numbers of the jBPM 3 jPDL
>>> plugin (org.jbpm.gd.jpdl) where unnecessarily bumped to 3.4.0 instead of
>>> 3.3.1. JBIDE-8979 needed a different approach for trunk and for branch
>>> as the problem did not exist in trunk. So Max and me decided to rollback
>>> the change to 3.4.0 to 3.3.1 in branch rather than bumping the version
>>> in trunk up to 3.5.0. This might create some fallout as rolling back a
>>> version number is not a good thing. Is there anything else I need to do
>>> to minimize this?
>>>
>>> Regards,
>>> Koen
>>
>> --
>> 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
>
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
14 years, 5 months
Re: [jbosstools-dev] jBPM 3 jPDL plugin version rollback in branch
by Nick Boldt
As long as the version released in JBT 3.2.0.GA was not 3.4.0, then this
change shouldn't impact any actual users (just maybe some QE folks
who'll have to uninstall before they can "upgrade" from 3.4 to 3.3).
If, however, the version of jBPM 3 jPDL released in 3.2.0.GA was 3.4.0,
then you're screwed and can't backlevel.
N
On 05/30/2011 07:10 AM, Koen Aers wrote:
> Nick,
>
> With the resolution of JBIDE-8956 the version numbers of the jBPM 3 jPDL
> plugin (org.jbpm.gd.jpdl) where unnecessarily bumped to 3.4.0 instead of
> 3.3.1. JBIDE-8979 needed a different approach for trunk and for branch
> as the problem did not exist in trunk. So Max and me decided to rollback
> the change to 3.4.0 to 3.3.1 in branch rather than bumping the version
> in trunk up to 3.5.0. This might create some fallout as rolling back a
> version number is not a good thing. Is there anything else I need to do
> to minimize this?
>
> Regards,
> Koen
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
14 years, 5 months