You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Benson Margulies <bi...@gmail.com> on 2012/04/24 14:42:08 UTC
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Proposal: the maven build-from-source-plugin
Posted by Jesse Farinacci <ji...@gmail.com>.
Greetings,
On Tue, Apr 24, 2012 at 8:42 AM, Benson Margulies <bi...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Proposal: the maven build-from-source-plugin
Posted by Benson Margulies <bi...@gmail.com>.
On Wed, Apr 25, 2012 at 10:45 AM, Stephen Connolly
<st...@gmail.com> wrote:
> On 25 April 2012 14:46, Benson Margulies <bi...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Proposal: the maven build-from-source-plugin
Posted by Stephen Connolly <st...@gmail.com>.
On 25 April 2012 14:46, Benson Margulies <bi...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Proposal: the maven build-from-source-plugin
Posted by Benson Margulies <bi...@gmail.com>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Proposal: the maven build-from-source-plugin
Posted by Chris Graham <ch...@gmail.com>.
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 <bi...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org