[hibernate-dev] New project layer

Max Rydahl Andersen max.andersen at redhat.com
Thu Feb 15 12:19:18 EST 2007


>>> IntelliJ works nice to with cross module dependency. Doesn't eclipse  
>>> support cross module dependencies?
>>
>> It supports project dependencies; but not cyclic ones. (I don't know of  
>> any IDE that
>> supports that (without having to build the annotations.jar by hand and  
>> then not let the project
>> be dependent on each other )
>
> Well IntelliJ IDEA does...

Does it solve it by letting you point to classes a .jar or actually point  
to
the *project* as a dependency.

The first part is what I can do too in eclipse; the second one I can't  
because it
creates a cyclic dependency.

Anyway - I don't like the cyclic dependency there is here; with or without  
any ide ;)

/max

>>
>> I could probably tell it to point to the build/classes directory  
>> instead of the project;
>> but that is still horrible - it does not remove the cyclic that still  
>> exists here.
>>
>> To resolve it you would need to move the search/validator tests to  
>> annotations or
>> remove the AnnotationConfiguration depenendency in the tests...
>>
>> /max
>>
>>>
>>> On 15 févr. 07, at 06:33, Max Rydahl Andersen wrote:
>>>
>>>>
>>>>> validator
>>>>>    lib (empty)
>>>>>    compile depends on jpa-api, commons-annotations, core
>>>>>    compiletest depends on annotations //DDL integration, will depend  
>>>>> on jpa //JPA integration
>>>>>
>>>>> annotations
>>>>>    lib (empty)
>>>>>    compile depends on jpa-api, validator, commons-annotations, core
>>>>>      //want to add a dependency to search for ease of use
>>>>>    compiletest depends on nothing more
>>>>
>>>> I did not notice this until I actually tried to put this into eclipse.
>>>>
>>>> You have a dependency cycle here - annotations needs validator, but  
>>>> validator
>>>> (it's tests at least) cannot be compiled without annotations...
>>>>
>>>> I can probably solve this by putting a compiled annotations on the  
>>>> classpath of validator
>>>> but that is so yucky! :(
>>>>
>>>> /max
>>>>
>>>>
>>>>> jpa
>>>>>    lib (jboss-archive-browser)
>>>>>    compile depends on jpa-api, validator, commons-annotations,  
>>>>> annotations, core
>>>>>    compiletest depends on nothing more
>>>>>
>>>>>
>>>>> Dependencies are managed by the building system automatically. The  
>>>>> way it is done is a hack in the build.xml files (no clean  
>>>>> encapsulation), but it deals nicely with compilation dependencies vs  
>>>>> test compilation dependencies: it could be improved by implementing  
>>>>> a specific ant task. The build looks for the availability of the jar  
>>>>> dependencies, and if not present clean, jar is called on this  
>>>>> dependency project
>>>>> Alternatively, Ivy looks very promising and quite lightweight in the  
>>>>> way dependencies are handled, so we could use it: no rush though,  
>>>>> since the job is done and there won't be much dependency changes.
>>>>>
>>>>> The nice thing about it is that there is no more lib/* duplication  
>>>>> (most are shared)
>>>>>
>>>>> I still need to tackle with the dist task and copy the dependency  
>>>>> libraries instead.
>>>>>
>>>>> Aside from the build changes:
>>>>>   - commons-annotations is now independent with no dependencies
>>>>>   - validator still depend on core (it is actually hard not to), but  
>>>>> it can work fine without HAN, you can use it with a plain JPA engine.
>>>>>   - search is independent of HAN, per se but not from core, it could  
>>>>> be easily though I think and we could support plain JPA engines as  
>>>>> well.
>>>>>
>>>>> A few remaining questions:
>>>>>   - HAN as an integration project
>>>>> Should Hibernate Annotations embed search and validator jars, I  
>>>>> think so as third party jars, it would make the full blend HAN usage  
>>>>> smoother (like event listener auto configuration)
>>>>> The idea is to embed a reference version of validator and search in  
>>>>> HAN with he ability for a user to upgrade validator or search for a  
>>>>> given HAN version
>>>>>
>>>>>   - Version number
>>>>> I am in favor of keeping the version number root 3.2.2. Hibernate  
>>>>> Search however is still beta, so a different versioning would be  
>>>>> better 3.2.2.beta1 and so on (3.2.2.beta2 or 3.2.3.beta1).
>>>>>
>>>>>   - Documentation
>>>>> Since Validator and Search will be integrated to HAN, should I keep  
>>>>> the chapters in both the HAN doc and the validator doc?
>>>>>
>>>>> I plan to apply that sometimes this week (tomorrow hopefully). Once  
>>>>> I'm done we'll be able to think about the website changes.
>>>>> Comments welcome before I commit that work.
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>
>>>>
>>>>
>>>> ----
>>>> Max Rydahl Andersen
>>>> callto://max.rydahl.andersen
>>>>
>>>> Hibernate
>>>> max at hibernate.org
>>>> http://hibernate.org
>>>>
>>>> JBoss a division of Red Hat
>>>> max.andersen at jboss.com
>>>
>>
>>
>>
>> ----
>> Max Rydahl Andersen
>> callto://max.rydahl.andersen
>>
>> Hibernate
>> max at hibernate.org
>> http://hibernate.org
>>
>> JBoss a division of Red Hat
>> max.andersen at jboss.com
>



-- 
--
Max Rydahl Andersen
callto://max.rydahl.andersen

Hibernate
max at hibernate.org
http://hibernate.org

JBoss a division of Red Hat
max.andersen at jboss.com



More information about the hibernate-dev mailing list