I guarantee if you try to keep the same versioning you will regret it. Ralph
> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal <mikael.stal...@magine.com> wrote: > > I was under the impression that we were not ready to integrate the site from > log4j-scala. That's why I considered the release of log4j-scala as delayed, > since there is no point of releasing it if we cannot get the site integrated. > > But now when Ralph says he's ready to integrate the site, I guess we can go > ahead and release log4j-scala. > > I don't like the idea of having separate versioning for log4j-scala, that > will be confusing since we have already started with the same versioning as > Log4j. Log4j-scala also have a dependency on log4j-api, and I think we want > to keep that in sync. > > >> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <boa...@gmail.com> wrote: >> One issue we came across in practice is that Scala 2.12 requires Java 8, but >> we don't want to require that for the entire build, so we separated the >> repo. This also helps avoid making the main log4j repo from taking forever >> to build and release which can help the RERO idea. Plus, these non-core >> modules don't change nearly as often as log4j-core or log4j-api, so they >> don't really need new releases all that often. >> >>> On 28 February 2017 at 01:44, Remko Popma <remko.po...@gmail.com> wrote: >>> To be honest I still don't understand >>> >>> * the vision of what we ultimately want to achieve >>> * how different repos fit into that vision >>> * what different websites we are planning to create to give users access to >>> these different modules >>> * what websites are going to be driven from which modules or projects >>> * who of us is going to be driving what aspect of the above >>> >>> My lack of understanding is not just limited to the Scala modules but is >>> about the whole splitting up the release. >>> >>> Perhaps a diagram would help clarify my understanding. (I think there's >>> already a JIRA or an epic for the above. Adding some diagrams there would >>> be very useful.) >>> >>> Remko >>> >>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <boa...@gmail.com> wrote: >>>> I'd be in favour of starting a new release train for the Log4j Scala APIs. >>>> Not exactly sure which version to start from, though. >>>> >>>> On 27 February 2017 at 18:35, Ralph Goers <ralph.go...@dslextreme.com> >>>> wrote: >>>> 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> >>>>> 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> >>>>>> 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> 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> 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> 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> 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> >>>>>>>> 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> 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> >>>>>>>>> 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> 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> >>>>>>>>>> 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> >>>>>>>>>>> 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> >>>>>>>>>>> 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> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>>>> JUnit in Action, Second Edition >>>>>>>>>>> Spring Batch in Action >>>>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>>>> Home: http://garygregory.com/ >>>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matt Sicker <boa...@gmail.com> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> >>>>>> Mikael Ståldal >>>>>> Senior software developer >>>>>> >>>>>> Magine TV >>>>>> mikael.stal...@magine.com >>>>>> Grev Turegatan 3 | 114 46 Stockholm, Sweden | 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> >>>> >>>> >>>> >>>> >>>> -- >>>> Matt Sicker <boa...@gmail.com> >> >> >> >> -- >> Matt Sicker <boa...@gmail.com> > > > > -- > > > Mikael Ståldal > Senior software developer > > Magine TV > mikael.stal...@magine.com > Grev Turegatan 3 | 114 46 Stockholm, Sweden | 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. >
