Hi,
Unfortunately I don't think that's possible. The code is hosted at ASF, and
synced with GitHub.
The issues are also hosted at ASF infra, but I don't believe we have any sort
of issues-mirroring service available at ASF.
I agree it would be convenient to have everything in a single place,
I see that bugs are tracked using JIRA. Is there any chance you could sync
GitHub issues with the JIRA bug tracker. As far as I can see, you would
normally browse the code at GitHub & having all the issues with it would be
fantastic.
I use Daemon at work quite a bit so yes I've done more than look at it ;-)
Right now we can't tell if it will even build and run on Java > 11 since as
of Java 12 onwards javac doesn't support building for Java 6.
So this -1 is not a good technical argument IMO. The fact that we can't
even run a
If we want ARM builds for a component, then by all means let's us Travis
until GitHub catches up.
Gary
On Sat, Aug 15, 2020, 16:51 Geoffrey Blake
wrote:
> Not familiar with Apache CI, but github actions do not support Arm builds.
> Arm should be recognized as a first class build target these
"When you say pushing SNAPSHOT to github.io would that be a nightly or
weekly or merge triggered releases?"
Same as normal build triggers: commits.
Gary
On Sat, Aug 15, 2020, 17:30 John Patrick wrote:
> Personally I wouldn't use GitHub Actions, it seems wrong coupling
> yourself to what is
Personally I wouldn't use GitHub Actions, it seems wrong coupling
yourself to what is hosting your code. I'm not saying anything is
wrong with GitHub Actions it just feels like vendor lock in.
When you say pushing SNAPSHOT to github.io would that be a nightly or
weekly or merge triggered
What if you're wanting to use it on Java 14, 15 RC, 16 EA or in 6
months time 17 EA, will they support such an old version?
Reading the website;
Tomcat 7 needs Java 6 and later and (Java 7 for WebSockets),
Tomcat 8 is Java 7 and later
Tomcat 9 is Java 8 and later
Tomcat 10 is Java 8 and later
2020-08-15 22:51 UTC+02:00, Geoffrey Blake :
> Not familiar with Apache CI, but github actions do not support Arm builds.
> Arm should be recognized as a first class build target these days. Travis
> allows Arm builds so not sure about the reasoning for moving off.
Also, is Travis computing time
Not familiar with Apache CI, but github actions do not support Arm builds.
Arm should be recognized as a first class build target these days. Travis
allows Arm builds so not sure about the reasoning for moving off.
-Geoff
On Sat, Aug 15, 2020 at 1:11 PM Matt Sicker wrote:
> Agreed on the
On Sat, 15 Aug 2020 at 19:01, Gary Gregory wrote:
>
> On Sat, Aug 15, 2020 at 1:14 PM Mark Thomas wrote:
>
> > On 10/08/2020 17:26, Gary Gregory wrote:
> > > As recently done for [EMAIL], I propose we update [LOGGING] and [DAEMON]
> > > from Java 6 to 7 to streamline building on CIs.
> >
> > -1
Hi All,
I would really prefer we do not do this.
Note that there is no blocking issue to fix here. When you build in a CI,
you know what OS you get and Maven is pre-configured, no mystery.
My view here is that it would be the CI's job to toggle the Maven version
just like a CI does for Java,
Hello.
Le sam. 15 août 2020 à 19:22, Rob Tompkins a écrit :
>
> Hello all,
>
> I first want to thank John for bringing these points to light as I think we
> can have quite a healthy discussion about the CI/CD philosophy employed by
> the project (Apache Commons) generally. Furthermore, I hope
I'll note that at least from a Jenkins point of view (probably similar
with GitHub Actions), it's easier to set up your CI config to use the
Maven wrapper script instead of configuring a Maven tool (Jenkins) or
using a specific Docker image or similar extra config. We've had a
wrapper script in
Agreed on the GitHub Actions. Neutral about how snapshot sites are
published since there are multiple methods of doing the same thing,
though if that's also simple to set up via the action to commit the
output to the gh-pages branch, I'd say go for it!
On Sat, 15 Aug 2020 at 13:07, Gary Gregory
Hi All,
In order to ease maintenance, I propose that we drop Travis CI in favor of
Apache CI and GitHub Actions. 2 CI systems instead of 3 seems like plenty
to me. The exception would be a component with an existing complex Travis
build that was not or cannot be reproduced in GitHub Actions.
On Sat, Aug 15, 2020 at 1:14 PM Mark Thomas wrote:
> On 10/08/2020 17:26, Gary Gregory wrote:
> > As recently done for [EMAIL], I propose we update [LOGGING] and [DAEMON]
> > from Java 6 to 7 to streamline building on CIs.
>
> -1 for DAEMON. Tomcat 7 depends on it and has a specification
Hello all,
I first want to thank John for bringing these points to light as I think we can
have quite a healthy discussion about the CI/CD philosophy employed by the
project (Apache Commons) generally. Furthermore, I hope to set precedent with
intent and direction with the following comments.
On 10/08/2020 17:26, Gary Gregory wrote:
> As recently done for [EMAIL], I propose we update [LOGGING] and [DAEMON]
> from Java 6 to 7 to streamline building on CIs.
-1 for DAEMON. Tomcat 7 depends on it and has a specification mandated
requirement to run on Java 6.
Are there any features / bugs
I've raised some pull requests to add the Takari maven wrapper.
The Takari maven wrapper is EOL and will be replaced with the Maven
Wrapper when Maven v3.7.0 is released.
I've added the Takari version as maven v3.7.0 is not yet out. I've
been using the Takari maven wrapper for about 4 years now
>
>
>>
>> Note that commons-beanutils last successful build was 2 years ago. It has
> been failing when trying to clean the staging area:
>
> [ERROR] Failed to execute goal
> org.apache.commons:commons-release-plugin:1.7:clean-staging (clean-staging)
> on project commons-beanutils2: Failed to
On Fri, 14 Aug 2020 at 16:04, Alex Herbert wrote:
>
> I did not move all the old jenkins jobs over for all the projects [2].
> However some of the old jenkins jobs deployed snapshots when successful
> using the deploy goal of maven. A quick investigation lists these that do
> snapshot deployment
21 matches
Mail list logo
