Copyright headers
by Emmanuel Bernard
Guys,
It is not OK to blindly replace a copyright header with another one.
One must at least make sure that:
- the original copyright date is not erased
- copyright holders included in the header are not removed
For the date, if a file was initially created in 2007 and updated this year (or any other year in between), the reference will then be 2007-2011
See http://community.jboss.org/wiki/CopyrightOwnershipandLicenses for more info.
15 years
Re: [hibernate-dev] HHH-5562, services and eventlisteners
by Emmanuel Bernard
On Feb 17, 2011, at 7:22 PM, Steve Ebersole wrote:
> I see drawbacks to either approach.
>
> If the services can be shared across multiple SessionFactory instance then they *must* be stateless (or the state must be designed to be shared) which brings about portability/migration concerns. Additionally consider the case of "configuring" services shared across multiple SessionFactory instances; for example imagine changing the option to enable sql logging on the JDBC Service. Of course maybe that is what the user wants/intends so its nice from that perspective.
>
Yes but at least intuitively, I think the more simple Service contract (ie allowed to keep direct state) is preferable to the extra flexibility.
> Really its a matter of the API for creating a SessionFactory. This came up in the IRC meeting. Its actually difficult to enforce that a ServiceRegistry only get used in a single SessionFactory.
>
True.
15 years, 1 month
UserType.nullSafeSet() and nullSafeGet() in H4
by Gail Badner
I noticed that UserType.nullSafeSet() and nullSafeGet() don't have a
SessionImplementor argument, but those methods in CompositeUserType do
have it.
This might not make a difference in 3.6.x, but in H4, not having the
SessionImplementor argument makes it impossible to do dynamic type
overrides specified by the dialect.
As an example, suppose a UserType delegates nullSafeGet()/nullSafeSet()
to StandardBasicTypes.BLOB.nullSafeGet()/nullSafeSet(). True, the
UserType could delegate to the proper type (streaming or lob-binding).
To be able to use the same UserType for, say, both Oracle and
PostgreSQL, it would have to be possible to do the override based on
dialect.
I think the right thing to do is add the SessionImplementor argument for H4.
Comments?
Gail
15 years, 1 month
Applying patches between Core 3.6 and 4
by Emmanuel Bernard
Here is the method I've just used.
I work on say 3.6 and apply n commits, ideally I do apply my changes so that each commit does not cross several modules (ie core and entitymanager)
For each commit:
cd targeted-module
git diff --no-prefix previous-commit-sha1 actual-commit-sha1 | patch -p1
The patch is applied and I need to add the necessary files and commit.
Not a perfect method by any mean, but that's a start :)
HTH
Emmanuel
15 years, 1 month
Latest Hibernate Core build needs Gradle 0.9.2
by Hardy Ferentschik
Hi all,
I tried to build trunk of Hibernate Core this morning and got some
problems building the
sources in buildSrc (the directory contains some build
customizations/plugins for our build).
After upgrading to Gradle 0.9.2 the build worked fine again.
I think this is related to some changes Steve made in order to read nexus
credentials from
settings.xml (for deploys).
Just thought I let you know :)
--Hardy
15 years, 1 month
Re: [hibernate-dev] HV-376
by Emmanuel Bernard
Hi,
On 6 févr. 2011, at 20:57, Gunnar Morling wrote:
>
> one other issue we might/should deliver for Beta2 is http://opensource.atlassian.com/projects/hibernate/browse/HV-371 ("Support method-level constraints in meta-data API"), at least API-wise. I pushed a first draft to https://github.com/gunnarmorling/hibernate-validator/tree/HV-371 and would be happy on your feedback.
>
> With some exceptions this is pretty similar to what is suggested in Appendix C. As we can't alter the BeanDescriptor type, I created a new type TypeDescriptor (I think the name is better anyways, as constraints are no longer restricted to bean-style types with the advent of method validation). This type resembles BeanDescriptor (it doesn't inherit for the naming reason but I would let me convince if you think it should) and is returned by MethodValidator#getConstraintsForType().
It seems that in the grand scheme of BV 1.1, we would put all your methods back on BeanDescription without necessarily adding a new type. I initially thought of adding TypeDescriptor as a superclass of BeanDescriptor but the idea of having the noting of properties on TypeDescriptor felt wrong (in Java).
WDYT?
If we all agree then that means TypeDescriptor is really a (temporary) subclass of BeanDescriptor
>
> Anything else is pretty much straight forward. Currently it is not possible to determine from which exact method version in a hierarchy a certain constraint originates (using the ConstraintFinder API one can only find out, whether a constraint is defined locally or *somewhere* up in the hierarchy). Do you think this would be needed? I think, the same restriction holds for the existing property descriptor API.
I've always envisioned that one in need to find where a constraint was exactly would use a combination of lookingAt(LOCAL_ELEMENT) and clazz.getSuperclass().
What would be the use case for reaching the exact method straight?
>
> The existing methods (getElementClass(), getConstraintDescriptors() etc.) on ElementDescriptor all seem to make sense for the new descriptor types. For MethodDescriptor they should relate to the return value type/constraints, for ParameterDescriptor to the parameter type/constraints.
yep.
>
> WDYT, should we ship this as API in Beta2 for public review and implement it with the next milestone? I'm also CC-ing Emmanuel as I think he originally wrote Appendix C.
Fine by me, it's up to you guys. The design is very much inline with the original design of Bean Validation.
BTW
MethodDescriptor#getMethod
why is it required? I think we've discussed that but I forgot.
15 years, 1 month
Error building Entity Manager documentation
by Gail Badner
I'm getting this error:
java.lang.IllegalStateException: basedir
/NotBackedUp/gbadner/git/hibernate-core-3.6.1-Final/entitymanager/src/main/docbook/en/images
does not exist
After creating the missing directory, the doc builds successfully.
I'm not sure where the bug is. Is it really because the directory is
missing or does some plugin make an incorrect assumption.
Here are the details:
[gbadner@gbadner entitymanager]$ mvn -version
Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
Java version: 1.5.0_16
Java home: /NotBackedUp/gbadner/apps/jdk1.5.0_16/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux" version: "2.6.18-212.el5.bz573514" arch: "i386" Family:
"unix"
I'm using the command:
mvn org.jboss.maven.plugins:maven-jdocbook-plugin:2.3.4:resources
org.jboss.maven.plugins:maven-jdocbook-plugin:2.3.4:generate -P doc
--settings ~/.m2/settings-3.6.1-Final.xml
The failure:
[INFO] Expanding:
/home/gbadner/NotBackedUp/.m2/repository-3.6.1-Final/org/jboss/jbossorg-fonts/1.0.0/jbossorg-fonts-1.0.0.jdocbook-style
into
/NotBackedUp/gbadner/git/hibernate-core-3.6.1-Final/entitymanager/target/docbook/staging
[INFO]
------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO]
------------------------------------------------------------------------
[INFO] basedir
/NotBackedUp/gbadner/git/hibernate-core-3.6.1-Final/entitymanager/src/main/docbook/en/images
does not exist
[INFO]
------------------------------------------------------------------------
[INFO] Trace
java.lang.IllegalStateException: basedir
/NotBackedUp/gbadner/git/hibernate-core-3.6.1-Final/entitymanager/src/main/docbook/en/images
does not exist
at
org.codehaus.plexus.util.DirectoryScanner.scan(DirectoryScanner.java:550)
at
org.jboss.maven.shared.resource.ResourceDelegate.collectFileNames(ResourceDelegate.java:164)
at
org.jboss.maven.shared.resource.ResourceDelegate.process(ResourceDelegate.java:108)
at
org.jboss.maven.plugins.jdocbook.ResourceMojo.stageProjectResources(ResourceMojo.java:114)
at
org.jboss.maven.plugins.jdocbook.ResourceMojo.process(ResourceMojo.java:63)
at
org.jboss.maven.plugins.jdocbook.AbstractDocBookMojo.doExecute(AbstractDocBookMojo.java:295)
at
org.jboss.maven.plugins.jdocbook.AbstractDocBookMojo.execute(AbstractDocBookMojo.java:227)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[
15 years, 1 month
Missing artifacts building hibernate-core 3.6.1-Final
by Gail Badner
I need to get some rest. I'll pick this up tomorrow.
I'm getting the following:
[INFO]
------------------------------------------------------------------------
[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Missing:
----------
1) org.apache.maven.surefire:surefire-booter:jar:2.4.3
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.maven.surefire
-DartifactId=surefire-booter -Dversion=2.4.3 -Dpackaging=jar
-Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file
there:
mvn deploy:deploy-file -DgroupId=org.apache.maven.surefire
-DartifactId=surefire-booter -Dversion=2.4.3 -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.4.3
2) org.apache.maven.surefire:surefire-booter:jar:2.4.3
2) org.apache.maven.surefire:surefire-api:jar:2.4.3
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.maven.surefire
-DartifactId=surefire-api -Dversion=2.4.3 -Dpackaging=jar
-Dfile=/path/to/file
Alternatively, if you host your own repository you can deploy the file
there:
mvn deploy:deploy-file -DgroupId=org.apache.maven.surefire
-DartifactId=surefire-api -Dversion=2.4.3 -Dpackaging=jar
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.apache.maven.plugins:maven-surefire-plugin:maven-plugin:2.4.3
2) org.apache.maven.surefire:surefire-booter:jar:2.4.3
3) org.apache.maven.surefire:surefire-api:jar:2.4.3
---------
15 years, 1 month
