Re: [status] main issues
On Thursday 07 October 2004 21:37, Stefano Mazzocchi wrote: The problem with maven is that I don't know how we can inject the gump-generated dependency jars into maven. Brett Porter (Maven expert) is normally around to answer questions on how Maven operates. Does anybody have an idea? we can't expect excalibur to fix this on their own since this is obviously a gump issue, more than an excalibur issue. I can propose a short term solution; Revert the Excalibur packages in Gump back to the one sitting in the frozen avalon-excalibur CVS, which builds close to perfectly in Gump (I think there is the altrmi instrumentation packages that fails as a dep on altrmi, or something like that.) Then we take the Excalibur Maven projects and name them slightly different, so we can sort that out without holding up all the projects downstream. Cheers Niclas -- +--//---+ / http://www.bali.ac/ / http://niclas.hedhman.org / +--//---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [status] main issues
-Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] But the *most* serious concern is that we seem to have no way to build with Maven and, due to excalibur, this is holding up basically 15 percent of our projects (including, yes, you guessed right, cocoon). Fast track solution could be to put the last released jar files into an excalibur-releases module with project ids matching the current set of ids, and disable the existing excalibur descriptors pending resolution of gump/maven equation (see below). The problem with maven is that I don't know how we can inject the gump-generated dependency jars into maven. Maven is fine on the injection stuff - basically it used a jar override property that tells maven to use the jar file named in a property value as the actual jar to bind against. The problem is the generation of the property files (by gump's maven builder). Does anybody have an idea? Gump uses a namespace made of a project id and an optional output key. Maven uses a combination of group and artifact name combination. If we take for example - the jar file produced by ant containing the junit optional task is referenced in gump as: project: ant id: junit In Maven the same jar file is normally referenced as: groupId: ant artifactId: ant-junit When Gump's maven builder generates the proprieties file used during the maven build, it uses the gump project model to establish the set of dependencies and for each dump declared dependency (with full inheritance of dependencies) create a property with the following name and value: maven.jar.junit=/usr/local/gump/public/workspace/ant/dist/lib/ant-junit. jar Problem here is that: 1. this property definition does not correspond to anything declared in the target project's project.xml (because the property is derived from the gump based dependencies - not the project's declared dependencies) 2. the strategy for mapping of gump artifact keys to maven artifact keys is basically broken in that duplicate property names can be generated (e.g. the property name generated for the main JUnit project jar file is maven.jar.junit) The solution to this problem is to drive the property file generation off the project.xml file and NOT the gump dependency graph. This will solve most issues because it will result in a much smaller set of properties - but an underlying problem needs to be solved - namely the declaration within a maven project of any mappings between maven artifact names to gump project keys (e.g. ant/ant-junit -- ant:junit). These mappings need to be used by the maven gump task when generating a maven project descriptor. Stephen. we can't expect excalibur to fix this on their own since this is obviously a gump issue, more than an excalibur issue. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [status] main issues
Stephen, thanks much for your input. Some comments below. But the *most* serious concern is that we seem to have no way to build with Maven and, due to excalibur, this is holding up basically 15 percent of our projects (including, yes, you guessed right, cocoon). Fast track solution could be to put the last released jar files into an excalibur-releases module with project ids matching the current set of ids, and disable the existing excalibur descriptors pending resolution of gump/maven equation (see below). Yes, that might be an ad-hoc solution and it might work for now since there are not so many maven projects in our tree anyway (just checked). Can you provide such a 'fake' descriptor? i think it would be much faster than me trying to hack one up. The problem with maven is that I don't know how we can inject the gump-generated dependency jars into maven. Maven is fine on the injection stuff - basically it used a jar override property that tells maven to use the jar file named in a property value as the actual jar to bind against. The problem is the generation of the property files (by gump's maven builder). Ok, good to know. Does anybody have an idea? Gump uses a namespace made of a project id and an optional output key. Maven uses a combination of group and artifact name combination. If we take for example - the jar file produced by ant containing the junit optional task is referenced in gump as: project: ant id: junit In Maven the same jar file is normally referenced as: groupId: ant artifactId: ant-junit When Gump's maven builder generates the proprieties file used during the maven build, it uses the gump project model to establish the set of dependencies and for each dump declared dependency (with full inheritance of dependencies) create a property with the following name and value: maven.jar.junit=/usr/local/gump/public/workspace/ant/dist/lib/ant-junit. jar Problem here is that: 1. this property definition does not correspond to anything declared in the target project's project.xml (because the property is derived from the gump based dependencies - not the project's declared dependencies) 2. the strategy for mapping of gump artifact keys to maven artifact keys is basically broken in that duplicate property names can be generated (e.g. the property name generated for the main JUnit project jar file is maven.jar.junit) The solution to this problem is to drive the property file generation off the project.xml file and NOT the gump dependency graph. This will solve most issues because it will result in a much smaller set of properties - but an underlying problem needs to be solved - namely the declaration within a maven project of any mappings between maven artifact names to gump project keys (e.g. ant/ant-junit -- ant:junit). These mappings need to be used by the maven gump task when generating a maven project descriptor. I'm sorry, but I have lost you. If the strategy is broken, why don't we fix it? [but I think I'm missing a point here obviously] -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [status] main issues
3) the maven integration is poor and hacky How much do you actually know about this integration? I don't know that it is poor, and I believe it is not hacky. Where are you getting your information? But the *most* serious concern is that we seem to have no way to build with Maven and, due to excalibur, this is holding up basically 15 percent of our projects (including, yes, you guessed right, cocoon). The problem with maven is that I don't know how we can inject the gump-generated dependency jars into maven. We are doing it. Clearly you've next to no idea on how this works. We use the technique that Mavenites told us was appropriate: http://maven.apache.org/reference/user-guide.html#Overriding_Stated_Dependencies Does anybody have an idea? we can't expect excalibur to fix this on their own since this is obviously a gump issue, more than an excalibur issue. So what is the problem? regards, Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [status] main issues
-Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] But the *most* serious concern is that we seem to have no way to build with Maven and, due to excalibur, this is holding up basically 15 percent of our projects (including, yes, you guessed right, cocoon). Fast track solution could be to put the last released jar files into an excalibur-releases module with project ids matching the current set of ids, and disable the existing excalibur descriptors pending resolution of gump/maven equation (see below). The problem with maven is that I don't know how we can inject the gump-generated dependency jars into maven. Maven is fine on the injection stuff - basically it used a jar override property that tells maven to use the jar file named in a property value as the actual jar to bind against. The problem is the generation of the property files (by gump's maven builder). Does anybody have an idea? Gump uses a namespace made of a project id and an optional output key. Maven uses a combination of group and artifact name combination. If we take for example - the jar file produced by ant containing the junit optional task is referenced in gump as: project: ant id: junit In Maven the same jar file is normally referenced as: groupId: ant artifactId: ant-junit When Gump's maven builder generates the proprieties file used during the maven build, it uses the gump project model to establish the set of dependencies and for each dump declared dependency (with full inheritance of dependencies) create a property with the following name and value: maven.jar.junit=/usr/local/gump/public/workspace/ant/dist/lib/ant-junit. jar Problem here is that: 1. this property definition does not correspond to anything declared in the target project's project.xml (because the property is derived from the gump based dependencies - not the project's declared dependencies) 2. the strategy for mapping of gump artifact keys to maven artifact keys is basically broken in that duplicate property names can be generated (e.g. the property name generated for the main JUnit project jar file is maven.jar.junit) The solution to this problem is to drive the property file generation off the project.xml file and NOT the gump dependency graph. This will solve most issues because it will result in a much smaller set of properties - but an underlying problem needs to be solved - namely the declaration within a maven project of any mappings between maven artifact names to gump project keys (e.g. ant/ant-junit -- ant:junit). These mappings need to be used by the maven gump task when generating a maven project descriptor. Stephen. we can't expect excalibur to fix this on their own since this is obviously a gump issue, more than an excalibur issue. -- Stefano. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [status] main issues
Adam R. B. Jack wrote: So what is the problem? Problem is http://brutus.apache.org/gump/public/excalibur/ maven integration might not be hacky (true, I had no idea we were injectin stuff in, so I take that back) but it does not work at all. Now, tell me, is this just a matter of fixing the excalibur.xml file or, like Stephen suggested, the problem is much deeper? -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
