I put the Scala and Kotlin sites inside the log4j site repo mostly because
that’s where they used to be in SVN. They could be split out at some point.
Matt Sicker
> On Oct 19, 2021, at 17:52, Ralph Goers wrote:
>
> Log4j-kotlin and log4j-scala could have had their own website repo if Matt
>
Log4j-kotlin and log4j-scala could have had their own website repo if Matt had
wanted it.
You’d have to ask him why he chose not to.
No, having the site and source in the same repo is a disaster. First, our
website repo
is huge as it contains every release of log4j, so doing a git clone would
Indeed log4jcxx and log4net don't use logging-log4j-site, hence this was a
mistake from my side. Yet log4j-kotlin and log4j-scala do.
I am not able to see how my point about the difficulty of multi-repo setups
is addressed. Log4j sources and the site are on different repos.
In conclusion, I am
There are links to all the project web site repos at
https://cwiki.apache.org/confluence/display/LOGGING/Managing+the+Logging+Services+Web+Sites.
Ralph
> On Oct 19, 2021, at 6:37 AM, Apache wrote:
>
> Volkan,
>
> I am not in front of my computer at the moment, but I am 100% sure you are
>
Volkan,
I am not in front of my computer at the moment, but I am 100% sure you are
incorrect. Every logging project has its own GitHub repo for its own web site.
The thought of having log4cxx and Log4Net use a repo with Log4J in the name
doesn’t make any sense.
Publishing a web site involves
In its current state, all Logging Services projects (log4j, log4jcxx,
log4net, etc.) dump their websites to a single repository:
https://github.com/apache/logging-log4j-site If I need to publish
continuous benchmark results of logging-log4j2 repository, I need to push
my changes to two other
OK. So you are proposing that instead of documenting the plugin in the Log4j
web site that we create a new site for it using GitHub Pages?
Ralph
> On Oct 18, 2021, at 12:45 PM, Matt Sicker wrote:
>
> The Maven shade plugin thing.
>
> On Mon, Oct 18, 2021 at 2:44 PM Apache wrote:
>>
>> What
The Maven shade plugin thing.
On Mon, Oct 18, 2021 at 2:44 PM Apache wrote:
>
> What new plug-in?
>
> Ralph
>
> > On Oct 18, 2021, at 12:32 PM, Matt Sicker wrote:
> >
> > Testing the website publishing from the new plugin. It’s probably easier
> > to keep it under the ASF pages thing than it
What new plug-in?
Ralph
> On Oct 18, 2021, at 12:32 PM, Matt Sicker wrote:
>
> Testing the website publishing from the new plugin. It’s probably easier to
> keep it under the ASF pages thing than it is to combine it with GH pages.
> Since it’s storing generated markup in a git repo, it
Testing the website publishing from the new plugin. It’s probably easier to
keep it under the ASF pages thing than it is to combine it with GH pages. Since
it’s storing generated markup in a git repo, it doesn’t matter much which
system it’s using besides whatever integration we already have
I feel like I am going in circles.
Testing of what? I still don’t understand what the use case is for GitHub
Pages. What problem is it solving?
Ralph
> On Oct 18, 2021, at 12:05 PM, Matt Sicker wrote:
>
> I’d imagine it’s for testing purposes initially. We should integrate it into
> the
I’d imagine it’s for testing purposes initially. We should integrate it into
the main domain when it’s ready for release. This should all be controllable
via the .asf.yaml file.
Matt Sicker
> On Oct 18, 2021, at 12:32, Ralph Goers wrote:
>
> Why?
>
> Ralph
>
>> On Oct 18, 2021, at 8:40
Why?
Ralph
> On Oct 18, 2021, at 8:40 AM, Volkan Yazıcı wrote:
>
> For the moment, I just want the `gh-pages` branch of the logging-log4j2
> GitHub project to be accessible at "a" URL – just like any other non-ASF
> GitHub project.
>
> On Mon, Oct 18, 2021 at 5:38 PM Ralph Goers
> wrote:
>
OK. That page didn’t exist when I migrated the site from the CMS. That still
leaves
the second question. What are you proposing? I don’t really see the point of
moving
the existing site to GitHub Pages.
Ralph
> On Oct 18, 2021, at 8:31 AM, Volkan Yazıcı wrote:
>
> GitHub Pages look pretty
Matt, okay, forget about the domain name. Can you help me with setting up
gh-pages branch to show up in a page that is not overriding a currently
existing one. Any domain name is fine.
On Fri, Oct 15, 2021 at 5:27 PM Matt Sicker wrote:
> I’m not exactly sure how we can get a beta subdomain,
GitHub Pages look pretty doable to me:
https://cwiki.apache.org/confluence/display/INFRA/GitHub+Pages
On Fri, Oct 15, 2021 at 6:35 PM Ralph Goers
wrote:
> I don’t really understand this. When I was migrating the web site from the
> ASF CMS to GitHub
> it was made clear that web site hosting
I don’t really understand this. When I was migrating the web site from the ASF
CMS to GitHub
it was made clear that web site hosting using GitHub Pages wasn’t supported. I
am not sure
what the proposal here is.
Ralph
> On Oct 15, 2021, at 8:27 AM, Matt Sicker wrote:
>
> I’m not exactly
I’m not exactly sure how we can get a beta subdomain, though the staging one is
built in. And while it would be great to automate as much as possible about the
release process in GHA, the code signing aspect is still not possible (though
we might be able to integrate with another service at
I long had the ambition to move the entire site & manual to gh-pages.
In an ideal world, I would even move the release process to GitHub Actions
too.
But these are, for now, pretty ambitious goals.
What I would really appreciate is to access gh-pages content via, say,
19 matches
Mail list logo
