No objection from me to release log4j-scala. Do you have a versioning scheme that lets log4j-scala and log4j upgrade independently?
Sent from my iPhone > On Mar 8, 2017, at 1:42, Mikael Ståldal <mikael.stal...@magine.com> wrote: > > Can we release log4j-scala now? Or to we have to wait for the next release of > main repo with Scala modules removed? Should we remove the Scala modules from > main repo now? > >> On Fri, Mar 3, 2017 at 5:16 PM, Matt Sicker <boa...@gmail.com> wrote: >> The Scala language versions is already done the same standard way everyone >> implements Scala libraries (hence the strange naming scheme we already >> have). I'd imagine that the versions can be completely decoupled by >> specifying a minimum Log4j API version it requires (though should generally >> be whatever the latest was at release) and bumping its own version as new >> features or bugfixes are added. I'd like to see that follow semantic >> versioning properly, too. >> >>> On 3 March 2017 at 06:15, Mikael Ståldal <mikael.stal...@magine.com> wrote: >>> I guess the idea is that releases of Log4j 2 and log4j-scala should be >>> independent in both ways, right? >>> >>> I think I have coordination between log4j-scala and Scala language covered >>> already. >>> >>>> On Fri, Mar 3, 2017 at 10:19 AM, Remko Popma <remko.po...@gmail.com> wrote: >>>> 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> >>> >>> >>> >>> -- >>> >>> >>> 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> > > > > -- > > > 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. >
