Option 2 makes no sense to me. I don’t plan on being the release manager for log4j-scala. In order for me to implement option 2 I would have to include the log4j-scala site into the log4j release process - as well as log4j-examples, etc if they move out. That is just not doable. Deploying the Scala site parallel to log4j makes it much easier to maintain independently of log4j.
Ralph > On Feb 24, 2017, at 11:15 PM, Matt Sicker <boa...@gmail.com> wrote: > > The site repository is laid out like this: > > log4j/2.x/ -(symlink)-> log4j-2.8/ > log4j/log4j-2.8/log4j-api/ > ... > log4j/2.x/log4j-api-scala_2.11/ > > Option 1 is to put it here instead: > log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; that's a pretty ugly > URL honestly) > log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory > > Option 2 is to commit the scala site where it is now, but you'd have to > manage it alongside log4j core releases. Option 1 still requires maintenance, > too. > > On 25 February 2017 at 00:05, Apache <ralph.go...@dslextreme.com > <mailto:ralph.go...@dslextreme.com>> wrote: > There is a specific location in svn where the site pages have to be > committed, so I don’t really understand option 1. > > Ralph > >> On Feb 24, 2017, at 9:48 PM, Matt Sicker <boa...@gmail.com >> <mailto:boa...@gmail.com>> wrote: >> >> I see two ways of doing that, though: >> >> 1. Commit the Scala site in a separate directory similar to what I started >> doing with Log4j Boot. Add redirect pages or rewrite rules via .htaccess if >> possible to keep links from breaking. >> 2. Commit the Scala site where it would go when creating the main site. >> Depending on how you update the files in svn for a site update, could this >> be more annoying to maintain? >> >> On 24 February 2017 at 22:30, Apache <ralph.go...@dslextreme.com >> <mailto:ralph.go...@dslextreme.com>> wrote: >> From my perspective that doesn’t matter. However, we would really need a >> Scala site before we can modify the Log4j site, otherwise it will be a dead >> link. >> >> All that really needs to happen is the Scala site needs to be checked in >> adjacent to the Log4j 2 site. Then the Log4j 2 site just has a link to the >> Scala site from the main menu. The two sites won’t really be “integrated” - >> they will just have links to each other. >> >> Ralph >> >>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <boa...@gmail.com >>> <mailto:boa...@gmail.com>> wrote: >>> >>> It is cosmetic, but we'd also be adding the Scala 2.12 module. >>> >>> On 24 February 2017 at 14:17, Apache <ralph.go...@dslextreme.com >>> <mailto:ralph.go...@dslextreme.com>> wrote: >>> I don’t have the numbers but I have a couple of issues that need fixes. >>> >>> The modules stuff doesn’t require a major version bump. It is mostly >>> cosmetic. >>> >>> Ralph >>> >>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory <garydgreg...@gmail.com >>>> <mailto:garydgreg...@gmail.com>> wrote: >>>> >>>> I think we can do 2.8.1 with our current bug fixes. Moving modules around >>>> feels like a 2.9 item to me but that's just me. I really like the idea of >>>> making bug fixes available ASAP. The only issue I see that fixing now is >>>> the null classloader issue for which we have a patch but it does not work >>>> for me (see JIRA). >>>> >>>> Gary >>>> >>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <boa...@gmail.com >>>> <mailto:boa...@gmail.com>> wrote: >>>> I'm hoping we can get this released soon as we have some bugfixes and such >>>> ready to go. I also want to move forward with 2.9 changes but don't really >>>> want to deal with creating a 2.9 branch or forking master into a 2.8 >>>> branch. Let's go over anything left to do for 2.8.1: >>>> >>>> * Integrated log4j-api-scala website into main site >>>> * Remove scala modules from logging-log4j2 repo >>>> * Release scala modules from logging-log4j-scala repo (presumably shortly >>>> after releasing 2.8.1 of core?) >>>> >>>> I also have ideas on what we can shoot for in 2.9 and beyond, but that's >>>> for another day. I think getting everything working properly in Java 9 >>>> would be a good thing to start doing soon so we can figure out if our APIs >>>> will still work properly in the future or if we need to break backwards >>>> compatibility. Although, multi-jar support could help in migrating the API >>>> if needed for 9+, though that would be a rather unorthodox abuse of the >>>> feature. >>>> >>>> -- >>>> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>> >>>> >>>> >>>> >>>> -- >>>> E-Mail: garydgreg...@gmail.com <mailto:garydgreg...@gmail.com> | >>>> ggreg...@apache.org <mailto:ggreg...@apache.org> >>>> Java Persistence with Hibernate, Second Edition >>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> >>>> >>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459> >>>> JUnit in Action, Second Edition >>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> >>>> >>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021> >>>> Spring Batch in Action >>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> >>>> >>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951> >>>> Blog: http://garygregory.wordpress.com <http://garygregory.wordpress.com/> >>>> Home: http://garygregory.com/ <http://garygregory.com/> >>>> Tweet! http://twitter.com/GaryGregory <http://twitter.com/GaryGregory> >>> >>> >>> >>> -- >>> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>> >> >> >> >> >> -- >> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>> > > > > > -- > Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
