Scripting releases - SourceForge
by Steve Ebersole
I am working on scripting more of the release steps into the Gradle
build scripts. When it comes to uploading the release bundles to
SourceForge we have a choice to make. I will use rsync since we already
require people doing a release to have it installed because
docs.jboss.org uploads require it.
I can either account for the various SourceForge users in the script, or
we could define a single user in the SourceForge Hibernate project that
is there for uploading release bundles from the build. That upload user
would have just the permissions necessary to upload. We would need,
however, to manage getting keys uploaded to that user. Whereas if we
used our own SourceForge users we'd simply use our own keys.
Preferences?
Personally I'd rather just use our own users and account for the
different usernames in the script (read from ~/.gradle/gradle.settings
maybe).
13 years
Re: [hibernate-dev] breaking compatibility issues found in 4.3.0.Beta3
by Strong Liu
sorry, I missed the provided scope and runtime scope
the problem is :
now hibernate-core is a runtime scope dependency of h-em
so, suppose a project depends on h-em ( compile scope ) and the project uses h-core classes, then the project won't be compiled.
since runtime scope dependencies are not available on compile time classpath
a simple maven project would approve this ( attached )
On May 3, 2013, at 8:34 PM, Steve Ebersole <steven.ebersole(a)gmail.com> wrote:
> Have you tried this? Runtimr and compile scopes are both transitive, so the situation you describe should work just as before
> On May 3, 2013 7:23 AM, "Strong Liu" <stliu(a)hibernate.org> wrote:
>
> On May 3, 2013, at 8:13 PM, Steve Ebersole <steven.ebersole(a)gmail.com> wrote:
>
>> I dont understand what you mean with HHH-8220. OK its a change, but how is that breaking any builds?
>>
>
> suppose there is a WAR project that uses hibernate, and it has a compile scope dependency of h-em
>
> before this 4.3.0.Beta2, the HEM will brings all required dependencies in ( for example, h-core )
>
> but after upgrade to 4.3.0.Beta2, the build WAR will only contains HEM and no H-Core since HEM now has a runtime scope dependency of h-core
>
> then the WAR will fail when being deployed
>
>
>> And for JDK 7 we have discussed that on this list already. Gunnar will work on integrating some checks into the build to make sure we are not using JDK 7 features…
>>
>
>
> I'm aware of this , just pointed out that this 4.3.0.Beta2 will fail on JDK 6, and others who run into this issue will know the reason
>
>>
>> On 05/03/2013 02:08 AM, Strong Liu wrote:
>>> https://hibernate.atlassian.net/browse/HHH-8219
>>>
>>> https://hibernate.atlassian.net/browse/HHH-8220
>>>
>>>
>>> -------------------------
>>> Best Regards,
>>>
>>> Strong Liu <stliu at hibernate.org>
>>> http://about.me/stliu/bio
>>>
>>>
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
> -------------------------
> Best Regards,
>
> Strong Liu <stliu at hibernate.org>
> http://about.me/stliu/bio
>
>
>
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
13 years
Re: [hibernate-dev] breaking compatibility issues found in 4.3.0.Beta3
by Strong Liu
On May 3, 2013, at 8:13 PM, Steve Ebersole <steven.ebersole(a)gmail.com> wrote:
> I dont understand what you mean with HHH-8220. OK its a change, but how is that breaking any builds?
>
suppose there is a WAR project that uses hibernate, and it has a compile scope dependency of h-em
before this 4.3.0.Beta2, the HEM will brings all required dependencies in ( for example, h-core )
but after upgrade to 4.3.0.Beta2, the build WAR will only contains HEM and no H-Core since HEM now has a runtime scope dependency of h-core
then the WAR will fail when being deployed
> And for JDK 7 we have discussed that on this list already. Gunnar will work on integrating some checks into the build to make sure we are not using JDK 7 features…
>
I'm aware of this , just pointed out that this 4.3.0.Beta2 will fail on JDK 6, and others who run into this issue will know the reason
>
> On 05/03/2013 02:08 AM, Strong Liu wrote:
>> https://hibernate.atlassian.net/browse/HHH-8219
>>
>> https://hibernate.atlassian.net/browse/HHH-8220
>>
>>
>> -------------------------
>> Best Regards,
>>
>> Strong Liu <stliu at hibernate.org>
>> http://about.me/stliu/bio
>>
>>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
13 years
Re: [hibernate-dev] improved Eclipse project support
by Gunnar Morling
2013/4/16 Steve Ebersole <steven.ebersole(a)gmail.com>
> What is "configured JDK baseline"? Do you have to point to a JDK path? If
> so, no difference than just setting the javac bootstrap option to a local
> path.
No, you don't point to another JDK path, you use the JDK you are on, i.e.
Java 7. You just say which JDK version you want to target, e.g. 1.6. In the
HV case, the config is this:
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>animal-sniffer-maven-plugin</artifactId>
<version>1.9</version>
<configuration>
<signature>
<groupId>org.codehaus.mojo.signature</groupId>
<artifactId>java16</artifactId>
<version>1.0</version>
</signature>
</configuration>
</plugin>
The referenced signature artifact contains the API signature for that JDK
version, i.e. all Java 1.6 methods, public fields etc. If your code uses a
method which is not part of that API signature, the plug-in will fail the
build.
That is, you still use the Java 7 API to compile against, but the plug-in
makes sure you use only those parts of the API which where there already as
of Java 6. So this emulates building against Java 6, but without the hassle
of handling several actual JDKs, setting up the boot classpath etc.
>
>
> On Tue 16 Apr 2013 08:38:37 AM CDT, Gunnar Morling wrote:
>
>> In HV, we use the Animal Sniffer plug-in [1] for that purpose.
>>
>> This checks the code base against a configured JDK baseline and fails
>> the build, when e.g. using a method which is not part of the targeted
>> JDK release. In other words, you still use your current JDK for
>> building (avoiding any bootstrap path fiddling) but make sure you
>> invoke only those parts of the API which are also available in the
>> targeted Java version.
>>
>> Together with the source/target level correctly set, this allows to
>> safely compile with newer JDK versions and still be sure that the code
>> e.g. runs on 6.
>>
>> We use the Maven plug-in, but via the Ant task, this should also be
>> usable for Gradle builds. If you like me to, I can give this a try for
>> ORM.
>>
>> --Gunnar
>>
>> [1] http://mojo.codehaus.org/**animal-sniffer/index.html<http://mojo.codehaus.org/animal-sniffer/index.html>
>>
>>
>> 2013/4/16 Steve Ebersole <steven.ebersole(a)gmail.com
>> <mailto:steven.ebersole@gmail.**com <steven.ebersole(a)gmail.com>>>
>>
>>
>> Mainly thats an issue with that fact that so far we have not
>> defined 'bootstrap class path' option to javac to go along with
>> the source/target compatibility settings. The difficulty is that
>> defining bootstrap for javac becomes very system specific (it
>> needs to name a path). Sure we could externalize that into a
>> setting, but then what do you do when someone wants to build
>> Hibernate but has not defined this setting? Do you let the build
>> continue (aka, make the bootstrap setting optional)?
>>
>> Bottom line, just setting source/target compatibility is never enough.
>>
>>
>> On Tue 16 Apr 2013 03:44:29 AM CDT, Gunnar Morling wrote:
>>
>> On a related note:
>>
>> I know Java 7 is required to compile ORM, but is Java 7 also the
>> required runtime Java version now (I vaguely remember a related
>> discussion around the JPA API JAR)?
>>
>> I'm asking, because the Java 7 method
>> Collections#emptyIterator() is
>> used at two places, making this code not runnable on Java 6. If
>> requiring 7 is intentional, feel free to ignore this mail ;)
>>
>> --Gunnar
>>
>>
>>
>> 2013/4/16 Gunnar Morling <gunnar(a)hibernate.org
>> <mailto:gunnar@hibernate.org>
>> <mailto:gunnar@hibernate.org <mailto:gunnar@hibernate.org>>**>
>>
>>
>> 2013/4/15 Steve Ebersole <steven.ebersole(a)gmail.com
>> <mailto:steven.ebersole@gmail.**com <steven.ebersole(a)gmail.com>>
>> <mailto:steven.ebersole@gmail.**__com
>>
>> <mailto:steven.ebersole@gmail.**com <steven.ebersole(a)gmail.com>
>> >>>
>>
>>
>> I am not touching this :)
>>
>> I think I have explained this 198,052 times thus far lol
>>
>>
>> I must have missed this then. Or I was not yet part of the
>> team at
>> that time.
>>
>>
>> https://community.jboss.org/__**__wiki/GradleWhy<https://community.jboss.org/____wiki/GradleWhy>
>> <https://community.jboss.org/_**_wiki/GradleWhy<https://community.jboss.org/__wiki/GradleWhy>
>> >
>>
>>
>> <https://community.jboss.org/_**_wiki/GradleWhy<https://community.jboss.org/__wiki/GradleWhy>
>> <https://community.jboss.org/**wiki/GradleWhy<https://community.jboss.org/wiki/GradleWhy>>>
>> see #4
>>
>>
>> Thanks for the link.
>>
>> I get the reasoning about Maven's "one artifact" rule and
>> the need
>> for re-usable test code. But now that we use Gradle,
>> wouldn't it
>> be possible to move the things from hibernate-testng back to
>> hibernate-core and built two JARs with the different
>> contents from
>> there? To me, a circular dependency between two modules always
>> seems a bit suspicious, also if it is doable with Gradle,
>> turning
>> off warnings in the IDE etc.
>>
>> Btw. also Maven supports this particular use case of
>> creating a
>> main JAR and a JAR with re-usable test infrastructure [1].
>> We e.g.
>> make use of this in HV.
>>
>> --Gunnar
>>
>> [1]
>> http://maven.apache.org/__**plugins/maven-jar-plugin/test-**
>> __jar-mojo.html<http://maven.apache.org/__plugins/maven-jar-plugin/test-__jar-mojo.html>
>>
>> <http://maven.apache.org/**plugins/maven-jar-plugin/test-**
>> jar-mojo.html<http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html>
>> >
>>
>>
>> On Mon 15 Apr 2013 04:10:43 PM CDT, Gunnar Morling wrote:
>>
>> Hi Brett,
>>
>> That's good news, thanks for your efforts. Based
>> on step 3
>> from your blog
>> post it seems as there still is a circular dependency
>> between some of the
>> modules/projects. Just out of interest, could you give
>> some more details
>> why this kind of setup is required?
>>
>> --Gunnar
>>
>>
>>
>> 2013/4/15 Brett Meyer <brmeyer(a)redhat.com
>> <mailto:brmeyer@redhat.com>
>> <mailto:brmeyer@redhat.com
>>
>> <mailto:brmeyer@redhat.com>>>
>>
>>
>> There's been several complaints about ORM's use of
>> Gradle not generating
>> Eclipse projects correctly. This was recently
>> cleaned
>> up in HHH-7617 [1].
>> FYI, there's a quick blog post [2] about how to
>> quickly get
>> up-and-running. Please let me know if there
>> are any
>> further ways we could
>> streamline the IDE setup.
>>
>> [1]
>> https://hibernate.atlassian.__**__net/browse/HHH-7617
>>
>>
>> <https://hibernate.atlassian._**_net/browse/HHH-7617
>> <https://hibernate.atlassian.**net/browse/HHH-7617<https://hibernate.atlassian.net/browse/HHH-7617>
>> >>
>> [2]
>> http://in.relation.to/____**Bloggers/____**
>> ImprovedEclipseProjectSupportF**____orHibernateORMDevelopment<http://in.relation.to/____Bloggers/____ImprovedEclipseProjectSupportF____...>
>> <http://in.relation.to/__**Bloggers/__**
>> ImprovedEclipseProjectSupportF**__orHibernateORMDevelopment<http://in.relation.to/__Bloggers/__ImprovedEclipseProjectSupportF__orHibe...>
>> >
>>
>>
>>
>> <http://in.relation.to/__**Bloggers/__**
>> ImprovedEclipseProjectSupportF**__orHibernateORMDevelopment<http://in.relation.to/__Bloggers/__ImprovedEclipseProjectSupportF__orHibe...>
>> <http://in.relation.to/**Bloggers/**
>> ImprovedEclipseProjectSupportF**orHibernateORMDevelopment<http://in.relation.to/Bloggers/ImprovedEclipseProjectSupportForHibernateO...>
>> >>
>>
>> Brett Meyer
>> Red Hat Software Engineer, Hibernate
>>
>> ______________________________**_____________________
>>
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> <mailto:hibernate-dev@lists.**jboss.org<hibernate-dev(a)lists.jboss.org>
>> >
>> <mailto:hibernate-dev@lists.__**jboss.org<http://jboss.org>
>> <mailto:hibernate-dev@lists.**jboss.org<hibernate-dev(a)lists.jboss.org>
>> >>
>> https://lists.jboss.org/____**mailman/listinfo/hibernate-dev<https://lists.jboss.org/____mailman/listinfo/hibernate-dev>
>> <https://lists.jboss.org/__**mailman/listinfo/hibernate-dev<https://lists.jboss.org/__mailman/listinfo/hibernate-dev>
>> **>
>>
>> <https://lists.jboss.org/__**mailman/listinfo/hibernate-dev<https://lists.jboss.org/__mailman/listinfo/hibernate-dev>
>> <https://lists.jboss.org/**mailman/listinfo/hibernate-dev<https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> **>__>
>>
>> ______________________________**_____________________
>>
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> <mailto:hibernate-dev@lists.**jboss.org<hibernate-dev(a)lists.jboss.org>
>> >
>> <mailto:hibernate-dev@lists.__**jboss.org<http://jboss.org>
>> <mailto:hibernate-dev@lists.**jboss.org<hibernate-dev(a)lists.jboss.org>
>> >>
>> https://lists.jboss.org/____**mailman/listinfo/hibernate-dev<https://lists.jboss.org/____mailman/listinfo/hibernate-dev>
>> <https://lists.jboss.org/__**mailman/listinfo/hibernate-dev<https://lists.jboss.org/__mailman/listinfo/hibernate-dev>
>> **>
>>
>> <https://lists.jboss.org/__**mailman/listinfo/hibernate-dev<https://lists.jboss.org/__mailman/listinfo/hibernate-dev>
>> <https://lists.jboss.org/**mailman/listinfo/hibernate-dev<https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>> **>__>
>>
>>
>>
>>
>>
13 years
A synchronous JGroups backend for Hibernate Search
by Sanne Grinovero
In my first draft for HSEARCH-1296 I was automatically enabling the
blocking behaviour on JGroups if the worker backend was configured to
be synchronous (which is the default for workers),
but Emmanuel didn't like that and I think he has a good point:
The JGroups behaviour and the workers behaviour are two different
things; so I just separated this into a new configuration property
"block_waiting_ack" (boolean)
which of course applies only to the JGroups backends.
I agree it's important to keep the two separate, but also if the user
is configuring an ASYNC worker, he should set this option to false as
there is no benefit in waiting for the delivery.
Likewise, if SYNC is required, you would probably want to set this to true.
So I'm suggesting we make the default value ot "block_waiting_ack"
dependant on the worker execution, exposing the property as an
override.
Thoughts?
I guess it's much easier to understand the default behaviour if we
keep them separate, still I don't see much use for configuring the two
independently.
Cheers,
Sanne
https://hibernate.atlassian.net/browse/HSEARCH-1296
13 years
Checkstyle breaking the OGM build
by Emmanuel Bernard
Taking OGM master, I get a checkstyle failure on one of the test file.
But what is surprising is that I don't see new lines at the end of the
described file.
Can you guys reproduce?
Emmanuel
[INFO] --- maven-resources-plugin:2.5:resources (default-resources) @
hibernate-ogm-core ---
[debug] execute contextualize
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @
hibernate-ogm-core ---
[INFO] Compiling 150 source files to
/Users/emmanuel/Code/ogm/hibernate-ogm-core/target/classes
[INFO]
[INFO] --- maven-checkstyle-plugin:2.10:checkstyle (check-style) @
hibernate-ogm-core ---
[INFO] Starting audit...
/Users/emmanuel/Code/ogm/hibernate-ogm-core/src/test/java/org/hibernate/ogm/test/id/Label.java:64:
Only one new line is allowed at the end of a file
Audit done.
[INFO]
------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Hibernate OGM Aggregator .......................... SUCCESS
[3.493s]
[INFO] Hibernate Object Grid Mapper ...................... FAILURE
[28.596s]
[INFO] Hibernate OGM Ehcache integration ................. SKIPPED
[INFO] Hibernate OGM Infinispan integration .............. SKIPPED
[INFO] Hibernate OGM Module .............................. SKIPPED
[INFO] Hibernate OGM Integration and performance Tests ... SKIPPED
[INFO] Hibernate OGM Integration Test case ............... SKIPPED
[INFO]
------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 33.217s
[INFO] Finished at: Fri May 03 00:14:08 CEST 2013
[INFO] Final Memory: 36M/335M
[INFO]
------------------------------------------------------------------------
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-checkstyle-plugin:2.10:checkstyle
(check-style) on project hibernate-ogm-core: An error has occurred in
Checkstyle report generation. Failed during checkstyle execution: There
are 1 checkstyle errors. -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the
-e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions,
please read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the
command
[ERROR] mvn <goals> -rf :hibernate-ogm-core
13 years
4.3.0.Beta2 release tomorrow
by Steve Ebersole
Just a heads up that because of the instability with the CI job today
and with many of the team off today I decided to put this release off
until tomorrow.
13 years
