I don't see why it couldn't. I don't think OSX images are publicly
accessible in Docker Hub though, and if not we'd need a Mac as the
base machine to run the build. From the base machine we should be
able to call docker using the Maven exec plugin, use docker to pull in
the desired linux arch hos
There is a docker Maven plugin:
io.fabric8
docker-maven-plugin
0.33.0
Gary
On Sat, Jul 25, 2020, 00:20 Geoffrey Blake
wrote:
> Docker would be great. Next question, can that be integrated into
> Maven for automating these releases that someone k
On Fri, Jul 24, 2020 at 8:04 PM Alex Remily wrote:
> I'd recommend using MinGW. I installed it through brew on my Mac and cross
> compiled the windows build with little difficulty. I expect a similar
> experience on Linux. The MinGW install contains all the necessary windows
> headers.
>
Yep,
The Apache Commons Team announces the release of Apache Commons Text 1.9.
This document contains the release notes for the 1.9 version of Apache
Commons Text.
Commons Text is a set of utility functions and reusable components for the
purpose of processing
and manipulating text that should be of us
Applause
-Rob
> On Jul 25, 2020, at 10:59 AM, Gary Gregory wrote:
>
> The Apache Commons Team announces the release of Apache Commons Text 1.9.
>
> This document contains the release notes for the 1.9 version of Apache
> Commons Text.
> Commons Text is a set of utility functions and reusable
Hello.
Le ven. 24 juil. 2020 à 17:45, Stefan Bodewig a écrit :
>
> This is an attempt at answering something raised be Gilles in a
> different thread. I'm afraid it is getting longer than I
> intended. Something seems to need to get out. Sorry.
>
> On 2020-07-23, Gilles Sadowski wrote:
>
> > I mi
They’re not the same class and that’s the problem. It’s similar to loading
two versions of the same library in OSGi and allowing the two classes to
get mixed up somehow (fun errors like Foo is not type Foo), typically a bug.
On Fri, Jul 24, 2020 at 11:30 Gilles Sadowski wrote:
> Le ven. 24 juil.
GitHub is basically our interactive pull request interface. If we didn’t
have that, I bet we’d be running GitLab ourselves or similar.
Also, being that the bar to be a committer here is fairly low, getting
access to gitbox directly isn’t too difficult.
On Fri, Jul 24, 2020 at 12:17 Xeno Amess wr
Hello.
In the thread[1] from which the below quote is extracted:
> Would you be willing to provide a PR that deprecates the relevant APIs and
> points to their equivalent in RNG? It will be more cruft we can trim for
> 4.0, whenever that happens.
Gary mentions that copy/paste is a "coding horror".
>
> They’re not the same class and that’s the problem. It’s similar to loading
> two versions of the same library in OSGi
Let's say you are dealing with
org.vafer.Foo
the library relocates this as
org.apache.commons.compress.internal.org.vafer.Foo
The library only deals with
org.apache
> On 25 Jul 2020, at 19:25, Gilles Sadowski wrote:
>
> Hello.
>
> In the thread[1] from which the below quote is extracted:
>> Would you be willing to provide a PR that deprecates the relevant APIs and
>> points to their equivalent in RNG? It will be more cruft we can trim for
>> 4.0, whenever
It will only cause problems if this is registered as a service/spi/driver like
XML, Crypto, JDBC, Authentication and so on. For internal libraries functions
which don't have such global state it's fine.
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: Torsten Cur
How does this work with sealed jars?
Gary
On Sat, Jul 25, 2020, 15:57 Bernd Eckenfels wrote:
> It will only cause problems if this is registered as a service/spi/driver
> like XML, Crypto, JDBC, Authentication and so on. For internal libraries
> functions which don't have such global state it's
When you copy/shade classes then there is no sealing metadata copied, so unless
the code verifies how it is packaged, it will not know that it isn't sealed
anymore (or to a different package).
But I guess it doesn't matter, there are many libraries which can be shaded and
many which can't, for
Exactly. It’s not a general problem, but one specific to various legacy
APIs still commonly used.
On Sat, Jul 25, 2020 at 14:56 Bernd Eckenfels
wrote:
> It will only cause problems if this is registered as a service/spi/driver
> like XML, Crypto, JDBC, Authentication and so on. For internal libr
Hi.
2020-07-25 21:03 UTC+02:00, Alex Herbert :
>
>
>> On 25 Jul 2020, at 19:25, Gilles Sadowski wrote:
>>
>> Hello.
>>
>> In the thread[1] from which the below quote is extracted:
>>> Would you be willing to provide a PR that deprecates the relevant APIs
>>> and
>>> points to their equivalent in
> On Jul 25, 2020, at 5:28 PM, Matt Sicker wrote:
>
> Exactly. It’s not a general problem, but one specific to various legacy
> APIs still commonly used.
+1
>
>> On Sat, Jul 25, 2020 at 14:56 Bernd Eckenfels
>> wrote:
>>
>> It will only cause problems if this is registered as a service/s
>GitHub is basically our interactive pull request interface. If we didn’t
have that, I bet we’d be running GitLab ourselves or similar.
Yes, that is what I think gitbox lacks.
Cannot imagine a git-based website having no convenient pr system...
>Also, being that the bar to be a committer here is
18 matches
Mail list logo
