If you use that excuse they will never get released as it creates a catch-22. If I release without them then we have a regression until they are released.
This is why you shouldn’t really be releasing them using the Log4j versions. Change the artifactIds so they can start at 1.0, 2.0 or whatever. Once you create the release and deploy it to the web site I can modify the web site to point to it. Ralph > On Feb 27, 2017, at 5:19 PM, Matt Sicker <boa...@gmail.com> wrote: > > Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of makes it harder > to release from the log4j-scala repo when two of the three artifacts will > already exist. > > On 27 February 2017 at 12:14, Ralph Goers <ralph.go...@dslextreme.com > <mailto:ralph.go...@dslextreme.com>> wrote: > Why is the release of log4j-scala delayed? > > Ralph > >> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <mikael.stal...@magine.com >> <mailto:mikael.stal...@magine.com>> wrote: >> >> I would really like LOG4J2-1661 and LOG4J2-1690 out in the next release. >> >> I implemented LOG4J2-1690 only in the new log4j-scala repo since I thought >> that it would be released as part of 2.8, otherwise I would have put it to >> the main repo as well. But now releasing of the log4j-scala repo has been >> delayed and I start to get disappointed. >> >> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <boa...@gmail.com >> <mailto:boa...@gmail.com>> wrote: >> Relative symlinks would work for that regardless of version. Option 1 it is, >> then? >> >> On 25 February 2017 at 00:22, Apache <ralph.go...@dslextreme.com >> <mailto:ralph.go...@dslextreme.com>> wrote: >> Note that the link in the log4j site can reference a symlink so that the >> log4j site never has to change when the Scala site is updated. >> >> Ralph >> >>> On Feb 24, 2017, at 11:21 PM, Apache <ralph.go...@dslextreme.com >>> <mailto:ralph.go...@dslextreme.com>> wrote: >>> >>> 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 >>>> <mailto: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>> >>> >> >> >> >> >> -- >> Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>> >> >> >> >> -- >> >> >> Mikael Ståldal >> Senior software developer >> >> Magine TV >> mikael.stal...@magine.com <mailto:mikael.stal...@magine.com> >> Grev Turegatan 3 | 114 46 Stockholm, Sweden | www.magine.com >> <http://www.magine.com/> >> >> Privileged and/or Confidential Information may be contained in this message. >> If you are not the addressee indicated in this message >> (or responsible for delivery of the message to such a person), you may not >> copy or deliver this message to anyone. In such case, >> you should destroy this message and kindly notify the sender by reply email. >> > > > > > -- > Matt Sicker <boa...@gmail.com <mailto:boa...@gmail.com>>
