Re: Unpacking jars into target/classes

[Joachim Durchholz]

Am 07.03.2013 05:51, schrieb Matthew Adams:

Quick jist:
1. Use maven-install-plugin's
install-filegoal
to make maven artifacts out of the jars you intend to unpack, and do
it in any phase prior to process-classes (or do this first in the
process-classes phase).


The overall organisational project structure does not allow any central 
servers beyond the SCM.
It would also be silly to redundantly store a perfectly stable jar in a 
Maven repo just to make Maven happy.


Regards,
Jo

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Unpacking jars into target/classes

[Jörg Schaible]

Hi,

Joachim Durchholz wrote:

> Am 07.03.2013 05:51, schrieb Matthew Adams:
>> Quick jist:
>> 1. Use maven-install-plugin's
>> install-filegoal
>> to make maven artifacts out of the jars you intend to unpack, and do
>> it in any phase prior to process-classes (or do this first in the
>> process-classes phase).
> 
> The overall organisational project structure does not allow any central
> servers beyond the SCM.
> It would also be silly to redundantly store a perfectly stable jar in a
> Maven repo just to make Maven happy.

But that's the point: Maven is all about conventions. It will not help you a 
lot in other regards - on purpose. If you don't want to follow this 
conventions, it is probably no the right tool for your job.

- Jörg


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Unpacking jars into target/classes

[Baptiste MATHUS]

Le 7 mars 2013 10:02, "Jörg Schaible"  a
écrit :
>
> Hi,
>
> Joachim Durchholz wrote:
>
> > Am 07.03.2013 05:51, schrieb Matthew Adams:
> >> Quick jist:
> >> 1. Use maven-install-plugin's
> >> install-file plugin/install-file-mojo.html>goal
> >> to make maven artifacts out of the jars you intend to unpack, and do
> >> it in any phase prior to process-classes (or do this first in the
> >> process-classes phase).
> >
> > The overall organisational project structure does not allow any central
> > servers beyond the SCM.
> > It would also be silly to redundantly store a perfectly stable jar in a
> > Maven repo just to make Maven happy.
>
> But that's the point: Maven is all about conventions. It will not help
you a
> lot in other regards - on purpose. If you don't want to follow this
> conventions, it is probably no the right tool for your job.

+1.
I'm having a hard time understanding why you keep being unwilling to use
Maven conventions but keep using it at the same time.

Maven is the opinionated build tool. Using its conventions is almost
compulsory. Maven is all about conventions and making build standard across
projects.

If you want full scripting features and design the build the exact way you
want, then have a look at gradle. Or ant+ivy might make you happy.

Cheers

server-url in settings.xml

[Philip]

Hi List,

perhaps i have overlooked something obvious, but what is the point of
the server-element in settings.xml if i can't specify a server-url?

-Philip


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: server-url in settings.xml

[Anders Hammar]

It uses the id for matching.

/Anders


On Thu, Mar 7, 2013 at 11:19 AM, Philip  wrote:

> Hi List,
>
> perhaps i have overlooked something obvious, but what is the point of
> the server-element in settings.xml if i can't specify a server-url?
>
> -Philip
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: server-url in settings.xml

[Philip]

On Thu, 2013-03-07 at 11:20 +0100, Anders Hammar wrote:
> It uses the id for matching.
> 
> /Anders
> 
> 
Yes, but i still needed a profile for an url, it only provides user &
password.

Thanks for your answer,
Philip
> >



-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Unpacking jars into target/classes

[Joachim Durchholz]

Am 07.03.2013 10:00, schrieb Jörg Schaible:

Hi,

Joachim Durchholz wrote:


Am 07.03.2013 05:51, schrieb Matthew Adams:

Quick jist:
1. Use maven-install-plugin's
install-filegoal

to make maven artifacts out of the jars you intend to unpack, and do
it in any phase prior to process-classes (or do this first in the
process-classes phase).


The overall organisational project structure does not allow any central
servers beyond the SCM.
It would also be silly to redundantly store a perfectly stable jar in a
Maven repo just to make Maven happy.


But that's the point: Maven is all about conventions. It will not help you a
lot in other regards - on purpose.


So if a tool doesn't what it should, that's just on purpose? Come on.
Oh, and conventions are useless unless applied to some domain, and Maven 
does indeed have domains (dependency management, builds, build stability).


Sorry to sound harsh, but "it's on purpose" is just a cheap cop-out.

> If you don't want to follow this

conventions, it is probably no the right tool for your job.


I claim that Maven's stance of essentially requiring a repository 
manager needlessly complicates the build infrastructure.


Regards,
Jo

P.S.: Not that discussing Maven's philosophy helps my original problem 
in any way... essentially you're saying "Maven can't do that and that's 
okay", and I say "if Maven can't do that by design, then the design of 
Maven is broken".
You consider my position baseless because, from your perspective, I want 
the undesirable; I consider your position baseless because you're 
putting some very abstract theory about what's desirable ahead of very 
concrete and practical needs, and I consider theory useless if it 
doesn't cover all bases.
Given that situation, I don't think it's going to be very fruitful to 
discuss Maven's philosophy.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: server-url in settings.xml

[Anders Hammar]

Yes, server elements are only for credentials.

/Anders (mobile)
Den 7 mar 2013 11:29 skrev "Philip" :

> On Thu, 2013-03-07 at 11:20 +0100, Anders Hammar wrote:
> > It uses the id for matching.
> >
> > /Anders
> >
> >
> Yes, but i still needed a profile for an url, it only provides user &
> password.
>
> Thanks for your answer,
> Philip
> > >
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: server-url in settings.xml

[Adrien Rivard]

You specifiy the url in one of the  mirrors , proxies, repositories
sections in the settings or in repositories in the pom.xml of your projects.
see  http://maven.apache.org/settings.html




On Thu, Mar 7, 2013 at 11:38 AM, Philip  wrote:

> On Thu, 2013-03-07 at 11:20 +0100, Anders Hammar wrote:
> > It uses the id for matching.
> >
> > /Anders
> >
> >
> Yes, but i still needed a profile for an url, it only provides user &
> password.
>
> Thanks for your answer,
> Philip
> > >
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Adrien Rivard

Re: Unpacking jars into target/classes

[Jörg Schaible]

Hi Jo,

Joachim Durchholz wrote:

> Am 07.03.2013 10:00, schrieb Jörg Schaible:
>> Hi,
>>
>> Joachim Durchholz wrote:
>>
>>> Am 07.03.2013 05:51, schrieb Matthew Adams:
 Quick jist:
 1. Use maven-install-plugin's
 install-file> plugin/install-file-mojo.html>goal
 to make maven artifacts out of the jars you intend to unpack, and do
 it in any phase prior to process-classes (or do this first in the
 process-classes phase).
>>>
>>> The overall organisational project structure does not allow any central
>>> servers beyond the SCM.
>>> It would also be silly to redundantly store a perfectly stable jar in a
>>> Maven repo just to make Maven happy.
>>
>> But that's the point: Maven is all about conventions. It will not help
>> you a lot in other regards - on purpose.
> 
> So if a tool doesn't what it should, that's just on purpose? Come on.
> Oh, and conventions are useless unless applied to some domain, and Maven
> does indeed have domains (dependency management, builds, build stability).
> 
> Sorry to sound harsh, but "it's on purpose" is just a cheap cop-out.
> 
>  > If you don't want to follow this
>> conventions, it is probably no the right tool for your job.
> 
> I claim that Maven's stance of essentially requiring a repository
> manager needlessly complicates the build infrastructure.
> 
> Regards,
> Jo
> 
> P.S.: Not that discussing Maven's philosophy helps my original problem
> in any way... essentially you're saying "Maven can't do that and that's
> okay", and I say "if Maven can't do that by design, then the design of
> Maven is broken".
> You consider my position baseless because, from your perspective, I want
> the undesirable; I consider your position baseless because you're
> putting some very abstract theory about what's desirable ahead of very
> concrete and practical needs, and I consider theory useless if it
> doesn't cover all bases.
> Given that situation, I don't think it's going to be very fruitful to
> discuss Maven's philosophy.

You're free to have a different opinion, but don't expect Maven to change or 
to get a lot of help from the community then. A tool is designed for a 
special purpose and either you accept that or you get yourself into trouble. 
Maven was never meant as golden bullet for all cases. Personally, I'll 
simply stop to look at your questions, because you waste my time and IMHO 
you waste yours, too. And this is nothing personal nor do I want to start a 
flame war, it's just experience of using Maven for a lot of years.

Best whishes,
Jörg


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Unpacking jars into target/classes

[Adrien Rivard]

On Thu, Mar 7, 2013 at 11:37 AM, Joachim Durchholz  wrote:

> Am 07.03.2013 10:00, schrieb Jörg Schaible:
>
>  Hi,
>>
>> Joachim Durchholz wrote:
>>
>>  Am 07.03.2013 05:51, schrieb Matthew Adams:
>>>
 Quick jist:
 1. Use maven-install-plugin's
 install-file

>>> plugin/install-file-mojo.html>**goal
>>
>>> to make maven artifacts out of the jars you intend to unpack, and do
 it in any phase prior to process-classes (or do this first in the
 process-classes phase).

>>>
>>> The overall organisational project structure does not allow any central
>>> servers beyond the SCM.
>>> It would also be silly to redundantly store a perfectly stable jar in a
>>> Maven repo just to make Maven happy.
>>>
>>
>> But that's the point: Maven is all about conventions. It will not help
>> you a
>> lot in other regards - on purpose.
>>
>
> So if a tool doesn't what it should, that's just on purpose? Come on.
> Oh, and conventions are useless unless applied to some domain, and Maven
> does indeed have domains (dependency management, builds, build stability).
>
> Sorry to sound harsh, but "it's on purpose" is just a cheap cop-out.
>
>
> > If you don't want to follow this
>
>> conventions, it is probably no the right tool for your job.
>>
>
> I claim that Maven's stance of essentially requiring a repository manager
> needlessly complicates the build infrastructure.
>
>
It may complicate the build infrastrucure but it simplify and homogenize a
lots all the builds of all your project. Which is what Maven is all about.

If you don't want to use a repository manager, just don't use Maven, Maven
is not flexible by design. If you want to use it outside its main design,
you will have a too complex build. This will be better achieved with a
tools that support scripting in its design.

That said, it is still useful to have a repopsitory manager even with
others build tools like gradle/ant+ivy.


Regards,
> Jo
>
> P.S.: Not that discussing Maven's philosophy helps my original problem in
> any way... essentially you're saying "Maven can't do that and that's okay",
> and I say "if Maven can't do that by design, then the design of Maven is
> broken".
> You consider my position baseless because, from your perspective, I want
> the undesirable; I consider your position baseless because you're putting
> some very abstract theory about what's desirable ahead of very concrete and
> practical needs, and I consider theory useless if it doesn't cover all
> bases.
> Given that situation, I don't think it's going to be very fruitful to
> discuss Maven's philosophy.
>
>
> --**--**-
> To unsubscribe, e-mail: 
> users-unsubscribe@maven.**apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Adrien Rivard

tomcat6:list - minimum requirements to run

[Stadelmann Josef]

Hi all,

I have some difficulty to understand how to use the plugin below to do a
simple $ mvn tomcat6:list




org.apache.tomcat.maven
tomcat6-maven-plugin
2.1


org.apache.tomcat.maven
tomcat7-maven-plugin
2.1





I have integrated this plugin into my main pom.xml of the multi modul
project svnkit, of which svnkit-dav has a war file on board/generated.
Not an executable war file (what is that?) but just a war to be deployed
to a running tomcat AS.

As a starter, and not involfing any war file, I like just to know under
which circumstances I can use
$ mvn tomcat6:list

Josef - I have read the documentation and I am not clear what to do to
get an embedded tomcat OR how to use it.

Re: Unpacking jars into target/classes

[Joachim Durchholz]

Am 07.03.2013 12:07, schrieb Jörg Schaible:

Personally, I'll
simply stop to look at your questions, because you waste my time and IMHO
you waste yours, too.


I couldn't agree more to the waste-of-time observation.
Though in our case, I guess it's been your answer with its lengthy 
philosophical content that started the waste of time.


I suggest avoiding philosophy if that's not your interest, and simply 
sticking with answering questions at the factual level:

- No, this plugin is not for the use case you describe;
- yes, this option is the right one;
- oh, that's not the plugin you need but try that option instead;
- maybe you can vary your use case in this-and-that way?
This kind of answer would be very much appreciated.

Regards,
Jo

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Unpacking jars into target/classes

[Anders Hammar]

You forgot:
- You need a repo manager

:-)
Sorry, couldn't stop myself,
/Anders


On Thu, Mar 7, 2013 at 12:46 PM, Joachim Durchholz  wrote:

> Am 07.03.2013 12:07, schrieb Jörg Schaible:
>
>> Personally, I'll
>> simply stop to look at your questions, because you waste my time and IMHO
>> you waste yours, too.
>>
>
> I couldn't agree more to the waste-of-time observation.
> Though in our case, I guess it's been your answer with its lengthy
> philosophical content that started the waste of time.
>
> I suggest avoiding philosophy if that's not your interest, and simply
> sticking with answering questions at the factual level:
> - No, this plugin is not for the use case you describe;
> - yes, this option is the right one;
> - oh, that's not the plugin you need but try that option instead;
> - maybe you can vary your use case in this-and-that way?
> This kind of answer would be very much appreciated.
>
> Regards,
> Jo
>
> --**--**-
> To unsubscribe, e-mail: 
> users-unsubscribe@maven.**apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Unpacking jars into target/classes

[Joachim Durchholz]

Warning: Just philosophy here.
I AM trying to restrict myself to things I haven't said before. Some 
amount of repetition is inevitable, and this kind of discussion is 
nearing the point of diminishing returns, so I'm trying to cut down on 
this kind of discussion.


Am 07.03.2013 10:57, schrieb Baptiste MATHUS:

I'm having a hard time understanding why you keep being unwilling to use
Maven conventions but keep using it at the same time.


Hello? Because it has been advertised to me as "THE build tool that will 
solve my problems"? And maybe because switching build tool in mid-flight 
is a daunting task?


I'm here because I'm locked in, not because I think Maven is great.


Maven is the opinionated build tool. Using its conventions is almost
compulsory. Maven is all about conventions and making build standard across
projects.


Problem with Maven is that its conventions are too restrictive. Maven 
works well as long as you are 100% inside its mental model of how a 
build should be set up; the problem is that as soon as you (need to) 
work outside that box, Maven will break down, horribly.
Overly terse documentation makes it worse because that makes it hard to 
decide whether the reason for some problem is because some option wasn't 
properly set, or whether the plugin simply can't do what one wants. 
That's making for a lot of frustrating dead-end exploration.



If you want full scripting features and design the build the exact way you
want,


That's not really what I want.
I want a declarative specification so the tool can decide what build 
steps to run.
I want full scripting only for the individual build steps. This probably 
means an obligation to specify the declarative metadata so the tool can 
set up its build plan. Plus this probably also means that people will 
need a way to test whether their metadata are correct, since otherwise 
people will get subtle errors into the build plans.


I also want Eclipse integration, so build configuration doesn't need to 
be specified redundantly.
This is usually done via a plugin that configures Eclipse projects, 
restricting further what can and what cannot work as build script (or 
requires another layer of metadata so the plugin knows what to do; m2e's 
lifecycle mapping complications are a good example how complicated this 
problem is.)

(Substitute the IDE of your choice for Eclipse if you want.)

> then have a look at gradle. Or ant+ivy might make you happy.

I'm not sure whether Gradle fits the bill. Given the complexities 
involved, there's a high risk that it won't.
There's also that advice for any tool is invariably biased, so I also 
risk acting on inappropriate advice. I've been bitten by this time after 
time, Maven is just the last


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Unpacking jars into target/classes

[Joachim Durchholz]

Am 07.03.2013 12:53, schrieb Anders Hammar:

You forgot:
- You need a repo manager

:-)
Sorry, couldn't stop myself,


Yeah, talk about waste of time :-(

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Unpacking jars into target/classes

[Andreas Gudian]

Am Donnerstag, 7. März 2013 schrieb Joachim Durchholz :

> Warning: Just philosophy here.
> I AM trying to restrict myself to things I haven't said before. Some
> amount of repetition is inevitable, and this kind of discussion is nearing
> the point of diminishing returns, so I'm trying to cut down on this kind of
> discussion.
>
> Am 07.03.2013 10:57, schrieb Baptiste MATHUS:
>
>> I'm having a hard time understanding why you keep being unwilling to use
>> Maven conventions but keep using it at the same time.
>>
>
> Hello? Because it has been advertised to me as "THE build tool that will
> solve my problems"? And maybe because switching build tool in mid-flight is
> a daunting task?
>
> I'm here because I'm locked in, not because I think Maven is great.
>
>  Maven is the opinionated build tool. Using its conventions is almost
>> compulsory. Maven is all about conventions and making build standard
>> across
>> projects.
>>
>
> Problem with Maven is that its conventions are too restrictive. Maven
> works well as long as you are 100% inside its mental model of how a build
> should be set up; the problem is that as soon as you (need to) work outside
> that box, Maven will break down, horribly.
> Overly terse documentation makes it worse because that makes it hard to
> decide whether the reason for some problem is because some option wasn't
> properly set, or whether the plugin simply can't do what one wants. That's
> making for a lot of frustrating dead-end exploration.
>
>  If you want full scripting features and design the build the exact way you
>> want,
>>
>
> That's not really what I want.
> I want a declarative specification so the tool can decide what build steps
> to run.
> I want full scripting only for the individual build steps. This probably
> means an obligation to specify the declarative metadata so the tool can set
> up its build plan. Plus this probably also means that people will need a
> way to test whether their metadata are correct, since otherwise people will
> get subtle errors into the build plan.


Then the ant-plugin should help you. Eclipse might have a harder time in
that case, though.



>
> I also want Eclipse integration, so build configuration doesn't need to be
> specified redundantly.
> This is usually done via a plugin that configures Eclipse projects,
> restricting further what can and what cannot work as build script (or
> requires another layer of metadata so the plugin knows what to do; m2e's
> lifecycle mapping complications are a good example how complicated this
> problem is.)
> (Substitute the IDE of your choice for Eclipse if you want.)
>
> > then have a look at gradle. Or ant+ivy might make you happy.
>
> I'm not sure whether Gradle fits the bill. Given the complexities
> involved, there's a high risk that it won't.
> There's also that advice for any tool is invariably biased, so I also risk
> acting on inappropriate advice. I've been bitten by this time after time,
> Maven is just the last
>
> --**--**-
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Unpacking jars into target/classes

[Stephen Connolly]

On 7 March 2013 11:57, Joachim Durchholz  wrote:

> Warning: Just philosophy here.
> I AM trying to restrict myself to things I haven't said before. Some
> amount of repetition is inevitable, and this kind of discussion is nearing
> the point of diminishing returns, so I'm trying to cut down on this kind of
> discussion.
>
> Am 07.03.2013 10:57, schrieb Baptiste MATHUS:
>
>  I'm having a hard time understanding why you keep being unwilling to use
>> Maven conventions but keep using it at the same time.
>>
>
> Hello? Because it has been advertised to me as "THE build tool that will
> solve my problems"? And maybe because switching build tool in mid-flight is
> a daunting task?
>
> I'm here because I'm locked in, not because I think Maven is great.
>
>
>  Maven is the opinionated build tool. Using its conventions is almost
>> compulsory. Maven is all about conventions and making build standard
>> across
>> projects.
>>
>
> Problem with Maven is that its conventions are too restrictive. Maven
> works well as long as you are 100% inside its mental model of how a build
> should be set up; the problem is that as soon as you (need to) work outside
> that box, Maven will break down, horribly.
>

Maven is *the* opinionated build tool.

Like any relationship, you must have give and take... both sides need
flexibility... but at some point there will be a deal breaker...

I like to let the dishes soak in the burn your hands hot soapy water for 5
minutes to let the surfactants do their stuff... she likes to start washing
them straight away... meh! I can compromise and put up with slightly less
clean dishes... so what if I have a PhD in physical chemistry and *know*
that my way is the correct way to wash dishes... or maybe we buy a
dishwashing machine and let it do the dishes for us.

On the other hand, previously I didn't like kissing an ashtray, she didn't
want to give up smoking... that was something I tried to compromise on, but
you know what, turns out that smoking is a deal breaker, so that
relationship ended (lucky for me and my wife eh!)

This is not a "Maven" issue. This is a relationship issue.

To bring this back to Maven...

Maven wants the java source code in ${basedir}/src/main/java... you want it
somewhere else... you know what, Maven is OK with that

Maven wants to build the dependency tree before it finalizes a build plan
that will include plugin executions that require resolving the dependency
tree in order to ensure that the transitive dependency tree does not
reorder the build-plan... you don't want to use a maven repository manager
or run a separate script to install the 3rd party dependencies into the
local repository cache... that one is a deal breaker for Maven... the
question is I have for you is: can you live with Maven's restrictions? This
is something that Maven will not compromise on... the ball is in your court.


> Overly terse documentation makes it worse because that makes it hard to
> decide whether the reason for some problem is because some option wasn't
> properly set, or whether the plugin simply can't do what one wants. That's
> making for a lot of frustrating dead-end exploration.


I am trying to come up with a better user facing documentation for the core
of Maven itself... my aim being to let people know that Maven is
OPINIONATED, that it's ok to disagree on some of those opinions, but that
some things are core opinions and if you disagree with those core opinions,
please don't use Maven.



>
>
>  If you want full scripting features and design the build the exact way you
>> want,
>>
>
> That's not really what I want.
> I want a declarative specification so the tool can decide what build steps
> to run.
> I want full scripting only for the individual build steps. This probably
> means an obligation to specify the declarative metadata so the tool can set
> up its build plan. Plus this probably also means that people will need a
> way to test whether their metadata are correct, since otherwise people will
> get subtle errors into the build plans.
>

You don't want Maven... if you are not prepared to compromise on the above,
then (and please don't take this the wrong way) stop using Maven.


>
> I also want Eclipse integration, so build configuration doesn't need to be
> specified redundantly.
> This is usually done via a plugin that configures Eclipse projects,
> restricting further what can and what cannot work as build script (or
> requires another layer of metadata so the plugin knows what to do; m2e's
> lifecycle mapping complications are a good example how complicated this
> problem is.)
> (Substitute the IDE of your choice for Eclipse if you want.)


Do you want a pony too? ;-)


>
>
> > then have a look at gradle. Or ant+ivy might make you happy.
>
> I'm not sure whether Gradle fits the bill. Given the complexities
> involved, there's a high risk that it won't.
> There's also that advice for any tool is invariably biased, so I also risk
> acting on inappropriate advice. I'

Re: Unpacking jars into target/classes

[Joachim Durchholz]

(Sorry, more philosphy ahead, just trying to explain my situation to Adrien)

Am 07.03.2013 12:16, schrieb Adrien Rivard:

I claim that Maven's stance of essentially requiring a repository manager
needlessly complicates the build infrastructure.


It may complicate the build infrastrucure but it simplify and homogenize a
lots all the builds of all your project.


To date, I have been using Maven in one environment with a MRM and one 
without.
The MRM-based development got more complicated. I do see the advantages 
that an MRM can offer, but these have been irrelevant for our situation.


> Which is what Maven is all about.

I get that.
Trouble is that at the current project sizes, homogenization isn't 
giving me much of an advantage. I have inhomogenous jar imports, I have 
inhomogenous deployment scenarios, and there's nothing I can do about 
either side.



If you don't want to use a repository manager, just don't use Maven, Maven
is not flexible by design.


Understood, and a conclusion I have reached quite a while ago.

Unfortunately, changing the build tool is never an easy option.
So for now, I'm stuck with Maven, whether it's the right tool for the 
job or not, and I'll have to somehow make it work whatever the problems.


Regards,
Jo

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Unpacking jars into target/classes

[Joachim Durchholz]

Am 07.03.2013 13:05, schrieb Andreas Gudian:

That's not really what I want.
I want a declarative specification so the tool can decide what build steps
to run.
I want full scripting only for the individual build steps. This probably
means an obligation to specify the declarative metadata so the tool can set
up its build plan. Plus this probably also means that people will need a
way to test whether their metadata are correct, since otherwise people will
get subtle errors into the build plan.


Then the ant-plugin should help you. Eclipse might have a harder time in
that case, though.


I've been considering the ant plugin, but that's excactly the catch I've 
been worrying about.


The other reason is that Maven literature have generally been listing 
Ant as a kind of cop-out that should be avoided.
But maybe I've been taking that advice more seriously than it was ever 
intended, so I'll probably try that.


Regards,
Jo

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Unpacking jars into target/classes

[Joachim Durchholz]

Just some feedback...

Am 07.03.2013 13:22, schrieb Stephen Connolly:

Maven wants the java source code in ${basedir}/src/main/java... you want it
somewhere else... you know what, Maven is OK with that


I'm actually okay with that source structure, though I don't like the 
split between .../java/... and .../resources/..., it's ripping apart 
stuff that will live side-by-side in the jar.
But... meh, I can adapt and I can see the reasons why one would want to 
keep the directories apart, It's ultimately a judgement call.



Maven wants to build the dependency tree before it finalizes a build plan
that will include plugin executions that require resolving the dependency
tree in order to ensure that the transitive dependency tree does not
reorder the build-plan...


Which is a good thing in my book (and why I'm aghast when I see people 
building plugins during normal build).


> you don't want to use a maven repository manager

or run a separate script to install the 3rd party dependencies into the
local repository cache... that one is a deal breaker for Maven... the
question is I have for you is: can you live with Maven's restrictions? This
is something that Maven will not compromise on... the ball is in your court.


Well, I have to compromise on that if Maven won't budge, right?

Dropping Maven will ultimately be what I'm forced into, but I can't 
switch right now.



I am trying to come up with a better user facing documentation for the core
of Maven itself...


It's never a bad idea to improve the docs, but the real problem is the 
plugin docs. Many options are "documented" along the lines of "frob: 
frobs the build", which isn't very helpful. Few if any plugins clearly 
document the use cases they are built for, or (almost more importantly) 
the use cases that will not work. Of course, lifting the restrictions 
would be even more helpful than documenting them :-)


> my aim being to let people know that Maven is

OPINIONATED, that it's ok to disagree on some of those opinions, but that
some things are core opinions and if you disagree with those core opinions,
please don't use Maven.


These opinions need to be spelled out if people are to make an informed 
decision whether Maven is for them. The problem is that it's hard to 
spell everything out since it's so easy to have implied assumptions even 
without being aware of them. Plus, it's hard to spell everything out 
without getting lost in detail.


Also, such opinions need to be presented in a fashion that shows where 
there's room for reasonable disagreement. If opinions are presented as 
"that's the only reasonable alternative", people will assume that all 
the doubts they might harbor will eventually dissolve.
Maven is less prone to that problem than, say, Hibernate. Gavin has been 
promoting a single transactional model as the only reasonable one, which 
is okay for those programs that happen to live well with it but simply 
can't be made to work for all situations. It's a nasty kind of 
misrepresentation because it's to easy to fall to it, both for the 
author and for the reader.

Just listing that as a point to consider when laying out the arguments.


That's not really what I want.
I want a declarative specification so the tool can decide what build steps
to run.
I want full scripting only for the individual build steps. This probably
means an obligation to specify the declarative metadata so the tool can set
up its build plan. Plus this probably also means that people will need a
way to test whether their metadata are correct, since otherwise people will
get subtle errors into the build plans.


You don't want Maven... if you are not prepared to compromise on the above,


Ah, I was just on a tangent how an ideal build system should be done, 
IMNSHO.

I'm very aware that Maven isn't it :-)


then (and please don't take this the wrong way) stop using Maven.


No offense taken. I'm already on my way out, it's just that switching 
build tools in general is a high-effort high-risk endeavour.



Do you want a pony too? ;-)


In pink, preferrably ;-)


I'm not sure whether Gradle fits the bill. Given the complexities
involved, there's a high risk that it won't.
There's also that advice for any tool is invariably biased, so I also risk
acting on inappropriate advice. I've been bitten by this time after time,
Maven is just the last


Based on your wants stated above, my view is Gradle is what you want...


Maybe. I'm not sure whether it's really managing build ordering 
constraints well enough to be worth it.



might not be what anyone else working on your project wants, may not even
be what you need, but you have your core principals and they clash with
Maven's core principals, for the sake of the children (the source code)
perhaps you and Maven should get a divorce


I hear ya.
As with every divorce, things are easier said than done.

Regards,
Jo

-
To unsubscribe, e-mail: users-un

Re: Unpacking jars into target/classes

[Stephen Connolly]

On 7 March 2013 12:34, Joachim Durchholz  wrote:

> Am 07.03.2013 13:05, schrieb Andreas Gudian:
>
>  That's not really what I want.
>>> I want a declarative specification so the tool can decide what build
>>> steps
>>> to run.
>>> I want full scripting only for the individual build steps. This probably
>>> means an obligation to specify the declarative metadata so the tool can
>>> set
>>> up its build plan. Plus this probably also means that people will need a
>>> way to test whether their metadata are correct, since otherwise people
>>> will
>>> get subtle errors into the build plan.
>>>
>>
>> Then the ant-plugin should help you. Eclipse might have a harder time in
>> that case, though.
>>
>
> I've been considering the ant plugin, but that's excactly the catch I've
> been worrying about.
>
> The other reason is that Maven literature have generally been listing Ant
> as a kind of cop-out that should be avoided.
> But maybe I've been taking that advice more seriously than it was ever
> intended, so I'll probably try that.
>

The Maven philosophy is to avoid writing one-time code as much as possible.

So using antrun or the groovy plugins to run some 'specific to this build
only' step is frowned upon for the reason that it is most likely something
that could be reused in other projects if just made a little more generic
and then everyone wins.

When you write a "this project only" step, you are forcing anyone looking
at the build at a later point in time to figure out what the hell that is
doing. A properly documented plugin execution (yes yes when the hell have
we ever seen one of them... that's the difference between philosophy and
actually doing stuff) would just mean that I look at the plugin
documentation and hey! I know what thats doing.

BUT if you are doing something that is crazy and stupid and just has to be
this way for this one and only project, then antrun or the ant plugin or
the groovy plugin, they are all just fine and dandy and perfect for your
requirements if it turns out later that with some minor tweaks it could
be turned into a plugin that is generally useful to other projects... then
the frowns and looks of disapproval will reappear ;-)


>
> Regards,
> Jo
>
> --**--**-
>
> To unsubscribe, e-mail: 
> users-unsubscribe@maven.**apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

git release:prepare does not commit the poms (Linux)

[Willem Voogd]

Hi All,

I'm new to this mailing list, so if I'm posting at the wrong place, 
please say so kindly ;)


I am trying to craete a release, while making use of the github.

It seems the changed poms (with the release numbers) don't get commited, 
just added to staging. mvn does tag the branch, but since the new poms 
are not on the HEAD, the release:perform just releases the SNAPSHOT 
versions...


a snippet from my mvn output:

[INFO] Executing: /bin/sh -c cd /home/willem/var/sdu/bwb-cms/BWB-CMS/cms 
&& git add -- pom.xml cms-ejb/pom.xml cms-web/pom.xml 
stylesheets-jar/pom.xml cms-ear/pom.xml schaduw-ear/pom.xml 
buzacms-ear/pom.xml buzaschaduw-ear/pom.xml config-web/pom.xml

[INFO] Working directory: /home/willem/var/sdu/bwb-cms/BWB-CMS/cms
[INFO] Executing: /bin/sh -c cd /home/willem/var/sdu/bwb-cms/BWB-CMS/cms 
&& git status --porcelain

[INFO] Working directory: /home/willem/var/sdu/bwb-cms/BWB-CMS/cms
[INFO] Tagging release with the label cms-3.x_TEST...
[INFO] Executing: /bin/sh -c cd /home/willem/var/sdu/bwb-cms/BWB-CMS/cms 
&& git tag -F /tmp/maven-scm-1360697828.commit cms-3.x_TEST

[INFO] Working directory: /home/willem/var/sdu/bwb-cms/BWB-CMS/cms
[INFO] Executing: /bin/sh -c cd /home/willem/var/sdu/bwb-cms/BWB-CMS/cms 
&& git push g...@github.com:SDUUitgevers/BWB-CMS.git cms-3.x_TEST

[INFO] Working directory: /home/willem/var/sdu/bwb-cms/BWB-CMS/cms
[INFO] Executing: /bin/sh -c cd /home/willem/var/sdu/bwb-cms/BWB-CMS/cms 
&& git ls-files

[INFO] Working directory: /home/willem/var/sdu/bwb-cms/BWB-CMS/cms

I expect a commit after the git add statement, and a push before the tag 
statement.


the plugin part in my pom:


org.apache.maven.plugins
maven-release-plugin
2.4

true




Since the deployed versions are a dependency for another project, I 
cannot release this other project, because it cannot have a SNAPSHOT 
dependency of course...


Any tips on how to solve this are greatly appreciated...


thanks,

Willem Voogd


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Unpacking jars into target/classes

[Ron Wheeler]

Tens of thousands of developers use Maven every day.
They like the way that it works now and don't want it to change.
They build all kinds of projects - big ones, little ones, ones with lots 
of third party dependencies and lots with just a few.


We have an LMS that we built with Maven - it has over 80 projects that 
make up the artifacts required to provide all the functionality.
It leverages Spring, Hibernate, MySQL, JasperReports, CXF and Axis, JSF 
and a few more outside technologies.
We have our virtual meeting registration portal takeawebinar.com that is 
smaller with a similar set of technologies.
Our ADTransform only has 7 projects with JCR as its persistence 
architecture but it includes the manual which is written using DITA  and 
assembled using a Maven plug-in that controls the Open-DITA tool  kit.
I am also using Maven to assemble the study report that I am doing about 
how to modernize the delivery of training to police management and 
technical staff which is also being done in DITA.



Lots of people use Eclipse.
We use Eclipse/STS from Springsource since it gives us everything that 
we need in one download.
I am currently using the latest Eclipse Juno M2 with the Springsource 
Tool Kit added because there was a serious bug the the last Eclipse 
release with XML and DITA is all XML. Springsource will only release a 
new version when Eclipse releases the patched release this month.

I am the only one affected by this at Artifact.

We NEVER EVER use Maven from the command line.

Maven sits quietly in the background doing our builds without any fuss 
or bother just by right-clicking on  the POM and selecting the correct 
option off the Run As menu


For a new person to modify a project, they only have to use Eclipse to 
checkout the project, modify the code they want to changes, click on the 
pom to build it, and run the tests and then synchronize to update their 
changes in the SCM.
They do not need any other projects other than the one that they are 
working on. No interproject dependencies are resolved within the Eclipse 
workspace.
If they need to fix a module and a dependent library, they need to build 
the dependent library first  and at least "install" it.


Maven is not a deployment tool and we will probably use an installer 
(izPack looks good) with Ant to build installers for the supported 
architectures and configurations for ADTransform.


The other portals are hosted by us so we just copy the jars and wars 
when we need to make a change.
Embarrassingly low tech!!! We only release new versions very 
infrequently and bugs usually involve a single war file so it is not top 
of mind at this point.


We have Nexus and in our 3rd party library repo, we have 8 artifacts 
that are not available in Maven Central for various reasons(licensing, 
unreleased versions, not mavenized, etc.).

We had to download them and manually install them in the repo.

We do not offer any artifacts from our repo to the public.

We have tried to explain Maven best practices and I believe that I 
offered to show you how we use Eclipse.
The other people in this thread are the best Maven experts around . I am 
just a keen user of Maven.


Maven is like a very large ocean liner and it will change direction very 
slowly.
Paddling your canoe out in front and yelling "Turn, turn turn." at the 
top of your lungs will only get you run over.
We are all on board and are yelling that you need to buy the ticket and 
get on board where you will be warm and dry with a nice view or that you 
should find another place to paddle.
Sitting where you are, is not going to make you happy and the good ship 
Maven with it thousands of passengers is not going to turn in time to 
save you.


Ron


On 07/03/2013 5:37 AM, Joachim Durchholz wrote:

Am 07.03.2013 10:00, schrieb Jörg Schaible:

Hi,

Joachim Durchholz wrote:


Am 07.03.2013 05:51, schrieb Matthew Adams:

Quick jist:
1. Use maven-install-plugin's
install-filegoal

to make maven artifacts out of the jars you intend to unpack, and do
it in any phase prior to process-classes (or do this first in the
process-classes phase).


The overall organisational project structure does not allow any central
servers beyond the SCM.
It would also be silly to redundantly store a perfectly stable jar in a
Maven repo just to make Maven happy.


But that's the point: Maven is all about conventions. It will not 
help you a

lot in other regards - on purpose.


So if a tool doesn't what it should, that's just on purpose? Come on.
Oh, and conventions are useless unless applied to some domain, and 
Maven does indeed have domains (dependency management, builds, build 
stability).


Sorry to sound harsh, but "it's on purpose" is just a cheap cop-out.

> If you don't want to follow this

conventions, it is probably no the right tool for your job.


I claim that Maven's stance of essentially requiring a repository 
manager ne

Skinny WAR and SNAPSHOT

[Lewis, Eric]

Hi

I know a lot has been written about skinny WARs and the problems they represent.

The strategy that we're using is:

- Set dependencies in the web module to scope 'provided', except dependencies 
that are web-specific (PrimeFaces, ...)
- Set skinnyWars to true in the EAR project


The strategy works very well for releases. But for SNAPSHOTs (we use Maven 
3.0.4 with timestamped JARs) we have the problem that the same dependency still 
exists in both the WAR/WEB-INF/lib and the EAR/lib:

my.ear
  lib
util-logging-1.13.0-SNAPSHOT.jar
  my-ejb.jar
  my.war
WEB-INF
  lib
util-logging-1.13.0-20130305.151315-24.jar


>From my point of view, this is what happens:
- The WAR plugin for my.war resolves all dependencies and puts them into its 
WEB-INF/lib. For some reason, the JARs contain the timestamp instead of 
SNAPSHOT in the filename.
- The WAR is deployed to the repo
- The EAR plugin for my.ear gets the my.war and tries to figure out what files 
are both in its dependencies as well as in the WAR's WEB-INF/lib
- However, since the two filenames of util-logging differ, it's only successful 
up to a certain extent - anything which is resolved to different filenames 
leaves me with two JARs.

Am I right with this?

Also, how can I solve the problem with the SNAPSHOTs?
Is there any other way than to force people to always use 'provided' in the web 
module? (I guess I should write a Maven Enforcer rule for that)

Thanks for any pointers...

Best regards,
Eric

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

m2eclipse install

[Hossein Miri]

Hello,I'm a novice, trying to setup maven2 on my Mac.I would like to install the m2eclipse from: http://eclipse.org/m2e/and import a project as a Maven Project under the Eclipse menu.But when I go to the Help menu and look for m2eclipse in the MarketPlace,there are a number of options for install:  - Maven Integration for Eclipse WTP (Incubation)    by Eclipse.org, EPL  - m2eclipse-wtp : Maven Integration for Eclipse WTP (from github)    by Red Hat, Inc., EPL  - Maven Integration for Eclipse    by Eclipse.org, EPLWhich one should I install?Thanks,

Re: m2eclipse install

[Ron Wheeler]

You can save yourself a lot of grief just by installing Eclipse/STS from 
Springsource.
It includes Eclipse with a full set of plug-ins required to do 
development with Java, Maven and the Spring tool suite.


Saves all these questions about what to load and how to fix incompatible 
dependencies.

One download and install and you are good to go.

All free!
Ron

On 07/03/2013 9:46 AM, Hossein Miri wrote:

Hello,

I'm a novice, trying to setup maven2 on my Mac.

I would like to install the m2eclipse from: http://eclipse.org/m2e/

and import a project as a Maven Project under the Eclipse menu.

But when I go to the Help menu and look for m2eclipse in the MarketPlace,

there are a number of options for install:

  - Maven Integration for Eclipse WTP (Incubation)
by Eclipse.org, EPL

  - m2eclipse-wtp : Maven Integration for Eclipse WTP (from github)
by Red Hat, Inc., EPL

  - Maven Integration for Eclipse
by Eclipse.org, EPL

Which one should I install?

Thanks,







--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

File permissions after deploy using scpexe

[Jeff Lusted]

I'm using maven 2.2.1 and I have Nexus 2.2-01 open source version installed.
The client and server OS's involved are both Ubuntu 11.10.

I'm interested here in considering a snapshot repository, where I might
expect quite a bit of traffic from developers. To deploy I have the
distributionManagement set up to use scpexe. The problem I've encountered by
experimenting is that all files and directories created on the remote
snapshot repository have the user that submitted the mvn deploy command as
both owner and primary group  (ie: JohnDoe as user and JohnDoe as primary
group). 

When I then try as another developer on the same project, I get permission
problems. I can see this being frustrating for co-operating developers in a
small team. Actually, I can imagine the same problem surfacing on a related
project on a different team; eg: where a new artifact within the same maven
group was in concurrent development. But I haven't tried the latter
experiment yet.

Of course I can get around this in a number of ways. I can set the file and
directory permissions for the server within the settings.xml file to allow
write access to all. Or I can set up a group (say 'nexus') on the server
machine, make all developers a member of this group, and periodically on a
cron job change the group on all relevant directories and files within the
snapshot repository. 

But I suspect there might be a smoother, maven way of doing this that I have
overlooked. Is there a better way? Or have I been stupid and misunderstood
the problem altogether?

Regards
Jeff



--
View this message in context: 
http://maven.40175.n5.nabble.com/File-permissions-after-deploy-using-scpexe-tp5749909.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: File permissions after deploy using scpexe

[Ron Wheeler]

On 07/03/2013 9:53 AM, Jeff Lusted wrote:

I'm using maven 2.2.1 and I have Nexus 2.2-01 open source version installed.
The client and server OS's involved are both Ubuntu 11.10.

I'm interested here in considering a snapshot repository, where I might
expect quite a bit of traffic from developers. To deploy I have the
distributionManagement set up to use scpexe. The problem I've encountered by
experimenting is that all files and directories created on the remote
snapshot repository have the user that submitted the mvn deploy command as
both owner and primary group  (ie: JohnDoe as user and JohnDoe as primary
group).

When I then try as another developer on the same project, I get permission
problems. I can see this being frustrating for co-operating developers in a
small team. Actually, I can imagine the same problem surfacing on a related
project on a different team; eg: where a new artifact within the same maven
group was in concurrent development. But I haven't tried the latter
experiment yet.

Of course I can get around this in a number of ways. I can set the file and
directory permissions for the server within the settings.xml file to allow
write access to all. Or I can set up a group (say 'nexus') on the server
machine, make all developers a member of this group, and periodically on a
cron job change the group on all relevant directories and files within the
snapshot repository.

But I suspect there might be a smoother, maven way of doing this that I have
overlooked. Is there a better way? Or have I been stupid and misunderstood
the problem altogether?

Regards
Jeff



--
View this message in context: 
http://maven.40175.n5.nabble.com/File-permissions-after-deploy-using-scpexe-tp5749909.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


You might try this on the nexus list since it appears to be a 
Nexus-specific issue and the people there have probably seen this before.


Ron

--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: m2eclipse install

[Jeffrey E Care]

Hossein Miri  wrote on 03/07/2013 09:46:49 AM:

> there are a number of options for install:
> 
>   - Maven Integration for Eclipse WTP (Incubation)
> by Eclipse.org, EPL
> 
>   - m2eclipse-wtp : Maven Integration for Eclipse WTP (from github)
> by Red Hat, Inc., EPL
> 
>   - Maven Integration for Eclipse
> by Eclipse.org, EPL
> 
> Which one should I install?

The last one is actually m2e, so you need that one for sure. The other two 
are m2e extensions that attempt to integrate Eclipse's Web Tools Project 
(WTP) with the Maven WAR plugin.

Re: m2eclipse install

[Curtis Rueden]

Hi Hossein,

> I would like to install the m2eclipse

As Ron says, you can use Eclipse/STS if you want the whole enchilada.

Alternately, one middle ground is the "Eclipse IDE for Java Developers"
download, which comes with both M2E and EGit already installed. Feature
list here:


http://www.eclipse.org/downloads/packages/eclipse-ide-java-developers/junosr2

Regards,
Curtis


On Thu, Mar 7, 2013 at 8:46 AM, Hossein Miri  wrote:

> Hello,
>
> I'm a novice, trying to setup maven2 on my Mac.
>
> I would like to install the m2eclipse from: http://eclipse.org/m2e/
>
> and import a project as a Maven Project under the Eclipse menu.
>
> But when I go to the Help menu and look for m2eclipse in the MarketPlace,
>
> there are a number of options for install:
>
>   - Maven Integration for Eclipse WTP (Incubation)
> by Eclipse.org, EPL
>
>   - m2eclipse-wtp : Maven Integration for Eclipse WTP (from github)
> by Red Hat, Inc., EPL
>
>   - Maven Integration for Eclipse
> by Eclipse.org, EPL
>
> Which one should I install?
>
> Thanks,
>
>
>
>
>

Maven introductory course reviewers needed

[Russell Gold]

Hi,

I am developing an introductory course for Maven users. The publisher will 
eventually provide technical reviewers, but I was hoping for some earlier 
feedback. The full course is expected to be a bit over 2 hours long; I have 3/8 
sections created so far (14 videos totaling a bit over 45 minutes). If you 
would be willing to take a look at comment, please contact me at this address: 
r...@gold-family.us

Thanks
-
Come read my webnovel, Take a Lemon , 
and listen to the Misfile radio play 
!

Re: git release:prepare does not commit the poms (Linux)

[Robert Scholte]

Hi,

could you try to use maven-release-plugin 2.3.2?
There are some known issues with GIT and the maven-release-plugin 2.4,  
which need to be fixed in the SCM project first.


Robert

Op Thu, 07 Mar 2013 14:04:01 +0100 schreef Willem Voogd  
:



Hi All,

I'm new to this mailing list, so if I'm posting at the wrong place,  
please say so kindly ;)


I am trying to craete a release, while making use of the github.

It seems the changed poms (with the release numbers) don't get commited,  
just added to staging. mvn does tag the branch, but since the new poms  
are not on the HEAD, the release:perform just releases the SNAPSHOT  
versions...


a snippet from my mvn output:

[INFO] Executing: /bin/sh -c cd /home/willem/var/sdu/bwb-cms/BWB-CMS/cms  
&& git add -- pom.xml cms-ejb/pom.xml cms-web/pom.xml  
stylesheets-jar/pom.xml cms-ear/pom.xml schaduw-ear/pom.xml  
buzacms-ear/pom.xml buzaschaduw-ear/pom.xml config-web/pom.xml

[INFO] Working directory: /home/willem/var/sdu/bwb-cms/BWB-CMS/cms
[INFO] Executing: /bin/sh -c cd /home/willem/var/sdu/bwb-cms/BWB-CMS/cms  
&& git status --porcelain

[INFO] Working directory: /home/willem/var/sdu/bwb-cms/BWB-CMS/cms
[INFO] Tagging release with the label cms-3.x_TEST...
[INFO] Executing: /bin/sh -c cd /home/willem/var/sdu/bwb-cms/BWB-CMS/cms  
&& git tag -F /tmp/maven-scm-1360697828.commit cms-3.x_TEST

[INFO] Working directory: /home/willem/var/sdu/bwb-cms/BWB-CMS/cms
[INFO] Executing: /bin/sh -c cd /home/willem/var/sdu/bwb-cms/BWB-CMS/cms  
&& git push g...@github.com:SDUUitgevers/BWB-CMS.git cms-3.x_TEST

[INFO] Working directory: /home/willem/var/sdu/bwb-cms/BWB-CMS/cms
[INFO] Executing: /bin/sh -c cd /home/willem/var/sdu/bwb-cms/BWB-CMS/cms  
&& git ls-files

[INFO] Working directory: /home/willem/var/sdu/bwb-cms/BWB-CMS/cms

I expect a commit after the git add statement, and a push before the tag  
statement.


the plugin part in my pom:

 
org.apache.maven.plugins
maven-release-plugin
 2.4
 
true
 
 


Since the deployed versions are a dependency for another project, I  
cannot release this other project, because it cannot have a SNAPSHOT  
dependency of course...


Any tips on how to solve this are greatly appreciated...


thanks,

Willem Voogd


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Unpacking jars into target/classes

[Joachim Durchholz]

Am 07.03.2013 13:55, schrieb Stephen Connolly:

BUT if you are doing something that is crazy and stupid


Yeah okay, I stopped reading at that allegation.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Unpacking jars into target/classes

[Ron Wheeler]

The trick is not to stop reading it but to stop doing it.

You are getting advice from one of principle architects and authors of 
Maven.


What would you consider to be "expert advice" that you should follow?
Bear in mind that God is busy this week appointing a Pope!

Ron

On 07/03/2013 1:48 PM, Joachim Durchholz wrote:

Am 07.03.2013 13:55, schrieb Stephen Connolly:

BUT if you are doing something that is crazy and stupid


Yeah okay, I stopped reading at that allegation.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Unpacking jars into target/classes

[Stephen Connolly]

On Thursday, 7 March 2013, Joachim Durchholz wrote:

> Am 07.03.2013 13:55, schrieb Stephen Connolly:
>
>> BUT if you are doing something that is crazy and stupid
>>
>
> Yeah okay, I stopped reading at that allegation.


Think of it as

"BUT if one is doing..."

Keep in mind that the mailing list is a public archive, so sometimes we say
things with a wording designed to benefit future readers, one should not
take them quite so personally. 95% of the time "you" actually should be
read as "one" and then it makes more sense... But as it sounds more like
something a sovereign might say when addressing their subjects, we use the
informal "you"


>
> --**--**-
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: git release:prepare does not commit the poms (Linux)

[Mark Derricutt]

The 2.4 git problems are related to the release plugin ignoring local 
checkout/disabling push settings primarily, so that your release is 
tagged locally, but then MRP tries to clone the tag from upstream and fails.


Either way, dropping back to 2.3.2 to eliminate those issues would be a 
good point of call.


One thing I've also noticed that sounds familiar, make sure you don't 
have a release.properties in your working directory prior to a new 
release - sometimes I've noticed it gets left behind somehow and 
depending on whats in that file, MRP will "resume the release" from a 
point where it thinks your version number has already been updated - and 
thus releases/deploys a -SNAPSHOT to your release repo.


Mark


Robert Scholte wrote:

could you try to use maven-release-plugin 2.3.2?
There are some known issues with GIT and the maven-release-plugin 2.4, 
which need to be fixed in the SCM project first. 


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

error in unit test

[Alejandro . Endo]

I have a problem where my maven plugin's unit tests fail ONLY when i run
them in jenkins. When i run `mvn test` locally everything passes fine

The error i get is

Tests in error:
  testGetMyModules(com.example.AnalyzerTest): (class:
org/apache/maven/project/MavenProject, method:
getSnapshotArtifactRepository signature:
()Lorg/apache/maven/artifact/repository/ArtifactRepository;) Incompatible
argument to function

Does anyone know what this is related to?

Thank you,


Alejandro
DISCLAIMER:

Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.

Thank You.

Re: error in unit test

[Baptiste MATHUS]

Hi,
This is more a question for jenkins users ml.
I suppose you're using a Maven native type of job. Does it produce the same
error with a freestyle job&Maven step?

And also check you're using the same Maven version locally and in jenkins.
But from your logs, I don't think it's related.

Cheers
Le 7 mars 2013 21:25,  a écrit :

>
>
> I have a problem where my maven plugin's unit tests fail ONLY when i run
> them in jenkins. When i run `mvn test` locally everything passes fine
>
> The error i get is
>
> Tests in error:
>   testGetMyModules(com.example.AnalyzerTest): (class:
> org/apache/maven/project/MavenProject, method:
> getSnapshotArtifactRepository signature:
> ()Lorg/apache/maven/artifact/repository/ArtifactRepository;) Incompatible
> argument to function
>
> Does anyone know what this is related to?
>
> Thank you,
>
>
> Alejandro
> DISCLAIMER:
>
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
>
> Thank You.
>
>

Re: Unpacking jars into target/classes

[Joachim Durchholz]

Am 07.03.2013 19:53, schrieb Ron Wheeler:

The trick is not to stop reading it but to stop doing it.


Nope. The trick is to ignore abuse.


You are getting advice from one of principle architects and authors of
Maven.


No advice, just evangelizing and allegations that I'm an idiot.


What would you consider to be "expert advice" that you should follow?
Bear in mind that God is busy this week appointing a Pope!


So you're considering yourself Popes of the Church of Maven?
And you're taking that as an excuse to insult intelligent people, and to 
place yourself above them?


There is little polite I can say about that kind of stance.
And it's really, really, really best to leave it at that. This post 
required several rewrites, with gritted teeth, just to keep it barely civil.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Unpacking jars into target/classes

[Joachim Durchholz]

So no apology and you feel entirely justified.
With the argument that you're not talking to me but to posteriority. Now 
it seems that your perceptions of future readers are more important than 
anything I have to say; I'll keep that in mind.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Unpacking jars into target/classes

[Stephen Connolly]

Well if the thing that one is doing is neither crazy nor stupid  =>  others
will need to do it => should be turned into a plugin

If the thing one is doing is crazy but not stupid => others may want to do
it => should be turned into a plugin

If the thing one is doing is not crazy but is stupid  => others will want
to do it => should be turned into a plugin

If the thing one is doing is both crazy and stupid => nobody else will have
a need to do it => waste of time turning it into a plugin => use antrun or
equivalent

Crazy and stupid are not insults in this context...

Eg. Crazy can actually be the smart thing... An ex-coworker of mine is
working for a company where they write MySQL database tables raw without
using MySQL at all... How else can they take the routing info from a
network switch and capture it all... That is crazy... You wouldn't want to
do that without good reason... They have good reason

Eg. Stupid can actually be the pragmatic thing... I know people who deploy
into production by pushing to the DR instance and then they "pull the power
cord" on the live nodes... That's stupid... But it gives them confidence if
their HA

The type of things that I was referring to we're the ones where you tell an
ex-coworker what you do and they say "that's crazy" or "that's stupid" and
then you get to say "you'd think so, ordinarily you'd be right, *but* in
this very specific instance..."

I think you are taking this thread far too personally

-Stephen

On Thursday, 7 March 2013, Joachim Durchholz wrote:

> So no apology and you feel entirely justified.
> With the argument that you're not talking to me but to posteriority. Now
> it seems that your perceptions of future readers are more important than
> anything I have to say; I'll keep that in mind.
>
> --**--**-
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

[ANN] Maven Changes Plugin 2.9 Released

[Benson Margulies]

The Apache Maven team is pleased to announce the release of the Maven
Changes Plugin, version 2.9.


The changes plugin Creates a release history for inclusion into the
site and assists in generating an announcement mail.

http://maven.apache.org/plugins/maven-changes-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-changes-plugin
  2.9


Release Notes - Maven 2.x Changes Plugin - Version 2.9


Release Notes - Maven 2.x Changes Plugin - Version 2.9



** Bug
* [MCHANGES-276] - TracDownloader does not set issue key to ticket id
* [MCHANGES-293] - XML Parser error backtraces from, presumably,
malformed JIRA responses
* [MCHANGES-299] - ClassNotFoundException when running jira-report
using Maven 2.2.1
* [MCHANGES-301] - Impossible to use ParameterBasedQuery in
combination with JIRA authentication
* [MCHANGES-302] - The REST API is always used when JIRA
authentication is configured



** Improvement
* [MCHANGES-46] - There is no link to the RSS feed of changes in
the changes report
* [MCHANGES-278] - Improved logging and exception messages to aid
troubleshooting
* [MCHANGES-289] - Please add support for HTTP digest
authentication to the 'trac-report' plugin.
* [MCHANGES-290] - Provide GitHub support for generate announcement report
* [MCHANGES-295] - Remove need for numeric component ID's etc when
using REST with JIRA

** New Feature
* [MCHANGES-300] - Make it possible to run the changes-check and
changes-validate goals only once for a multi-module project


Enjoy,

-The Apache Maven team

Re: Unpacking jars into target/classes

[Joachim Durchholz]

Am 07.03.2013 22:41, schrieb Stephen Connolly:

Crazy and stupid are not insults in this context...


So if I call Ron a clown, and when he's considering that an insult, I 
explain to him that that's a very respectable thing to be?



I think you are taking this thread far too personally


On the other hand, I don't think you're in a position to decide that.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Unpacking jars into target/classes

[Stephen Connolly]

On Thursday, 7 March 2013, Joachim Durchholz wrote:

> Am 07.03.2013 22:41, schrieb Stephen Connolly:
>
>> Crazy and stupid are not insults in this context...
>>
>
> So if I call Ron a clown, and when he's considering that an insult, I
> explain to him that that's a very respectable thing to be?


People can take offence at the strangest of things.

The biggest fallacy is the "do onto others as you would have them do onto
you" mentality... It makes a lot of assumptions of others... And we all
know when we assume we make an ass of u and me.

If people want to take offence at something others say without malice, that
us life, we try to learn from it and adapt our internal models... But
sometimes it just doesn't fit.


>
>  I think you are taking this thread far too personally
>>
>
> On the other hand, I don't think you're in a position to decide that.


You are entitled to your opinion as much as I am entitled to mine. Agree to
differ and let's move on.


>
> --**--**-
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Release:perform failing on git ...

[Benson Margulies]

release plugin 2.3.2

prepare does fine.

perform fails with:

[INFO] --- maven-release-plugin:2.3.2:perform (default-cli) @
find-jug-dist-dir-maven-plugin ---
[INFO] Checking out the project to perform the release ...
[INFO] Executing: /bin/sh -c cd
/Users/benson/x/find-jug-dist-dir-maven-plugin/target && git clone --branch
find-jug-dist-dir-maven-plugin-1
g...@github.com:basis-technology-corp/find-jug-dist-dir-maven-plugin.git
/Users/benson/x/find-jug-dist-dir-maven-plugin/target/checkout
[INFO] Working directory:
/Users/benson/x/find-jug-dist-dir-maven-plugin/target
[ERROR] The git-clone command failed.

scm looks like:


  scm:git:g...@github.com:
basis-technology-corp/find-jug-dist-dir-maven-plugin.git
  scm:git:g...@github.com:
basis-technology-corp/find-jug-dist-dir-maven-plugin.git
  
https://github.com/basis-technology-corp/find-jug-dist-dir-maven-plugin

  HEAD

RE: Release:perform failing on git ...

[Tim Wu T]

I think it should better for you to provide more stacktrace.

[ERROR] The git-clone command failed. This message is too limited to find the 
root cause.

Br,
Tim
-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com] 
Sent: Friday, March 08, 2013 9:47 AM
To: Maven Users List
Subject: Release:perform failing on git ...

release plugin 2.3.2

prepare does fine.

perform fails with:

[INFO] --- maven-release-plugin:2.3.2:perform (default-cli) @
find-jug-dist-dir-maven-plugin ---
[INFO] Checking out the project to perform the release ...
[INFO] Executing: /bin/sh -c cd
/Users/benson/x/find-jug-dist-dir-maven-plugin/target && git clone --branch
find-jug-dist-dir-maven-plugin-1
g...@github.com:basis-technology-corp/find-jug-dist-dir-maven-plugin.git
/Users/benson/x/find-jug-dist-dir-maven-plugin/target/checkout
[INFO] Working directory:
/Users/benson/x/find-jug-dist-dir-maven-plugin/target
[ERROR] The git-clone command failed.

scm looks like:


  scm:git:g...@github.com:
basis-technology-corp/find-jug-dist-dir-maven-plugin.git
  scm:git:g...@github.com:
basis-technology-corp/find-jug-dist-dir-maven-plugin.git
  
https://github.com/basis-technology-corp/find-jug-dist-dir-maven-plugin

  HEAD


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Release:perform failing on git ...

[Benson Margulies]

Actually, I know what's happening.

To talk to this repo, I need to use a custom ssh key.

At command level, I use a shell script:

git clone --config ssh.key=/users/benson/.ssh/id_basis_rsa "$@"

THe question is, how do I get the m-r-p to do this?


On Thu, Mar 7, 2013 at 8:49 PM, Tim Wu T  wrote:

> I think it should better for you to provide more stacktrace.
>
> [ERROR] The git-clone command failed. This message is too limited to find
> the root cause.
>
> Br,
> Tim
> -Original Message-
> From: Benson Margulies [mailto:bimargul...@gmail.com]
> Sent: Friday, March 08, 2013 9:47 AM
> To: Maven Users List
> Subject: Release:perform failing on git ...
>
> release plugin 2.3.2
>
> prepare does fine.
>
> perform fails with:
>
> [INFO] --- maven-release-plugin:2.3.2:perform (default-cli) @
> find-jug-dist-dir-maven-plugin ---
> [INFO] Checking out the project to perform the release ...
> [INFO] Executing: /bin/sh -c cd
> /Users/benson/x/find-jug-dist-dir-maven-plugin/target && git clone --branch
> find-jug-dist-dir-maven-plugin-1
> g...@github.com:basis-technology-corp/find-jug-dist-dir-maven-plugin.git
> /Users/benson/x/find-jug-dist-dir-maven-plugin/target/checkout
> [INFO] Working directory:
> /Users/benson/x/find-jug-dist-dir-maven-plugin/target
> [ERROR] The git-clone command failed.
>
> scm looks like:
>
> 
>   scm:git:g...@github.com:
> basis-technology-corp/find-jug-dist-dir-maven-plugin.git
>   scm:git:g...@github.com:
>
> basis-technology-corp/find-jug-dist-dir-maven-plugin.git
>   
> https://github.com/basis-technology-corp/find-jug-dist-dir-maven-plugin
> 
>   HEAD
> 
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

RE: Release:perform failing on git ...

[Tim Wu T]

At Jenkins maven release plugin:

There is an option called: Configure M2 Extra Build Steps

You can config your pre steps.

Br,
Tim



-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com] 
Sent: Friday, March 08, 2013 9:53 AM
To: Maven Users List
Subject: Re: Release:perform failing on git ...

Actually, I know what's happening.

To talk to this repo, I need to use a custom ssh key.

At command level, I use a shell script:

git clone --config ssh.key=/users/benson/.ssh/id_basis_rsa "$@"

THe question is, how do I get the m-r-p to do this?


On Thu, Mar 7, 2013 at 8:49 PM, Tim Wu T  wrote:

> I think it should better for you to provide more stacktrace.
>
> [ERROR] The git-clone command failed. This message is too limited to find
> the root cause.
>
> Br,
> Tim
> -Original Message-
> From: Benson Margulies [mailto:bimargul...@gmail.com]
> Sent: Friday, March 08, 2013 9:47 AM
> To: Maven Users List
> Subject: Release:perform failing on git ...
>
> release plugin 2.3.2
>
> prepare does fine.
>
> perform fails with:
>
> [INFO] --- maven-release-plugin:2.3.2:perform (default-cli) @
> find-jug-dist-dir-maven-plugin ---
> [INFO] Checking out the project to perform the release ...
> [INFO] Executing: /bin/sh -c cd
> /Users/benson/x/find-jug-dist-dir-maven-plugin/target && git clone --branch
> find-jug-dist-dir-maven-plugin-1
> g...@github.com:basis-technology-corp/find-jug-dist-dir-maven-plugin.git
> /Users/benson/x/find-jug-dist-dir-maven-plugin/target/checkout
> [INFO] Working directory:
> /Users/benson/x/find-jug-dist-dir-maven-plugin/target
> [ERROR] The git-clone command failed.
>
> scm looks like:
>
> 
>   scm:git:g...@github.com:
> basis-technology-corp/find-jug-dist-dir-maven-plugin.git
>   scm:git:g...@github.com:
>
> basis-technology-corp/find-jug-dist-dir-maven-plugin.git
>   
> https://github.com/basis-technology-corp/find-jug-dist-dir-maven-plugin
> 
>   HEAD
> 
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Unpacking jars into target/classes

[Ron Wheeler]

I am not one of the experts, I am only a user of the software trying to 
tell you how we use it and trying to assure you that it works.


I was just trying to point out to you in a light-hearted way that you 
are getting the highest level of expertise available.



Everyone is being polite and respectful
You are getting advice and not abuse.
The fact that you do not like the advice and consider it abusive that 
you keep getting told that your approach is fraught with problems, does 
not make it abuse..


Ron

On 07/03/2013 4:24 PM, Joachim Durchholz wrote:

Am 07.03.2013 19:53, schrieb Ron Wheeler:

The trick is not to stop reading it but to stop doing it.


Nope. The trick is to ignore abuse.


You are getting advice from one of principle architects and authors of
Maven.


No advice, just evangelizing and allegations that I'm an idiot.


What would you consider to be "expert advice" that you should follow?
Bear in mind that God is busy this week appointing a Pope!


So you're considering yourself Popes of the Church of Maven?
And you're taking that as an excuse to insult intelligent people, and 
to place yourself above them?


There is little polite I can say about that kind of stance.
And it's really, really, really best to leave it at that. This post 
required several rewrites, with gritted teeth, just to keep it barely 
civil.


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Unpacking jars into target/classes

[Ron Wheeler]

On 07/03/2013 6:53 PM, Stephen Connolly wrote:

On Thursday, 7 March 2013, Joachim Durchholz wrote:


Am 07.03.2013 22:41, schrieb Stephen Connolly:


Crazy and stupid are not insults in this context...


So if I call Ron a clown, and when he's considering that an insult, I
explain to him that that's a very respectable thing to be?


I have a pretty thick skin and I would be somewhat comforted by the fact 
that my Maven setup works smooth as silk.


We are only trying to help you and I have written a lot of text trying 
to give you confidence that it can work for you by giving examples of 
the kinds of projects that we build under Maven.


Stephen has given you the very best advice in great detail.

I am not sure what you expect us to say.
By your own experience, your approach doesn't work; you won't try to do 
it the right way; you call people names who are trying to help you.


You may not have noticed but no one in the forum is jumping in to take 
your side.


Ron



People can take offence at the strangest of things.

The biggest fallacy is the "do onto others as you would have them do onto
you" mentality... It makes a lot of assumptions of others... And we all
know when we assume we make an ass of u and me.

If people want to take offence at something others say without malice, that
us life, we try to learn from it and adapt our internal models... But
sometimes it just doesn't fit.



  I think you are taking this thread far too personally
On the other hand, I don't think you're in a position to decide that.


You are entitled to your opinion as much as I am entitled to mine. Agree to
differ and let's move on.



--**--**-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Re: Release:perform failing on git ...

[Mirko Friedenhagen]

Hello Benson,

when this repository is on a host of it's own adding an entry to ssh-config
may help (http://linux.die.net/man/5/ssh_config) .

Regards Mirko
-- 
Sent from my mobile
On Mar 8, 2013 2:53 AM, "Benson Margulies"  wrote:

> Actually, I know what's happening.
>
> To talk to this repo, I need to use a custom ssh key.
>
> At command level, I use a shell script:
>
> git clone --config ssh.key=/users/benson/.ssh/id_basis_rsa "$@"
>
> THe question is, how do I get the m-r-p to do this?
>
>
> On Thu, Mar 7, 2013 at 8:49 PM, Tim Wu T  wrote:
>
> > I think it should better for you to provide more stacktrace.
> >
> > [ERROR] The git-clone command failed. This message is too limited to find
> > the root cause.
> >
> > Br,
> > Tim
> > -Original Message-
> > From: Benson Margulies [mailto:bimargul...@gmail.com]
> > Sent: Friday, March 08, 2013 9:47 AM
> > To: Maven Users List
> > Subject: Release:perform failing on git ...
> >
> > release plugin 2.3.2
> >
> > prepare does fine.
> >
> > perform fails with:
> >
> > [INFO] --- maven-release-plugin:2.3.2:perform (default-cli) @
> > find-jug-dist-dir-maven-plugin ---
> > [INFO] Checking out the project to perform the release ...
> > [INFO] Executing: /bin/sh -c cd
> > /Users/benson/x/find-jug-dist-dir-maven-plugin/target && git clone
> --branch
> > find-jug-dist-dir-maven-plugin-1
> > g...@github.com:basis-technology-corp/find-jug-dist-dir-maven-plugin.git
> > /Users/benson/x/find-jug-dist-dir-maven-plugin/target/checkout
> > [INFO] Working directory:
> > /Users/benson/x/find-jug-dist-dir-maven-plugin/target
> > [ERROR] The git-clone command failed.
> >
> > scm looks like:
> >
> > 
> >   scm:git:g...@github.com:
> > basis-technology-corp/find-jug-dist-dir-maven-plugin.git
> >   scm:git:g...@github.com:
> >
> >
> basis-technology-corp/find-jug-dist-dir-maven-plugin.git
> >   
> > https://github.com/basis-technology-corp/find-jug-dist-dir-maven-plugin
> > 
> >   HEAD
> > 
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >
>

Re: Unpacking jars into target/classes

[Joachim Durchholz]

Am 08.03.2013 04:48, schrieb Ron Wheeler:

I am not sure what you expect us to say.


Simply stick with the question at hand and don't waste everybody's time 
with evangelizing and philosophy.



By your own experience, your approach doesn't work; you won't try to do
it the right way;


If there's no way to get it to work (and that's the answer I got from 
Baptiste), then it's not me who's doing it wrong.


Matthew mentioned install-file, but I already explained why a Maven repo 
is not an option.


> you call people names who are trying to help you.

You may think you're trying to help, but repeating advice that can't be 
followed isn't.



You may not have noticed but no one in the forum is jumping in to take
your side.


Self-selected group.
Plus, many people shy controversy.
Plus, nothing new for the regulars.

I'd get the same kind of (non-)reaction in a Fortran group, for the same 
reasons, so that observation doesn't prove a thing.


And I think that's enough of off-topic discussion for this thread.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org