Re: Proposal: the maven build-from-source-plugin
Greetings, On Tue, Apr 24, 2012 at 8:42 AM, Benson Margulies bimargul...@gmail.com wrote: I was wondering how hard it would be to build a plugin, perhaps inspired by the scm plugin, that could download and build source. While I don't think I would personally use the reasons you want this plugin, I have several times before wanted to be able to materialize a project's source tree from a GAV coordinate. In my mind, I had seen this as mojos for m-dependency-p, where it already has the notion of copying dependencies and otherwise working with them, some examples: http://maven.apache.org/plugins/maven-dependency-plugin/ mvn dependency:materialize -DgroupId=g -DartifactId=a -Dversion=v OR -Ddependency=g:a:v mvn dependency:materialize-dependencies I agree, it would be great if it could locate the artifact using standard resolution, download parent chain, figure out the scm, then use maven-scm to check the version out (trunk if none specified). For materialize-dependencies, it should do that for all dependencies specified. -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposal: the maven build-from-source-plugin
Here's a use case, and I think a way to make something that works. Project A wants to make use of a dependency from project B. There is, however a bug. Project B is, for whatever reason, not going to release a bugfix any time soon. Project A really doesn't want to establish a full fork. In the good old days of open source, A would distribute a patch and leave it to their users to apply it. Now, consider a Maven project that is part of the tree of A. It's g/a/v says: 'our.fixed.version':'of-project-b':v. It uses a maven plugin to download the source of B. It applies a patch. It then uses the invoker, or anrun, or something, to build B. It then needs to attach the results so that the reactor can see them, and all is well. (It can shade or not as appropriate to circumstances). There is also a more philosophical use case that I won't bore you with. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposal: the maven build-from-source-plugin
On 25 April 2012 14:46, Benson Margulies bimargul...@gmail.com wrote: Here's a use case, and I think a way to make something that works. Project A wants to make use of a dependency from project B. There is, however a bug. Project B is, for whatever reason, not going to release a bugfix any time soon. Project A really doesn't want to establish a full fork. In the good old days of open source, A would distribute a patch and leave it to their users to apply it. Now, consider a Maven project that is part of the tree of A. It's g/a/v says: 'our.fixed.version':'of-project-b':v. without a provides (note the 's' is not a 'd') scope or equivalent that will cause endless problems with the transitive dependency hull. They would need to keep the G:A the same and vary the V... and that will hit issues publishing to Central. It uses a maven plugin to download the source of B. It applies a patch. It then uses the invoker, or anrun, or something, to build B. It then needs to attach the results so that the reactor can see them, and all is well. (It can shade or not as appropriate to circumstances). There is also a more philosophical use case that I won't bore you with. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposal: the maven build-from-source-plugin
On Wed, Apr 25, 2012 at 10:45 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 25 April 2012 14:46, Benson Margulies bimargul...@gmail.com wrote: Here's a use case, and I think a way to make something that works. Project A wants to make use of a dependency from project B. There is, however a bug. Project B is, for whatever reason, not going to release a bugfix any time soon. Project A really doesn't want to establish a full fork. In the good old days of open source, A would distribute a patch and leave it to their users to apply it. Now, consider a Maven project that is part of the tree of A. It's g/a/v says: 'our.fixed.version':'of-project-b':v. without a provides (note the 's' is not a 'd') scope or equivalent that will cause endless problems with the transitive dependency hull. They would need to keep the G:A the same and vary the V... and that will hit issues publishing to Central. No publication to central. That's a 'central' principle here. It uses a maven plugin to download the source of B. It applies a patch. It then uses the invoker, or anrun, or something, to build B. It then needs to attach the results so that the reactor can see them, and all is well. (It can shade or not as appropriate to circumstances). There is also a more philosophical use case that I won't bore you with. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Proposal: the maven build-from-source-plugin
From time to time, there is an impedance mismatch between the desires of an open source development community and the nature of Maven as a *binary* dependency management system. While I wouldn't, for a moment, suggest tampering with the existing binary system, I was wondering how hard it would be to build a plugin, perhaps inspired by the scm plugin, that could download and build source. One hopes to discover that the -sources artifact for a gav is, in fact, comprehensive and buildable. Could the results of such a build enter the reactor without core changes, or would there need to be a two-phase approach? This, of course, assumes that the sources are (a) buildable and (b) buildable with maven. (Give or take antrun or other scripting.) A further interesting wrinkle would be to add patch application to the mix -- possibly a problem bounded by the need for a Java implementation of 'patch'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Proposal: the maven build-from-source-plugin
I really don't see the point in this. Whilst I can see your intention, I do not see the need, nor do I see realistically that it is feasable. I do agree with the limitations that you state and I can think of more. To the point that I think it could only cover such a small subset of cases as to be questionable as to whether you'd bother. Perhaps you could better explain your thinking on the need? -Chris Sent from my iPhone On 24/04/2012, at 10:42 PM, Benson Margulies bimargul...@gmail.com wrote: From time to time, there is an impedance mismatch between the desires of an open source development community and the nature of Maven as a *binary* dependency management system. While I wouldn't, for a moment, suggest tampering with the existing binary system, I was wondering how hard it would be to build a plugin, perhaps inspired by the scm plugin, that could download and build source. One hopes to discover that the -sources artifact for a gav is, in fact, comprehensive and buildable. Could the results of such a build enter the reactor without core changes, or would there need to be a two-phase approach? This, of course, assumes that the sources are (a) buildable and (b) buildable with maven. (Give or take antrun or other scripting.) A further interesting wrinkle would be to add patch application to the mix -- possibly a problem bounded by the need for a Java implementation of 'patch'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
