Re: [mojo-dev] [DISCUSS] Codehaus EOL and MOJO migration

[Hervé BOUTEMY]

ok, we have a clear winner: MojoHaus
(and we'll have a statement like "formerly known as Codehaus Mojo project" on 
our website once migrated)


I created the github organization: https://github.com/MojoHaus

what are the next steps?

Regards,

Hervé

Le mercredi 11 mars 2015 08:54:09 Hervé BOUTEMY a écrit :
> then we have a few proposals:
> - Mojo Extras
> - MojoHaus
> - The Mojo Project
> 
> 
> I really like MojoHaus
> 
> Regards,
> 
> Hervé
> 
> Le mardi 10 mars 2015 09:28:59 vous avez écrit :
> > I think it's a bad idea to not include the "Mojo" name in some form. The
> > project has been around for over 10 years now and it widely known and used
> > in the Maven community.
> > 
> > I think Mojo Extras is a good name, I would like to propose "The Mojo
> > Project".
> > 
> > > ok, another idea: Mojo Extras (I just reserved the github org)
> > > 
> > > = Mojo (ie plugins for Maven) that can't be hosted at ASF for license
> > > issues, or generally less strict rules about anything (which comes at a
> > > price: this is not a foundation, no dev protection, or anything the
> > > rules
> > > are done for)
> > > 
> > > 
> > > I'm not trying anything to replace Codehaus name itself, because
> > > Codehaus
> > > is really wide
> > > 
> > > Regards,
> > > 
> > > Hervé
> > > 
> > > Le jeudi 5 mars 2015 15:51:03 vous avez écrit :
> > > > Hello Hervé,
> > > > 
> > > > I would suggest that "mojo" is quite unknown for most developers (who
> > > > are
> > > > non-maven-plugin developers) out there.
> > > > Few would even contemplate calling the plugins by their full - or even
> > > > abbreviated - name.
> > > > Whenever I hear people talking about a plugin, they simply say "the
> > > > aspectj
> > > > plugin" or equivalent.
> > > > Not "the aspectj-maven-plugin" - and definitely not "Mojo's
> > > > aspectj-maven-plugin".
> > > > 
> > > > Hence, I don't think that the Mojo "brand" is well-known at all
> > > > (actually,
> > > > it is more confusing since it can be mixed up with the name of the
> > > > Mojo
> > > > interface and AbstractMojo implementation).
> > > > I don't even believe that the "Codehaus" brand is well-known to the
> > > > genereal development community.
> > > > If anything, the names of the plugins themselves *could* be known.
> > > > 
> > > > So ... if we are going to refactor the Codehaus codebase and
> > > > organisation,
> > > > let's do it to best match the future demands.
> > > > 
> > > > I would also suggest being *very* clear about presenting the reason
> > > > that
> > > > the Codehaus/Mojo project develops Maven plugins instead of the
> > > > projects
> > > > themselves.
> > > > For example - it would seem apparent that the AspectJ project should
> > > > develop an aspectj-maven-plugin.
> > > > However, that plugin is developed by Codehaus, and I believe that we
> > > > should
> > > > be a bit clearer in documenting why.
> > > > 
> > > > Fair?
> > > > 
> > > > 2015-03-05 9:24 GMT+01:00 Hervé BOUTEMY :
> > > > > Le mercredi 4 mars 2015 14:16:08 vous avez écrit :
> > > > > > *Project name*
> > > > > > May not be a concern, but that needs to be cleared out sooner than
> > > > > > later.
> > > > > > I think that one of the most pressing subject may indeed not be
> > > > > > technical
> > > > > > but about the name of our project: what name should/could we use
> > > > > > for
> > > > > > the
> > > > > > project.
> > > > > > 
> > > > > > Should/could it stay "'Codehaus Mojo" on GitHub even after
> > > > > > Codehaus
> > > > > > EOL
> > > > > > (meaning we'd certainly use https://github.com/codehaus-mojo org)?
> > > > > > or
> > > > > > "Maven Mojo" (which would make googling for it quite difficult
> > > > > > btw)?
> > > > > > Or
> > > > > > change the project name even more?
> > > > > 
> > > > > -1 to "Maven Mojo": trademark concern on Maven (Apache Maven, to be
> > > > > precise)
> > > > > could be "Mojo for Maven"
> > > > > 
> > > > > why not just "Mojo" as the project name?
> > > > > AFAIK, it has become a well known name lately: is there really a
> > > > > need
> > > > > for
> > > > > "XXX
> > > > > Mojo", whatever XXX is?
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > Hervé
> > > > > 
> > > > > 
> > > > > -
> > > > > 
> > > > > To unsubscribe from this list, please visit:
> > > > > http://xircles.codehaus.org/manage_email
> > > 
> > > -
> > > 
> > > To unsubscribe from this list, please visit:
> > > http://xircles.codehaus.org/manage_email
> > 
> > -
> > 
> > To unsubscribe from this list, please visit:
> > http://xircles.codehaus.org/manage_email
> 
> -
> To unsubscribe from this list, please visit:
> 
> http://xircles.codehaus.org/manage_email


---

Re: [mojo-dev] [DISCUSS] Codehaus EOL and MOJO migration

[Karl Heinz Marbaise]

Hi Hervé,

On 3/14/15 1:43 PM, Hervé BOUTEMY wrote:

ok, we have a clear winner: MojoHaus
(and we'll have a statement like "formerly known as Codehaus Mojo project" on
our website once migrated)





I created the github organization: https://github.com/MojoHaus

what are the next steps?


Migration of the plugins to git repos...?


BTW: Could you please add me to the organization...

Kind regards
Karl Heinz Marbaise



Regards,

Hervé

Le mercredi 11 mars 2015 08:54:09 Hervé BOUTEMY a écrit :

then we have a few proposals:
- Mojo Extras
- MojoHaus
- The Mojo Project


I really like MojoHaus

Regards,

Hervé

Le mardi 10 mars 2015 09:28:59 vous avez écrit :

I think it's a bad idea to not include the "Mojo" name in some form. The
project has been around for over 10 years now and it widely known and used
in the Maven community.

I think Mojo Extras is a good name, I would like to propose "The Mojo
Project".


ok, another idea: Mojo Extras (I just reserved the github org)

= Mojo (ie plugins for Maven) that can't be hosted at ASF for license
issues, or generally less strict rules about anything (which comes at a
price: this is not a foundation, no dev protection, or anything the
rules
are done for)


I'm not trying anything to replace Codehaus name itself, because
Codehaus
is really wide

Regards,

Hervé

Le jeudi 5 mars 2015 15:51:03 vous avez écrit :

Hello Hervé,

I would suggest that "mojo" is quite unknown for most developers (who
are
non-maven-plugin developers) out there.
Few would even contemplate calling the plugins by their full - or even
abbreviated - name.
Whenever I hear people talking about a plugin, they simply say "the
aspectj
plugin" or equivalent.
Not "the aspectj-maven-plugin" - and definitely not "Mojo's
aspectj-maven-plugin".

Hence, I don't think that the Mojo "brand" is well-known at all
(actually,
it is more confusing since it can be mixed up with the name of the
Mojo
interface and AbstractMojo implementation).
I don't even believe that the "Codehaus" brand is well-known to the
genereal development community.
If anything, the names of the plugins themselves *could* be known.

So ... if we are going to refactor the Codehaus codebase and
organisation,
let's do it to best match the future demands.

I would also suggest being *very* clear about presenting the reason
that
the Codehaus/Mojo project develops Maven plugins instead of the
projects
themselves.
For example - it would seem apparent that the AspectJ project should
develop an aspectj-maven-plugin.
However, that plugin is developed by Codehaus, and I believe that we
should
be a bit clearer in documenting why.

Fair?

2015-03-05 9:24 GMT+01:00 Hervé BOUTEMY :

Le mercredi 4 mars 2015 14:16:08 vous avez écrit :

*Project name*
May not be a concern, but that needs to be cleared out sooner than
later.
I think that one of the most pressing subject may indeed not be
technical
but about the name of our project: what name should/could we use
for
the
project.

Should/could it stay "'Codehaus Mojo" on GitHub even after
Codehaus
EOL
(meaning we'd certainly use https://github.com/codehaus-mojo org)?
or
"Maven Mojo" (which would make googling for it quite difficult
btw)?
Or
change the project name even more?


-1 to "Maven Mojo": trademark concern on Maven (Apache Maven, to be
precise)
could be "Mojo for Maven"

why not just "Mojo" as the project name?
AFAIK, it has become a well known name lately: is there really a
need
for
"XXX
Mojo", whatever XXX is?

Regards,

Hervé



-
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email

Re: [mojo-dev] [DISCUSS] Codehaus EOL and MOJO migration

[Tony Chemit]

On Sat, 14 Mar 2015 14:11:47 +0100
Karl Heinz Marbaise  wrote:

> BTW: Could you please add me to the organization...

Hy herve, Can you also add me in organization. (tchemit on github)

thanks,

tony.

-- 
Tony Chemit

tél: +33 (0) 2 40 50 29 28
http://www.codelutin.com
email: che...@codelutin.com
twitter: https://twitter.com/tchemit

-
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Re[2]: [mojo-dev] [DISCUSS] Codehaus EOL and MOJO migration

[Sergei Ivanov]

 That name must have been my largest contribution to the cause so far :)
--
Sergei
>
>Saturday, 14 March 2015 12:43 + from Hervé BOUTEMY  
>:
>ok, we have a clear winner: MojoHaus
>(and we'll have a statement like "formerly known as Codehaus Mojo project" on
>our website once migrated)
>I created the github organization:  https://github.com/MojoHaus
>what are the next steps?
>Regards,
>Hervé
>Le mercredi 11 mars 2015 08:54:09 Hervé BOUTEMY a écrit :
>> then we have a few proposals:
>> - Mojo Extras
>> - MojoHaus
>> - The Mojo Project
>>
>>
>> I really like MojoHaus
>>
>> Regards,
>>
>> Hervé
>>
>> Le mardi 10 mars 2015 09:28:59 vous avez écrit :
>> > I think it's a bad idea to not include the "Mojo" name in some form. The
>> > project has been around for over 10 years now and it widely known and used
>> > in the Maven community.
>> >
>> > I think Mojo Extras is a good name, I would like to propose "The Mojo
>> > Project".
>> >
>> > > ok, another idea: Mojo Extras (I just reserved the github org)
>> > >
>> > > = Mojo (ie plugins for Maven) that can't be hosted at ASF for license
>> > > issues, or generally less strict rules about anything (which comes at a
>> > > price: this is not a foundation, no dev protection, or anything the
>> > > rules
>> > > are done for)
>> > >
>> > >
>> > > I'm not trying anything to replace Codehaus name itself, because
>> > > Codehaus
>> > > is really wide
>> > >
>> > > Regards,
>> > >
>> > > Hervé
>> > >
>> > > Le jeudi 5 mars 2015 15:51:03 vous avez écrit :
>> > > > Hello Hervé,
>> > > >
>> > > > I would suggest that "mojo" is quite unknown for most developers (who
>> > > > are
>> > > > non-maven-plugin developers) out there.
>> > > > Few would even contemplate calling the plugins by their full - or even
>> > > > abbreviated - name.
>> > > > Whenever I hear people talking about a plugin, they simply say "the
>> > > > aspectj
>> > > > plugin" or equivalent.
>> > > > Not "the aspectj-maven-plugin" - and definitely not "Mojo's
>> > > > aspectj-maven-plugin".
>> > > >
>> > > > Hence, I don't think that the Mojo "brand" is well-known at all
>> > > > (actually,
>> > > > it is more confusing since it can be mixed up with the name of the
>> > > > Mojo
>> > > > interface and AbstractMojo implementation).
>> > > > I don't even believe that the "Codehaus" brand is well-known to the
>> > > > genereal development community.
>> > > > If anything, the names of the plugins themselves *could* be known.
>> > > >
>> > > > So ... if we are going to refactor the Codehaus codebase and
>> > > > organisation,
>> > > > let's do it to best match the future demands.
>> > > >
>> > > > I would also suggest being *very* clear about presenting the reason
>> > > > that
>> > > > the Codehaus/Mojo project develops Maven plugins instead of the
>> > > > projects
>> > > > themselves.
>> > > > For example - it would seem apparent that the AspectJ project should
>> > > > develop an aspectj-maven-plugin.
>> > > > However, that plugin is developed by Codehaus, and I believe that we
>> > > > should
>> > > > be a bit clearer in documenting why.
>> > > >
>> > > > Fair?
>> > > >
>> > > > 2015-03-05 9:24 GMT+01:00 Hervé BOUTEMY < herve.bout...@free.fr >:
>> > > > > Le mercredi 4 mars 2015 14:16:08 vous avez écrit :
>> > > > > > *Project name*
>> > > > > > May not be a concern, but that needs to be cleared out sooner than
>> > > > > > later.
>> > > > > > I think that one of the most pressing subject may indeed not be
>> > > > > > technical
>> > > > > > but about the name of our project: what name should/could we use
>> > > > > > for
>> > > > > > the
>> > > > > > project.
>> > > > > >
>> > > > > > Should/could it stay "'Codehaus Mojo" on GitHub even after
>> > > > > > Codehaus
>> > > > > > EOL
>> > > > > > (meaning we'd certainly use  https://github.com/codehaus-mojo org)?
>> > > > > > or
>> > > > > > "Maven Mojo" (which would make googling for it quite difficult
>> > > > > > btw)?
>> > > > > > Or
>> > > > > > change the project name even more?
>> > > > >
>> > > > > -1 to "Maven Mojo": trademark concern on Maven (Apache Maven, to be
>> > > > > precise)
>> > > > > could be "Mojo for Maven"
>> > > > >
>> > > > > why not just "Mojo" as the project name?
>> > > > > AFAIK, it has become a well known name lately: is there really a
>> > > > > need
>> > > > > for
>> > > > > "XXX
>> > > > > Mojo", whatever XXX is?
>> > > > >
>> > > > > Regards,
>> > > > >
>> > > > > Hervé
>> > > > >
>> > > > > 
>> > > > > -
>> > > > >
>> > > > > To unsubscribe from this list, please visit:
>> > > > >  http://xircles.codehaus.org/manage_email
>> > >
>> > > -
>> > >
>> > > To unsubscribe from this list, please visit:
>> > >  http://xircles.codehaus.org/manage_email
>> >
>> > -
>> >
>> > To unsubscribe from this list, please visit:
>> >  http://xir

Re: [mojo-dev] [DISCUSS] Codehaus EOL and MOJO migration

[Baptiste Mathus]

+1 please (http://github.com/batmat).
And just in case: I bought http://mojohaus.org

Adding Codehaus support in CC:

@CodeHaus Support:
As for migration, how do we proceed? We've got a pretty big svn tree to
split in a myriad of small ones. How should we do that?
I mean, I know what to do technically, but should we do that by ourself, or
wait for some mirror to arrive on http://github.com/codehaus [1] and clone
that one before doing a bunch of filter-branch?

Thanks

[1] As stated in the blog at https://codehaus.org/ butt maybe it was only
meant for projects already using Git?




2015-03-14 14:30 GMT+01:00 Tony Chemit :

> On Sat, 14 Mar 2015 14:11:47 +0100
> Karl Heinz Marbaise  wrote:
>
> > BTW: Could you please add me to the organization...
>
> Hy herve, Can you also add me in organization. (tchemit on github)
>
> thanks,
>
> tony.
>
> --
> Tony Chemit
> 
> tél: +33 (0) 2 40 50 29 28
> http://www.codelutin.com
> email: che...@codelutin.com
> twitter: https://twitter.com/tchemit
>
> -
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>


-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: [mojo-dev] [DISCUSS] Codehaus EOL and MOJO migration

[Baptiste Mathus]

... This time actually supp...@codehaus.org in CC.

2015-03-14 14:52 GMT+01:00 Baptiste Mathus :

> +1 please (http://github.com/batmat).
> And just in case: I bought http://mojohaus.org
>
> Adding Codehaus support in CC:
>
> @CodeHaus Support:
> As for migration, how do we proceed? We've got a pretty big svn tree to
> split in a myriad of small ones. How should we do that?
> I mean, I know what to do technically, but should we do that by ourself,
> or wait for some mirror to arrive on http://github.com/codehaus [1] and
> clone that one before doing a bunch of filter-branch?
>
> Thanks
>
> [1] As stated in the blog at https://codehaus.org/ butt maybe it was only
> meant for projects already using Git?
>
>
>
>
> 2015-03-14 14:30 GMT+01:00 Tony Chemit :
>
>> On Sat, 14 Mar 2015 14:11:47 +0100
>> Karl Heinz Marbaise  wrote:
>>
>> > BTW: Could you please add me to the organization...
>>
>> Hy herve, Can you also add me in organization. (tchemit on github)
>>
>> thanks,
>>
>> tony.
>>
>> --
>> Tony Chemit
>> 
>> tél: +33 (0) 2 40 50 29 28
>> http://www.codelutin.com
>> email: che...@codelutin.com
>> twitter: https://twitter.com/tchemit
>>
>> -
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor !
>



-- 
Baptiste  MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: [mojo-dev] [DISCUSS] Codehaus EOL and MOJO migration

[Lennart Jörelid]

Hello Hervé,

All right; move to the next MojoHaus incarnation.
Would you please add me as well (https://github.com/lennartj)

2015-03-14 13:43 GMT+01:00 Hervé BOUTEMY :

> ok, we have a clear winner: MojoHaus
> (and we'll have a statement like "formerly known as Codehaus Mojo project"
> on
> our website once migrated)
>
>
> I created the github organization: https://github.com/MojoHaus
>
> what are the next steps?
>
> Regards,
>
> Hervé
>
> Le mercredi 11 mars 2015 08:54:09 Hervé BOUTEMY a écrit :
> > then we have a few proposals:
> > - Mojo Extras
> > - MojoHaus
> > - The Mojo Project
> >
> >
> > I really like MojoHaus
> >
> > Regards,
> >
> > Hervé
> >
> > Le mardi 10 mars 2015 09:28:59 vous avez écrit :
> > > I think it's a bad idea to not include the "Mojo" name in some form.
> The
> > > project has been around for over 10 years now and it widely known and
> used
> > > in the Maven community.
> > >
> > > I think Mojo Extras is a good name, I would like to propose "The Mojo
> > > Project".
> > >
> > > > ok, another idea: Mojo Extras (I just reserved the github org)
> > > >
> > > > = Mojo (ie plugins for Maven) that can't be hosted at ASF for license
> > > > issues, or generally less strict rules about anything (which comes
> at a
> > > > price: this is not a foundation, no dev protection, or anything the
> > > > rules
> > > > are done for)
> > > >
> > > >
> > > > I'm not trying anything to replace Codehaus name itself, because
> > > > Codehaus
> > > > is really wide
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > Le jeudi 5 mars 2015 15:51:03 vous avez écrit :
> > > > > Hello Hervé,
> > > > >
> > > > > I would suggest that "mojo" is quite unknown for most developers
> (who
> > > > > are
> > > > > non-maven-plugin developers) out there.
> > > > > Few would even contemplate calling the plugins by their full - or
> even
> > > > > abbreviated - name.
> > > > > Whenever I hear people talking about a plugin, they simply say "the
> > > > > aspectj
> > > > > plugin" or equivalent.
> > > > > Not "the aspectj-maven-plugin" - and definitely not "Mojo's
> > > > > aspectj-maven-plugin".
> > > > >
> > > > > Hence, I don't think that the Mojo "brand" is well-known at all
> > > > > (actually,
> > > > > it is more confusing since it can be mixed up with the name of the
> > > > > Mojo
> > > > > interface and AbstractMojo implementation).
> > > > > I don't even believe that the "Codehaus" brand is well-known to the
> > > > > genereal development community.
> > > > > If anything, the names of the plugins themselves *could* be known.
> > > > >
> > > > > So ... if we are going to refactor the Codehaus codebase and
> > > > > organisation,
> > > > > let's do it to best match the future demands.
> > > > >
> > > > > I would also suggest being *very* clear about presenting the reason
> > > > > that
> > > > > the Codehaus/Mojo project develops Maven plugins instead of the
> > > > > projects
> > > > > themselves.
> > > > > For example - it would seem apparent that the AspectJ project
> should
> > > > > develop an aspectj-maven-plugin.
> > > > > However, that plugin is developed by Codehaus, and I believe that
> we
> > > > > should
> > > > > be a bit clearer in documenting why.
> > > > >
> > > > > Fair?
> > > > >
> > > > > 2015-03-05 9:24 GMT+01:00 Hervé BOUTEMY :
> > > > > > Le mercredi 4 mars 2015 14:16:08 vous avez écrit :
> > > > > > > *Project name*
> > > > > > > May not be a concern, but that needs to be cleared out sooner
> than
> > > > > > > later.
> > > > > > > I think that one of the most pressing subject may indeed not be
> > > > > > > technical
> > > > > > > but about the name of our project: what name should/could we
> use
> > > > > > > for
> > > > > > > the
> > > > > > > project.
> > > > > > >
> > > > > > > Should/could it stay "'Codehaus Mojo" on GitHub even after
> > > > > > > Codehaus
> > > > > > > EOL
> > > > > > > (meaning we'd certainly use https://github.com/codehaus-mojo
> org)?
> > > > > > > or
> > > > > > > "Maven Mojo" (which would make googling for it quite difficult
> > > > > > > btw)?
> > > > > > > Or
> > > > > > > change the project name even more?
> > > > > >
> > > > > > -1 to "Maven Mojo": trademark concern on Maven (Apache Maven, to
> be
> > > > > > precise)
> > > > > > could be "Mojo for Maven"
> > > > > >
> > > > > > why not just "Mojo" as the project name?
> > > > > > AFAIK, it has become a well known name lately: is there really a
> > > > > > need
> > > > > > for
> > > > > > "XXX
> > > > > > Mojo", whatever XXX is?
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Hervé
> > > > > >
> > > > > >
> 
> > > > > > -
> > > > > >
> > > > > > To unsubscribe from this list, please visit:
> > > > > > http://xircles.codehaus.org/manage_email
> > > >
> > > > -
> > > >
> > > > To unsubscribe from this list, please visit:
> > > > http://xircles.cod

[mojo-dev] NPE in Versions Maven Plugin on display-plugin-updates goal

[Michał Kordas]

Hi,

I've found bug in Versions Maven Plugin.

Problematic part of pom:


  org.apache.maven.plugins
  maven-jar-plugin
  2.6
  

  
${project.build.sourceDirectory}/META-INF/MANIFEST.MF

  


NPE is caused by line:

${project.build.sourceDirectory}/META-INF/MANIFEST.MF

When I remove ${project.build.sourceDirectory} and leave only
/META-INF/MANIFEST.MF then NPE goes away.

Full POM available at
https://github.com/jboss-javassist/javassist/blob/1fd31f137c3995d29a5be698c9919b6f764ba882/pom.xml

Stacktrace:

[ERROR] Failed to execute goal
org.codehaus.mojo:versions-maven-plugin:2.1:display-plugin-updates
(default-cli) on project javassist: Execution default-cli of goal
org.codehaus.mojo:versions-maven-plugin:2.1:display-plugin-updates failed.
NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.codehaus.mojo:versions-maven-plugin:2.1:display-plugin-updates
(default-cli) on project javassist: Execution default-cli of goal
org.codehaus.mojo:versions-maven-plugin:2.1:display-plugin-updates failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-cli of goal
org.codehaus.mojo:versions-maven-plugin:2.1:display-plugin-updates failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 25 more
Caused by: java.lang.NullPointerException
at
org.apache.maven.project.interpolation.PathTranslatingPostProcessor.execute(PathTranslatingPostProcessor.java:58)
at
org.codehaus.plexus.interpolation.StringSearchInterpolator.interpolate(StringSearchInterpolator.java:223)
at
org.codehaus.plexus.interpolation.StringSearchInterpolator.interpolate(StringSearchInterpolator.java:124)
at
org.apache.maven.project.interpolation.AbstractStringBasedModelInterpolator.interpolateInternal(AbstractStringBasedModelInterpolator.java:316)
at
org.apache.maven.project.interpolation.StringSearchModelInterpolator$InterpolateObjectAction.traverseObjectWithParents(StringSearchModelInterpolator.java:187)
at
org.apache.maven.project.interpolation.StringSearchModelInterpolator$InterpolateObjectAction.run(StringSearchModelInterpolator.java:137)
at
org.apache.maven.project.interpolation.StringSearchModelInterpolator$InterpolateObjectAction.run(StringSearchModelInterpolator.java:104)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.maven.project.interpolation.StringSearchModelInterpolator.interpolateObject(StringSearchModelInterpolator.java:83)
at
org.apache.maven.project.interpolation.StringSearchModelInterpolator.interpolate(StringSearchModelInterpolator.java:65)
at
org.codehaus.mojo.versions.DisplayPluginUpdatesMojo.getProjectPlugins(DisplayPluginUpdatesMojo.java:1557)
at
org.codehaus.mojo.versions.DisplayPluginUpdatesMojo.execute(DisplayPluginUpdatesMojo.java:469)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(Defaul

Re: [mojo-dev] NPE in Versions Maven Plugin on display-plugin-updates goal

[Karl Heinz Marbaise]

Hi Michał,

could you please so kind to open an jira issue for versions-maven-plugin?

Thanks in advance.


On 3/14/15 6:23 PM, Michał Kordas wrote:

Hi,

I've found bug in Versions Maven Plugin.

Problematic part of pom:


   org.apache.maven.plugins
   maven-jar-plugin
   2.6
   
 
   
${project.build.sourceDirectory}/META-INF/MANIFEST.MF
 
   


NPE is caused by line:

${project.build.sourceDirectory}/META-INF/MANIFEST.MF

When I remove${project.build.sourceDirectory}and leave 
only/META-INF/MANIFEST.MF  then NPE goes away.

Full POM available 
athttps://github.com/jboss-javassist/javassist/blob/1fd31f137c3995d29a5be698c9919b6f764ba882/pom.xml

Stacktrace:

[ERROR] Failed to execute goal
org.codehaus.mojo:versions-maven-plugin:2.1:display-plugin-updates
(default-cli) on project javassist: Execution default-cli of goal
org.codehaus.mojo:versions-maven-plugin:2.1:display-plugin-updates
failed. NullPointerException -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal
org.codehaus.mojo:versions-maven-plugin:2.1:display-plugin-updates
(default-cli) on project javassist: Execution default-cli of goal
org.codehaus.mojo:versions-maven-plugin:2.1:display-plugin-updates failed.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:225)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
default-cli of goal
org.codehaus.mojo:versions-maven-plugin:2.1:display-plugin-updates failed.
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:110)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 25 more
Caused by: java.lang.NullPointerException
at
org.apache.maven.project.interpolation.PathTranslatingPostProcessor.execute(PathTranslatingPostProcessor.java:58)
at
org.codehaus.plexus.interpolation.StringSearchInterpolator.interpolate(StringSearchInterpolator.java:223)
at
org.codehaus.plexus.interpolation.StringSearchInterpolator.interpolate(StringSearchInterpolator.java:124)
at
org.apache.maven.project.interpolation.AbstractStringBasedModelInterpolator.interpolateInternal(AbstractStringBasedModelInterpolator.java:316)
at
org.apache.maven.project.interpolation.StringSearchModelInterpolator$InterpolateObjectAction.traverseObjectWithParents(StringSearchModelInterpolator.java:187)
at
org.apache.maven.project.interpolation.StringSearchModelInterpolator$InterpolateObjectAction.run(StringSearchModelInterpolator.java:137)
at
org.apache.maven.project.interpolation.StringSearchModelInterpolator$InterpolateObjectAction.run(StringSearchModelInterpolator.java:104)
at java.security.AccessController.doPrivileged(Native Method)
at
org.apache.maven.project.interpolation.StringSearchModelInterpolator.interpolateObject(StringSearchModelInterpolator.java:83)
at
org.apache.maven.project.interpolation.StringSearchModelInterpolator.interpolate(StringSearchModelInterpolator.java:65)
at
org.codehaus.mojo.versions.DisplayPluginUpdatesMojo.getProjectPlugins(DisplayPluginUpdatesMojo.java:1557)
at
org.code

Re: [mojo-dev] NPE in Versions Maven Plugin on display-plugin-updates goal

[Michał Kordas]

Hi Karl,

I wanted to submit Jira, but I don't have an account. On
https://jira.codehaus.org/login.jsp?os_destination=%2Fbrowse%2FMVERSIONS I
see:
*Not a member? To request an account, please contact your JIRA
administrators.*

Can you help me with that?

Thanks,
Michal

2015-03-14 18:32 GMT+01:00 Karl Heinz Marbaise :

> Hi Michał,
>
> could you please so kind to open an jira issue for versions-maven-plugin?
>
> Thanks in advance.
>
>
> On 3/14/15 6:23 PM, Michał Kordas wrote:
>
>> Hi,
>>
>> I've found bug in Versions Maven Plugin.
>>
>> Problematic part of pom:
>>
>> 
>>org.apache.maven.plugins
>>maven-jar-plugin
>>2.6
>>
>>  
>>${project.build.sourceDirectory}/META-INF/
>> MANIFEST.MF
>>  
>>
>> 
>>
>> NPE is caused by line:
>>
>> ${project.build.sourceDirectory}/META-INF/
>> MANIFEST.MF
>>
>> When I remove${project.build.sourceDirectory}and leave
>> only/META-INF/MANIFEST.MF  then NPE goes
>> away.
>>
>> Full POM available athttps://github.com/jboss-javassist/javassist/blob/
>> 1fd31f137c3995d29a5be698c9919b6f764ba882/pom.xml
>>
>>
>> Stacktrace:
>>
>> [ERROR] Failed to execute goal
>> org.codehaus.mojo:versions-maven-plugin:2.1:display-plugin-updates
>> (default-cli) on project javassist: Execution default-cli of goal
>> org.codehaus.mojo:versions-maven-plugin:2.1:display-plugin-updates
>> failed. NullPointerException -> [Help 1]
>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
>> execute goal
>> org.codehaus.mojo:versions-maven-plugin:2.1:display-plugin-updates
>> (default-cli) on project javassist: Execution default-cli of goal
>> org.codehaus.mojo:versions-maven-plugin:2.1:display-plugin-updates
>> failed.
>> at
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(
>> MojoExecutor.java:225)
>> at
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(
>> MojoExecutor.java:153)
>> at
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(
>> MojoExecutor.java:145)
>> at
>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
>> LifecycleModuleBuilder.java:84)
>> at
>> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(
>> LifecycleModuleBuilder.java:59)
>> at
>> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(
>> LifecycleStarter.java:183)
>> at
>> org.apache.maven.lifecycle.internal.LifecycleStarter.
>> execute(LifecycleStarter.java:161)
>> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
>> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
>> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
>> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
>> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(
>> NativeMethodAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(
>> DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:483)
>> at
>> org.codehaus.plexus.classworlds.launcher.Launcher.
>> launchEnhanced(Launcher.java:290)
>> at
>> org.codehaus.plexus.classworlds.launcher.Launcher.
>> launch(Launcher.java:230)
>> at
>> org.codehaus.plexus.classworlds.launcher.Launcher.
>> mainWithExitCode(Launcher.java:409)
>> at org.codehaus.plexus.classworlds.launcher.Launcher.
>> main(Launcher.java:352)
>> at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> at
>> sun.reflect.NativeMethodAccessorImpl.invoke(
>> NativeMethodAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(
>> DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:483)
>> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
>> Caused by: org.apache.maven.plugin.PluginExecutionException: Execution
>> default-cli of goal
>> org.codehaus.mojo:versions-maven-plugin:2.1:display-plugin-updates
>> failed.
>> at
>> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(
>> DefaultBuildPluginManager.java:110)
>> at
>> org.apache.maven.lifecycle.internal.MojoExecutor.execute(
>> MojoExecutor.java:209)
>> ... 25 more
>> Caused by: java.lang.NullPointerException
>> at
>> org.apache.maven.project.interpolation.PathTranslatingPostProcessor.
>> execute(PathTranslatingPostProcessor.java:58)
>> at
>> org.codehaus.plexus.interpolation.StringSearchInterpolator.interpolate(
>> StringSearchInterpolator.java:223)
>> at
>> org.codehaus.plexus.interpolation.StringSearchInterpolator.interpolate(
>> StringSearchInterpolator.java:124)
>> at
>> org.apache.maven.project.interpolation.AbstractStringBasedModelInterp
>> olator.interpolateInternal(AbstractStringBasedModelInterpolator.java:316)
>> at
>> org.apache.maven.project.interpolation.StringSearchModelInterpolator$
>> InterpolateObjectAction.traverseObjectWithParents(
>> StringSearchModelInterpol

Re: [mojo-dev] NPE in Versions Maven Plugin on display-plugin-updates goal

[Karl Heinz Marbaise]

Hi Michał,

just take a look here:

http://maven.apache.org/issue-tracking.html

Request an xcircle account...

Kind regards
Karl Heinz Marbaise
On 3/14/15 6:36 PM, Michał Kordas wrote:

Hi Karl,

I wanted to submit Jira, but I don't have an account. On
https://jira.codehaus.org/login.jsp?os_destination=%2Fbrowse%2FMVERSIONS
I see:
/Not a member? To request an account, please contact your JIRA
administrators./

Can you help me with that?

Thanks,
Michal

2015-03-14 18:32 GMT+01:00 Karl Heinz Marbaise mailto:khmarba...@gmx.de>>:

Hi Michał,

could you please so kind to open an jira issue for
versions-maven-plugin?

Thanks in advance.


On 3/14/15 6:23 PM, Michał Kordas wrote:

Hi,

I've found bug in Versions Maven Plugin.

Problematic part of pom:


org.apache.maven.__plugins
maven-jar-plugin
2.6

  

  
${project.build.__sourceDirectory}/META-INF/__MANIFEST.MF
  



NPE is caused by line:


${project.build.__sourceDirectory}/META-INF/__MANIFEST.MF

When I remove${project.build.__sourceDirectory}and leave
only/META-INF/__MANIFEST.MF  then
NPE goes away.

Full POM available

athttps://github.com/jboss-__javassist/javassist/blob/__1fd31f137c3995d29a5be698c9919b__6f764ba882/pom.xml




Stacktrace:

[ERROR] Failed to execute goal
org.codehaus.mojo:versions-__maven-plugin:2.1:display-__plugin-updates
(default-cli) on project javassist: Execution default-cli of goal
org.codehaus.mojo:versions-__maven-plugin:2.1:display-__plugin-updates
failed. NullPointerException -> [Help 1]
org.apache.maven.lifecycle.__LifecycleExecutionException: Failed to
execute goal
org.codehaus.mojo:versions-__maven-plugin:2.1:display-__plugin-updates
(default-cli) on project javassist: Execution default-cli of goal
org.codehaus.mojo:versions-__maven-plugin:2.1:display-__plugin-updates
failed.
at

org.apache.maven.lifecycle.__internal.MojoExecutor.execute(__MojoExecutor.java:225)
at

org.apache.maven.lifecycle.__internal.MojoExecutor.execute(__MojoExecutor.java:153)
at

org.apache.maven.lifecycle.__internal.MojoExecutor.execute(__MojoExecutor.java:145)
at

org.apache.maven.lifecycle.__internal.__LifecycleModuleBuilder.__buildProject(__LifecycleModuleBuilder.java:__84)
at

org.apache.maven.lifecycle.__internal.__LifecycleModuleBuilder.__buildProject(__LifecycleModuleBuilder.java:__59)
at

org.apache.maven.lifecycle.__internal.LifecycleStarter.__singleThreadedBuild(__LifecycleStarter.java:183)
at

org.apache.maven.lifecycle.__internal.LifecycleStarter.__execute(LifecycleStarter.java:__161)
at
org.apache.maven.DefaultMaven.__doExecute(DefaultMaven.java:__320)
at org.apache.maven.DefaultMaven.__execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.__execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.__doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.__main(MavenCli.java:141)
at sun.reflect.__NativeMethodAccessorImpl.__invoke0(Native Method)
at

sun.reflect.__NativeMethodAccessorImpl.__invoke(__NativeMethodAccessorImpl.java:__62)
at

sun.reflect.__DelegatingMethodAccessorImpl.__invoke(__DelegatingMethodAccessorImpl.__java:43)
at java.lang.reflect.Method.__invoke(Method.java:483)
at

org.codehaus.plexus.__classworlds.launcher.Launcher.__launchEnhanced(Launcher.java:__290)
at

org.codehaus.plexus.__classworlds.launcher.Launcher.__launch(Launcher.java:230)
at

org.codehaus.plexus.__classworlds.launcher.Launcher.__mainWithExitCode(Launcher.__java:409)
at

org.codehaus.plexus.__classworlds.launcher.Launcher.__main(Launcher.java:352)
at org.codehaus.classworlds.__Launcher.main(Launcher.java:__47)
at sun.reflect.__NativeMethodAccessorImpl.__invoke0(Native Method)
at

sun.reflect.__NativeMethodAccessorImpl.__invoke(__NativeMethodAccessorImpl.java:__62)
at

sun.reflect.__DelegatingMethodAccessorImpl.__invoke(__DelegatingMethodAccessorImpl.__java:43)
at java.lang.reflect.Method.__invoke(Method.java:483)
at
com.intellij.rt.execution.__application.AppMain.main(__AppMain.java:140)
Caused by: org.apache.maven.plugin.__PluginExecutionException:
Execution
default-cli of goal
org.codehaus.mojo:versions-__maven-plugin:2.1:display-__plugin-updates
failed.
at

org.apache.maven.plugin.__DefaultBuildPluginManager.__executeMojo(__DefaultB

[mojo-dev] [jira] (MVERSIONS-277) NPE when display-plugin-updates invoked

[Michal Kordas (JIRA)]

Title: Message Title










 

 Michal Kordas created an issue











 






 Mojo's Versions Maven Plugin /  MVERSIONS-277



  NPE when display-plugin-updates invoked 










Issue Type:

  Bug




Affects Versions:


 2.1




Assignee:


 Unassigned




Created:


 14/Mar/15 1:46 PM




Priority:

  Major




Reporter:

 Michal Kordas










Command used: mvn versions:display-plugin-updates
Problematic part of pom:




  org.apache.maven.plugins
  maven-jar-plugin
  2.6
  

  ${project.build.sourceDirectory}/META-INF/MANIFEST.MF

  




NPE is caused by line: 


${project.build.sourceDirectory}/META-INF/MANIFEST.MF


When I remove ${project.build.sourceDirectory} and leave only /META-INF/MANIFEST.MF then NPE goes away.
Full POM available at https://github.com/jboss-javassist/javassist/blob/1fd31f137c3995d29a5be698c9919b6f764ba882/pom.xml
Stacktrace:



[ERROR] Failed to execute goal org.codehaus.mojo:versions-maven-plugin:2.1:display-plugin-updates (default-cli) on project javassist: Executi

Re: [mojo-dev] NPE in Versions Maven Plugin on display-plugin-updates goal

[Michał Kordas]

Thanks! Now I have an account an I've submitted
http://jira.codehaus.org/browse/MVERSIONS-277

Regards,
Michal Kordas

2015-03-14 18:57 GMT+01:00 Karl Heinz Marbaise :

> Hi Michał,
>
> just take a look here:
>
> http://maven.apache.org/issue-tracking.html
>
> Request an xcircle account...
>
> Kind regards
> Karl Heinz Marbaise
> On 3/14/15 6:36 PM, Michał Kordas wrote:
>
>> Hi Karl,
>>
>> I wanted to submit Jira, but I don't have an account. On
>> https://jira.codehaus.org/login.jsp?os_destination=%2Fbrowse%2FMVERSIONS
>> I see:
>> /Not a member? To request an account, please contact your JIRA
>> administrators./
>>
>> Can you help me with that?
>>
>> Thanks,
>> Michal
>>
>> 2015-03-14 18:32 GMT+01:00 Karl Heinz Marbaise > >:
>>
>> Hi Michał,
>>
>> could you please so kind to open an jira issue for
>> versions-maven-plugin?
>>
>> Thanks in advance.
>>
>>
>> On 3/14/15 6:23 PM, Michał Kordas wrote:
>>
>> Hi,
>>
>> I've found bug in Versions Maven Plugin.
>>
>> Problematic part of pom:
>>
>> 
>> org.apache.maven.__plugins
>> maven-jar-plugin
>> 2.6
>> 
>>   
>>
>>   ${project.build.__sourceDirectory}/META-INF/__
>> MANIFEST.MF
>>   
>> 
>> 
>>
>> NPE is caused by line:
>>
>> ${project.build.__sourceDirectory}/META-INF/__
>> MANIFEST.MF
>>
>> When I remove${project.build.__sourceDirectory}and leave
>> only/META-INF/__MANIFEST.MF  then
>> NPE goes away.
>>
>> Full POM available
>> athttps://github.com/jboss-__javassist/javassist/blob/__
>> 1fd31f137c3995d29a5be698c9919b__6f764ba882/pom.xml
>> > 1fd31f137c3995d29a5be698c9919b6f764ba882/pom.xml>
>>
>>
>> Stacktrace:
>>
>> [ERROR] Failed to execute goal
>> org.codehaus.mojo:versions-__maven-plugin:2.1:display-__
>> plugin-updates
>> (default-cli) on project javassist: Execution default-cli of goal
>> org.codehaus.mojo:versions-__maven-plugin:2.1:display-__
>> plugin-updates
>> failed. NullPointerException -> [Help 1]
>> org.apache.maven.lifecycle.__LifecycleExecutionException: Failed
>> to
>> execute goal
>> org.codehaus.mojo:versions-__maven-plugin:2.1:display-__
>> plugin-updates
>> (default-cli) on project javassist: Execution default-cli of goal
>> org.codehaus.mojo:versions-__maven-plugin:2.1:display-__
>> plugin-updates
>> failed.
>> at
>> org.apache.maven.lifecycle.__internal.MojoExecutor.execute(
>> __MojoExecutor.java:225)
>> at
>> org.apache.maven.lifecycle.__internal.MojoExecutor.execute(
>> __MojoExecutor.java:153)
>> at
>> org.apache.maven.lifecycle.__internal.MojoExecutor.execute(
>> __MojoExecutor.java:145)
>> at
>> org.apache.maven.lifecycle.__internal.__LifecycleModuleBuilder.__
>> buildProject(__LifecycleModuleBuilder.java:__84)
>> at
>> org.apache.maven.lifecycle.__internal.__LifecycleModuleBuilder.__
>> buildProject(__LifecycleModuleBuilder.java:__59)
>> at
>> org.apache.maven.lifecycle.__internal.LifecycleStarter.__
>> singleThreadedBuild(__LifecycleStarter.java:183)
>> at
>> org.apache.maven.lifecycle.__internal.LifecycleStarter.__
>> execute(LifecycleStarter.java:__161)
>> at
>> org.apache.maven.DefaultMaven.__doExecute(DefaultMaven.java:
>> __320)
>> at org.apache.maven.DefaultMaven.__execute(DefaultMaven.java:156)
>> at org.apache.maven.cli.MavenCli.__execute(MavenCli.java:537)
>> at org.apache.maven.cli.MavenCli.__doMain(MavenCli.java:196)
>> at org.apache.maven.cli.MavenCli.__main(MavenCli.java:141)
>> at sun.reflect.__NativeMethodAccessorImpl.__invoke0(Native
>> Method)
>> at
>> sun.reflect.__NativeMethodAccessorImpl.__invoke(__
>> NativeMethodAccessorImpl.java:__62)
>> at
>> sun.reflect.__DelegatingMethodAccessorImpl.__invoke(__
>> DelegatingMethodAccessorImpl.__java:43)
>> at java.lang.reflect.Method.__invoke(Method.java:483)
>> at
>> org.codehaus.plexus.__classworlds.launcher.Launcher.
>> __launchEnhanced(Launcher.java:__290)
>> at
>> org.codehaus.plexus.__classworlds.launcher.Launcher.
>> __launch(Launcher.java:230)
>> at
>> org.codehaus.plexus.__classworlds.launcher.Launcher.
>> __mainWithExitCode(Launcher.__java:409)
>> at
>> org.codehaus.plexus.__classworlds.launcher.Launcher.
>> __main(Launcher.java:352)
>> at org.codehaus.classworlds.__Launcher.main(Launcher.java:__47)
>> at sun.reflect.__NativeMethodAccessorImpl.__invoke0(Native
>> Method)
>> at
>> sun.reflect.__NativeMethodAccessorImpl.__invoke(__
>> NativeMethodAccessorImpl.java:__62)
>>