Fwd: [gradle-dev] Parallel project execution
by Steve Ebersole
Sweet!
-------- Original Message --------
Subject: [gradle-dev] Parallel project execution
Date: Wed, 8 Aug 2012 15:11:10 -0600
From: Daz DeBoer <darrell.deboer(a)gradleware.com>
Reply-To: dev(a)gradle.codehaus.org
To: dev(a)gradle.codehaus.org
G'day
Over the upcoming releases we will be working on a new feature to enable
parallel execution of projects in a multi-project build.
A first cut of the design doc for this new piece of work is now
available at:
https://github.com/gradle/gradle/blob/master/design-docs/parallel-project...
This doc includes some mock-ups of what the console output will look
like when projects are executed in parallel, some ideas for how this
feature will be configured, and some of the limitations that will be
placed on your Gradle builds in order to take advantage of it.
This is a work in progress, but any constructive feedback would be
appreciated.
cheers
--
Darrell (Daz) DeBoer
Principal Engineer, Gradleware
http://www.gradleware.com <http://www.gradleware.com/>
13 years, 10 months
Unit test failures using the new metamodel
by Gail Badner
I'm seeing the following failures using hibernate.test.new_metadata_mappings=true that appear to be regressions:
- org.hibernate.jpa.test.connection.DataSourceInjectionTest fails (also fails using the old metadata);
- org.hibernate.test.annotations.lob.LobTest.testSerializableToBlob
- org.hibernate.test.naturalid.mutable.cached.CachedMutableNaturalIdTest.testChangedNaturalIdNotCachedAfterTransactionFailure
Strong and Hardy, do you have an ideas about any of these?
Also, there were numerous failures in hibernate-core when building with hibernate.test.validatefailureexpected=true, which validates that those tests annotated with @FailureExpected or @FailureExpectedWithNewMetamodel actually fail. If an annotated test does not fail as expected, org.hibernate.testing.junit4.FailureExpectedHandler$FailureExpectedTestPassedException is thrown causing the test to fail.
In most cases this is happening because there is some new functionality working now (e.g., sequences and other persistent ID generators) that was not working when John added @FailureExpectedWithNewMetamodel. The fix in these cases is to simply remove @FailureExpectedWithNewMetamodel.
When hibernate.test.validatefailureexpected is false (the default), the result from FailureExpected tests is simply ignored.
I've gone ahead and pushed a fix that removes @FailureExpectedWithNewMetamodel from those tests that succeed without the annotation.
There are 2 tests where this does not work:
org.hibernate.test.annotations.interfaces.InterfacesTest
org.hibernate.test.annotations.idmanytoone.alphabetical.AlphabeticalIdManyToOneTest
These tests fail with org.hibernate.cfg.NotYetImplementedException when the sources are being processed. For some reason. this failure is not recognized as an expected failure. I'm not sure of the reason for this.
It seems that now would be a good time to make both hibernate.test.new_metadata_mappings=true and hibernate.test.validatefailureexpected=true the default when building. That way we'll know when to remove @FailureExpectedWithNewMetamodel from tests that succeed due to added functionality. It will also help us know when there are regressions.
WDYT?
Regards,
Gail
13 years, 10 months
SourceForge project
by Steve Ebersole
Not sure if y'all are tracking what is going on at SourceForge. They
have done a redesign of the site using a new hosting software they
developed called Allura. We will need to upgrade to use Allura at some
point. The upgrade has a few ramifications that I wanted to give
everyone some time to handle.
First is our hosted MediaWiki instance. As far as I know, I am the only
one that uses that, so I don't think this affects anyone other than me.
In fact all hosted apps will be getting decommissioned. We only have
MediaWiki, WordPress and dotProject enabled to date. To the best of my
knowledge, only MediaWiki ever got used.
Source Code. We still have the original CVS repo accessible for read.
As I understand it, that will remain true and use the same urls. We
moved directly from SF CVS to JBoss SVN, so no SF SVN to worry about
that I know of. For Git, we did create some Git repos. Those will be
inaccessible after the upgrade; so if there is anything y'all want in
any of those Git repos, you should pull/clone it. Let me know.
I do not know of any other ramifications. Let me know if you think of
others that need to be addresses.
If you are unfamiliar and want to see what Allura offers, here is the
link: http://sourceforge.net/p/allura/wiki/Features/
--
steve(a)hibernate.org
http://hibernate.org
13 years, 10 months
Fwd: Building hibernate from hibernate source code
by mutaz kabbashi
hi
i am trying to build hibernate from hibernate source code as you
explained here but i couldn't
when i issue gradlew clean build -x test
the following exception appered
* What went wrong:
Execution failed for task ':hibernate-entitymanager:compileJava'.
> Compile failed; see the compiler error output for details.
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug
option to get more log output.
BUILD FAILED
13 years, 10 months
