You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Antonio Petrelli <an...@gmail.com> on 2012/05/31 21:46:53 UTC
[maven-reorg] Reorganizations ongoing at forked Git repository
Hi all
following Christian's rant at Google+:
https://plus.google.com/102440702937210603575/posts/HbD1fa9NGHY
I started forking Log4j at GitHub:
https://github.com/apetrelli/log4j
The first step I did is providing a stub for a multi-module build.
Assuming that Log4j should be multi-module is fundamental. I don't
want to start a Maven lesson, you can see anywhere about the benefit
of having separated modules with well-identified dependencies.
For now, I have only a parent project (pom type) and a "core" project,
that soon will go on a diet, moving code in other modules.
About the version, you might notice that I put "1.3.0-SNAPSHOT"
version because, at the end, you will not recognize Log4j 1.2.x
artifacts at all. They will be more numerous, smaller and with
specific dependencies.
Feel free to discuss or to help via forking.
Best regards
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Christian Grobmeier <gr...@gmail.com>.
On Fri, Jun 1, 2012 at 9:24 AM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2012/5/31 Ralph Goers <ra...@dslextreme.com>:
>> Log4j 2 is already a multi-module build. I am not at all sure why you would want to expend all this effort on a 1.3 when 2.0 should be our next target.
>
> I agree, however Christian says that 1.x is still maintained and the
> last build of 1.2.x was a nightmare. Anyway, I suggest Christian to
> jump into the discussion because he can explain it better than me.
We have no fixed release date for log4j 2.0. This is of course the
successor of log4j 1. But as long as we have no proper release (means
GA ready) we need to maintain the old codebase. Otherwise users will
ask us why they should use 2.0, when we were not able to maintain 1.x.
And, of course, even when 2.0 is avail it does not mean everybody
can/wants to migrate immediately. there is so much software using
log4j1, I expect it takes a long while until we can speak of an EOL.
That being said: 1.2 build is horrible and complex. It took ages to
get us all the necessary votes. Not everybody is able to build it
completely. It is not possible to make some "small reversible steps"
here, we need to clean up - or we face the situation to not longer be
able to maintain log4j1. This is how I see it - therefore I would like
to put some good effort in cleaning up the build and release bugfixes
form time to time, while the huge efforts go into log4j 2.0
Cheers
Christian
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Antonio Petrelli <an...@gmail.com>.
2012/5/31 Ralph Goers <ra...@dslextreme.com>:
> Log4j 2 is already a multi-module build. I am not at all sure why you would want to expend all this effort on a 1.3 when 2.0 should be our next target.
I agree, however Christian says that 1.x is still maintained and the
last build of 1.2.x was a nightmare. Anyway, I suggest Christian to
jump into the discussion because he can explain it better than me.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Christian Grobmeier <gr...@gmail.com>.
On Fri, Jun 1, 2012 at 9:26 AM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2012/6/1 Ralph Goers <rg...@apache.org>:
>> Why would that require a 1.3?
>
> Just because it will be a complete change in organizations of jars. If
> you want to stick with 1.2.x version scheme it's only a matter of
> changing a version.
Actually I think we should stick with 1.2.
Reasons:
- there was an effort to create log4j 1.3 in the past. This version
has failed and was cancelled. To my knowledge this was the time Ceki
stopped development at the ASF and founded logback/slf4j. Since then
1.2 was releasing bugfix versions from time to time. It would be
confusing for oldschoolers to hear about a new 1.3 version
- we need to show the sign that we maintain 1.2 without breaking the
code. But of course we should show the 2.0 flag. All our marketing
efforts etc should go into 2.0 soon and personally I would like to
avoid efforts in pushing a new version.
As we do not break the code and just require new pom.xml artifacts
which must be touched when a new version comes out I think 1.2.18
would be fine.
Cheers
Christian
> Notice that I am not here to interfere with Log4j team decisions, only
> to help with the build.
Thank you very much! You are welcome!
Cheers
Christian
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Ralph Goers <ra...@dslextreme.com>.
On Jun 1, 2012, at 12:26 AM, Antonio Petrelli wrote:
> 2012/6/1 Ralph Goers <rg...@apache.org>:
>> Why would that require a 1.3?
>
> Just because it will be a complete change in organizations of jars. If
> you want to stick with 1.2.x version scheme it's only a matter of
> changing a version.
>
> Notice that I am not here to interfere with Log4j team decisions, only
> to help with the build.
Feel free to "interfere". All opinions, suggestions, feedback, etc are welcome!
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Antonio Petrelli <an...@gmail.com>.
2012/6/1 Ralph Goers <rg...@apache.org>:
> Why would that require a 1.3?
Just because it will be a complete change in organizations of jars. If
you want to stick with 1.2.x version scheme it's only a matter of
changing a version.
Notice that I am not here to interfere with Log4j team decisions, only
to help with the build.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Ralph Goers <rg...@apache.org>.
Why would that require a 1.3?
Ralph
On May 31, 2012, at 2:24 PM, "Jacob Kjome" <ho...@visi.com> wrote:
>
> The main point is separate the tools from the library. That means each of Lf5, Chainsaw1, and Chainsaw2 have their own artifacts, separate from Log4j.jar. That's all. This will make Log4j.jar much smaller (by extracting Lf5 and Chainsaw1). Only users that specifically want to use the tools will need to get their appropriate jar. And all will depend upon Log4j.jar. That really doesn't seem too complex to me.
>
>
> Jake
>
> On Thu, 31 May 2012 17:15:47 -0400
> Gary Gregory <ga...@gmail.com> wrote:
>> My beef is that I do not want 10 jars to pick from, this is a low level
>> components, give me one jar to rule them all. Or at least give me the
>> option to pick an all-in-one jar. For those who want to save 10KB here and
>> there, they can cherry pick I suppose.
>> Gary
>> On Thu, May 31, 2012 at 3:52 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>>> Log4j 2 is already a multi-module build. I am not at all sure why you
>>> would want to expend all this effort on a 1.3 when 2.0 should be our next
>>> target.
>>>
>>> Ralph
>>>
>>> On May 31, 2012, at 12:46 PM, Antonio Petrelli wrote:
>>>
>>> > Hi all
>>> > following Christian's rant at Google+:
>>> > https://plus.google.com/102440702937210603575/posts/HbD1fa9NGHY
>>> > I started forking Log4j at GitHub:
>>> > https://github.com/apetrelli/log4j
>>> >
>>> > The first step I did is providing a stub for a multi-module build.
>>> > Assuming that Log4j should be multi-module is fundamental. I don't
>>> > want to start a Maven lesson, you can see anywhere about the benefit
>>> > of having separated modules with well-identified dependencies.
>>> > For now, I have only a parent project (pom type) and a "core" project,
>>> > that soon will go on a diet, moving code in other modules.
>>> >
>>> > About the version, you might notice that I put "1.3.0-SNAPSHOT"
>>> > version because, at the end, you will not recognize Log4j 1.2.x
>>> > artifacts at all. They will be more numerous, smaller and with
>>> > specific dependencies.
>>> >
>>> > Feel free to discuss or to help via forking.
>>> >
>>> > Best regards
>>> > Antonio
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Gary Gregory <ga...@gmail.com>.
On May 31, 2012, at 22:41, Ralph Goers <rg...@apache.org> wrote:
If you don't do that then you end up with a bunch of optional dependencies
that you will forget to include or a bunch of required dependencies that
you may not really need.
Separating the API from the impl is useful as it keeps users from accessing
stuff that wasn't meant to be public - which is one of the more serious
problems in 1.x.
For that I like the .internal. package name convention Eclipse uses.
Gary
Ralph
On May 31, 2012, at 2:37 PM, Gary Gregory <ga...@gmail.com> wrote:
On Thu, May 31, 2012 at 5:24 PM, Jacob Kjome <ho...@visi.com> wrote:
>
> The main point is separate the tools from the library. That means each of
> Lf5, Chainsaw1, and Chainsaw2 have their own artifacts, separate from
> Log4j.jar. That's all. This will make Log4j.jar much smaller (by
> extracting Lf5 and Chainsaw1). Only users that specifically want to use
> the tools will need to get their appropriate jar. And all will depend upon
> Log4j.jar. That really doesn't seem too complex to me.
>
Well, I agree on splitting the logging from the UI, it's the all the little
jars this-over-that that-over-this, that I find lame.
G
>
>
> Jake
>
>
> On Thu, 31 May 2012 17:15:47 -0400
> Gary Gregory <ga...@gmail.com> wrote:
>
>> My beef is that I do not want 10 jars to pick from, this is a low level
>> components, give me one jar to rule them all. Or at least give me the
>> option to pick an all-in-one jar. For those who want to save 10KB here and
>> there, they can cherry pick I suppose.
>>
>> Gary
>>
>> On Thu, May 31, 2012 at 3:52 PM, Ralph Goers <ra...@dslextreme.com>
>> **wrote:
>>
>> Log4j 2 is already a multi-module build. I am not at all sure why you
>>> would want to expend all this effort on a 1.3 when 2.0 should be our next
>>> target.
>>>
>>> Ralph
>>>
>>> On May 31, 2012, at 12:46 PM, Antonio Petrelli wrote:
>>>
>>> > Hi all
>>> > following Christian's rant at Google+:
>>> > https://plus.google.com/**102440702937210603575/posts/**HbD1fa9NGHY<https://plus.google.com/102440702937210603575/posts/HbD1fa9NGHY>
>>> > I started forking Log4j at GitHub:
>>> > https://github.com/apetrelli/**log4j<https://github.com/apetrelli/log4j>
>>> >
>>> > The first step I did is providing a stub for a multi-module build.
>>> > Assuming that Log4j should be multi-module is fundamental. I don't
>>> > want to start a Maven lesson, you can see anywhere about the benefit
>>> > of having separated modules with well-identified dependencies.
>>> > For now, I have only a parent project (pom type) and a "core" project,
>>> > that soon will go on a diet, moving code in other modules.
>>> >
>>> > About the version, you might notice that I put "1.3.0-SNAPSHOT"
>>> > version because, at the end, you will not recognize Log4j 1.2.x
>>> > artifacts at all. They will be more numerous, smaller and with
>>> > specific dependencies.
>>> >
>>> > Feel free to discuss or to help via forking.
>>> >
>>> > Best regards
>>> > Antonio
>>> >
>>> > ------------------------------**------------------------------**
>>> ---------
>>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.**apache.org<lo...@logging.apache.org>
>>> > For additional commands, e-mail: log4j-dev-help@logging.apache.**org<lo...@logging.apache.org>
>>> >
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.**apache.org<lo...@logging.apache.org>
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.**org<lo...@logging.apache.org>
>>>
>>>
>>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http:/**/bit.ly/ECvg0<http://bit.ly/ECvg0>
>> Spring Batch in Action: <http://s.apache.org/HOq>http:**//bit.ly/bqpbCK<http://bit.ly/bqpbCK>
>>
>> Blog: http://garygregory.wordpress.**com<http://garygregory.wordpress.com>
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.**apache.org<lo...@logging.apache.org>
> For additional commands, e-mail: log4j-dev-help@logging.apache.**org<lo...@logging.apache.org>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Antonio Petrelli <an...@gmail.com>.
2012/6/5 Gary Gregory <ga...@gmail.com>:
> On Tue, Jun 5, 2012 at 8:45 AM, ceki <ce...@qos.ch> wrote:
>>
>> On 01.06.2012 04:41, Ralph Goers wrote:
>>>
>>> If you don't do that then you end up with a bunch of optional
>>> dependencies that you will forget to include or a bunch of required
>>> dependencies that you may not really need.
>>>
>>> Separating the API from the impl is useful as it keeps users from
>>> accessing stuff that wasn't meant to be public - which is one of the
>>> more serious problems in 1.x.
>>>
>>> Ralph
>>
>>
>> Agreed. Separating chainsaw and lf5 into new modules is most
>> reasonable. However, modularization can be easily overdone. Assuming
>> the code in org.apache.log4j.net has not changed much since the last
>> time I looked, I would recommend that the org.apache.log4j.net be part
>> of the core module, not separate.
>
>
> +1, please don't over do it. And at least give me an option to use one
> server-side jar to rule them all.
As I said before, create another module built with Shade plugin. You
can do it, but it is useful only for non Maven users.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by ceki <ce...@qos.ch>.
On 05.06.2012 16:57, Ralph Goers wrote:
> I originally had the Flume Appender packaged with the log4j2 core
> module. Then Flume went and created an incompatible version. At that
> point it became obvious that it was nuts to package flume with log4j,
> much less two versions of Flume.
>
> Ideally, log4j should have as few dependencies as possible. If a
> component requires dependencies most users won't want then I'd vote to
> move it to a separate module.
A conclusion which may be perfectly valid for flume does not
necessarily apply to javax.mail which does not suffer from API
instability. We are talking abut the o.a.log4j.net module which would
seem to be rather widely used.
BTW, the present discussion on whether to modularize o.a.log4j.net or
not should not mask the agreement on the necessity to modularize
chainsaw, lf5, nt, performance. and contribs. The latter two could be
even zapped.
--
Ceki
http://twitter.com/#!/ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Ralph Goers <ra...@dslextreme.com>.
I originally had the Flume Appender packaged with the log4j2 core module. Then Flume went and created an incompatible version. At that point it became obvious that it was nuts to package flume with log4j, much less two versions of Flume.
Ideally, log4j should have as few dependencies as possible. If a component requires dependencies most users won't want then I'd vote to move it to a separate module.
Ralph
On Jun 5, 2012, at 7:34 AM, Christian Grobmeier wrote:
> On Tue, Jun 5, 2012 at 3:59 PM, Scott Deboy <sc...@gmail.com> wrote:
>> A number of the appenders in the net package have no external dependencies.
>> They should be In the core jar.
>>
>> The smtp and jms appenders could be separate if necessary.
>
> +1
>
>>
>> Scott
>>
>>
>>
>> On Jun 5, 2012, at 5:51 AM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> On Tue, Jun 5, 2012 at 8:45 AM, ceki <ce...@qos.ch> wrote:
>>>
>>> On 01.06.2012 04:41, Ralph Goers wrote:
>>>>
>>>> If you don't do that then you end up with a bunch of optional
>>>> dependencies that you will forget to include or a bunch of required
>>>> dependencies that you may not really need.
>>>>
>>>> Separating the API from the impl is useful as it keeps users from
>>>> accessing stuff that wasn't meant to be public - which is one of the
>>>> more serious problems in 1.x.
>>>>
>>>> Ralph
>>>
>>>
>>> Agreed. Separating chainsaw and lf5 into new modules is most
>>> reasonable. However, modularization can be easily overdone. Assuming
>>> the code in org.apache.log4j.net has not changed much since the last
>>> time I looked, I would recommend that the org.apache.log4j.net be part
>>> of the core module, not separate.
>>
>>
>> +1, please don't over do it. And at least give me an option to use one
>> server-side jar to rule them all.
>>
>> G
>>>
>>>
>>> --
>>> Ceki
>>> http://twitter.com/#!/ceki
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Antonio Petrelli <an...@gmail.com>.
2012/6/6 Tushar Kapila <tg...@gmail.com>:
> +1 for no heavy dependancies and big jar or zip (with jars and a
> classpath jar) for easy server side inclusion. Be nice for applets,web
> start and other desk top code that want file append.
I don't know if it applies to applets, but with
"webstart-maven-plugin" you don't have to worry about dependencies
list, and even signing jars is just a matter of configuration.
Again, this is not a problem for Maven users and again, over and over,
there's the Shade plugin.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Tushar Kapila <tg...@gmail.com>.
+1 for no heavy dependancies and big jar or zip (with jars and a
classpath jar) for easy server side inclusion. Be nice for applets,web
start and other desk top code that want file append.
On 6/5/12, Christian Grobmeier <gr...@gmail.com> wrote:
> On Tue, Jun 5, 2012 at 3:59 PM, Scott Deboy <sc...@gmail.com> wrote:
>> A number of the appenders in the net package have no external
>> dependencies.
>> They should be In the core jar.
>>
>> The smtp and jms appenders could be separate if necessary.
>
> +1
>
>>
>> Scott
>>
>>
>>
>> On Jun 5, 2012, at 5:51 AM, Gary Gregory <ga...@gmail.com> wrote:
>>
>> On Tue, Jun 5, 2012 at 8:45 AM, ceki <ce...@qos.ch> wrote:
>>>
>>> On 01.06.2012 04:41, Ralph Goers wrote:
>>>>
>>>> If you don't do that then you end up with a bunch of optional
>>>> dependencies that you will forget to include or a bunch of required
>>>> dependencies that you may not really need.
>>>>
>>>> Separating the API from the impl is useful as it keeps users from
>>>> accessing stuff that wasn't meant to be public - which is one of the
>>>> more serious problems in 1.x.
>>>>
>>>> Ralph
>>>
>>>
>>> Agreed. Separating chainsaw and lf5 into new modules is most
>>> reasonable. However, modularization can be easily overdone. Assuming
>>> the code in org.apache.log4j.net has not changed much since the last
>>> time I looked, I would recommend that the org.apache.log4j.net be part
>>> of the core module, not separate.
>>
>>
>> +1, please don't over do it. And at least give me an option to use one
>> server-side jar to rule them all.
>>
>> G
>>>
>>>
>>> --
>>> Ceki
>>> http://twitter.com/#!/ceki
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>> Spring Batch in Action: http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
Sent from my mobile device
Regards
Tushar Kapila
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Christian Grobmeier <gr...@gmail.com>.
On Tue, Jun 5, 2012 at 3:59 PM, Scott Deboy <sc...@gmail.com> wrote:
> A number of the appenders in the net package have no external dependencies.
> They should be In the core jar.
>
> The smtp and jms appenders could be separate if necessary.
+1
>
> Scott
>
>
>
> On Jun 5, 2012, at 5:51 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Tue, Jun 5, 2012 at 8:45 AM, ceki <ce...@qos.ch> wrote:
>>
>> On 01.06.2012 04:41, Ralph Goers wrote:
>>>
>>> If you don't do that then you end up with a bunch of optional
>>> dependencies that you will forget to include or a bunch of required
>>> dependencies that you may not really need.
>>>
>>> Separating the API from the impl is useful as it keeps users from
>>> accessing stuff that wasn't meant to be public - which is one of the
>>> more serious problems in 1.x.
>>>
>>> Ralph
>>
>>
>> Agreed. Separating chainsaw and lf5 into new modules is most
>> reasonable. However, modularization can be easily overdone. Assuming
>> the code in org.apache.log4j.net has not changed much since the last
>> time I looked, I would recommend that the org.apache.log4j.net be part
>> of the core module, not separate.
>
>
> +1, please don't over do it. And at least give me an option to use one
> server-side jar to rule them all.
>
> G
>>
>>
>> --
>> Ceki
>> http://twitter.com/#!/ceki
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Scott Deboy <sc...@gmail.com>.
A number of the appenders in the net package have no external dependencies. They should be In the core jar.
The smtp and jms appenders could be separate if necessary.
Scott
On Jun 5, 2012, at 5:51 AM, Gary Gregory <ga...@gmail.com> wrote:
> On Tue, Jun 5, 2012 at 8:45 AM, ceki <ce...@qos.ch> wrote:
> On 01.06.2012 04:41, Ralph Goers wrote:
> If you don't do that then you end up with a bunch of optional
> dependencies that you will forget to include or a bunch of required
> dependencies that you may not really need.
>
> Separating the API from the impl is useful as it keeps users from
> accessing stuff that wasn't meant to be public - which is one of the
> more serious problems in 1.x.
>
> Ralph
>
> Agreed. Separating chainsaw and lf5 into new modules is most
> reasonable. However, modularization can be easily overdone. Assuming
> the code in org.apache.log4j.net has not changed much since the last
> time I looked, I would recommend that the org.apache.log4j.net be part
> of the core module, not separate.
>
> +1, please don't over do it. And at least give me an option to use one server-side jar to rule them all.
>
> G
>
> --
> Ceki
> http://twitter.com/#!/ceki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Jun 5, 2012 at 8:45 AM, ceki <ce...@qos.ch> wrote:
> On 01.06.2012 04:41, Ralph Goers wrote:
>
>> If you don't do that then you end up with a bunch of optional
>> dependencies that you will forget to include or a bunch of required
>> dependencies that you may not really need.
>>
>> Separating the API from the impl is useful as it keeps users from
>> accessing stuff that wasn't meant to be public - which is one of the
>> more serious problems in 1.x.
>>
>> Ralph
>>
>
> Agreed. Separating chainsaw and lf5 into new modules is most
> reasonable. However, modularization can be easily overdone. Assuming
> the code in org.apache.log4j.net has not changed much since the last
> time I looked, I would recommend that the org.apache.log4j.net be part
> of the core module, not separate.
>
+1, please don't over do it. And at least give me an option to use one
server-side jar to rule them all.
G
>
> --
> Ceki
> http://twitter.com/#!/ceki
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.**apache.org<lo...@logging.apache.org>
> For additional commands, e-mail: log4j-dev-help@logging.apache.**org<lo...@logging.apache.org>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by ceki <ce...@qos.ch>.
On 06.06.2012 09:53, Christian Grobmeier wrote:
> On Tue, Jun 5, 2012 at 5:35 PM, ceki<ce...@qos.ch> wrote:
>> Right. Lf5 and chainsaw merit to be in different projects. You are also
>> right to point out that I had module and project confused. If the
>> modules have different release cycles they should be in different
>> projects.
>
> There is currently no one working on Lf5 or chainsaw1 to my knowledge.
> Therefore I'd lets make them modules, as they will most likely not see
> a release outside log4j1.x
>
>> My point about separately documenting lof4j-uber.jar and the log4j-*
>> jars remains valid though.
>
> I don't see a big issue here.
There are no big issues involved here. We are talking about making a
fine adjustment.
> I think Documentation for maven users which tell them what to include
> is much more easier than knowing what to exclude. Inclusion is
> standard, for ecxlusion i always need to google. In fact, since I know
> about the Shade plugin I am always angry with people who force me make
> my pom.xml look even more messy with exclusions.
No one is arguing for non-optional dependencies. I also find projects
requiring exclusions lame. The way dependencies are currently declared
in log4j is sub-optimal (to put it politely) and should only be taken
as an example of what not to do. However, the current approach should
not serve as justification for forcing the pendulum too far in the
other direction. More below.
> That being said, currently I see the following modules below log4j-parent:
>
> log4j-parent
> +--log4j-core
> +--log4j-chainsaw
> +--log4j-lf5
> +--log4j-smtpappender
> +--log4j-ee (* contains the code whic uses Geronimo dependencies)
> +--log4j-ntdll (* pending NAR plugin evaluation)
This makes sense. As stated earlier, I'd recommend merging log4j-ee
(more precisely the o.a.log4j.net package) with log4j-core. It's just
a recommendation, feel free to ignore.
Cheers,
--
Ceki
http://twitter.com/#!/ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Christian Grobmeier <gr...@gmail.com>.
On Tue, Jun 5, 2012 at 5:35 PM, ceki <ce...@qos.ch> wrote:
> Right. Lf5 and chainsaw merit to be in different projects. You are also
> right to point out that I had module and project confused. If the
> modules have different release cycles they should be in different
> projects.
There is currently no one working on Lf5 or chainsaw1 to my knowledge.
Therefore I'd lets make them modules, as they will most likely not see
a release outside log4j1.x
> My point about separately documenting lof4j-uber.jar and the log4j-*
> jars remains valid though.
I don't see a big issue here.
Many projects describe how projects can be included on their homepage.
It can be seen easily that a new dependency needs to go in.
As for the Uber.jar, the shade plugin might help:
http://maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html
(not tried)
Many people I know complain about the dependency issues in log4j
(meaning: using javax.* etc)
My guess is that using multiple modules might not do harm to many of
them, just ease their life.
If we just modularize the things which need the dependencies, like the
appender, we have a good chance
a lot of people will not reckognize the change (only guessing)
>>> As for flagging it as
>>> optional, well, just document the dependency. If the o.a.log4j.net
>>> module is separate, then you still have to document the existence fo
>>> the log4j-net module (obviously). Compare that to documenting the
>>> javax.mail dependency. I am not sure the former approach compares that
>>> favorably from the user's point of view.
>>
>>
>> Maven repositories come with search engines. What I usually do when I
>> need an artifact is using a search engine, like Jarvana, MVNRepository
>> etc.
>> For example, I have a "NoClassDefFoundError" or a
>> "ClassNotFoundException", pick the class and put it in the search
>> engine and, et voilà, you have your artifact.
>
> Yes, but the same argument applies to javax.mail.Session. :-)
I think Documentation for maven users which tell them what to include
is much more easier than knowing what to exclude. Inclusion is
standard, for ecxlusion i always need to google. In fact, since I know
about the Shade plugin I am always angry with people who force me make
my pom.xml look even more messy with exclusions.
That being said, currently I see the following modules below log4j-parent:
log4j-parent
+--log4j-core
+--log4j-chainsaw
+--log4j-lf5
+--log4j-smtpappender
+--log4j-ee (* contains the code whic uses Geronimo dependencies)
+--log4j-ntdll (* pending NAR plugin evaluation)
I would like to kick "performance" and "contrib". Ceki mentioned it
would be possible without big harm. I have looked a little bit through
it and I can't find a reason to keep them.
Have I missed something? Did I overdo it? Let me know.
In the parent pom of the organization branch:
http://svn.apache.org/repos/asf/logging/log4j/branches/log4j12-bz53299/
Is the Geronimo Specs listed as dependency. Anybody knows for what it is?
Cheers
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by ceki <ce...@qos.ch>.
On 05.06.2012 17:13, Antonio Petrelli wrote:
> 2012/6/5 ceki<ce...@qos.ch>:
>>
>> Lumping all modules into one in addition to the smaller modules
>> creates two separate packaging branches which must be maintained and
>> documented separately. It's just not a valid option for such a widely
>> used project such as log4j.
>
> You are confusing modules with projects.
> A modular project, i.e. a "pom" parent project with submodules, is
> going to be released altogether. They won't be maintained separately,
> only code is separated.
> Probably lf5 and chainsaw need a different *project* on their own.
Right. Lf5 and chainsaw merit to be in different projects. You are also
right to point out that I had module and project confused. If the
modules have different release cycles they should be in different
projects.
My point about separately documenting lof4j-uber.jar and the log4j-*
jars remains valid though.
>> Including java.mail as a non-optional transitive dependency is out of
>> question. Is anyone suggesting that approach?
>
> This is in fact how now it works, see the dependencies:
> http://mvnrepository.com/artifact/log4j/log4j/1.2.16
> So in my project I have to exclude dependencies.
I had nothing to do with that decision. Anyway, I don't think anyone
is still advocating non-optional deps for javax.mail.
>> As for flagging it as
>> optional, well, just document the dependency. If the o.a.log4j.net
>> module is separate, then you still have to document the existence fo
>> the log4j-net module (obviously). Compare that to documenting the
>> javax.mail dependency. I am not sure the former approach compares that
>> favorably from the user's point of view.
>
> Maven repositories come with search engines. What I usually do when I
> need an artifact is using a search engine, like Jarvana, MVNRepository
> etc.
> For example, I have a "NoClassDefFoundError" or a
> "ClassNotFoundException", pick the class and put it in the search
> engine and, et voilà, you have your artifact.
Yes, but the same argument applies to javax.mail.Session. :-)
> Antonio
Cheers,
--
Ceki
http://twitter.com/#!/ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Antonio Petrelli <an...@gmail.com>.
2012/6/5 ceki <ce...@qos.ch>:
> On 05.06.2012 14:53, Antonio Petrelli wrote:
>>
>> 2012/6/5 ceki<ce...@qos.ch>:
>>>
>>> On 01.06.2012 04:41, Ralph Goers wrote:
>>>>
>>>>
>>>> If you don't do that then you end up with a bunch of optional
>>>> dependencies that you will forget to include or a bunch of required
>>>> dependencies that you may not really need.
>>>>
>>>> Separating the API from the impl is useful as it keeps users from
>>>> accessing stuff that wasn't meant to be public - which is one of the
>>>> more serious problems in 1.x.
>>>>
>>>> Ralph
>>>
>>>
>>>
>>> Agreed. Separating chainsaw and lf5 into new modules is most
>>> reasonable. However, modularization can be easily overdone. Assuming
>>> the code in org.apache.log4j.net has not changed much since the last
>>> time I looked, I would recommend that the org.apache.log4j.net be part
>>> of the core module, not separate.
>>
>>
>> It's not a question of the module themselves, but a question about the
>> dependency they carry with them.
>> In this case, "net" module carries the javax.mail dependency, that you
>> need only if you want to use it.
>
>
> Good point regarding javax.mail.
>
> Dependencies is one criteria for modularizing. Another criteria is the
> release cycle. If the log4j-net module is always released at the same
> time as log4j-core, then it *may* make sense to merge them. Note that
> the release cycles for chainsaw and respectively lf5 are radically
> different. As for the javax.mail dependency, documenting javax.mail as
> dependency for SMTPAppender may suffice.
>
> Lumping all modules into one in addition to the smaller modules
> creates two separate packaging branches which must be maintained and
> documented separately. It's just not a valid option for such a widely
> used project such as log4j.
You are confusing modules with projects.
A modular project, i.e. a "pom" parent project with submodules, is
going to be released altogether. They won't be maintained separately,
only code is separated.
Probably lf5 and chainsaw need a different *project* on their own.
>
>
>> IOW, you should put yourself in the shoes of the Maven users: if
>> he/she does not want to use mail, he/she has to exclude it. If you
>> flag it as optional, it is not obvious for the user that he/she has to
>> include it.
>
>
> Including java.mail as a non-optional transitive dependency is out of
> question. Is anyone suggesting that approach?
This is in fact how now it works, see the dependencies:
http://mvnrepository.com/artifact/log4j/log4j/1.2.16
So in my project I have to exclude dependencies.
> As for flagging it as
> optional, well, just document the dependency. If the o.a.log4j.net
> module is separate, then you still have to document the existence fo
> the log4j-net module (obviously). Compare that to documenting the
> javax.mail dependency. I am not sure the former approach compares that
> favorably from the user's point of view.
Maven repositories come with search engines. What I usually do when I
need an artifact is using a search engine, like Jarvana, MVNRepository
etc.
For example, I have a "NoClassDefFoundError" or a
"ClassNotFoundException", pick the class and put it in the search
engine and, et voilà, you have your artifact.
>> So guess what is the solution? Right, modules :-)
>
>
> As should be apparent from the above, it's not so clear cut to me. :-)
I think that, clearing the difference between a module and a project,
you will be convinced.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by ceki <ce...@qos.ch>.
On 05.06.2012 14:53, Antonio Petrelli wrote:
> 2012/6/5 ceki<ce...@qos.ch>:
>> On 01.06.2012 04:41, Ralph Goers wrote:
>>>
>>> If you don't do that then you end up with a bunch of optional
>>> dependencies that you will forget to include or a bunch of required
>>> dependencies that you may not really need.
>>>
>>> Separating the API from the impl is useful as it keeps users from
>>> accessing stuff that wasn't meant to be public - which is one of the
>>> more serious problems in 1.x.
>>>
>>> Ralph
>>
>>
>> Agreed. Separating chainsaw and lf5 into new modules is most
>> reasonable. However, modularization can be easily overdone. Assuming
>> the code in org.apache.log4j.net has not changed much since the last
>> time I looked, I would recommend that the org.apache.log4j.net be part
>> of the core module, not separate.
>
> It's not a question of the module themselves, but a question about the
> dependency they carry with them.
> In this case, "net" module carries the javax.mail dependency, that you
> need only if you want to use it.
Good point regarding javax.mail.
Dependencies is one criteria for modularizing. Another criteria is the
release cycle. If the log4j-net module is always released at the same
time as log4j-core, then it *may* make sense to merge them. Note that
the release cycles for chainsaw and respectively lf5 are radically
different. As for the javax.mail dependency, documenting javax.mail as
dependency for SMTPAppender may suffice.
Lumping all modules into one in addition to the smaller modules
creates two separate packaging branches which must be maintained and
documented separately. It's just not a valid option for such a widely
used project such as log4j.
> IOW, you should put yourself in the shoes of the Maven users: if
> he/she does not want to use mail, he/she has to exclude it. If you
> flag it as optional, it is not obvious for the user that he/she has to
> include it.
Including java.mail as a non-optional transitive dependency is out of
question. Is anyone suggesting that approach? As for flagging it as
optional, well, just document the dependency. If the o.a.log4j.net
module is separate, then you still have to document the existence fo
the log4j-net module (obviously). Compare that to documenting the
javax.mail dependency. I am not sure the former approach compares that
favorably from the user's point of view.
> So guess what is the solution? Right, modules :-)
As should be apparent from the above, it's not so clear cut to me. :-)
> Antonio
--
Ceki
http://twitter.com/#!/ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Antonio Petrelli <an...@gmail.com>.
2012/6/5 ceki <ce...@qos.ch>:
> On 01.06.2012 04:41, Ralph Goers wrote:
>>
>> If you don't do that then you end up with a bunch of optional
>> dependencies that you will forget to include or a bunch of required
>> dependencies that you may not really need.
>>
>> Separating the API from the impl is useful as it keeps users from
>> accessing stuff that wasn't meant to be public - which is one of the
>> more serious problems in 1.x.
>>
>> Ralph
>
>
> Agreed. Separating chainsaw and lf5 into new modules is most
> reasonable. However, modularization can be easily overdone. Assuming
> the code in org.apache.log4j.net has not changed much since the last
> time I looked, I would recommend that the org.apache.log4j.net be part
> of the core module, not separate.
It's not a question of the module themselves, but a question about the
dependency they carry with them.
In this case, "net" module carries the javax.mail dependency, that you
need only if you want to use it.
IOW, you should put yourself in the shoes of the Maven users: if
he/she does not want to use mail, he/she has to exclude it. If you
flag it as optional, it is not obvious for the user that he/she has to
include it.
So guess what is the solution? Right, modules :-)
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by ceki <ce...@qos.ch>.
On 01.06.2012 04:41, Ralph Goers wrote:
> If you don't do that then you end up with a bunch of optional
> dependencies that you will forget to include or a bunch of required
> dependencies that you may not really need.
>
> Separating the API from the impl is useful as it keeps users from
> accessing stuff that wasn't meant to be public - which is one of the
> more serious problems in 1.x.
>
> Ralph
Agreed. Separating chainsaw and lf5 into new modules is most
reasonable. However, modularization can be easily overdone. Assuming
the code in org.apache.log4j.net has not changed much since the last
time I looked, I would recommend that the org.apache.log4j.net be part
of the core module, not separate.
--
Ceki
http://twitter.com/#!/ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Ralph Goers <rg...@apache.org>.
If you don't do that then you end up with a bunch of optional dependencies that you will forget to include or a bunch of required dependencies that you may not really need.
Separating the API from the impl is useful as it keeps users from accessing stuff that wasn't meant to be public - which is one of the more serious problems in 1.x.
Ralph
On May 31, 2012, at 2:37 PM, Gary Gregory <ga...@gmail.com> wrote:
>
>
> On Thu, May 31, 2012 at 5:24 PM, Jacob Kjome <ho...@visi.com> wrote:
>
> The main point is separate the tools from the library. That means each of Lf5, Chainsaw1, and Chainsaw2 have their own artifacts, separate from Log4j.jar. That's all. This will make Log4j.jar much smaller (by extracting Lf5 and Chainsaw1). Only users that specifically want to use the tools will need to get their appropriate jar. And all will depend upon Log4j.jar. That really doesn't seem too complex to me.
>
> Well, I agree on splitting the logging from the UI, it's the all the little jars this-over-that that-over-this, that I find lame.
>
> G
>
>
> Jake
>
>
> On Thu, 31 May 2012 17:15:47 -0400
> Gary Gregory <ga...@gmail.com> wrote:
> My beef is that I do not want 10 jars to pick from, this is a low level
> components, give me one jar to rule them all. Or at least give me the
> option to pick an all-in-one jar. For those who want to save 10KB here and
> there, they can cherry pick I suppose.
>
> Gary
>
> On Thu, May 31, 2012 at 3:52 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>
> Log4j 2 is already a multi-module build. I am not at all sure why you
> would want to expend all this effort on a 1.3 when 2.0 should be our next
> target.
>
> Ralph
>
> On May 31, 2012, at 12:46 PM, Antonio Petrelli wrote:
>
> > Hi all
> > following Christian's rant at Google+:
> > https://plus.google.com/102440702937210603575/posts/HbD1fa9NGHY
> > I started forking Log4j at GitHub:
> > https://github.com/apetrelli/log4j
> >
> > The first step I did is providing a stub for a multi-module build.
> > Assuming that Log4j should be multi-module is fundamental. I don't
> > want to start a Maven lesson, you can see anywhere about the benefit
> > of having separated modules with well-identified dependencies.
> > For now, I have only a parent project (pom type) and a "core" project,
> > that soon will go on a diet, moving code in other modules.
> >
> > About the version, you might notice that I put "1.3.0-SNAPSHOT"
> > version because, at the end, you will not recognize Log4j 1.2.x
> > artifacts at all. They will be more numerous, smaller and with
> > specific dependencies.
> >
> > Feel free to discuss or to help via forking.
> >
> > Best regards
> > Antonio
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Antonio Petrelli <an...@gmail.com>.
2012/6/1 Christian Grobmeier <gr...@gmail.com>:
> On Fri, Jun 1, 2012 at 2:49 PM, Antonio Petrelli
> <an...@gmail.com> wrote:
>> 2012/6/1 Christian Grobmeier <gr...@gmail.com>:
>>> Suggestion: the easy part is to make chainsaw and lf5 classes a
>>> module. I have nuked them but Jacob requested they come back :-) These
>>> are all GUI related stuff. Next thing I'll do is create the module
>>> folders and get the code back to these.
>>> Then we can move the rest into a "core" folder and create the parent pom.
>>>
>>> Do you think this would be an acceptable move?
>>
>> So if I understand you well, you would like to create a core, simply
>> by removing the GUI-related stuff?
>> I think that, if a reorganization has to be done, it should be done
>> the right way.
>
> I think like that:
>
> /pom.xml <-- parent
> /core/src/main/java <-- Just logging classes
> /lf5/src/main/java
> /chainsaw/src/main/java
>
> etc
> The core might need some more extractions but this could be the first step.
>
>
>>> https://github.com/astubbs/log4j/tree/modulriseify
>>
>> With the exception of directory naming, it seems like a good job. Why
>> did'nt you take it in consideration 2 years ago?
>
> I was not really deep into log4j back then (still fighting) and why
> this has not been included: don't know. But better late than never.
>
OK. I think I will merge and tweak it. Apparently, it needs only a
little of polishing (pointing to apache-master, renaming the
directories as the names of modules, using the standard Apache release
system [that uses Nexus]).
Thanks for the pointer (to Anthony too, if he still reads that).
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Christian Grobmeier <gr...@gmail.com>.
On Fri, Jun 1, 2012 at 2:49 PM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2012/6/1 Christian Grobmeier <gr...@gmail.com>:
>> Suggestion: the easy part is to make chainsaw and lf5 classes a
>> module. I have nuked them but Jacob requested they come back :-) These
>> are all GUI related stuff. Next thing I'll do is create the module
>> folders and get the code back to these.
>> Then we can move the rest into a "core" folder and create the parent pom.
>>
>> Do you think this would be an acceptable move?
>
> So if I understand you well, you would like to create a core, simply
> by removing the GUI-related stuff?
> I think that, if a reorganization has to be done, it should be done
> the right way.
I think like that:
/pom.xml <-- parent
/core/src/main/java <-- Just logging classes
/lf5/src/main/java
/chainsaw/src/main/java
etc
The core might need some more extractions but this could be the first step.
>> https://github.com/astubbs/log4j/tree/modulriseify
>
> With the exception of directory naming, it seems like a good job. Why
> did'nt you take it in consideration 2 years ago?
I was not really deep into log4j back then (still fighting) and why
this has not been included: don't know. But better late than never.
Cheers
Christian
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Antonio Petrelli <an...@gmail.com>.
2012/6/1 Christian Grobmeier <gr...@gmail.com>:
>> Yes believe me, we need modules. Provided scope's use case is not the
>> one that you mentioned. You can mark a dependency as "optional" but
>> then you leave the burden of adding a dependency to the user, without
>> the benefit of transitive dependencies. It's not so obvious.
>> The best thing is to have modules, with explicit and minimal
>> dependencies. So if a user wants the Log4j support for NT logging,
>> he/she will add that specific module.
>
> Suggestion: the easy part is to make chainsaw and lf5 classes a
> module. I have nuked them but Jacob requested they come back :-) These
> are all GUI related stuff. Next thing I'll do is create the module
> folders and get the code back to these.
> Then we can move the rest into a "core" folder and create the parent pom.
>
> Do you think this would be an acceptable move?
So if I understand you well, you would like to create a core, simply
by removing the GUI-related stuff?
I think that, if a reorganization has to be done, it should be done
the right way.
>
> Not sure we should do it exactly like Anthony did it here, but this is
> for sure inspiring:
> https://github.com/astubbs/log4j/tree/modulriseify
>
> I already wrote Anthony an mail to rejoin :-)
>
With the exception of directory naming, it seems like a good job. Why
did'nt you take it in consideration 2 years ago?
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Christian Grobmeier <gr...@gmail.com>.
> Yes believe me, we need modules. Provided scope's use case is not the
> one that you mentioned. You can mark a dependency as "optional" but
> then you leave the burden of adding a dependency to the user, without
> the benefit of transitive dependencies. It's not so obvious.
> The best thing is to have modules, with explicit and minimal
> dependencies. So if a user wants the Log4j support for NT logging,
> he/she will add that specific module.
Suggestion: the easy part is to make chainsaw and lf5 classes a
module. I have nuked them but Jacob requested they come back :-) These
are all GUI related stuff. Next thing I'll do is create the module
folders and get the code back to these.
Then we can move the rest into a "core" folder and create the parent pom.
Do you think this would be an acceptable move?
Not sure we should do it exactly like Anthony did it here, but this is
for sure inspiring:
https://github.com/astubbs/log4j/tree/modulriseify
I already wrote Anthony an mail to rejoin :-)
Cheers
Christian
>
>> Another important thing for me: extract the windows related build
>> stuff. It caused much pain.
>
> I think that the Nar plugin could help, but I will check it when the
> right time comes.
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Antonio Petrelli <an...@gmail.com>.
2012/6/1 Christian Grobmeier <gr...@gmail.com>:
> On Thu, May 31, 2012 at 11:37 PM, Gary Gregory <ga...@gmail.com> wrote:
>> On Thu, May 31, 2012 at 5:24 PM, Jacob Kjome <ho...@visi.com> wrote:
>>> The main point is separate the tools from the library. That means each of
>>> Lf5, Chainsaw1, and Chainsaw2 have their own artifacts, separate from
>>> Log4j.jar. That's all. This will make Log4j.jar much smaller (by
>>> extracting Lf5 and Chainsaw1). Only users that specifically want to use the
>>> tools will need to get their appropriate jar. And all will depend upon
>>> Log4j.jar. That really doesn't seem too complex to me.
>>
>> Well, I agree on splitting the logging from the UI, it's the all the little
>> jars this-over-that that-over-this, that I find lame.
>
> Agreed, no need to split "everything" to save space. But UI should be
> out, and we need to take care on JMX etc dependencies. Those can
> really cause headache to some users. Not sure if we need modules here,
> maybe another option comes up (like change from compiled scope to
> provided)
Yes believe me, we need modules. Provided scope's use case is not the
one that you mentioned. You can mark a dependency as "optional" but
then you leave the burden of adding a dependency to the user, without
the benefit of transitive dependencies. It's not so obvious.
The best thing is to have modules, with explicit and minimal
dependencies. So if a user wants the Log4j support for NT logging,
he/she will add that specific module.
> Another important thing for me: extract the windows related build
> stuff. It caused much pain.
I think that the Nar plugin could help, but I will check it when the
right time comes.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Christian Grobmeier <gr...@gmail.com>.
On Thu, May 31, 2012 at 11:37 PM, Gary Gregory <ga...@gmail.com> wrote:
> On Thu, May 31, 2012 at 5:24 PM, Jacob Kjome <ho...@visi.com> wrote:
>> The main point is separate the tools from the library. That means each of
>> Lf5, Chainsaw1, and Chainsaw2 have their own artifacts, separate from
>> Log4j.jar. That's all. This will make Log4j.jar much smaller (by
>> extracting Lf5 and Chainsaw1). Only users that specifically want to use the
>> tools will need to get their appropriate jar. And all will depend upon
>> Log4j.jar. That really doesn't seem too complex to me.
>
> Well, I agree on splitting the logging from the UI, it's the all the little
> jars this-over-that that-over-this, that I find lame.
Agreed, no need to split "everything" to save space. But UI should be
out, and we need to take care on JMX etc dependencies. Those can
really cause headache to some users. Not sure if we need modules here,
maybe another option comes up (like change from compiled scope to
provided)
Another important thing for me: extract the windows related build
stuff. It caused much pain.
>
> G
>>
>>
>>
>> Jake
>>
>>
>> On Thu, 31 May 2012 17:15:47 -0400
>> Gary Gregory <ga...@gmail.com> wrote:
>>>
>>> My beef is that I do not want 10 jars to pick from, this is a low level
>>> components, give me one jar to rule them all. Or at least give me the
>>> option to pick an all-in-one jar. For those who want to save 10KB here
>>> and
>>> there, they can cherry pick I suppose.
>>>
>>> Gary
>>>
>>> On Thu, May 31, 2012 at 3:52 PM, Ralph Goers
>>> <ra...@dslextreme.com>wrote:
>>>
>>>> Log4j 2 is already a multi-module build. I am not at all sure why you
>>>> would want to expend all this effort on a 1.3 when 2.0 should be our
>>>> next
>>>> target.
>>>>
>>>> Ralph
>>>>
>>>> On May 31, 2012, at 12:46 PM, Antonio Petrelli wrote:
>>>>
>>>> > Hi all
>>>> > following Christian's rant at Google+:
>>>> > https://plus.google.com/102440702937210603575/posts/HbD1fa9NGHY
>>>> > I started forking Log4j at GitHub:
>>>> > https://github.com/apetrelli/log4j
>>>> >
>>>> > The first step I did is providing a stub for a multi-module build.
>>>> > Assuming that Log4j should be multi-module is fundamental. I don't
>>>> > want to start a Maven lesson, you can see anywhere about the benefit
>>>> > of having separated modules with well-identified dependencies.
>>>> > For now, I have only a parent project (pom type) and a "core" project,
>>>> > that soon will go on a diet, moving code in other modules.
>>>> >
>>>> > About the version, you might notice that I put "1.3.0-SNAPSHOT"
>>>> > version because, at the end, you will not recognize Log4j 1.2.x
>>>> > artifacts at all. They will be more numerous, smaller and with
>>>> > specific dependencies.
>>>> >
>>>> > Feel free to discuss or to help via forking.
>>>> >
>>>> > Best regards
>>>> > Antonio
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>> >
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>>>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, May 31, 2012 at 5:24 PM, Jacob Kjome <ho...@visi.com> wrote:
>
> The main point is separate the tools from the library. That means each of
> Lf5, Chainsaw1, and Chainsaw2 have their own artifacts, separate from
> Log4j.jar. That's all. This will make Log4j.jar much smaller (by
> extracting Lf5 and Chainsaw1). Only users that specifically want to use
> the tools will need to get their appropriate jar. And all will depend upon
> Log4j.jar. That really doesn't seem too complex to me.
>
Well, I agree on splitting the logging from the UI, it's the all the little
jars this-over-that that-over-this, that I find lame.
G
>
>
> Jake
>
>
> On Thu, 31 May 2012 17:15:47 -0400
> Gary Gregory <ga...@gmail.com> wrote:
>
>> My beef is that I do not want 10 jars to pick from, this is a low level
>> components, give me one jar to rule them all. Or at least give me the
>> option to pick an all-in-one jar. For those who want to save 10KB here and
>> there, they can cherry pick I suppose.
>>
>> Gary
>>
>> On Thu, May 31, 2012 at 3:52 PM, Ralph Goers <ra...@dslextreme.com>
>> **wrote:
>>
>> Log4j 2 is already a multi-module build. I am not at all sure why you
>>> would want to expend all this effort on a 1.3 when 2.0 should be our next
>>> target.
>>>
>>> Ralph
>>>
>>> On May 31, 2012, at 12:46 PM, Antonio Petrelli wrote:
>>>
>>> > Hi all
>>> > following Christian's rant at Google+:
>>> > https://plus.google.com/**102440702937210603575/posts/**HbD1fa9NGHY<https://plus.google.com/102440702937210603575/posts/HbD1fa9NGHY>
>>> > I started forking Log4j at GitHub:
>>> > https://github.com/apetrelli/**log4j<https://github.com/apetrelli/log4j>
>>> >
>>> > The first step I did is providing a stub for a multi-module build.
>>> > Assuming that Log4j should be multi-module is fundamental. I don't
>>> > want to start a Maven lesson, you can see anywhere about the benefit
>>> > of having separated modules with well-identified dependencies.
>>> > For now, I have only a parent project (pom type) and a "core" project,
>>> > that soon will go on a diet, moving code in other modules.
>>> >
>>> > About the version, you might notice that I put "1.3.0-SNAPSHOT"
>>> > version because, at the end, you will not recognize Log4j 1.2.x
>>> > artifacts at all. They will be more numerous, smaller and with
>>> > specific dependencies.
>>> >
>>> > Feel free to discuss or to help via forking.
>>> >
>>> > Best regards
>>> > Antonio
>>> >
>>> > ------------------------------**------------------------------**
>>> ---------
>>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.**apache.org<lo...@logging.apache.org>
>>> > For additional commands, e-mail: log4j-dev-help@logging.apache.**org<lo...@logging.apache.org>
>>> >
>>>
>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.**apache.org<lo...@logging.apache.org>
>>> For additional commands, e-mail: log4j-dev-help@logging.apache.**org<lo...@logging.apache.org>
>>>
>>>
>>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http:/**/bit.ly/ECvg0<http://bit.ly/ECvg0>
>> Spring Batch in Action: <http://s.apache.org/HOq>http:**//bit.ly/bqpbCK<http://bit.ly/bqpbCK>
>>
>> Blog: http://garygregory.wordpress.**com<http://garygregory.wordpress.com>
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.**apache.org<lo...@logging.apache.org>
> For additional commands, e-mail: log4j-dev-help@logging.apache.**org<lo...@logging.apache.org>
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Jacob Kjome <ho...@visi.com>.
The main point is separate the tools from the library. That means each of
Lf5, Chainsaw1, and Chainsaw2 have their own artifacts, separate from
Log4j.jar. That's all. This will make Log4j.jar much smaller (by extracting
Lf5 and Chainsaw1). Only users that specifically want to use the tools will
need to get their appropriate jar. And all will depend upon Log4j.jar. That
really doesn't seem too complex to me.
Jake
On Thu, 31 May 2012 17:15:47 -0400
Gary Gregory <ga...@gmail.com> wrote:
> My beef is that I do not want 10 jars to pick from, this is a low level
> components, give me one jar to rule them all. Or at least give me the
> option to pick an all-in-one jar. For those who want to save 10KB here and
> there, they can cherry pick I suppose.
>
> Gary
>
> On Thu, May 31, 2012 at 3:52 PM, Ralph Goers
><ra...@dslextreme.com>wrote:
>
>> Log4j 2 is already a multi-module build. I am not at all sure why you
>> would want to expend all this effort on a 1.3 when 2.0 should be our next
>> target.
>>
>> Ralph
>>
>> On May 31, 2012, at 12:46 PM, Antonio Petrelli wrote:
>>
>> > Hi all
>> > following Christian's rant at Google+:
>> > https://plus.google.com/102440702937210603575/posts/HbD1fa9NGHY
>> > I started forking Log4j at GitHub:
>> > https://github.com/apetrelli/log4j
>> >
>> > The first step I did is providing a stub for a multi-module build.
>> > Assuming that Log4j should be multi-module is fundamental. I don't
>> > want to start a Maven lesson, you can see anywhere about the benefit
>> > of having separated modules with well-identified dependencies.
>> > For now, I have only a parent project (pom type) and a "core" project,
>> > that soon will go on a diet, moving code in other modules.
>> >
>> > About the version, you might notice that I put "1.3.0-SNAPSHOT"
>> > version because, at the end, you will not recognize Log4j 1.2.x
>> > artifacts at all. They will be more numerous, smaller and with
>> > specific dependencies.
>> >
>> > Feel free to discuss or to help via forking.
>> >
>> > Best regards
>> > Antonio
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Ralph Goers <ra...@dslextreme.com>.
On Jun 1, 2012, at 12:22 AM, Antonio Petrelli wrote:
> 2012/5/31 Gary Gregory <ga...@gmail.com>:
>> My beef is that I do not want 10 jars to pick from, this is a low level
>> components, give me one jar to rule them all. Or at least give me the option
>> to pick an all-in-one jar. For those who want to save 10KB here and there,
>> they can cherry pick I suppose.
>
> You can have best of both worlds, by using the maven-shade-plugin to
> create an "uberjar". I already did it for Velocity:
> http://svn.apache.org/repos/asf/velocity/engine/trunk/velocity-engine-uberjar/
> Moreover, your argument is the one of a non-Maven user, because a
> Maven user is not worried to add a new dependency because he does not
> need to download an artifact manually.
Using the shade plugin to combine the API and Core contents together makes sense to me. However, I still wouldn't add the support for SLF4J, Commons Logging, etc to that jar.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Christian Grobmeier <gr...@gmail.com>.
On Fri, Jun 1, 2012 at 9:22 AM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2012/5/31 Gary Gregory <ga...@gmail.com>:
>> My beef is that I do not want 10 jars to pick from, this is a low level
>> components, give me one jar to rule them all. Or at least give me the option
>> to pick an all-in-one jar. For those who want to save 10KB here and there,
>> they can cherry pick I suppose.
>
> You can have best of both worlds, by using the maven-shade-plugin to
> create an "uberjar". I already did it for Velocity:
> http://svn.apache.org/repos/asf/velocity/engine/trunk/velocity-engine-uberjar/
> Moreover, your argument is the one of a non-Maven user, because a
> Maven user is not worried to add a new dependency because he does not
> need to download an artifact manually.
Shade is actually an option. Lets look at it for some of the heavy
dependencies maybe.
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Antonio Petrelli <an...@gmail.com>.
2012/5/31 Gary Gregory <ga...@gmail.com>:
> My beef is that I do not want 10 jars to pick from, this is a low level
> components, give me one jar to rule them all. Or at least give me the option
> to pick an all-in-one jar. For those who want to save 10KB here and there,
> they can cherry pick I suppose.
You can have best of both worlds, by using the maven-shade-plugin to
create an "uberjar". I already did it for Velocity:
http://svn.apache.org/repos/asf/velocity/engine/trunk/velocity-engine-uberjar/
Moreover, your argument is the one of a non-Maven user, because a
Maven user is not worried to add a new dependency because he does not
need to download an artifact manually.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Gary Gregory <ga...@gmail.com>.
My beef is that I do not want 10 jars to pick from, this is a low level
components, give me one jar to rule them all. Or at least give me the
option to pick an all-in-one jar. For those who want to save 10KB here and
there, they can cherry pick I suppose.
Gary
On Thu, May 31, 2012 at 3:52 PM, Ralph Goers <ra...@dslextreme.com>wrote:
> Log4j 2 is already a multi-module build. I am not at all sure why you
> would want to expend all this effort on a 1.3 when 2.0 should be our next
> target.
>
> Ralph
>
> On May 31, 2012, at 12:46 PM, Antonio Petrelli wrote:
>
> > Hi all
> > following Christian's rant at Google+:
> > https://plus.google.com/102440702937210603575/posts/HbD1fa9NGHY
> > I started forking Log4j at GitHub:
> > https://github.com/apetrelli/log4j
> >
> > The first step I did is providing a stub for a multi-module build.
> > Assuming that Log4j should be multi-module is fundamental. I don't
> > want to start a Maven lesson, you can see anywhere about the benefit
> > of having separated modules with well-identified dependencies.
> > For now, I have only a parent project (pom type) and a "core" project,
> > that soon will go on a diet, moving code in other modules.
> >
> > About the version, you might notice that I put "1.3.0-SNAPSHOT"
> > version because, at the end, you will not recognize Log4j 1.2.x
> > artifacts at all. They will be more numerous, smaller and with
> > specific dependencies.
> >
> > Feel free to discuss or to help via forking.
> >
> > Best regards
> > Antonio
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-dev-help@logging.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Ralph Goers <ra...@dslextreme.com>.
Log4j 2 is already a multi-module build. I am not at all sure why you would want to expend all this effort on a 1.3 when 2.0 should be our next target.
Ralph
On May 31, 2012, at 12:46 PM, Antonio Petrelli wrote:
> Hi all
> following Christian's rant at Google+:
> https://plus.google.com/102440702937210603575/posts/HbD1fa9NGHY
> I started forking Log4j at GitHub:
> https://github.com/apetrelli/log4j
>
> The first step I did is providing a stub for a multi-module build.
> Assuming that Log4j should be multi-module is fundamental. I don't
> want to start a Maven lesson, you can see anywhere about the benefit
> of having separated modules with well-identified dependencies.
> For now, I have only a parent project (pom type) and a "core" project,
> that soon will go on a diet, moving code in other modules.
>
> About the version, you might notice that I put "1.3.0-SNAPSHOT"
> version because, at the end, you will not recognize Log4j 1.2.x
> artifacts at all. They will be more numerous, smaller and with
> specific dependencies.
>
> Feel free to discuss or to help via forking.
>
> Best regards
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Christian Grobmeier <gr...@gmail.com>.
On Fri, Jun 1, 2012 at 4:33 PM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2012/6/1 Christian Grobmeier <gr...@gmail.com>:
>> Antonio,
>>
>> I just realized you already have created a parent pom and move the
>> code into log4j-core.
>>
>> is it possible you provide a patch for this? I would like to apply it
>> and then I could bring back the mentioned chainsaw/lf5 code, which is
>> currently not in your repos.
>
> A patch is worthless in case of change of getting from Git, it is
> better to use pulls. For a guide:
> http://wiki.apache.org/general/GitAtApache
Thanks! Looks good.
> Anyway, again, the job that Anthony did needs to be evaluated, because
> it seems nice. And remember that Git is much better that SVN at
> managing changes.
Yes, fine. I missed that mail, just saw it.
Anyway, in the current trunk "chainsaw" and "lf5" are missing. If you
merge and see the chance, you can put them back into the trunk. I was
to fast here.
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Christian Grobmeier <gr...@gmail.com>.
On Fri, Jun 1, 2012 at 4:41 PM, Antonio Petrelli
<an...@gmail.com> wrote:
> 2012/6/1 Antonio Petrelli <an...@gmail.com>:
>> A patch is worthless in case of change of getting from Git
>
> What I wrote? Sorry I meant "a patch is worthless in case of change of
> *directories in SVN*".
In any way, I got the message.
>
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Antonio Petrelli <an...@gmail.com>.
2012/6/1 Antonio Petrelli <an...@gmail.com>:
> A patch is worthless in case of change of getting from Git
What I wrote? Sorry I meant "a patch is worthless in case of change of
*directories in SVN*".
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Antonio Petrelli <an...@gmail.com>.
2012/6/1 Christian Grobmeier <gr...@gmail.com>:
> Antonio,
>
> I just realized you already have created a parent pom and move the
> code into log4j-core.
>
> is it possible you provide a patch for this? I would like to apply it
> and then I could bring back the mentioned chainsaw/lf5 code, which is
> currently not in your repos.
A patch is worthless in case of change of getting from Git, it is
better to use pulls. For a guide:
http://wiki.apache.org/general/GitAtApache
Anyway, again, the job that Anthony did needs to be evaluated, because
it seems nice. And remember that Git is much better that SVN at
managing changes.
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [maven-reorg] Reorganizations ongoing at forked Git repository
Posted by Christian Grobmeier <gr...@gmail.com>.
Antonio,
I just realized you already have created a parent pom and move the
code into log4j-core.
is it possible you provide a patch for this? I would like to apply it
and then I could bring back the mentioned chainsaw/lf5 code, which is
currently not in your repos.
Cheers
On Thu, May 31, 2012 at 9:46 PM, Antonio Petrelli
<an...@gmail.com> wrote:
> Hi all
> following Christian's rant at Google+:
> https://plus.google.com/102440702937210603575/posts/HbD1fa9NGHY
> I started forking Log4j at GitHub:
> https://github.com/apetrelli/log4j
>
> The first step I did is providing a stub for a multi-module build.
> Assuming that Log4j should be multi-module is fundamental. I don't
> want to start a Maven lesson, you can see anywhere about the benefit
> of having separated modules with well-identified dependencies.
> For now, I have only a parent project (pom type) and a "core" project,
> that soon will go on a diet, moving code in other modules.
>
> About the version, you might notice that I put "1.3.0-SNAPSHOT"
> version because, at the end, you will not recognize Log4j 1.2.x
> artifacts at all. They will be more numerous, smaller and with
> specific dependencies.
>
> Feel free to discuss or to help via forking.
>
> Best regards
> Antonio
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
--
http://www.grobmeier.de
https://www.timeandbill.de
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org