Mikael, you probably need to plan your versioning scheme to handle any combination of the following: * log4j 2 releases: do you want to do a release for the log4j-scala modules every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding is that once they are decoupled, the log4j-scala modules won't be released automatically with log4j anymore, someone needs to do the work for a log4j-scala release separately. * Scala releases: how do you want to sync up with Scala language versions? (I guess include major&minor Scala version in the log4j-scala module version) * log4j-scala module versions: enhancements to these modules, independent of the above
Sent from my iPhone > On Mar 3, 2017, at 9:10, Mikael Ståldal <mikael.stal...@magine.com> wrote: > > I would like to keep package and artifact names, and bump version to 11.0. > >>> On Mar 1, 2017 4:04 PM, "Matt Sicker" <boa...@gmail.com> wrote: >>> If you change artifact ids, it's generally a good idea to change packages, >>> too. I've had issues in the past with Feign for instance because they >>> changed groupId/artifactId at one point but kept the same API, so I had two >>> copies on the classpath until I found out there was a duplicate and >>> excluded them (though admittedly not a problem in OSGi environments :P). >>> >>> On 1 March 2017 at 07:47, Ralph Goers <ralph.go...@dslextreme.com> wrote: >>> You can do that, but that will probably confuse users too. I would suggest >>> changing the artifactId and then start at either 1.0 or 2.0. >>> >>> Ralph >>> >>>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal <mikael.stal...@magine.com> >>>> wrote: >>>> >>>> OK, but then at least we have to start with a version > 2.8. >>>> >>>> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ralph.go...@dslextreme.com> wrote: >>>>> 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. >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> 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>
