+1
Regards,
Hervé
Le dimanche 24 janvier 2016 20:26:22 Karl Heinz Marbaise a écrit :
> Hi,
>
> We solved 16 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317020&ve
> rsion=12330202
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/j
in short: if you prefer the parse method with ParseRequest, I'm ok
in more details:
IMHO, the Parser interface tell what we want it to tell: yes, currently it was
done as there is no state, and while adding this emitComment property, I
changed it to be stateful.
I'm not convinced that making the
Already figured out the problem with Arnaud. The test must have profiles,
since (only?) MacOS6 has a classes.jar instead of tools.jar
MSHADE-182 already described that in its example, the IT was simplified a
bit too much.
thanks,
Robert
Op Tue, 26 Jan 2016 21:57:54 +0100 schreef Benson Margu
If it is a per-file setting, then I think this approach is wrong (even if
it is a singleton or not).
The Parser interface only tells us what kind of parser it is ( text, xml
or unknown ) and it has the parse-method (ignoring the LogEnabled
interface :) ).
So only if you can say that for i
GitHub user flavioarcega opened a pull request:
https://github.com/apache/maven-wagon/pull/22
Implementation for Secure FTP (FTPS protocol)
I'm sharing an implementation that I've been using of the FTPS Protocol
based on the original FtpWagon class with commons-net 3.4
You can merg
Hi,
here is my +1
Kind regards
Karl Heinz
Hi,
We solved 16 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317020&version=12330202
There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/browse/MACR/?selectedTab=com.atlassian.jira.jira-proj
I don’t use the variable myself, I have no way to know who does. But if we
remove it just remove it and don’t replace it with MVN_HOME. To me that’s even
more confusing.
I prefer it not there, but I don’t want to break anyone in a minor version. I
don’t feel that strongly about it. I’ll retract
+1 to simply remove the variable.
That's what I've been doing and advising for years.
Settings M2_HOME only highers the risk to get to weird issues for newcomers
with NoClassDefFoundError where actually M2_HOME points to a different
maven root that the binary in the PATH.
2016-01-27 11:23 GMT+00:
Am 27.01.2016 um 11:02 schrieb Arnaud Héritier:
-1
See https://issues.apache.org/jira/browse/MNG-5607
Ok to introduce MVN_HOME with M2_HOME value as default when defined (and
then remove M2_HOME in Maven 4)
But replacing M2_HOME by MVN_HOME in 3.4 seems to be a risky change for our
ecosystem (IDE
Yes, I agree.
-1
Don’t maven M2_HOME to MVN_HOME during 3.x and for Maven 4.x we can probably
just get rid of the shell variable all together.
> On Jan 27, 2016, at 5:02 AM, Arnaud Héritier wrote:
>
> -1
> See https://issues.apache.org/jira/browse/MNG-5607
> Ok to introduce MVN_HOME with M2_H
-1
See https://issues.apache.org/jira/browse/MNG-5607
Ok to introduce MVN_HOME with M2_HOME value as default when defined (and
then remove M2_HOME in Maven 4)
But replacing M2_HOME by MVN_HOME in 3.4 seems to be a risky change for our
ecosystem (IDE, CI servers, ...) and not only for the local user
11 matches
Mail list logo
