You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Francesco Mari <ma...@gmail.com> on 2013/07/24 13:57:02 UTC
Passing information between goals
Hi,
I wrote some MOJOs which use common data. This data depends on the
structure of the project and can't be changed at runtime.
I would like to compute this information at the beginiing of the build
process, and re-use it in each related goal. Ideally, the first goal should
compute the data, and the following ones will just use it.
Which is the best option? Are there any plugins already implementing such a
strategy, so I can take a look at their source code?
Re: Passing information between goals
Posted by Fred Cooke <fr...@gmail.com>.
Just remove the and from the end of it...
On Wed, Jul 24, 2013 at 3:30 PM, Martin Gainty <mg...@hotmail.com> wrote:
>
> can anyone reach the URL?
>
> Baptiste is it possible to repost comments for build-helper to pastebin?
>
> http://pastebin.com/
>
>
>
>
> > Date: Wed, 24 Jul 2013 15:20:33 +0200
> > Subject: Re: Passing information between goals
> > From: ml@batmat.net
> > To: dev@maven.apache.org
> >
> > Hi,
> >
> > I remember doing that for build-helper. It was for many executions of the
> > same mojo though, not sure how it behaves with different mojos.
> > See
> >
> http://mojo.10943.n7.nabble.com/build-helper-m-p-thread-safety-issue-td39561.htmland
> > the ReserveListenerPortMojo
> >
> > My 2 cents.
> >
> > Cheers
> > Le 24 juil. 2013 14:17, "Stephen Connolly" <
> stephen.alan.connolly@gmail.com>
> > a écrit :
> >
> > > This is generally a tad tricky.
> > >
> > > 1. Because of class unloading it may not be possible to use the
> Hack-type
> > > solution of stashing the data in a Class level static field. Though
> that
> > > solution will work as long as the field uses a collection type that
> allows
> > > for GC when the MavenProject that it is caching a value for has been
> > > collected by GC (think of the users of Maven Embedder who's Maven
> process
> > > may be long lived and reused multiple times)
> > >
> > > 2. Easiest way may just be to serialize the value into a string form
> and
> > > set a project property with a non-maven resolvable name to the string
> > > value. For example I do not think it is possible to have a Maven
> property
> > > start with the null character.
> > >
> > > You code will need to be defensive, and if the property (or cache
> value if
> > > you go route 1) is missing it will have to calculate the value from
> scratch
> > >
> > >
> > > On 24 July 2013 12:57, Francesco Mari <ma...@gmail.com>
> wrote:
> > >
> > > > Hi,
> > > >
> > > > I wrote some MOJOs which use common data. This data depends on the
> > > > structure of the project and can't be changed at runtime.
> > > >
> > > > I would like to compute this information at the beginiing of the
> build
> > > > process, and re-use it in each related goal. Ideally, the first goal
> > > should
> > > > compute the data, and the following ones will just use it.
> > > >
> > > > Which is the best option? Are there any plugins already implementing
> > > such a
> > > > strategy, so I can take a look at their source code?
> > > >
> > >
>
>
RE: Passing information between goals
Posted by Martin Gainty <mg...@hotmail.com>.
can anyone reach the URL?
Baptiste is it possible to repost comments for build-helper to pastebin?
http://pastebin.com/
> Date: Wed, 24 Jul 2013 15:20:33 +0200
> Subject: Re: Passing information between goals
> From: ml@batmat.net
> To: dev@maven.apache.org
>
> Hi,
>
> I remember doing that for build-helper. It was for many executions of the
> same mojo though, not sure how it behaves with different mojos.
> See
> http://mojo.10943.n7.nabble.com/build-helper-m-p-thread-safety-issue-td39561.htmland
> the ReserveListenerPortMojo
>
> My 2 cents.
>
> Cheers
> Le 24 juil. 2013 14:17, "Stephen Connolly" <st...@gmail.com>
> a écrit :
>
> > This is generally a tad tricky.
> >
> > 1. Because of class unloading it may not be possible to use the Hack-type
> > solution of stashing the data in a Class level static field. Though that
> > solution will work as long as the field uses a collection type that allows
> > for GC when the MavenProject that it is caching a value for has been
> > collected by GC (think of the users of Maven Embedder who's Maven process
> > may be long lived and reused multiple times)
> >
> > 2. Easiest way may just be to serialize the value into a string form and
> > set a project property with a non-maven resolvable name to the string
> > value. For example I do not think it is possible to have a Maven property
> > start with the null character.
> >
> > You code will need to be defensive, and if the property (or cache value if
> > you go route 1) is missing it will have to calculate the value from scratch
> >
> >
> > On 24 July 2013 12:57, Francesco Mari <ma...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I wrote some MOJOs which use common data. This data depends on the
> > > structure of the project and can't be changed at runtime.
> > >
> > > I would like to compute this information at the beginiing of the build
> > > process, and re-use it in each related goal. Ideally, the first goal
> > should
> > > compute the data, and the following ones will just use it.
> > >
> > > Which is the best option? Are there any plugins already implementing
> > such a
> > > strategy, so I can take a look at their source code?
> > >
> >
Re: Passing information between goals
Posted by Francesco Mari <ma...@gmail.com>.
Thank you all for the useful isnights.
2013/7/24 Stephen Connolly <st...@gmail.com>
> getPluginContext() is the one you want. Use that to stash your info.
>
>
> On 24 July 2013 15:15, Francesco Mari <ma...@gmail.com> wrote:
>
> > Thank you for the link, but I don't need to coordinate multiple projects
> in
> > the same session. My use case is only focused on one project.
> >
> > What about serializing the information somewhere in the
> > ${project.build.directory} folder?
> >
> > Are there any issues I should aware of if I implement this solution?
> >
> >
> > 2013/7/24 Stephen Connolly <st...@gmail.com>
> >
> > > Ahh yes... that's the one... I spent 3-5 min searching for it.
> > >
> > > getPluginContext() is the map you want (unless you want to span
> > modules...
> > > even then I think you can cheat slightly by doing some funky stuff)
> > >
> > >
> > > On 24 July 2013 14:20, Baptiste MATHUS <ml...@batmat.net> wrote:
> > >
> > > > Hi,
> > > >
> > > > I remember doing that for build-helper. It was for many executions of
> > the
> > > > same mojo though, not sure how it behaves with different mojos.
> > > > See
> > > >
> > > >
> > >
> >
> http://mojo.10943.n7.nabble.com/build-helper-m-p-thread-safety-issue-td39561.htmland
> > > > the ReserveListenerPortMojo
> > > >
> > > > My 2 cents.
> > > >
> > > > Cheers
> > > > Le 24 juil. 2013 14:17, "Stephen Connolly" <
> > > > stephen.alan.connolly@gmail.com>
> > > > a écrit :
> > > >
> > > > > This is generally a tad tricky.
> > > > >
> > > > > 1. Because of class unloading it may not be possible to use the
> > > Hack-type
> > > > > solution of stashing the data in a Class level static field. Though
> > > that
> > > > > solution will work as long as the field uses a collection type that
> > > > allows
> > > > > for GC when the MavenProject that it is caching a value for has
> been
> > > > > collected by GC (think of the users of Maven Embedder who's Maven
> > > process
> > > > > may be long lived and reused multiple times)
> > > > >
> > > > > 2. Easiest way may just be to serialize the value into a string
> form
> > > and
> > > > > set a project property with a non-maven resolvable name to the
> string
> > > > > value. For example I do not think it is possible to have a Maven
> > > property
> > > > > start with the null character.
> > > > >
> > > > > You code will need to be defensive, and if the property (or cache
> > value
> > > > if
> > > > > you go route 1) is missing it will have to calculate the value from
> > > > scratch
> > > > >
> > > > >
> > > > > On 24 July 2013 12:57, Francesco Mari <ma...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I wrote some MOJOs which use common data. This data depends on
> the
> > > > > > structure of the project and can't be changed at runtime.
> > > > > >
> > > > > > I would like to compute this information at the beginiing of the
> > > build
> > > > > > process, and re-use it in each related goal. Ideally, the first
> > goal
> > > > > should
> > > > > > compute the data, and the following ones will just use it.
> > > > > >
> > > > > > Which is the best option? Are there any plugins already
> > implementing
> > > > > such a
> > > > > > strategy, so I can take a look at their source code?
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Passing information between goals
Posted by Stephen Connolly <st...@gmail.com>.
getPluginContext() is the one you want. Use that to stash your info.
On 24 July 2013 15:15, Francesco Mari <ma...@gmail.com> wrote:
> Thank you for the link, but I don't need to coordinate multiple projects in
> the same session. My use case is only focused on one project.
>
> What about serializing the information somewhere in the
> ${project.build.directory} folder?
>
> Are there any issues I should aware of if I implement this solution?
>
>
> 2013/7/24 Stephen Connolly <st...@gmail.com>
>
> > Ahh yes... that's the one... I spent 3-5 min searching for it.
> >
> > getPluginContext() is the map you want (unless you want to span
> modules...
> > even then I think you can cheat slightly by doing some funky stuff)
> >
> >
> > On 24 July 2013 14:20, Baptiste MATHUS <ml...@batmat.net> wrote:
> >
> > > Hi,
> > >
> > > I remember doing that for build-helper. It was for many executions of
> the
> > > same mojo though, not sure how it behaves with different mojos.
> > > See
> > >
> > >
> >
> http://mojo.10943.n7.nabble.com/build-helper-m-p-thread-safety-issue-td39561.htmland
> > > the ReserveListenerPortMojo
> > >
> > > My 2 cents.
> > >
> > > Cheers
> > > Le 24 juil. 2013 14:17, "Stephen Connolly" <
> > > stephen.alan.connolly@gmail.com>
> > > a écrit :
> > >
> > > > This is generally a tad tricky.
> > > >
> > > > 1. Because of class unloading it may not be possible to use the
> > Hack-type
> > > > solution of stashing the data in a Class level static field. Though
> > that
> > > > solution will work as long as the field uses a collection type that
> > > allows
> > > > for GC when the MavenProject that it is caching a value for has been
> > > > collected by GC (think of the users of Maven Embedder who's Maven
> > process
> > > > may be long lived and reused multiple times)
> > > >
> > > > 2. Easiest way may just be to serialize the value into a string form
> > and
> > > > set a project property with a non-maven resolvable name to the string
> > > > value. For example I do not think it is possible to have a Maven
> > property
> > > > start with the null character.
> > > >
> > > > You code will need to be defensive, and if the property (or cache
> value
> > > if
> > > > you go route 1) is missing it will have to calculate the value from
> > > scratch
> > > >
> > > >
> > > > On 24 July 2013 12:57, Francesco Mari <ma...@gmail.com>
> > wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I wrote some MOJOs which use common data. This data depends on the
> > > > > structure of the project and can't be changed at runtime.
> > > > >
> > > > > I would like to compute this information at the beginiing of the
> > build
> > > > > process, and re-use it in each related goal. Ideally, the first
> goal
> > > > should
> > > > > compute the data, and the following ones will just use it.
> > > > >
> > > > > Which is the best option? Are there any plugins already
> implementing
> > > > such a
> > > > > strategy, so I can take a look at their source code?
> > > > >
> > > >
> > >
> >
>
Re: Passing information between goals
Posted by Francesco Mari <ma...@gmail.com>.
Thank you for the link, but I don't need to coordinate multiple projects in
the same session. My use case is only focused on one project.
What about serializing the information somewhere in the
${project.build.directory} folder?
Are there any issues I should aware of if I implement this solution?
2013/7/24 Stephen Connolly <st...@gmail.com>
> Ahh yes... that's the one... I spent 3-5 min searching for it.
>
> getPluginContext() is the map you want (unless you want to span modules...
> even then I think you can cheat slightly by doing some funky stuff)
>
>
> On 24 July 2013 14:20, Baptiste MATHUS <ml...@batmat.net> wrote:
>
> > Hi,
> >
> > I remember doing that for build-helper. It was for many executions of the
> > same mojo though, not sure how it behaves with different mojos.
> > See
> >
> >
> http://mojo.10943.n7.nabble.com/build-helper-m-p-thread-safety-issue-td39561.htmland
> > the ReserveListenerPortMojo
> >
> > My 2 cents.
> >
> > Cheers
> > Le 24 juil. 2013 14:17, "Stephen Connolly" <
> > stephen.alan.connolly@gmail.com>
> > a écrit :
> >
> > > This is generally a tad tricky.
> > >
> > > 1. Because of class unloading it may not be possible to use the
> Hack-type
> > > solution of stashing the data in a Class level static field. Though
> that
> > > solution will work as long as the field uses a collection type that
> > allows
> > > for GC when the MavenProject that it is caching a value for has been
> > > collected by GC (think of the users of Maven Embedder who's Maven
> process
> > > may be long lived and reused multiple times)
> > >
> > > 2. Easiest way may just be to serialize the value into a string form
> and
> > > set a project property with a non-maven resolvable name to the string
> > > value. For example I do not think it is possible to have a Maven
> property
> > > start with the null character.
> > >
> > > You code will need to be defensive, and if the property (or cache value
> > if
> > > you go route 1) is missing it will have to calculate the value from
> > scratch
> > >
> > >
> > > On 24 July 2013 12:57, Francesco Mari <ma...@gmail.com>
> wrote:
> > >
> > > > Hi,
> > > >
> > > > I wrote some MOJOs which use common data. This data depends on the
> > > > structure of the project and can't be changed at runtime.
> > > >
> > > > I would like to compute this information at the beginiing of the
> build
> > > > process, and re-use it in each related goal. Ideally, the first goal
> > > should
> > > > compute the data, and the following ones will just use it.
> > > >
> > > > Which is the best option? Are there any plugins already implementing
> > > such a
> > > > strategy, so I can take a look at their source code?
> > > >
> > >
> >
>
Re: Passing information between goals
Posted by Stephen Connolly <st...@gmail.com>.
Ahh yes... that's the one... I spent 3-5 min searching for it.
getPluginContext() is the map you want (unless you want to span modules...
even then I think you can cheat slightly by doing some funky stuff)
On 24 July 2013 14:20, Baptiste MATHUS <ml...@batmat.net> wrote:
> Hi,
>
> I remember doing that for build-helper. It was for many executions of the
> same mojo though, not sure how it behaves with different mojos.
> See
>
> http://mojo.10943.n7.nabble.com/build-helper-m-p-thread-safety-issue-td39561.htmland
> the ReserveListenerPortMojo
>
> My 2 cents.
>
> Cheers
> Le 24 juil. 2013 14:17, "Stephen Connolly" <
> stephen.alan.connolly@gmail.com>
> a écrit :
>
> > This is generally a tad tricky.
> >
> > 1. Because of class unloading it may not be possible to use the Hack-type
> > solution of stashing the data in a Class level static field. Though that
> > solution will work as long as the field uses a collection type that
> allows
> > for GC when the MavenProject that it is caching a value for has been
> > collected by GC (think of the users of Maven Embedder who's Maven process
> > may be long lived and reused multiple times)
> >
> > 2. Easiest way may just be to serialize the value into a string form and
> > set a project property with a non-maven resolvable name to the string
> > value. For example I do not think it is possible to have a Maven property
> > start with the null character.
> >
> > You code will need to be defensive, and if the property (or cache value
> if
> > you go route 1) is missing it will have to calculate the value from
> scratch
> >
> >
> > On 24 July 2013 12:57, Francesco Mari <ma...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I wrote some MOJOs which use common data. This data depends on the
> > > structure of the project and can't be changed at runtime.
> > >
> > > I would like to compute this information at the beginiing of the build
> > > process, and re-use it in each related goal. Ideally, the first goal
> > should
> > > compute the data, and the following ones will just use it.
> > >
> > > Which is the best option? Are there any plugins already implementing
> > such a
> > > strategy, so I can take a look at their source code?
> > >
> >
>
Re: Passing information between goals
Posted by Baptiste MATHUS <ml...@batmat.net>.
Hi,
I remember doing that for build-helper. It was for many executions of the
same mojo though, not sure how it behaves with different mojos.
See
http://mojo.10943.n7.nabble.com/build-helper-m-p-thread-safety-issue-td39561.htmland
the ReserveListenerPortMojo
My 2 cents.
Cheers
Le 24 juil. 2013 14:17, "Stephen Connolly" <st...@gmail.com>
a écrit :
> This is generally a tad tricky.
>
> 1. Because of class unloading it may not be possible to use the Hack-type
> solution of stashing the data in a Class level static field. Though that
> solution will work as long as the field uses a collection type that allows
> for GC when the MavenProject that it is caching a value for has been
> collected by GC (think of the users of Maven Embedder who's Maven process
> may be long lived and reused multiple times)
>
> 2. Easiest way may just be to serialize the value into a string form and
> set a project property with a non-maven resolvable name to the string
> value. For example I do not think it is possible to have a Maven property
> start with the null character.
>
> You code will need to be defensive, and if the property (or cache value if
> you go route 1) is missing it will have to calculate the value from scratch
>
>
> On 24 July 2013 12:57, Francesco Mari <ma...@gmail.com> wrote:
>
> > Hi,
> >
> > I wrote some MOJOs which use common data. This data depends on the
> > structure of the project and can't be changed at runtime.
> >
> > I would like to compute this information at the beginiing of the build
> > process, and re-use it in each related goal. Ideally, the first goal
> should
> > compute the data, and the following ones will just use it.
> >
> > Which is the best option? Are there any plugins already implementing
> such a
> > strategy, so I can take a look at their source code?
> >
>
Re: Passing information between goals
Posted by Stephen Connolly <st...@gmail.com>.
This is generally a tad tricky.
1. Because of class unloading it may not be possible to use the Hack-type
solution of stashing the data in a Class level static field. Though that
solution will work as long as the field uses a collection type that allows
for GC when the MavenProject that it is caching a value for has been
collected by GC (think of the users of Maven Embedder who's Maven process
may be long lived and reused multiple times)
2. Easiest way may just be to serialize the value into a string form and
set a project property with a non-maven resolvable name to the string
value. For example I do not think it is possible to have a Maven property
start with the null character.
You code will need to be defensive, and if the property (or cache value if
you go route 1) is missing it will have to calculate the value from scratch
On 24 July 2013 12:57, Francesco Mari <ma...@gmail.com> wrote:
> Hi,
>
> I wrote some MOJOs which use common data. This data depends on the
> structure of the project and can't be changed at runtime.
>
> I would like to compute this information at the beginiing of the build
> process, and re-use it in each related goal. Ideally, the first goal should
> compute the data, and the following ones will just use it.
>
> Which is the best option? Are there any plugins already implementing such a
> strategy, so I can take a look at their source code?
>