On 07.02.18 00:28, Gilles wrote:
> Having no idea on how to achieve it, I'd wish that creating
> the "full dist" only requires a custom "goal" like (?)
> $ mvn package:dist
> with no ad-hoc directory/module: all modules specified in the
> top POM would have their artefacts (recursively) bundled in
> On Feb 18, 2018, at 5:11 AM, Thomas Vandahl wrote:
>
>> On 07.02.18 00:28, Gilles wrote:
>> Having no idea on how to achieve it, I'd wish that creating
>> the "full dist" only requires a custom "goal" like (?)
>> $ mvn package:dist
>> with no ad-hoc directory/module: all modules specified in
On 18.02.18 14:20, Rob Tompkins wrote:
> Not quite because our release process isn’t precisely the same as what maven
> does. Hence, our release plugin strives to be a shim for our site and
> distribution files. But yes, I agree that “mvn deploy” should essentially do
> everything you need.
Do
On 18 February 2018 at 13:46, Thomas Vandahl wrote:
> On 18.02.18 14:20, Rob Tompkins wrote:
>> Not quite because our release process isn’t precisely the same as what maven
>> does. Hence, our release plugin strives to be a shim for our site and
>> distribution files. But yes, I agree that “mvn
On Sun, 18 Feb 2018 14:46:03 +0100, Thomas Vandahl wrote:
On 18.02.18 14:20, Rob Tompkins wrote:
Not quite because our release process isn’t precisely the same as
what maven does. Hence, our release plugin strives to be a shim for
our site and distribution files. But yes, I agree that “mvn depl
On Sun, 18 Feb 2018 13:50:26 +, sebb wrote:
On 18 February 2018 at 13:46, Thomas Vandahl wrote:
On 18.02.18 14:20, Rob Tompkins wrote:
Not quite because our release process isn’t precisely the same as
what maven does. Hence, our release plugin strives to be a shim for
our site and distrib
On 18 February 2018 at 14:03, Gilles wrote:
> On Sun, 18 Feb 2018 13:50:26 +, sebb wrote:
>>
>> On 18 February 2018 at 13:46, Thomas Vandahl wrote:
>>>
>>> On 18.02.18 14:20, Rob Tompkins wrote:
Not quite because our release process isn’t precisely the same as what
maven does.
On Sat, Feb 17, 2018 at 11:09 AM, Otto Fowler
wrote:
> Thanks! Please assign VFS-614, VFS-398, LANG-1373 to me.
>
> I am familiar with the differences between a contributor or a committer
> both in the foundation and jira.
> I would like _contributor_ rights, not commit rights.
>
I do not see yo
Hi All,
Our HTTP provider org.apache.commons.vfs2.provider.http still uses Apache
HttpClient 3.1.
Some of these classes surface the HttpClient class from 3.1 in APIs marked
public.
Looking forward to HttpClient 4 and 5-Alpha/Beta, I wonder how to move
forward.
We could:
- Create a new package
Hello,
for my accidential commit I opeend a Infra Task (since I canot rename the
branches)
https://issues.apache.org/jira/browse/INFRA-16054
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Bernd Eckenfels
Gesendet: Freitag, 16. Februar 2018 03:08
An: Commons Developers List
Betreff: Re: [VFS]
If we want to do a minor update (2.3) we should not introduce new Major
dependencies (unless optional), so having a http4 package and an optional
dependency on http3+http4 sounds like the better solution.
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Gary Gregory
Gesendet: Sonntag, 18. Febru
On Sun, Feb 18, 2018 at 1:28 PM, Bernd Eckenfels
wrote:
> If we want to do a minor update (2.3) we should not introduce new Major
> dependencies (unless optional), so having a http4 package and an optional
> dependency on http3+http4 sounds like the better solution.
>
I am more concerned about n
On Sun, Feb 18, 2018 at 1:34 PM, Gary Gregory
wrote:
> On Sun, Feb 18, 2018 at 1:28 PM, Bernd Eckenfels
> wrote:
>
>> If we want to do a minor update (2.3) we should not introduce new Major
>> dependencies (unless optional), so having a http4 package and an optional
>> dependency on http3+http4
On Sat, 17 Feb 2018 22:30:38 +0300, Alexander Nozik wrote:
On 17.02.2018 21:16, Gilles wrote:
I have a problem with the CM "Field".
Did you have a look at my comments to issue MATH-1448 (and related
code)?
Unfortunately, I don't have the time right now to go further with
that work; but I'm more
We've even talked about adding Scala libraries in the past and there was
support, so I'd imagine Kotlin is fine as well. It may be worth including
as its own module mainly due to the Kotlin dependency, though the domain
itself helps raise it to that level as it is.
On 18 February 2018 at 18:02, Gi
On 17 February 2018 at 12:09, Otto Fowler wrote:
> I am familiar with the differences between a contributor or a committer
> both in the foundation and jira.
> I would like _contributor_ rights, not commit rights.
>
In what context? You already have commit rights if you're a committer on
any oth
16 matches
Mail list logo
