Build and AnnotationProcessors
by Steve Ebersole
As discussed a little in HHH-8140[1] and on the earlier Eclipse thread,
I'd like to look at simplifying the build a bit around making IDE setup
easier. One thing that came to mind was looking at source generation.
Today we have source generation occur for:
* Antlr
* JAXB
* JPA static metamodel gen
* Logging
The first 2 rely on specific tools while the other 2 are generated via
AnnotationProcessors.
For the first 2, there is really not much to discuss aside from possibly
to consider adding those outputs to Git. I'd actually be open to
considering that for JAXB. Its inputs are very infrequently changing,
so much so that I don't see needing to generate that stuff often. The
Antlr stuff on the other hand changes more frequently.
But really it is the AnnotationProcessors I wanted to talk about.
Currently we apply the AnnotationProcessors in separate javac task
configurations. I cannot remember all the reasons we decided to do it
this way originally. But I know that one was wanting to be able to keep
the output of each (the generated sources) in dedicated directories[2].
But we could also just lump all the APT output into one single, separate
directory (target/generated-src/apt/main, target/generated-src/apt/test,
e.g.). What this would gain us is the ability for the IDE to run APT as
part of normal javac. It would be one less thing to set up when setting
up the IDE project.
WDYT?
[1] https://hibernate.atlassian.net/browse/HHH-8140
[2] Also, I remember IDEA, back then, had difficulty with
AnnotationProcessors and separating the compilation dir and generation
dir. It wrote both to the same dir, which is the javac apt default;
IDEA just had no option to adjust that. IDEA 12 does.
13 years, 1 month
Re: [hibernate-dev] improved Eclipse project support
by Gunnar Morling
2013/4/15 Steve Ebersole <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>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
>
> 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>
>>
>> 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>
>>> [2]
>>> 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
>>> 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
>> https://lists.jboss.org/**mailman/listinfo/hibernate-dev<https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>>
>
13 years, 1 month
Re: [hibernate-dev] improved Eclipse project support
by Gunnar Morling
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
2013/4/16 Steve Ebersole <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>>
>>
>> 2013/4/15 Steve Ebersole <steven.ebersole(a)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>>
>> 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>
>>
>>
>> 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>>
>>
>>
>> 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>
>> >
>> [2]
>> 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>
>> >
>> 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>
>> >
>> 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, 1 month
HSEARCH-1296
by Ales Justin
Although this change fixes query lookup,
it adds horrible performance:
Running CapeDwarf cluster QueryTest:
with HSEARCH-1296
21:00:27,188 INFO [org.hibernate.search.indexes.impl.DirectoryBasedIndexManager] (http-/192.168.1.102:8080-1) HSEARCH000168: Serialization service Avro SerializationProvider v1.0 being used for index 'default_capedwarf-test__com.google.appengine.api.datastore.Entity'
21:01:17,911 INFO [org.jboss.web] (ServerService Thread Pool -- 49) JBAS018224: Unregister web context: /capedwarf-tests
50sec
old 4.2.0.Final HS
21:08:19,988 INFO [org.hibernate.search.indexes.impl.DirectoryBasedIndexManager] (http-/192.168.1.102:8080-2) HSEARCH000168: Serialization service Avro SerializationProvider v1.0 being used for index 'default_capedwarf-test__com.google.appengine.api.datastore.Entity'
21:08:20,829 INFO [org.jboss.web] (ServerService Thread Pool -- 49) JBAS018224: Unregister web context: /capedwarf-tests
841ms
---
I added
<property name="enable_bundling">true</property>
to AS jgroups transport config, but no improvement.
Any (other) idea?
-Ales
13 years, 1 month
Envers compile issue
by Steve Ebersole
I just made a change to help catch runtime problems that kept cropping
up. The change was to org.hibernate.mapping.Value#getColumnIterator.
The problem is that code in many modules (hem, envers) that actually
deals with mapping code were making a bad assumption here. The returned
iterator actually returns a Iterable<Selectable>, not Iterable<Column>.
Selectable is the contract shared between Column and Formula. So when
code non-defensively tries to treat that thing as a Iterable<Column> we
often have issues.
Yes, the method is very poorly named. Actually it predates formula as a
feature. But be that as it may, the code casting those elements to
Column are just wrong.
For envers, I am not actually sure how to handle Formula elements. I
need some help there. The issues are all isolated to
org.hibernate.envers.configuration.internal.metadata Could someone more
familiar with envers (and especially its entity definition stuff) take a
look?
Thanks!
13 years, 1 month
[HSEARCH] Dynamic Sharding and directory template
by Emmanuel Bernard
I am currently working on a solution for dynamically adding new shards
to Hibernate Search (for example one per tenant with a list growing).
https://hibernate.atlassian.net/browse/HSEARCH-472
Things are going well but there is an interesting problem related to a
subsequent feature
https://hibernate.atlassian.net/browse/HSEARCH-1295
In short, EntityIndexBinders create additional IndexManagers when a not
yet created shard id requested. The IndexManager is uniquely identified
by its indexName.
In the old sharding approach, the index name was turned into indexName.n
(n being the shard number) and this new indexName.n is passed along to
DirectoryProviders etc
To implement HSEARCH-1295 properly, you need the DirectoryProvider to
have access to the original index name and the shard identifier as
independent dataset.
We can hack around the model and pass the original indexName and shard
identifier in specific Properties entries. That's backward compatible.
An alternative is to replace String indexName in all thee contracts with
a proper IndexName object pointing to the original indexName and to the
shard idenfitier. That one breaks a bunch of SPI and in particular
DirectoryProvider.
Thoughts?
Emmanuel
13 years, 1 month
IRC meeting
by Steve Ebersole
Sorry all but I won't be able to make meeting. In the middle of internet
connection provider setup. Of course they showed up right at time of
meeting :(
Anyway I just have cell connection atm.
13 years, 1 month
