Mojos and JDK5
I am working on a plugin which uses JDK5 generics. Attempting to build that plugin gives me: com.thoughtworks.qdox.parser.ParseException: syntax error @[744,56] in file:/home/steve/projects/jboss/dev/maven/maven-plugins/trunk/maven-jdocbook-plugin/src/main/java/org/jboss/jgettext/xml/XmlHandlerImpl.java at com.thoughtworks.qdox.parser.impl.Parser.yyerror(Parser.java:638) at com.thoughtworks.qdox.parser.impl.Parser.yyparse(Parser.java:747) at com.thoughtworks.qdox.parser.impl.Parser.parse(Parser.j ... That position in the file is method returning a generic collection. Is JDK5 allowed in writing a plugin? If so, any idea what I might be doing wrong? -- Steve Ebersole Hibernate Project Lead http://hibernate.org Principal Software Engineer http://redhat.com http://jboss.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to do incremental build?
This is an idea that JBoss and myself, personally, have brought up with the Maven team quite a few times. The terms we use is that of a binary (repo) dependency versus a source (module) dependency. Another name for 'source dependency' might be 'local dependency'. Whatever its term, I personally really see benefit in this when a project is modularized as an implement detail as opposed to any desire to have seperate release cycles to the modules. For example, in the mavenization of Hibernate I chose to break out modules to better isolate dependencies. I have no intention that the modules be versioned separately, or really even developed separately. When I make a change in module, I want modules which depend in it to see that change just like when I operate within IntelliJ (and probably all other IDEs, I would assume). On Monday 03 December 2007 05:09:48 am Dimitris Kapanidis wrote: I agree, When I started using maven with multi-module projects, intuively when doing mvn package in a module I was supposing that local changes of other modules will be used to test the local changes of the tested module. A possible solution that I can see would be to have an mvn parameter to trigger a classpath of the local modules, instead of the repository ones. for example (the name is just an example): $ mvn --help -lc --local-classpath Use local classpath instead of repository. if there is the following module structure: /pom.xml (root pom) /moduleA/pom.xml (changed module) /moduleB/pom.xml (changed module) /moduleC/pom.xml (unchanged module) the following command: /moduleA/$ mvn test should be testing moduleA with the last installed moduleB and moduleC. and the following command /moduleA/$ mvn -lc test should be testing moduleA with a classpath similar to src/main/test:src/main/java:../moduleA/src/main/test/: I'd like some comments about if this is possible/desirable or not. -- Steve Ebersole Hibernate Project Lead http://hibernate.org Principal Software Engineer http://redhat.com http://jboss.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven2 and unit tests with hibernate and jpa connection problems
On Saturday 01 December 2007 09:53:30 am Ryan Moquin wrote: I think my main concern with this (hence why I'm asking general advice) is that sometimes a unit test might work against HSQL and fail against another database such as MSSQL? Or am I worrying about something I shouldn't? I did make some progress finally though, I kept connection pooling on in my unit tests since I don't think it's possible for me to run my build without it, and then I stopped using the maven-sql-plugin and went back to the hibernate ddl create-drop method of recreating my schema (which I ran into problems with, which caused me to go to maven-sql-plugin previously). That alleviates the database in use when the plugin tries to drop and recreate it. Of course, this doesn't answer whether or not I should be using an inmem database like HSQL ... I think depending on people's experiences on the pros and cons will be what will cause me to switch. I'm just worried that I might lose some accuracy in my unit tests going to that approach? Speaking theoretically, a *unit test* for your application should not be concerned with the specific database being used under the covers. That responsibility would fall under the unit tests of the code actually communicating with the database (Hibernate). I stressed the term unit test above, because it has a very specific meaning that is actually not strictly adhered to alot of times; not saying this is good or bad, just saying it is the case. So really it just comes down to personal choice. The usual (productive) middle ground between theory and pragmatism in this realm is to use an in memory database (I actually prefer H2 over HSQLDB) -- Steve Ebersole Hibernate Project Lead http://hibernate.org Principal Software Engineer http://redhat.com http://jboss.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven/Hibernate error / anyone has find similar?
http://opensource.atlassian.com/projects/hibernate/browse/HHH- perchance? On Thursday 15 November 2007 02:30:56 pm Marco Mistroni wrote: Hello, mm not really :) found out that i had a clash between followign dependencies - hibernate 3.2.x - asm-all -cglib - spring ? i am trying to move my project from ant to maven, and we are using hibernate spring, cglib and asm libraries when i downloaded them from web, i got error, when instead i pointed to version installed on my local machine (teh one i m using with ant) everythign worked fine i'll need toinvestigate more as this may cause us problems if we update any versions of spring or hibernate i'll report back here my findings once i proceed with my investigation regards marco On Nov 14, 2007 9:04 PM, Wayne Fay [EMAIL PROTECTED] wrote: Take a look at your applicationContext.xml file, apparently you have an issue with how you've defined your sessionFactory bean (??). org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory' defined in class path resource [applicationContext.xml]: Invocation of init method failed; nested exception is java.lang.NoClassDefFoundError Caused by: java.lang.NoClassDefFoundError at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.getProxyFactory(CGLIB LazyInitializer.java:107) Wayne On 11/14/07, Marco Mistroni [EMAIL PROTECTED] wrote: hi all, i am trying to port an app from ant to maven , but it looks like i am having troubles iwth dependencies. has anyone ever found the error below? i attach my dependencies at the end of message, hope someone can sort me out Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.39 sec FAILURE! testGetBSDRBondIdsReturnsBondIds(com.bnpparibas.risk.collateralrisk.dao .IssueDaoIntegrationTest) Time elapsed: 0.359 sec ERROR! org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory' defined in class path resource [applicationContext.xml]: Invocation of init method failed; nested exception is java.lang.NoClassDefFoundError Caused by: java.lang.NoClassDefFoundError at org.hibernate.proxy.pojo.cglib.CGLIBLazyInitializer.getProxyFactory(CGL IBLazyInitializer.java:107) at org.hibernate.proxy.pojo.cglib.CGLIBProxyFactory.postInstantiate(CGLIBP roxyFactory.java:43) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Steve Ebersole Hibernate Project Lead http://hibernate.org Principal Software Engineer http://redhat.com http://jboss.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test multiple DBs in sequence
On Monday 29 October 2007 05:46:25 pm Yan Huang wrote: Hello Folks, If I want to run the same unit test cases against a list of DBs within a single build, is there a way to configure it in pom.xml? Basically, let's say I want to run the tests against oracle, sybase and mysql in sequence within the same test phase, how can I do it? Maven1 has a jelly's tag called j:forEach to navigate through a collection, how can I achieve the same on maven2? Thanks Yan I was never able to figure out a way to do it. We ended up with with different test runs, one for each DB, using profiles. http://fisheye.jboss.org/browse/Hibernate/core/trunk/testsuite/pom.xml?r=13985 http://fisheye.jboss.org/browse/Hibernate/core/trunk/testsuite/src/test/resources/hibernate.properties?r=12891 Depending upon how you 'prepare and then acquire' connections to the DB, you would be able to achieve this using a custom suite. -- Steve Ebersole Hibernate Project Lead http://hibernate.org Principal Software Engineer http://redhat.com http://jboss.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven hibernate, dependencies not working,plz help :)
I think you mean sp1, not spl thats a 1 (one) ... On Thursday 19 July 2007 08:57:14 pm Wayne Fay wrote: As you can see here: http://repo1.maven.org/maven2/hibernate/hibernate/ 3.2.4.spl is not a valid hibernate version. Where did you get this version number? Wayne On 7/19/07, pinky88 [EMAIL PROTECTED] wrote: Hi everyone, I'm a beginner to maven and hibernate, and i'm trying to build up a small project as a tutorial using maven. I'm using hibernate and hsqldb also. Using examples I've found on the net, I've added dependencies for both hibernate and hsqldb, so my pom.xml looks like this: project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdde.groegl.road2hibernate/groupId artifactIdHibernateTutorial/artifactId packagingjar/packaging version1.0-SNAPSHOT/version nameHibernateTutorial/name urlhttp://maven.apache.org/url dependencies dependency groupIdjunit/groupId artifactIdjunit/artifactId version3.8.1/version scopetest/scope /dependency dependency groupIdhsqldb/groupId artifactIdhsqldb/artifactId version1.8.0.6/version /dependency dependency groupIdhibernate/groupId artifactIdhibernate/artifactId version3.2.4.spl/version scopecompile/scope /dependency /dependencies /project The versions are correct and i have both hibernate and hsqldb downloaded and unzipped.. When i run mvn eclipse:eclipse i get the following : [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'eclipse'. [INFO] - --- [INFO] Building HibernateTutorial [INFO]task-segment: [eclipse:eclipse] [INFO] - --- [INFO] Preparing eclipse:eclipse [INFO] No goals needed for project - skipping [INFO] [eclipse:eclipse] Downloading: http://repo1.maven.org/maven2/hibernate/hibernate/3.2.4.spl/hibernate-3.2 .4.spl.pom Downloading: http://repo1.maven.org/maven2/hsqldb/hsqldb/1.8.0.6/hsqldb-1.8.0.6.pom Downloading: http://repo1.maven.org/maven2/hibernate/hibernate/3.2.4.spl/hibernate-3.2 .4.spl.jar [WARNING] An error occurred during dependency resolution. Failed to retrieve hibernate:hibernate-3.2.4.spl Caused by: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=hibernate -DartifactId=hibernate \ -Dversion=3.2.4.spl -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=hibernate -DartifactId=hibernate \ -Dversion=3.2.4.spl -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) de.groegl.road2hibernate:HibernateTutorial:jar:1.0-SNAPSHOT 2) hibernate:hibernate:jar:3.2.4.spl hibernate:hibernate:jar:3.2.4.spl from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] Unable to read jar manifest from /home/karen/.m2/repository/hibernate/hibernate/3.2.4.spl/hibernate-3.2.4. spl.jar Downloading: http://repo1.maven.org/maven2/hsqldb/hsqldb/1.8.0.6/hsqldb-1.8.0.6.jar [WARNING] An error occurred during dependency resolution. Failed to retrieve hsqldb:hsqldb-1.8.0.6 Caused by: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=hsqldb -DartifactId=hsqldb \ -Dversion=1.8.0.6 -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=hsqldb -DartifactId=hsqldb \ -Dversion=1.8.0.6 -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) de.groegl.road2hibernate:HibernateTutorial:jar:1.0-SNAPSHOT 2) hsqldb:hsqldb:jar:1.8.0.6 hsqldb:hsqldb:jar:1.8.0.6 from the specified remote repositories: central (http://repo1.maven.org/maven2) [INFO] Unable to read jar manifest from /home/karen/.m2/repository/hsqldb/hsqldb/1.8.0.6/hsqldb-1.8.0.6.jar [INFO] Using source status cache: /home/karen/development/workspace/HibernateTutorial/target/mvn-eclipse-ca che.properties [INFO] Not writing settings - defaults suffice [INFO] File /home/karen/development/workspace/HibernateTutorial/.project already exists. Additional settings will be preserved, run mvn eclipse:clean
module ordering
I am having a problem getting multi-module builds to work right. All this stuff is publicly accessible, if someone was willing to take a look and try to help me figure it out. There are a couple of piece of information you'd need: 1) First, you'd need to define the jboss repo in addition to the central repo: repositories repository idjboss/id urlhttp://repository.jboss.com/maven2/url releases enabledtrue/enabled /releases snapshots enabledfalse/enabled /snapshots /repository /repositories pluginRepositories pluginRepository idjboss-plugins/id urlhttp://repository.jboss.com/maven2/url releases enabledtrue/enabled /releases snapshots enabledfalse/enabled /snapshots /pluginRepository /pluginRepositories 2) Check out the parent poms and install them locally: a) http://anonsvn.jboss.org/repos/testhibernate/maven-poms/trunk/core-parent/ b) http://anonsvn.jboss.org/repos/testhibernate/maven-poms/trunk/core-manual-parent/ 3) Check out the project: http://anonsvn.jboss.org/repos/testhibernate/core/trunk/ The situation is that I have a root project (./pom.xml) which defines a number of sub-projects via modules. Some of those sub-projects have dependencies on one another. So for example, ./core/pom.xml is depended upon by a number of other modules. Attempts to run 'mvn install' against the root project fail. They fail in a bizarre fashion. The output shows that maven believes (I think) that ./core/pom.xml has a dependency on ./cache-ehcache/pom.xml. It fails because ./cache-ehcache/pom.xml does then in fact have a dependency back to ./core/pom.xml: [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] Hibernate Core [INFO] Hibernate Ehcache Integration [INFO] Hibernate JBossCache Integration [INFO] Hibernate JBossCache2.x Integration [INFO] Hibernate OSCache Integration [INFO] Hibernate SwarmCache Integration [INFO] Hibernate C3P0 ConnectionProvider [INFO] Hibernate Proxool ConnectionProvider [INFO] Hibernate JMX Module [INFO] Hibernate Testing [INFO] Hibernate Testsuite [INFO] Hibernate Example [INFO] Hibernate Manual (en-US) [INFO] Hibernate Manual (fr-FR) [INFO] Hibernate Manual (aggregator) [INFO] Hibernate Tutorial [INFO] Hibernate Core - Documentation [INFO] Hibernate Core Aggregator [INFO] --- [INFO] Building Hibernate Core [INFO]task-segment: [install] [INFO] --- [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.hibernate:hibernate-core:jar:3.3.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.hibernate -DartifactId=hibernate-c re \ -Dversion=3.3.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.hibernate -DartifactId=hibernate-core -Dversion=3.3.0-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file \ -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.hibernate:hibernate-ehcache:jar:3.3.0-SNAPSHOT 2) org.hibernate:hibernate-core:jar:3.3.0-SNAPSHOT -- 1 required artifact is missing. for artifact: org.hibernate:hibernate-ehcache:jar:3.3.0-SNAPSHOT from the specified remote repositories: central (http://repo1.maven.org/maven2), jboss (http://repository.jboss.com/maven2) But, dependency:analyze shows that core really does not have a dep on ehcache module: [INFO] [dependency:analyze] [INFO] Used declared dependencies: [INFO]commons-collections:commons-collections:jar:3.1:compile [INFO]javax.transaction:jta:jar:1.1:compile [INFO]javassist:javassist:jar:3.4.GA:compile [INFO]javax.security:jaas:jar:1.0.01:provided [INFO]ant:ant:jar:1.6.5:provided [INFO]commons-logging:commons-logging:jar:1.0.4:compile [INFO]javax.security:jacc:jar:1.0:provided [INFO]dom4j:dom4j:jar:1.6.1:compile [INFO]cglib:cglib:jar:2.1_3:compile [INFO]asm:asm-attrs:jar:1.5.3:compile [INFO]antlr:antlr:jar:2.7.6:compile [INFO] Used undeclared dependencies: [WARNING]asm:asm:jar:1.5.3:compile [WARNING]xml-apis:xml-apis:jar:1.0.b2:compile [INFO] Unused
Re: Release top pom without sub modules (projects)
Ahh, the moving modules into profiles approach is nice. Good thought. Tim Kettler wrote: Hi, you have a few options to achieve what you want: 1. I suppose you currently use the top level pom for two things: subproject aggregation (modules/ tag) and the definition of default values for you subprojects (parent pom). You can just split this two concerns in two distinct poms. For example you could create a 'myproject-parent' subproject and release just that. 2. Maven has a command line option '--non-recursive' perhaps this does what you want. 3. Or you can move the module/ definitions in a profile in the pom and just activate it when you want to do a full release. Hope this helps -Tim gc134728 schrieb: Hey maven users, I have a multi-module project architecture with at the top one pom. This pom contains several sub poms which contain sub poms ... When i perform a release on the top pom every project gets released with it. How can i just perform a release on the top pom without releasing it's subprojects with it? One remark sometimes i do want to make a full release of top pom and all subpoms. So what I'm looking for is a property that blocks the transitive release process of the maven-release-plugin. for example : release:prepare -Dblock-reactor Thx for any info Yves --- http://www.scarlet.be/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release top pom without sub modules (projects)
Don't know if this is the correct answer, but I have the same issue and here is how I plan on getting around it. Basically, split the top poms into one for inheritance (used in the parent/ definition) and one for reactor/aggregation (defining the modules/). This is based on the observation that typically it is this super class-type information that I generally need to install/deploy separately; given this breakdown I can do that without installing/deploying all the subprojects. gc134728 wrote: Hey maven users, I have a multi-module project architecture with at the top one pom. This pom contains several sub poms which contain sub poms ... When i perform a release on the top pom every project gets released with it. How can i just perform a release on the top pom without releasing it's subprojects with it? One remark sometimes i do want to make a full release of top pom and all subpoms. So what I'm looking for is a property that blocks the transitive release process of the maven-release-plugin. for example : release:prepare -Dblock-reactor Thx for any info Yves --- http://www.scarlet.be/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
custom packaging
I asked this before, but I don't think I understood the problem well enough to voice it properly nor had I sat down and implemented the alternatives. This is in regards to my DocBook plugin which works completely off the Maven dependency mechanism. So every aspect of the DocBook environment is defined by dependencies rather than having to have DocBook set up locally as is usual with DocBook plugins. So everything from the DocBook XSLT and DTD distro to customizations, fonts and images are defined via dependencies and mixed together to actually perform the transformation. Anyway, logically it makes sense to break the pieces up into a few dependencies: 1) DocBook distro 2) fonts 3) resources (images, css, etc) 4) custom XSLT (might contain #2 and/or #3 also) 5) DocBook sources (might contain #2, #3 and/or #4 also) The way DocBook works, fonts and images have to be treated specially depending on the formating. Thus, I need a way to be able to identify dependencies containing fonts and/or images and stage them. It is this identification step on which I need advice. Basically there seem to be 2 approaches. The first approach I have seen in many plugins. Here I would require the user to tell me the groupId/artifactId of dependency artifacts which contain fonts and images. The (major) downside of this to me always seemed the duplication of this information. For example, consider: plugin ... configuration imageSources artifact !-- here is the duplication -- groupIdcom.acme/groupId artifactIduber-docbook-xslt/artifactId /artifact /imageSources /configuration dependencies dependency groupIdcom.acme/groupId artifactIduber-docbook-xslt/artifactId version1.0.0/version /dependency /dependencies /plugin The other approach does not seem much used (that I could find). The thought was to use custom packaging definitions for the various types of ingredients that go into this DocBook mixture. Then I could distinguish the various pieces based on the artifact.type w/o any duplication: plugin ... configuration ... /configuration dependencies dependency groupIdcom.acme/groupId artifactIduber-docbook-xslt/artifactId typedocbook-xslt/type version1.0.0/version /dependency /dependencies /plugin The other aspect of this comes into play after identification, when I need to stage these resources. Basically, this means I need to aggregate the images and fonts from multiple sources into a local staging or work directory. For dedicated bundles like #2 and #3, this is no issue as I can make the assumption that the directory structure inside the archive is the target structure as well as the fact that all files should get staged. However, for #4 (and to an extent #5) that is most likely not the case. So again, applying the 2 approaches, the first seems pretty verbose: plugin ... configuration imageSources artifact !-- here is the duplication -- groupIdcom.acme/groupId artifactIduber-docbook-xslt/artifactId sourceBaseresources/sourceBase targetBaseimages/targetBase includes.../includes excludes.../excludes /artifact /imageSources /configuration dependencies dependency groupIdcom.acme/groupId artifactIduber-docbook-xslt/artifactId version1.0.0/version /dependency /dependencies /pluginplugin ... configuration imageSources artifact !-- here is the duplication -- groupIdcom.acme/groupId artifactIduber-docbook-xslt/artifactId /artifact /imageSources /configuration dependencies dependency groupIdcom.acme/groupId artifactIduber-docbook-xslt/artifactId version1.0.0/version /dependency /dependencies /plugin Whereas with the second approach, because it is a known packaging, I can make educated assumptions about the contents and structure of those contents. I guess, overall, a slight variation on the first approach would be to use dependency properties rather than explicit configuration. Overall I really liked the idea of custom packaging as a solution here but I had concerns because I did not see anyone using packaging in this manner which leads me to believe that either this is not its intended use or there is some practical difficulty with using them. Anyway, if someone could validate my thinking here and give recomendations/suggestions, that would be much appreciated. Thanks, Steve - To unsubscribe, e-mail: [EMAIL
Re: Enterprise M2 repository stored in subversion
Sure. The JBoss repo (http://repository.jboss.com/maven2/) does exactly this. If the SVN repo is enabled for http access, then its no different from accessing any other Maven repository. Raphaël Piéroni wrote: Hi, i have googled for an answer on the question whether it is possible to store an entreprise Maven repository in subversion and build a freshly checkouted project in a computer with an empty local repository. obviously the project's pom will contain the url to the svn repository. but what such an URL would be ? Thanks in advance for any help Regards, Raphaël - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: docbook + maven
If you look at the code and projects using it, yes, I am aware of this. Or did you miss the directories containing the font definitios tongue-in-cheekly named no-idea-what-to-do-with-these-yet? ;) Actually I was leaning on the expertise of the Red Hat documentation team here, since DocBook (nor xslt, really) is not my forte. I have yet to breach this particular topic with them. If you have a particular need/requirement, well, patches welcome ;) On Thu, 2007-06-07 at 13:15 +0200, Tamás Cservenák wrote: Hello, I had another problem with docbook plugins for maven2. I will just describe it, as it is too often overseen :) My problem was FOP and it's configuration in docbkx plugin. I needed docbook in maven2 to generate docs in Hungarian language. The FOP per default produces PDF with Adobe Default font set (16 fonts) and with all of them in LATIN1 encoding, which is not enough for Eastern European languages. The resolution is to introduce different fonts beside defaults to FOP. See: http://xmlgraphics.apache.org/fop/0.20.5/fonts.html#register Just a thought, since as i read your code, you do the similar thing as docbkx: http://anonsvn.jboss.org/repos/hibernate/trunk/sandbox/maven-poc/plugins/maven-jboss-docbook-plugin/src/main/java/org/jboss/maven/plugin/docbook/gen/render/PdfRenderer.java http://docbkx-tools.googlecode.com/svn/trunk/docbkx-maven-plugin/src/main/java/com/agilejava/docbkx/maven/AbstractPdfMojo.java The configuration customization for FOP is unreachable in both cases, thus it both would renders unusable PDFs in non-LATIN1 environments. The solution would be to make FOP configuration reachable from maven config, or at least create a possibility to direct the FOP to use some specific config-file from within the project. Btw, the docbkx project moved from agilejava.com to http://code.google.com/p/docbkx-tools/ Cheers, ~t~ On 6/4/07, Steve Ebersole [EMAIL PROTECTED] wrote: As part of migrating Hibernate to use Maven, one of the big issues I ran into was the current state of DocBook plugins for Maven. The current mojo-codehaus hosted plugin is insufficient. There is another more widely used one done by one Wilfred Springer as part of something called agilejava. The agilejava one is fairly full featured, but is really pretty bare bones in terms of configuration (its is mainly a simplistic wrapper around the defined DocBook xslt parameters). In my estimation the, agilejava one was closer to usability, but Mr. Springer did not seem interested in accepting my volunteer to help improve his plugin. So I began implementing my own. It works off of a slightly different approach than the other two. The biggest difference being that custom stylesheets are packaged as separate projects and included via the Maven dependency mechanism. This allows true reuse of the stylesheets across projects. The other is planned better support of translations which is important for Hibernate, and most projects using DocBook. This however led to a conceptual question regarding how to best handle image references. As background, in DocBook, the way images normally get resolved is as via xslt templates. The DocBook supplied templates do a hard file lookup relative to a xslt parameter named 'img.src.path' if it is set; and really this is format specific as well. Regardless, though, I need a mechanism to access the image files from these style projects and be able to resolve reference to them from the DocBook source or xsl stylesheets. I have identified a few potential approaches to achieve that: 1) force separation of (a) xslt and (b) resources like images/css into separate projects. Specifically, #b would need a custom packaging which would allow me to find resources and unarchive them locally into a staging dir for use in 'img.src.path'. A variation on this would be to bundle them together with a custom packaging and somehow extract just the resources. 2) Apply custom graphics resolution templates to the built xsl transformers, hoping that the custom xslt does not itself do this. I'm not (necessarily) looking for volunteers (although certainly that is welcome). More I just need people's thoughts on the various approaches, especially those using or familiar with DocBook. Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: docbook + maven
Sure. What we do is we package the styles in a zip file using a
standard maven project and the build-helper-mojo from codehaus. The
zip file contains not only the CSS, the XSLT parameters but also the
images linked to the style.
Next, in a doc project, we depend on the zip above and we use the
dependency plugin to inject the data (dependency:unpack) in the
target/${artifactId} directory where the docb sources are copied.
I am not overly familiar with this dependency plugin, but the overall
approach sounds essentially the same as I described in my staging
approach. The concern I had was knowing which dependencies to pull
resources from. I would then guess that this dependency plugin you
mention requires you to explicitly state the coordinate to be unpacked;
essentially doubling the config?
Now, we have a hard dependency on xmlto for the actual generation. If
we can use a more elegant solution, I'll be glad to test :)
I am not overly familiar with 'xmlto' other than the fact it exists ;)
From my understanding, it is an xslt framework, right? I just use SAXON
inline with the plugin using a Transformer built based on the
configuration, project, etc. The only drawback I have seen is the fact
that SAXON eats large amounts of memory.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: docbook + maven
On Tue, 2007-06-05 at 09:18 +0200, Stephane Nicoll wrote: I am currently migration our doc on docbook+M2 and I ran in the same issues. Is your plugin freely available? Sure, as of now it is in Hibernate SVN and published to the JBoss Maven repo. Regarding styles, we also use them as dependencies and images are located alongside the docbook file. Images alongside the DocBook source is fine for images referenced from those sources; that makes sense. But I am talking about images packaged with the styles. Remember, the whole point is to have reusable xslt bundles. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Can a POM import a profile from anothe POM?
I wanted to throw a comment into this discussion... Please keep in mind that this level of build reproducibility is not *necessarily* a good thing. The particular issue I have with the reproducibility is actually the testing side of it (functional/integration testing). I would love to use profiles in a drop-in fashion specifically to alter the reproducibility of the builds *from a test perspective*. However, that would mean use of either profiles.xml or profiles in settings.xml, neither of which is allowed to change either of the two things which would be needed, in the name of reproducibility: dependencies and testResources. So I would argue that the notion of build reproducibility should be limited to not cover test related concerns. On Sat, 2007-06-02 at 15:09 -0500, Jeff Jensen wrote: I agree! This I said: if they truly all have the same profiles and profile deps, which in your case fails - they share some, but not all share the same ones. In the spirit of idea exchange...if you really don't want poms having duplicate deps, profiles, etc., I would consider using multiple parent poms. One of the things I've done for my current customer is multiple base poms. There is the master base pom that they all use eventually extend from, and every component uses every dependency in that top base pom. I'm sure you can imagine the next tier or two having one or a few poms. Each component's pom extends from the correct parent pom so it has only the deps necessary from the lineage. Component specific info is in its own pom. There are only a handful of parent poms, so it is not unwieldy. The thing I like is the change it in one place. It's just like a class hierarchy in the end, but pom info instead :-). It is a very large system (approaching 12,000 classes) and many components (jars, wars, ear - web apps and batches), and this structure helps us ensure all components have the same dep versions per release as we need. This still has the inconvenience of new versions for _all_ poms when the top-level master changes, but it is fine for me (and a smaller impact when a different parent pom changes). Things usually change when many components are in development mode; hence they are all in SNAPSHOT versions anyway. I would appreciate a better way suggestion or two if someone has any ideas. This is what works well for us. -Original Message- From: Paul Spencer [mailto:[EMAIL PROTECTED] Sent: Saturday, June 02, 2007 2:15 PM To: Maven Users List Subject: Re: Can a POM import a profile from anothe POM? Jeff, My projects fit into the following groups: o jars containing business logic o jars containing common utilities o wars for specific application servers All of the above may share a parent POM, but why should a project that produces a jars containing business logic be affected when a profile that it does not use, like cargo_tomcat_test, is updated? Like you, I am just sharing my thoughts. The more we understand how something is used, the better decision we can make. Worse yet, we may learn something new in the process :) Paul Spencer Jeff Jensen wrote: Hi Paul, Indeed, yes. My comment on lack of build reproducibility was addressing the shared resource approach (and you did not suggest), which is usually not reproducible unless steps are deliberately made to source control the shared resource in a correct manner (in the codelines of all its dependents); apologies for not making that clear! :-) By the fact that your deps profiles are in the pom, which is versioned of its own series, the profiles have the build reproducibility. I also was commenting on the weigh the effort for the benefit of holding profiles in a parent pom, which you commented was impractical, but the benefit of reuse may outweigh the inconvenience, if they truly all have the same profiles and profile deps. That is kind of stating the obvious, but wanted to share the thought that it does have value even though I agree it can be inconvenient... :-) -Original Message- From: Paul Spencer [mailto:[EMAIL PROTECTED] Sent: Saturday, June 02, 2007 12:59 PM To: Maven Users List Subject: Re: Can a POM import a profile from anothe POM? Jeff, I believe I address your concern, which I share, of build reproducibility by including a version number on the imported profile's artifact, essentially making it behave like a dependency. Below is the example, which was in my original post. *** * POM of project which imports the profiles cargo_tomcat_remote and * cargo_jetty_remote and selenium-integration-test. *** project ... groupIdcom.foo.applications/groupId artifactIdwebapp_1/artifactId ... profiles profile idcargo_tomcat_remote/id groupIdcom.foo.profiles/groupId artifactIdcargo/artifactId version1.0/version
docbook + maven
As part of migrating Hibernate to use Maven, one of the big issues I ran into was the current state of DocBook plugins for Maven. The current mojo-codehaus hosted plugin is insufficient. There is another more widely used one done by one Wilfred Springer as part of something called agilejava. The agilejava one is fairly full featured, but is really pretty bare bones in terms of configuration (its is mainly a simplistic wrapper around the defined DocBook xslt parameters). In my estimation the, agilejava one was closer to usability, but Mr. Springer did not seem interested in accepting my volunteer to help improve his plugin. So I began implementing my own. It works off of a slightly different approach than the other two. The biggest difference being that custom stylesheets are packaged as separate projects and included via the Maven dependency mechanism. This allows true reuse of the stylesheets across projects. The other is planned better support of translations which is important for Hibernate, and most projects using DocBook. This however led to a conceptual question regarding how to best handle image references. As background, in DocBook, the way images normally get resolved is as via xslt templates. The DocBook supplied templates do a hard file lookup relative to a xslt parameter named 'img.src.path' if it is set; and really this is format specific as well. Regardless, though, I need a mechanism to access the image files from these style projects and be able to resolve reference to them from the DocBook source or xsl stylesheets. I have identified a few potential approaches to achieve that: 1) force separation of (a) xslt and (b) resources like images/css into separate projects. Specifically, #b would need a custom packaging which would allow me to find resources and unarchive them locally into a staging dir for use in 'img.src.path'. A variation on this would be to bundle them together with a custom packaging and somehow extract just the resources. 2) Apply custom graphics resolution templates to the built xsl transformers, hoping that the custom xslt does not itself do this. I'm not (necessarily) looking for volunteers (although certainly that is welcome). More I just need people's thoughts on the various approaches, especially those using or familiar with DocBook. Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [hibernate-dev] docbook + maven
Mark and I already discussed this. But its a different discussion, since he does not deal with pre-packaged styles... On Mon, 2007-06-04 at 21:38 +0200, Max Rydahl Andersen wrote: one thing is for sure, the current image location in our docbook is annoying ;( It is not relative to where the xml files are and hence it does not show up in e.g. xmlmind. What makes most sense to me is that the images is located relative/correctly based on the actual xml they are referred in. I know Marc Proctor solved this (at least he claims so) - but I don't know how so I cc'ed him in ;) /max As part of migrating Hibernate to use Maven, one of the big issues I ran into was the current state of DocBook plugins for Maven. The current mojo-codehaus hosted plugin is insufficient. There is another more widely used one done by one Wilfred Springer as part of something called agilejava. The agilejava one is fairly full featured, but is really pretty bare bones in terms of configuration (its is mainly a simplistic wrapper around the defined DocBook xslt parameters). In my estimation the, agilejava one was closer to usability, but Mr. Springer did not seem interested in accepting my volunteer to help improve his plugin. So I began implementing my own. It works off of a slightly different approach than the other two. The biggest difference being that custom stylesheets are packaged as separate projects and included via the Maven dependency mechanism. This allows true reuse of the stylesheets across projects. The other is planned better support of translations which is important for Hibernate, and most projects using DocBook. This however led to a conceptual question regarding how to best handle image references. As background, in DocBook, the way images normally get resolved is as via xslt templates. The DocBook supplied templates do a hard file lookup relative to a xslt parameter named 'img.src.path' if it is set; and really this is format specific as well. Regardless, though, I need a mechanism to access the image files from these style projects and be able to resolve reference to them from the DocBook source or xsl stylesheets. I have identified a few potential approaches to achieve that: 1) force separation of (a) xslt and (b) resources like images/css into separate projects. Specifically, #b would need a custom packaging which would allow me to find resources and unarchive them locally into a staging dir for use in 'img.src.path'. A variation on this would be to bundle them together with a custom packaging and somehow extract just the resources. 2) Apply custom graphics resolution templates to the built xsl transformers, hoping that the custom xslt does not itself do this. I'm not (necessarily) looking for volunteers (although certainly that is welcome). More I just need people's thoughts on the various approaches, especially those using or familiar with DocBook. Thanks, Steve ___ hibernate-dev mailing list [EMAIL PROTECTED] https://lists.jboss.org/mailman/listinfo/hibernate-dev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: extensible database integration testing
I may never know :)
I had thought of a similar approach, but some JDBC drivers are actually
mutliple jars...
On Fri, 2007-05-25 at 11:32 +0100, Pete wrote:
I'm not sure I understand at which point you do know these 'execution
environments' but maybe you could specify the values on the command
line along with a pom as follows :-
dependency
groupId${jdbc.groupId}/groupId
artifactId${jdbc.artifactId}/artifactId
version${jdbc.version}/version
/dependency
and
hibernate-configuration
session-factory
!-- Database connection settings --
property
name=connection.driver_class${jdbc.driverClassName}/property
property name=connection.url${jdbc.url}/property
property name=connection.username${jdbc.username}/property
property name=connection.password${jdbc.password}/property
property name=dialect${hibernate.dialect}/property
property name=show_sqltrue/property
/session-factory
/hibernate-configuration
then specify the values using -Djdbc.driverClassName=etc
or in the pom have a number of profiles that can be activated on demand e.g.
profile
idmysql/id
activation
property
namemysql/name
valuetrue/value
/property
/activation
properties
rdbmsmysql/rdbms
hibernate.dialectorg.hibernate.dialect.MySQLInnoDBDialect/hibernate.dialect
jdbc.groupIdmysql/jdbc.groupId
jdbc.artifactIdmysql-connector-java/jdbc.artifactId
jdbc.version5.0.4/jdbc.version
jdbc.driverClassNamecom.mysql.jdbc.Driver/jdbc.driverClassName
/properties
/profile
On 23/05/07, Steve Ebersole [EMAIL PROTECTED] wrote:
I am looking to migrate Hibernate to use Maven for building. I am
currently running into a problem porting the Hibernate testsuite. The
Hibernate testsuite is mainly a bunch of functional and integration
tests and not really unit tests per-se. But it is built on top of
Junit.
Anyway, the problem I am facing is in regards to the need to run the
Hibernate test suite against multiple databases and JDBC drivers.
Basically I need the ability to vary (1) Hibernate configuration and (2)
test dependencies (jdbc drivers) per environment. Logically one would
think of profiles to help solve this, with one profile per
environment. And in fact defining all the profiles in the pom does
in fact work, as i can separately define (1) dependencies and (2)
resources (or properties) per profile.
However, the trick is that I do not know all these execution
environments up front. And thus I cannot define them in the pom. user
supplied profiles.xmls would be an option, except that profiles.xml is
not allowed to specify either of the two things I need (ok, ok, I could
munge the requirements and get properties+resourceFilters to do the
trick for Hibernate configuration).
Anyone have any thoughts on how this may be achievable?
Thanks,
Steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
extensible database integration testing
I am looking to migrate Hibernate to use Maven for building. I am currently running into a problem porting the Hibernate testsuite. The Hibernate testsuite is mainly a bunch of functional and integration tests and not really unit tests per-se. But it is built on top of Junit. Anyway, the problem I am facing is in regards to the need to run the Hibernate test suite against multiple databases and JDBC drivers. Basically I need the ability to vary (1) Hibernate configuration and (2) test dependencies (jdbc drivers) per environment. Logically one would think of profiles to help solve this, with one profile per environment. And in fact defining all the profiles in the pom does in fact work, as i can separately define (1) dependencies and (2) resources (or properties) per profile. However, the trick is that I do not know all these execution environments up front. And thus I cannot define them in the pom. user supplied profiles.xmls would be an option, except that profiles.xml is not allowed to specify either of the two things I need (ok, ok, I could munge the requirements and get properties+resourceFilters to do the trick for Hibernate configuration). Anyone have any thoughts on how this may be achievable? Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
