+1
Solves everyone's concerns and is a nice solution.
On Feb 9, 2015, at 3:31 PM, Igor Fedorenko wrote:
> Well, calling mvn from mvnDebug/mvnyjp was an excellent idea, I wish I
> thought of it myself.
>
> https://git1-us-west.apache.org/repos/asf?p=maven.git;a=commit;h=7c7bf4dfef1b465196233bf3
Well, calling mvn from mvnDebug/mvnyjp was an excellent idea, I wish I
thought of it myself.
https://git1-us-west.apache.org/repos/asf?p=maven.git;a=commit;h=7c7bf4dfef1b465196233bf35e520fdde4fd5b49
--
Regards,
Igor
On 2015-02-08 10:11, Bernd Eckenfels wrote:
Am Sun, 08 Feb 2015 07:57:03 -050
Yes, I agree not supporting this feature on windows is not desirable,
but I don't know enough about windows scripting to implement this myself
and until somebody helps with the implementation we won't support this
feature on windows.
--
Regards,
Igor
On 2015-02-08 9:44, Arnaud Héritier wrote:
A
Am Sun, 08 Feb 2015 07:57:03 -0500
schrieb Igor Fedorenko :
> What if there was single "real" mvn script and mvnDebug/mvnyjp were
> just symlinks pointing back to it? The script will behave differently
> based on the script name. Any objections to this plan?
I am all for having only one script. T
And what about our dear windows users ?
Don't forget that they are very numerous.
Sadly Linux shell is many many far more powerful than windows .bat files
and often we have to reduce features to keep the compatibility with windows.
I wouldn't like to have different features for linux and for window
I think that also works. But I think the script not being executable it makes
it clear it's not a script. Whatever we decide I'm again filtering it, just
makes debugging painful.
On Feb 8, 2015, at 7:57 AM, Igor Fedorenko wrote:
> I think maintenance overhead and code duplication concerns outw
I think maintenance overhead and code duplication concerns outweigh
possible confusion an extra file might cause, but I think I have a
better solution.
What if there was single "real" mvn script and mvnDebug/mvnyjp were just
symlinks pointing back to it? The script will behave differently based
o
Igor, Jason,
my concern is not about having shared scripting. If that works, that'll be
great.
But from a user perspective I'd like to have a clean bin-folder. Only have
useful scripts here.
So my idea would be: when generating the distribution, just merge these
files to the ones we now hav
Robert,
Can you explain your concerns? I believe it is a common practice to use
separate "include" file to keep logic shared by multiple scripts, why do
you think we need do it differently?
--
Regards,
Igor
On 2015-02-07 4:24, Robert Scholte wrote:
Igor,
how about generating these scripts?
I'
On Feb 7, 2015, at 4:24 AM, Robert Scholte wrote:
> Igor,
>
> how about generating these scripts?
I don't think generating them is a good idea. Primarily because it makes it far
more difficult for anyone to patch the script and try. If someone has to run a
build to generate a script to test
Igor,
how about generating these scripts?
I'd prefer to have only useful scripts for the users in the bin directory.
IIUC the mvn-common.sh is just used by all other scripts and shouldn't be
called by users.
So instead I'd like to see the other scripts being generated, all
including this comm
11 matches
Mail list logo