logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: Roadmap for 2.8.1
Date Wed, 01 Mar 2017 15:03:59 GMT
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.goers@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.staldal@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.goers@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.staldal@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 <boards@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.popma@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 <boards@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.goers@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 <boards@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.goers@dslextreme.com>
>>>>> wrote:
>>>>>
>>>>> Why is the release of log4j-scala delayed?
>>>>>
>>>>> Ralph
>>>>>
>>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal <
>>>>> mikael.staldal@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 <boards@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.goers@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.goers@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 <boards@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.goers@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 <boards@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.goers@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 <boards@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.goers@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 <garydgregory@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 <boards@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 <boards@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@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
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <boards@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <boards@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <boards@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <boards@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> [image: MagineTV]
>>>>>
>>>>> *Mikael Ståldal*
>>>>> Senior software developer
>>>>>
>>>>> *Magine TV*
>>>>> mikael.staldal@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 <boards@gmail.com>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Matt Sicker <boards@gmail.com>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Matt Sicker <boards@gmail.com>
>>>
>>
>>
>>
>> --
>> [image: MagineTV]
>>
>> *Mikael Ståldal*
>> Senior software developer
>>
>> *Magine TV*
>> mikael.staldal@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.
>>
>>
>
>
> --
> [image: MagineTV]
>
> *Mikael Ståldal*
> Senior software developer
>
> *Magine TV*
> mikael.staldal@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 <boards@gmail.com>

Mime
View raw message