I take that back. Jars are declared as dependencies in the distribution pom. If they are listed there they are included, so it should just be a matter of leaving log4j-perf out. log4j-samples is also not part of the distribution.
Ralph On Jun 19, 2014, at 8:44 PM, Ralph Goers <ralph.go...@dslextreme.com> wrote: > I will try but that may not be possible. > > Ralph > > On Jun 19, 2014, at 8:21 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > >> Keep the perf module name as is please. It would make a mess when with other >> tooling like mvn eclipse:eclipse that create projects. Now all projects >> nicely sort together. >> >> Gary >> >> >> -------- Original message -------- >> From: Remko Popma >> Date:06/19/2014 22:38 (GMT-05:00) >> To: Log4J Developers List >> Subject: Re: Next Release >> >> About outstanding issues: >> I'm aware of two things: changes to the site for the new logo (incl updating >> the home page announcement) >> and ensuring that the log4j-perf module is not included in the distribution. >> This last thing may be easiest accomplished by renaming it so that it >> doesn't match the "log4j-" pattern used in assembly/bin. (Also may need a >> change in assembly/source.) >> Perhaps rename to log4j2-perf or just perf? >> >> Going over other Jiras now but so far didn't see any showstoppers. >> >> >> Sent from my iPhone >> >> On 2014/06/20, at 9:23, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> >>> I’m fine with all that. What bugs need to be fixed before rc2 (if any). I >>> am hoping I can find the time this weekend to create the release. >>> >>> Ralph >>> >>> >>> On Jun 19, 2014, at 4:37 PM, Remko Popma <remko.po...@gmail.com> wrote: >>> >>>> I think we are actually missing out on a lot of community feedback by not >>>> releasing 2.0. Many people are waiting... >>>> >>>> If we want to make this release an RC release instead of GA, I can live >>>> with that, but then we should do our utmost to make the next release GA. >>>> >>>> If we want to avoid branching, then let's agree to only commit bug fixes, >>>> and no new features/refactoring to trunk until after GA. >>>> >>>> Thoughts? >>>> >>>> Sent from my iPhone >>>> >>>> On 2014/06/19, at 23:19, Gary Gregory <garydgreg...@gmail.com> wrote: >>>> >>>>> It feels to early to create busy work to branch IMO. We should do RC2 >>>>> first and get feedback first IMO. >>>>> >>>>> Gary >>>>> >>>>> >>>>> On Thu, Jun 19, 2014 at 10:09 AM, Matt Sicker <boa...@gmail.com> wrote: >>>>> I agree with Remko on the branching idea. Yes, it would make sense to >>>>> make RC2 and if that is sufficiently stable, tag it as 2.0 GA. When we do >>>>> RC2, it should be copied to branches/2.0 or similar. Then we can continue >>>>> work for 2.1 in trunk. >>>>> >>>>> Bug fixes for 2.0 should be done on the 2.0 branch and merged to trunk. I >>>>> think that works rather well usually. >>>>> >>>>> >>>>> On 19 June 2014 08:25, Remko Popma <remko.po...@gmail.com> wrote: >>>>> Personally I would like to release a GA as soon as possible. I remember >>>>> that in spring of 2013 we were talking about releasing GA that summer, so >>>>> we've missed that goal by a year already! I agree with Ralph that I think >>>>> the code is ready. >>>>> >>>>> If many people want to release an RC2 first in order to confirm the >>>>> stability before releasing the GA, then I would agree with that, but that >>>>> would only make sense if we can also agree not to make changes that would >>>>> require yet another RC... >>>>> >>>>> I would propose that with RC2 we do a feature freeze. We create a >>>>> "2.0-release" branch (or something like that, any name is fine), and we >>>>> only commit bug fixes to that branch. After say, one month (what would be >>>>> a reasonable time?) we release GA from that branch. >>>>> >>>>> Meanwhile, development for new features, refactoring etc continues on >>>>> trunk. Of course any bug fix committed to the 2.0-release branch also >>>>> needs to be merged into trunk. >>>>> >>>>> Perhaps one of the reasons we've not been able to do the 2.0 release >>>>> earlier is that currently there is only one branch, trunk, where both bug >>>>> fixes and new development happens, which makes it hard to say that "now >>>>> we have something that is stable enough to release". >>>>> >>>>> We could also do this the other way around, make trunk the release >>>>> branch, and create a "2.1" (or something) branch for new development, >>>>> that would work too. The point is, we want to be able to add new features >>>>> and refactor on the one hand, and on the other hand we want to stabilize >>>>> the code for the GA release, and I think separate branches will help us >>>>> accomplish that. >>>>> >>>>> Remko >>>>> >>>>> >>>>> On Thu, Jun 19, 2014 at 8:47 PM, Gary Gregory <garydgreg...@gmail.com> >>>>> wrote: >>>>> To me it feels like another RC would be best. So many changes went in >>>>> since RC 1 that feedback and community testing are needed. If things are >>>>> stable with RC 2 then we can release. There also one non trivial >>>>> issue/feature I'll ask about ASAP on the ML. >>>>> >>>>> Gary >>>>> >>>>> >>>>> -------- Original message -------- >>>>> From: Ralph Goers >>>>> Date:06/19/2014 00:57 (GMT-05:00) >>>>> To: Log4J Developers List >>>>> Subject: Next Release >>>>> >>>>> We are overdue for a release. The only question I have is whether it >>>>> should be rc2 or GA. >>>>> 1. Are there any open issues that are blockers to a GA release? >>>>> 2. Is everyone comfortable with the state of the code for a GA release? >>>>> >>>>> For me, I am not aware of any blockers and I think the code is good. The >>>>> only thing I am wondering is with all the changes that have been made >>>>> from rc1 what risk there is with this release being GA. I suppose one >>>>> possibility would be to release rc2 and then do GA after just a few weeks. >>>>> >>>>> Thoughts? >>>>> >>>>> Ralph >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >>>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>> >
