[hibernate-dev] Test
Sorry for the spam, having subscription problems. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] mutable versus immutable natural keys
After our conversion in IRC I think the latest iteration of the idea
having the following would suffice:
public @interface NaturalId {
/**
* If the NaturalId can change, either via the application or direct
database manipulation
*/
boolean mutable() default false;
/**
* If the NaturalId->PrimaryKey resolution should be stored in the L2
cache
*/
boolean cache() default true;
}
I think we can do away with IMMUTABLE vs IMMUTABLE_CHECKED and simply
always do the consistency check when detached entities with natural ids
are attached.
As for the conflict of doing something like:
@NaturalId
@Column(updatable=true)
private String userName;
I think the solution is to log a warning along the lines of
"com.example.User.userName is marked as an immutable NaturalId and
always marked as updatable, the updatable flag will be ignored"
-Eric
On 01/17/2012 02:18 PM, st...@hibernate.org wrote:
In talking with few people that use this feature, there is def a desire
to account for both immutable-with-checking and
immutable-without-checking.
Initially I started down the path of an enum to model this:
public enum NaturalIdMutability {
MUTABLE,
IMMUTABLE,
IMMUTABLE_CHECKED,
@Deprecated
UNSPECIFIED
}
and:
public @interface NaturalId {
@Deprecated
boolean mutable() default false;
NaturalIdMutability mutability() default
NaturalIdMutability.UNSPECIFIED;
}
But I started to think it might be better to instead separate the
definition of mutable/immutable and whether or not to do checking on
immutable. What is the difference in folks minds between:
public class User {
...
@NaturalId(mutable=false)
private String userName;
}
and
public class User {
...
@NaturalId
@Column(updatable=false)
private String userName;
}
?
Or is everyone ok with this form:
public class User {
...
@NaturalId(mutability=NaturalIdMutability.MUTABLE)
private String userName;
}
and if so, how should this be interpreted:
public class User {
...
@NaturalId(mutability=NaturalIdMutability.IMMMUTABLE)
@Column(updatable=true)
private String userName;
}
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Proxies and typing
Perhaps an overloaded method for those that want generics and proxies?
public T load(Class entityType, Class proxyType, ...)
It is kinda gross and results in higher level code knowing about the
proxies but it would work for those people that are using proxyClass
without having to make lower level changes.
-Eric
On 1/25/12 10:54 PM, Steve Ebersole wrote:
> In terms of caching the resolution (User-UserImpl) on SessionFactory,
> if we go that route, we can just limit it to specified proxyClass
> values as opposed to a more free-form "any and all interfaces".
>
> Also, as far as the Session get and load methods, we don't have to
> switch them to use generics. We can leave this feature for the load
> access stuff.
>
> On Wed 25 Jan 2012 10:48:30 PM CST, Steve Ebersole wrote:
>> Not really following what you are advocating Sanne.
>>
>> The problem with accepting the interface in the API is that we do not
>> track this information today. From a Session, I have no way to get
>> from User -> UserImpl unless I iterate every persister registered with
>> the SessionFactory and check its mapped class type against the
>> incoming interface. Yes we could start tracking such information but
>> thats yet even more data cached as part of the SessionFactory.
>>
>> When you say that "the first case would work only in certain
>> situations even with the current code, depending if you actually get a
>> proxy or not", yes that is true but that is true specifically because
>> at one point very early on this proxy class generation code was
>> changed to not use the entity class as part of the proxy class
>> definition when the mapping specified an interface as the proxy.
>> Before that change it used to use entity class AND the proxy
>> interface. What I am asking is whether we want to switch back to that
>> to help facilitate generic signatures.
>>
>> In psuedo-code, the User/UserImpl example below today results in
>> essentially this:
>> public class ProxyClassForUserImpl extends Object implements User, ... {
>> ...
>> }
>>
>> It used to initially result in:
>> public class ProxyClassForUserImpl extends UserImpl implements User,
>> ... {
>> ...
>> }
>>
>> On 01/25/2012 05:00 PM, Sanne Grinovero wrote:
>>> Would it be acceptable for such a use case to demand to use the
>>> interface instead ?
>>>
>>> UserImpl u = (UserImpl) session.load( UserImpl.class, ... ) -> Illegal
>>> type exception
>>> User u = (User) session.load( User.class, ... ) -> Ok
>>>
>>> I think it would, as the first case would work only in certain
>>> situations even with the current code, depending if you actually get a
>>> proxy or not, so I would consider such code wrong even with the older
>>> API.
>>>
>>> It would only break this currently working code:
>>> User u = (User) session.load( UserImpl.class, ... )
>>>
>>> but it won't break at runtime, it would stop compiling.. which is a
>>> good warning imho. Existing code (already compiled) would throw a
>>> runtime exception though.
>>>
>>> -- Sanne
>>>
>>>
>>> On 25 January 2012 21:26, Steve Ebersole wrote:
BTW, I did go back and verify that indeed the mismatch is with
@Proxy.proxyClass specifying an interface. Consider an example:
@Entity
@Proxy(proxyClass=User.class)
public class UserImpl implements User {
...
}
You will never be able to cast proxies instance of this thing to
UserImpl. This call will fail with CCE:
UserImpl u = (UserImpl) session.load( UserImpl.class, ... )
get() may or may not work depending.
This is the source of us not being able to offer generic signatures.
On Wed 25 Jan 2012 01:33:14 PM CST, Steve Ebersole wrote:
> In regards to the new "load access", a user asked why we don't
> leverage generics.
>
> The problem is the existence of @Proxy#proxyClass. We have the same
> issue with Session#load/get taking the entity Class. We can't use a
> generic sig like:
>
> public T load(Class entityType, ...)
>
> because at times we return objects that are not typed to. I have
> to dive back into the specifics, but IIRC the problem is that we don't
> do the expected thing and have the generated proxy class extend from
> the entity class if @Proxy#proxyClass names an interface. I remember
> this change way back when, but the specifics of why escape me at the
> moment.
>
> IMO I think providing generic signatures would obviously be a great
> improvement. Is it enough to change this behavior?
>
> WDYT?
>
--
st...@hibernate.org
http://hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Pull requests for JIRA issues related to NaturalIdLoadAccess
It would be great if those could get merged since I can't use the natural id features until they are fixed. Someone else reported two more bugs in the new code: https://hibernate.onjira.com/browse/HHH-7112 https://hibernate.onjira.com/browse/HHH-7113 I'm going to be on vacation until Sunday but I'll see if I can get both of those addressed first thing on Monday unless someone else gets to them first. -Eric On 2/29/12 6:37 PM, Gail Badner wrote: > I noticed that Eric Dalquist created some pull requests for JIRA issues > related to NaturalIdLoadAccess. These issues are not scheduled for fixing yet. > > Should they be scheduled for 4.1.1? Is there someone that plans to apply > them? Should I do it? > > Please let me know. > > Thanks, > Gail > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] natural-id to primary key cache
This has been completed and made it into the 4.1 release. There are two parts, a persistence context level cache of PK->NaturalId and NaturalId->PK and a new NaturalIdCacheRegion was added to the caching SPI. The Ehcache provider that ships with Hibernate was updated to support the new region as well. This region ignores the update timestamp cache so it is not invalidated by modifications to the entities. The cache is also populated on insert, update, and load meaning that any time you touch an entity with a naturalId the cache should then be warm for accessing that entity. -Eric On 03/06/2012 08:41 AM, Alex Snaps wrote: > This has been a recurring subject in the ehcache forum and a source of > misunderstanding by many. > Having the second level cache support these as "first class citizen" > makes total sense to me. Is there some draft of how this would look > like ? Would this be a mapping of natural id to primary key ? > Sorry for not replying any earlier, but I totally oversaw this. Also, > I might be asking the obvious here. Will start looking around the > Loader for natural ids in the meantime. > Do you guys think we can still sync to have the new API in both > Infinispan& Ehcache, or is time running short ? > > On Fri, Jan 20, 2012 at 1:20 PM, Steve Ebersole wrote: >> Historically natural-id look ups were accomplished by leveraging >> Criteria queries. Caching was handled through the second level query >> cache. >> >> One of the new things in 4.1 is the dedicated natural-id loading API. >> So the caching will be quite different here. I am a little leery about >> making a breaking changes in 4.1 after all the changes in 4.0 if we can >> avoid it. If we can't we can't. One thought for this was to use a >> SessionFactory scoped "cache" for this in 4.1 and then add a new second >> level cache Region construct for this in 5.0. The *only* benefit is to >> keep the second level cache SPI the same between 4.0 and 4.1. Is that >> worth it? Any thoughts? >> >> >> -- >> st...@hibernate.org >> http://hibernate.org >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] NaturalIdXrefDelegate key comparison issue
I haven't spent a ton of time looking into this yet but while trying to update uPortal to use naturalIds in 4.1.1 I think I ran into a bug in: NaturalIdXrefDelegate$NaturalIdResolutionCache.areSame(Object[], Object[]) That code uses Type.compare(Object x, Object y) to compare each pair of fields in the two naturalIds. I have an entity that has a field of type Class which ends up using the org.hibernate.type.ClassType. ClassType relies on parent class AbstractStandardBasicType to implement the compare method. AbstractStandardBasicType uses the JavaTypeDescriptor.getComparator() method to get the comparator to use. For ClassType the JavaTypeDescriptor is org.hibernate.type.descriptor.java.ClassTypeDescriptor which never sets a comparator so JavaTypeDescriptor.getComparator() returns null resulting in the following NPE: Caused by: java.lang.NullPointerException at org.hibernate.type.AbstractStandardBasicType.compare(AbstractStandardBasicType.java:210) at org.hibernate.engine.internal.NaturalIdXrefDelegate$NaturalIdResolutionCache.areSame(NaturalIdXrefDelegate.java:353) at org.hibernate.engine.internal.NaturalIdXrefDelegate$NaturalIdResolutionCache.cache(NaturalIdXrefDelegate.java:338) at org.hibernate.engine.internal.NaturalIdXrefDelegate.cacheNaturalIdResolution(NaturalIdXrefDelegate.java:78) at org.hibernate.engine.internal.StatefulPersistenceContext.entityStateUpdatedNotification(StatefulPersistenceContext.java:1732) at org.hibernate.engine.spi.EntityEntry.notifyLoadedStateUpdated(EntityEntry.java:382) at org.hibernate.engine.spi.EntityEntry.postUpdate(EntityEntry.java:244) at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:152) at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:362) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:354) at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:276) at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:326) at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:52) at org.hibernate.internal.SessionImpl.flush(SessionImpl.java:1127) at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:325) at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:101) at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:175) at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:73) I likely won't have time to try and reproduce this in a hibernate unit test until Monday or Tuesday, I'm hoping someone might have a quick insight. -Eric ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Adding features to Dialect class
Could this be a common enough issue that Hibernate includes a
work-around type so that everyone doesn't have to write their own?
We've had to address this wonderful Oracle "feature" via a custom user
type as well, ours is based on http://usertype.sourceforge.net/ and the
NullSafeStringType and NullSafeStringColumnMapper are available here:
https://github.com/Jasig/uPortal/blob/master/uportal-war/src/main/java/org/jasig/portal/dao/usertype/
Our approach is that any non-null string gets prefixed with _ when
stored in the DB
-Eric
On 04/23/2012 01:23 PM, Steve Ebersole wrote:
> Personally I think people relying on this Oracle (mis-)behavior are
> just asking for problems.
>
> But lets say people do agree that we should handle this... so you add a
> method to Dialect to handle detect this environment... how do you plan
> on checking it? Today it is the Types that are responsible for
> equality checking (I assume that is what Envers uses as well). So I am
> just suggesting that the user supplying a custom
> FunkyOracleStringVarcharType Type implementation is probably a better
> option. Unless I misunderstand how Envers is doing the equality
> checking and y'all do not use Types for that.
>
> On Mon 23 Apr 2012 11:18:44 AM CDT, Łukasz Antoniak wrote:
>> Totaly agree that expecting null to be equal to empty string in Java model
>> is wrong.
>>
>> IMO he has spotted that when null string reference is replaced with an empty
>> string, Envers creates new revision. From database
>> perspective (Oracle) two records does not differ in any way. This could be
>> actually handled easily in Envers code. I thought that
>> it would be more elegant to add new dialect feature, but if this behavior is
>> special to Oracle, there is no need.
>>
>> // Revision 1
>> em.getTransaction().begin();
>> StrTestEntity emptyEntity = new StrTestEntity("");
>> em.persist(emptyEntity);
>> em.getTransaction().commit();
>> // Should not generate revision after NULL to "" modification on Oracle. But
>> now it does.
>> em.getTransaction().begin();
>> emptyEntity = em.find(StrTestEntity.class, emptyId);
>> emptyEntity.setStr(null);
>> em.merge(emptyEntity);
>> em.getTransaction().commit();
>>
>> Will use dev mailing list. Sorry for that.
>>
>> Steve Ebersole wrote:
>>> Their better option is to apply a Type for String that handles this.
>>>
>> http://docs.jboss.org/hibernate/orm/4.1/manual/en-US/html_single/#types-registry
>>>
>>> This is the type of thing we will be able to handle automatically in
>> 5.0
>>>
>>> But as for the forum user's exact question, personally I think him
>>> expecting null and empty string *in the java model* to be handled
>>> equally is just plain wrong.
>>>
>>> P.S., these kinds of questions should be directed at the dev list so
>> we
>>> can get everyone's input.
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> --
> st...@hibernate.org
> http://hibernate.org
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate Developer IRC meeting - 5/03
Next time I grab a heap dump from one of our prod boxes I can poke around in the org.hibernate classes a bit and let you know what YourKit says if you guys want :) -Eric On 5/4/12 7:14 AM, Steve Ebersole wrote: > Apparently this did not go through to the list the first time, sorry... > > Completely agree. > > I focused on perf in my last comment but I dont think memory is all that > much different. The declaration of all that state already has to be > accounted for in its current "flattened" parallel-array representation. >The trades off here are: > 1) X number of array declarations versus 1 > 2) overhead of the class definition; again its actual state field memory > footprint is already accounted for so we really are just talking about > small amount of memory here. > > Certainly I think its a great idea to try to actually calculate and > compare the memory diffs here. I am pretty confident the difference is > negligible. But either way Hardy's point about higher likelihood of > bugs is the biggest concern. In my experience lack of cohesive > encapsulation is just a recipe for situations where hard to find > problems creep into the code. > > > On 05/04/2012 05:39 AM, Hardy Ferentschik wrote: >> Even taking the risk of pouring oil onto the fire, I think a simpler data >> structure wins in most cases over >> the parallel arrays. It is much harder to use the latter and easier to make >> mistakes which leads to more >> bugs and higher maintenance costs. >> >> As Sanne is saying performance questions are tricky. So many thing are >> happening with the code our days >> before they are getting executed on the bare metal that it is hard to know >> what performance impacts a certain >> change has. In the end you just have to measure. >> >> Personally I think we should primarily strive for a better and easier to use >> API. Oppertunities to optimizes arise >> then often naturally. >> >> And now my dear disciples let me close with: >>"The First Rule of Program Optimization: Don't do it. The Second Rule of >> Program Optimization (for experts only!): Don't do it yet." — Michael A. >> Jackson >> >> :-) >> >> --Hardy >> >> On May 4, 2012, at 11:58 AM, Sanne Grinovero wrote: >> >>> tricky subject. >>> I'm confident that there are many cases in which we should have used >>> arrays rather than maps, especially for temporary objects which aren't >>> short lived enough (an HashMap living in the scope of a single method >>> is going to be cheap). We should have either objects allocated for >>> very long (like forever in the scope of the SessionFactory), or very >>> short. >>> >>> In the case of how we keep metadata, I think performance would be >>> dominated not that much by the fact it's a slightly bigger object but >>> by prefetching and what is going to be available in the cache lines >>> you just have filled in: obviously cache is way faster than memory so >>> being clever in the sequence you lay out your data structure could >>> speed you up by a couple of orders of magnitude. >>> >>> Using primitives and array matrixes makes the data smaller, hence more >>> likely to fit in the cache; but if using an array of objects in which >>> each object collects the needed fields in one group, that's likely >>> going to be faster.. but I'm making assumptions on how this structure >>> is going to be read more frequently. >>> >>> For example when declaring a matrix as an [ ][ ], performance will be >>> very different depending if you read by columns or rows - forgot which >>> one is better now - but in that case if the common use case is using >>> the slower path it's usually a good idea to invert the matrix. >>> >>> I'd love it if we could enter this space, or even if it's not suited >>> for it, at least be considered "lite": >>> http://stackoverflow.com/questions/10374735/lucene-and-ormlite-on-android >>> >>> Sanne >>> >>> On 4 May 2012 10:07, Emmanuel Bernard wrote: Performance I don't know, you are probably right. But memory wise, that could be way different. Even ignoring the overhead of the object + pointer in memory, the alignment of boolean or other small objects would make a significant impact. Of course if we are talking about 20 values, we should not bother. But persisters and the like store more than 20 values and we have more than one persister / loader. It might be inconsequential in the end but that might be worth testing. On a related note it's up for debate whether or not putting data in a hash map for faster lookup later is worth it in all cases: - it takes much more space than raw arrays - array scan might be as fast or faster for a small enough array. As we have seen in Infinispan and OGM, computing a hash is not a cheap operation. Again this require testing but I am guilty as charge of using collections in AnnotationBinder when doing some computations that would be better off
Re: [hibernate-dev] Memory consumption
One option we use on our uPortal installs is to enable -XX:+UseCompressedStrings It requires a bit more CPU but we are generally memory bound and not CPU bound. The description reads "Use a byte[] for Strings which can be represented as pure ASCII. (Introduced in Java 6 Update 21 Performance Release)" for many applications, even those used in other locales, a majority of the strings just use the ascii charset which only needs 1 byte/char See http://thevirtualmachinist.blogspot.com/2010/12/xxusecompressedstrings-explained.html I realize this isn't a general solution but might be interesting as a suggestion for people to look at if they are running into memory issues. -Eric On 5/16/12 11:28 PM, Hardy Ferentschik wrote: >> Its been proposed a number of times to instead generate just a single >> loader for loading that number of items. This would mean generating a >> single SQL statement that has parameter holders for the full batch size >> and then somehow "filling out" the empty slots when the number of things >> to load is less that 16. If this could be made workable across all >> dialects, I personally think it would be the best approach as it >> probably gets close to the start up sizings you claimed but would never >> grow beyond that. > +1 if it is possible it sounds like the best way of doing it > > --hardy > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] mocking library for hibernate unit tests?
I'm working on a fix for https://hibernate.onjira.com/browse/HHH-7468 but I want to write a test first to reproduce the problem. Any recommendations for mocking an EntityPersister and a SessionImplementor in the hibernate (4.1 branch) project? I didn't see something like mockito or easymock on the classpath. Thanks, -Eric ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] mocking library for hibernate unit tests?
Thanks, I'll add a dependency on Mockito for the test and include that with the pull request. -Eric On 8/1/12 1:22 AM, Hardy Ferentschik wrote: > Hi Eric, > > None of the existing tests uses a mock framework. In fact a great part of our > test cases are functional in nature (going through whole Session life > cycles). We have often discussed that we need more actual unit tests. If you > want to use a mocking framework to do this I don't see why you should not be > able to use one. > > --hardy > > > > On 1 Aug 2012, at 06:02, Eric Dalquist wrote: > >> I'm working on a fix for https://hibernate.onjira.com/browse/HHH-7468 >> but I want to write a test first to reproduce the problem. Any >> recommendations for mocking an EntityPersister and a SessionImplementor >> in the hibernate (4.1 branch) project? I didn't see something like >> mockito or easymock on the classpath. >> >> Thanks, >> -Eric >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] SchemaManagementTool / Exportable
+1 for the externalization. We actually have a custom schema-export tool for hibernate 4.1 that plugs in with how we configure data sources in spring much better than the provided tool. -Eric On 08/09/2012 11:38 AM, Steve Ebersole wrote: > The basics of org.hibernate.service.schema.spi.SchemaManagementTool are > essentially done. There is a lot of clean up I want to do after > Configuration is gutted or removed, changing how SchemaExport, etc work > internally. > > But one thing I wanted to discuss was to change up how Exportable works. >Today, its really not much different than what we used to do. The > database objects themselves know how to render themselves into SQL > CREATE/DROP/ALTER commands. What I am contemplating is externalizing > this rendering (lets call them ExportableRenderer, thought better names > welcome). This would serve 2 useful purposes: > 1) Clean up the Table, Sequence, etc code clutter. > 2) Allow plugging in alternate renderings for things. This could be > dialects or users or event custom SchemaManagementTool supplied. > > WDYT? > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Build and AnnotationProcessors
Just to chime in on the IDE use. While hibernate is on the significantly complex side of things for OSS projects go most projects I deal with that are using Maven or Gradle I do just checkout in my IDE and expect to work. For 99% of maven projects this is the case, I checkout/clone the project, import it as a maven project in Eclipse and I'm done. All code and resources required to build are correctly setup on the classpath and I'm good to go. For 99% of gradle project I do something similar but before the import I just run the gradle eclipse command on the CLI. Unless I'm going to be doing active development or patching on a project I don't care about a CLI build, I care about a functional IDE experience so I can run unit tests and debug code to verify some behavior/problem/bug. I don't have much to say specifically on the annotation processors stuff. Right now all the jasig projects use a combination of the maven-processor-plugin and the build-helper-maven-plugin to get the meta-model built and added to the classpath. Honestly I don't care how that happens as long as I can end up with the same final result of maven knowing about a generated-sources directory and code getting placed there during the generate-sources build phase. https://github.com/UW-Madison-DoIT/BlackboardVCPortlet/blob/uw-master/blackboardvc-portlet-webapp/pom.xml#L284 -Eric On 04/17/2013 11:58 AM, Steve Ebersole wrote: > On Wed 17 Apr 2013 11:44:18 AM CDT, Hardy Ferentschik wrote: >> On 17 Jan 2013, at 6:30 PM, Sanne Grinovero wrote: >> >>> AFAIK the reason we originally had a separate phase for annotation >>> processors was to workaround the following javac bug: >>> http://bugs.sun.com/view_bug.do?bug_id=6512707 >> From a Maven perspective (not an ORM issue longer) there is/was also >> the issue of configuring the annotation processors in the compiler plugin. >> There are several unresolved Jira issues for that, but according to David >> they are resolved, even though I cannot see any reference of that in the >> Maven issue tracker. > Right, would not affect ORM anyway. > > >>> On command line users.. I'd agree with Hardy that we likely all prefer >>> building from the command line rather than from the IDE, but I don't >>> expect that to be the majority of users. >> So what do you do when you are interested in some project and want to check >> it out? >> Get the sources and load it directly in your IDE. IMO that is stupid. I >> first build at least >> once from the command line and have a look at the generated directories. >> Does the >> build work? Can I make sense off things w/o knowing much about the code? >> Only then I would start using an IDE and I expect that a developer can set >> up his >> IDE of choice. > So when someone does something different than you they are stupid... > nice :) > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
