Re: [hibernate-dev] New project layer
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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss a division of Red Hat [EMAIL PROTECTED] ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] New project layer
Same cycle exists for search and annotations. Alternative workaround for me is to remove the test's from the classpath (but that's even worse) /max 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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss a division of Red Hat [EMAIL PROTECTED] ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] New project layer
It actually works perfectly with ant. IntelliJ works nice to with cross module dependency. Doesn't eclipse support cross module dependencies? 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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss a division of Red Hat [EMAIL PROTECTED] ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] New project layer
It actually works perfectly with ant. Well sure - here you don't specify the project dependencies. You specify the dependencies for each compile. 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 ) 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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss a division of Red Hat [EMAIL PROTECTED] -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss a division of Red Hat [EMAIL PROTECTED] ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] New project layer
On 15 févr. 07, at 09:47, Max Rydahl Andersen wrote: It actually works perfectly with ant. Well sure - here you don't specify the project dependencies. You specify the dependencies for each compile. 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... 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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss a division of Red Hat [EMAIL PROTECTED] -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss a division of Red Hat [EMAIL PROTECTED] ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] New project layer
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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss a division of Red Hat [EMAIL PROTECTED] Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss a division of Red Hat [EMAIL PROTECTED] -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss a division of Red Hat [EMAIL PROTECTED] ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] New project layer
With the help of Paolo on commons-annotations refactoring, I came up with a decent prototype, here is the structure jpa-api lib (empty) compile depends on nothing compiletest depends on nothing commons-annotations lib (empty) compile depends on commons logging, log4j compiletest depends on jpa-api //jpa annotations are used for tests validator lib (empty) compile depends on jpa-api, commons-annotations, core compiletest depends on annotations //DDL integration, will depend on jpa //JPA integration search lib (empty) compile depends on commons-annotations, core compiletest depends on annotations, validator, jpa-api 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 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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] New project layer
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. you keep these things in hibernateext, correct ? ..and how much do i need to do to have the same dependency check for tools ? -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss a division of Red Hat [EMAIL PROTECTED] ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] New project layer
yes round 10 lines of ant script in your build.xml file. here is my comment on that !-- To add a dependency: defines the dependency.jar property that points to the expected jar file in init, add an available dependency.jar and populate dependency.jar.available create a target get.dependency which calls clean and jar add get.depdendecy to depends= for compile or compiletest alter lib.moduleclass.path or junit.moduleclasspath accordingly -- We could mutualize that a bit more though and avoid to create a target get.dependency which calls clean and jar, call a generic one instead. On 30 janv. 07, at 16:31, Max Rydahl Andersen wrote: 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. you keep these things in hibernateext, correct ? ..and how much do i need to do to have the same dependency check for tools ? -- -- Max Rydahl Andersen callto://max.rydahl.andersen Hibernate [EMAIL PROTECTED] http://hibernate.org JBoss a division of Red Hat [EMAIL PROTECTED] ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
