Docker would be great. Next question, can that be integrated into
Maven for automating these releases that someone knows offhand?
-Geoff
On Fri, Jul 24, 2020 at 7:50 PM Alex Remily wrote:
>
> Sounds like a great idea.
>
> On Fri, Jul 24, 2020, 8:29 PM Marcelo Vanzin wrote:
>
> > Is it
Sounds like a great idea.
On Fri, Jul 24, 2020, 8:29 PM Marcelo Vanzin wrote:
> Is it possible to cross-compile from Linux to MacOS?
>
> Even if it isn't, might be a good idea to write a docker image to do
> the other cross-builds; then from a Mac you can build the MacOS binary
> and call
Is it possible to cross-compile from Linux to MacOS?
Even if it isn't, might be a good idea to write a docker image to do
the other cross-builds; then from a Mac you can build the MacOS binary
and call docker to build all the others.
On Fri, Jul 24, 2020 at 5:04 PM Alex Remily wrote:
>
> I'd
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.
On Fri, Jul 24, 2020, 7:16 PM Gary Gregory wrote:
> Thanks
Thanks Geoffrey,
Are you available at some point to do a webex to straighten out my local
set up? Just email me directly so we can coordinate.
Gary
On Fri, Jul 24, 2020 at 4:34 PM Geoffrey Blake
wrote:
> Hi Gary,
>
> windows.h/Windows.h/WINDOWS.H are all names for the same file, on
> Windows
This vote passes with the following +1 votes cast:
- Bruno P. Kinoshita, binding
- Rob Tompkins , binding
- Amey Jadiye, non-binding
- Gary Gregory, binding
Gary
On Fri, Jul 24, 2020 at 9:22 AM Gary Gregory wrote:
> My +1
>
> Gary
>
>
> On Tue, Jul 21, 2020 at 4:56 PM Gary Gregory wrote:
>
On 7/24/20 1:04 AM, Stefan Bodewig wrote:
Hi all
here I'd like to explain why I prefer not to update dependencies just
because we can. Maybe you can convince me that I'm wrong. I've tried to
make this point in different threads but either it has been lost or it
just wasn't worth discussing.
Hi Gary,
windows.h/Windows.h/WINDOWS.H are all names for the same file, on
Windows I've found out, the FS is case-insensitive. This is not true
on a Linux box though. I submitted a new PR to fix this and get
Windows builds working again on a Linux box, as well as testing that
windows artifacts
>
> > - library L1 shades library ShadedA-1.0 and ShadedB-1.1.
> >> - library L2 shades library ShadedA-1.1 and ShadedB-1.0.
> >> - An app wants to use L1, L2, ShadedA-1.1, and ShadedB-1.1 but it can't
> no
> >> matter what classpath ordering it uses.
> >> - An app wants to use L1, L2,
>
> The key phrase is "which would be stupid" which you as a consumer have zero
> control over. People do stupid things all the time.
>
If people use a package that is called "internal" or something - there is
nothing anyone can do.
And really beyond the point.
> > To be more explicit. I am
On 2020-07-24, Xeno Amess wrote:
>> We respectfully discuss and in the end come to a compromise or a common
>> ground where we can agree to disagree. I still see this happen here and
>> don't think all of us need to have the same opinion.
> So maybe at the end some of commons repos using as new
> We respectfully discuss and in the end come to a compromise or a common
ground where we can agree to disagree. I still see this happen here and
don't think all of us need to have the same opinion.
So maybe at the end some of commons repos using as new version of
dependencies as they can,
On 2020-07-23, Olivier Lamy wrote:
> In the Maven project we have plenty of maven-* git repo so we have created
> a dedicated Jenkins plugin (which is used by other TLP such netbeans) which
> scan the gitbox server to get repo based on regular expression or name
> content and create the build
On 2020-07-24, Xeno Amess wrote:
> As for community building, I agree with you that commons seems not a
> close community, but I doubt it be github's fault. even there be no
> github, sub-repos in commons are not that close to each other.
Commons is an old project and it started with a striving
for example...we become even hard to get an agreement on whether to upgrade
dependencies...(sigh)
Atleast on this thing I don't think github is the one to blame...
Xeno Amess 于 2020年7月25日周六 上午1:21写道：
> As for community building, I agree with you that commons seems not a close
> community, but I
As for community building, I agree with you that commons seems not a close
community, but I doubt it be github's fault.
even there be no github, sub-repos in commons are not that close to each
other.
Xeno Amess 于 2020年7月25日周六 上午1:16写道：
> besides, that is JIRA where we can apply patch, but I
besides, that is JIRA where we can apply patch, but I think it SHOULD be
done on gutbox. github, gitlab, all of them have a convienent pr system.
so yes our JIRA is good, I like JIRA.
But for gitbox, I think it really lack lots of things.
Or, there be those things, but not open.
Xeno Amess 于
you know that is really complex and time costing...
especially when we want some trigger invoked like travis-ci.
Stefan Bodewig 于 2020年7月25日周六 上午1:06写道：
> On 2020-07-24, Xeno Amess wrote:
>
> > I will explain why github come to be center, but not apache gitbox.
> > 1.1
> > I have right to
Apologize for being in mood.
So my opinion is if github is the only way people where ANY people can
create pr, then no wonder it will become center gradually.
Gary Gregory 于 2020年7月25日周六 上午12:53写道：
> Xeno,
>
> Your last sentence contains language that is completely inappropriate here.
>
>
On 2020-07-24, Xeno Amess wrote:
> I will explain why github come to be center, but not apache gitbox.
> 1.1
> I have right to register an account on github.
> 1.2
> I registered an account at github.
> 1.3
> I commit then create pr.
> 1.4
> pr get reviewed then merged.
I am fully aware of how
Xeno,
Your last sentence contains language that is completely inappropriate here.
Please take a breath. Any point you are trying to make is most likely to
get lost by your invective.
Gary
On Fri, Jul 24, 2020, 12:40 Xeno Amess wrote:
> I will explain why github come to be center, but not
Le ven. 24 juil. 2020 à 17:39, Gary Gregory a écrit :
>
> On Fri, Jul 24, 2020 at 11:30 AM Rob Tompkins wrote:
>
> >
> >
> > > On Jul 24, 2020, at 9:41 AM, Torsten Curdt wrote:
> > >
> > >>
> > >> You can imagine all manner of jar-hell created by shading. For
> > instance:
> > >>
> > > -
I will explain why github come to be center, but not apache gitbox.
1.1
I have right to register an account on github.
1.2
I registered an account at github.
1.3
I commit then create pr.
1.4
pr get reviewed then merged.
2.1
I have no right to register on apache gitbox.
2.2
I can not register on
Le ven. 24 juil. 2020 à 17:46, Matt Sicker a écrit :
>
> Shading also violates a lot of common ClassLoader assumptions like not
> having multiple copies of the same class in the same visible context (even
> if different packages)
How classes in different packages could be the same class?
Gilles
On Fri, Jul 24, 2020 at 12:00 PM Gary Gregory
wrote:
> On Fri, Jul 24, 2020 at 11:43 AM Rob Tompkins wrote:
>
>>
>>
>> > On Jul 24, 2020, at 11:36 AM, Gary Gregory
>> wrote:
>> >
>> > On Fri, Jul 24, 2020 at 11:30 AM Rob Tompkins
>> wrote:
>> >
>> >>
>> >>
>> >>> On Jul 24, 2020, at 9:41 AM,
> On Jul 24, 2020, at 12:00 PM, Gary Gregory wrote:
>
> On Fri, Jul 24, 2020 at 11:43 AM Rob Tompkins wrote:
>
>>
>>
>>> On Jul 24, 2020, at 11:36 AM, Gary Gregory
>> wrote:
>>>
>>> On Fri, Jul 24, 2020 at 11:30 AM Rob Tompkins
>> wrote:
>>>
> On Jul 24, 2020, at 9:41
On Fri, Jul 24, 2020 at 11:43 AM Rob Tompkins wrote:
>
>
> > On Jul 24, 2020, at 11:36 AM, Gary Gregory
> wrote:
> >
> > On Fri, Jul 24, 2020 at 11:30 AM Rob Tompkins
> wrote:
> >
> >>
> >>
> >>> On Jul 24, 2020, at 9:41 AM, Torsten Curdt wrote:
> >>>
>
> You can imagine all manner
Shading also violates a lot of common ClassLoader assumptions like not
having multiple copies of the same class in the same visible context (even
if different packages) and gets more complex as your types do. I’ve seen
this problem when projects tried to shade Avro or Protobuf. As a downstream
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 missed the turn where this project's PMC decided that we must
> be present on GH
> On Jul 24, 2020, at 11:36 AM, Gary Gregory wrote:
>
> On Fri, Jul 24, 2020 at 11:30 AM Rob Tompkins wrote:
>
>>
>>
>>> On Jul 24, 2020, at 9:41 AM, Torsten Curdt wrote:
>>>
You can imagine all manner of jar-hell created by shading. For
>> instance:
>>> - library L1
On Fri, Jul 24, 2020 at 11:30 AM Rob Tompkins wrote:
>
>
> > On Jul 24, 2020, at 9:41 AM, Torsten Curdt wrote:
> >
> >>
> >> You can imagine all manner of jar-hell created by shading. For
> instance:
> >>
> > - library L1 shades library ShadedA-1.0 and ShadedB-1.1.
> >> - library L2 shades
On Fri, Jul 24, 2020 at 10:50 AM Gilles Sadowski
wrote:
> Hello.
>
> Le ven. 24 juil. 2020 à 14:48, Gary Gregory a
> écrit :
> >
> > On Fri, Jul 24, 2020 at 6:03 AM Gilles Sadowski
> > wrote:
> >
> > > 2020-07-24 11:25 UTC+02:00, Torsten Curdt :
> > > > It still needs a person to decide to
> On Jul 24, 2020, at 9:41 AM, Torsten Curdt wrote:
>
>>
>> You can imagine all manner of jar-hell created by shading. For instance:
>>
> - library L1 shades library ShadedA-1.0 and ShadedB-1.1.
>> - library L2 shades library ShadedA-1.1 and ShadedB-1.0.
>> - An app wants to use L1, L2,
On Fri, Jul 24, 2020 at 10:02 AM Torsten Curdt wrote:
> >
> > You can imagine all manner of jar-hell created by shading. For instance:
> >
> - library L1 shades library ShadedA-1.0 and ShadedB-1.1.
> > - library L2 shades library ShadedA-1.1 and ShadedB-1.0.
> > - An app wants to use L1, L2,
>
> Unless I'm mistaken, there is one drawback to shading: Since
> it creates new classes, there will be less shared code, hence
> one could imagine a potential hit on performance (?).
>
Of course it means some code duplication in the final artifact.
This means slightly bigger artifacts - but
On 2020-07-24, Bernd Eckenfels wrote:
> When it comes to dependencies wie have both problems: if we upgrade
> dependencies to aggressively (or if we don't test with older dependencies)
> then users have the problem that they might not easily be able to upgrade to
> a new commons version since
Pipelines are the text file method of Jenkins jobs. You can store them in
the repo you’re building similar to other CI systems, or you can make a
dedicated repo for holding pipelines, or you can even store the pipeline
script directly in Jenkins (not the best idea, but can be useful during
Hello.
Le ven. 24 juil. 2020 à 14:48, Gary Gregory a écrit :
>
> On Fri, Jul 24, 2020 at 6:03 AM Gilles Sadowski
> wrote:
>
> > 2020-07-24 11:25 UTC+02:00, Torsten Curdt :
> > > It still needs a person to decide to merge a PR for a new version.
> > > So this indeed is just about the dependency
On 2020-07-24, Xeno Amess wrote:
> how about:
> 1. we force versions of dependencies in commons-parent
> 2. we make every commons repo use commons-parent as parent.
> 3. we make sure no other repos forces versions of dependencies; all of the
> versions number shall be inherited from
Hello,
We can certainly put some dependencies in commons parent dependency management
(and the plugins like we used to), but for a lot of stuff I don't think we will
be able to find a common ground, and it will be quite painful if projects no
longer can update commons parent without major
how about:
1. we force versions of dependencies in commons-parent
2. we make every commons repo use commons-parent as parent.
3. we make sure no other repos forces versions of dependencies; all of the
versions number shall be inherited from commons-parent
4. we upgrade versions in commons-parent
Hello,
When it comes to dependencies wie have both problems: if we upgrade
dependencies to aggressively (or if we don't test with older dependencies) then
users have the problem that they might not easily be able to upgrade to a new
commons version since the required new dependency version
>
> You can imagine all manner of jar-hell created by shading. For instance:
>
- library L1 shades library ShadedA-1.0 and ShadedB-1.1.
> - library L2 shades library ShadedA-1.1 and ShadedB-1.0.
> - An app wants to use L1, L2, ShadedA-1.1, and ShadedB-1.1 but it can't no
> matter what classpath
On 2020-07-24, Gary Gregory wrote:
> Now back to our code depending on other dependencies. My view is that there
> are bugs, you just have not hit them. If I find one in a dependency and it
> gets fixed, it's going to mean a new version of that dependency.
This either is "we hit a bug that
My +1
Gary
On Tue, Jul 21, 2020 at 4:56 PM Gary Gregory wrote:
> Hi All,
>
> We have fixed a few bugs and added some enhancements since Apache Commons
> Text 1.8 was released, so I would like to release Apache Commons Text 1.9.
>
> Apache Commons Text 1.9 RC1 is available for review here:
>
Hi All:
I'd like to start here by flipping the story around by looking at what we
do.
Ideally, a PR comes in for a bug with its fix and unit test. This is the
best case scenario. If the PR is green, we squash and merge, and tell
folks, yes, it will be in the next release.
At times, a message
+1 Release this artifact.
build, tests passing well, everything from defaultGoal looks good to me.
the site, hashes look good.
Regards,
Amey
---
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For
On Fri, Jul 24, 2020 at 6:03 AM Gilles Sadowski
wrote:
> 2020-07-24 11:25 UTC+02:00, Torsten Curdt :
> > It still needs a person to decide to merge a PR for a new version.
> > So this indeed is just about the dependency upgrade policies.
> >
> > But isn't that what the version definition is for?
Hi.
2020-07-23 15:59 UTC+02:00, Matt Sicker :
> [...] make every Commons component
> easily buildable in Jenkins [...]
How to do it practically?
Can we create a text file and drop it somewhere, or has
the configuration to be done in GUI ?
Gilles
On 2020-07-24, Torsten Curdt wrote:
> It still needs a person to decide to merge a PR for a new version.
> So this indeed is just about the dependency upgrade policies.
Right.
> But isn't that what the version definition is for?
> I'd argue that 1.12.4 <-> 1.12.6 should be a compatible upgrade
2020-07-24 11:25 UTC+02:00, Torsten Curdt :
> It still needs a person to decide to merge a PR for a new version.
> So this indeed is just about the dependency upgrade policies.
>
> But isn't that what the version definition is for?
Ideally.
In practice, I think that all we can assume is that the
Hi Stefan and all.
2020-07-24 8:35 UTC+02:00, Stefan Bodewig :
> On 2020-07-24, Rob Tompkins wrote:
>
>>> On Jul 23, 2020, at 10:16 PM, Matt Sicker wrote:
>
>>> Also, how different is a bot proposing a dependency update from a human
>>> doing the same? The bot includes far more context about
It still needs a person to decide to merge a PR for a new version.
So this indeed is just about the dependency upgrade policies.
But isn't that what the version definition is for?
I'd argue that 1.12.4 <-> 1.12.6 should be a compatible upgrade AND
downgrade,
1.12.4 -> 1.20.0 not so much.
But to
Hi all
here I'd like to explain why I prefer not to update dependencies just
because we can. Maybe you can convince me that I'm wrong. I've tried to
make this point in different threads but either it has been lost or it
just wasn't worth discussing.
First of all let me get a few things out of
On 2020-07-24, Rob Tompkins wrote:
>> On Jul 23, 2020, at 10:16 PM, Matt Sicker wrote:
>> Also, how different is a bot proposing a dependency update from a human
>> doing the same? The bot includes far more context about the update in the
>> PR comment, too, which is super useful for
On 2020-07-23, Oliver Heger wrote:
> Am 22.07.20 um 18:28 schrieb Stefan Bodewig:
>> On 2020-07-22, Rob Tompkins wrote:
>>> I’m happy to merge them….will get to them by tomorrow morning ok?
>> Personally I don't see any value for our downstream users if we update
>> our dependencies without
56 matches
Mail list logo
