Let's talk about the roadmap to 2.0 and 2.1.

[Matt Sicker <bo...@gmail.com>]

I've got a few topics to mention.

1. Should we consider making a 2.0 release branch so that trunk can
continue to be the active development branch? That way we can work on new
things while just ironing out the remaining issues for 2.0 GA in the 2.0
branch. Unless you guys prefer a different branching workflow like trunk
being the stable branch, and then using feature branches.

2. OSGi support. What I'm thinking will be the easiest way to get this
working correctly without having to worry so much about duplicating bundles
would be to simply drop the log4j-osgi modules and just add the OSGi
MANIFEST.MF metadata to our normal releases. This would effectively be good
enough for supporting OSGi bundles in that regard. We can figure out how to
trim down log4j-core independently of anything OSGi. I've already began
work on this by updating the poms for log4j, log4j-api, and log4j-1.2-api.
I'll update the other smaller modules to reflect the updated build process
as well. There may be a slight issue with the log4j-slf4j-impl module due
to how SLF4J expects implementations to be packaged, so I'll take a look
into that as well (and possibly go complain to them if necessary). In fact,
supporting OSGi for some of these modules might not be possible due to
package splits and backwards compatibility.

3. Essentially, I'm thinking that we could separate out all the parts of
log4j-core that use external dependencies with the exception of AsyncLogger
(we could potentially fork lmax-disruptor into our own repository similar
to how Tomcat handles some of their dependencies). That way, we don't need
to worry about optional dependencies, either, because when they're split
up, the new modules can have required dependencies instead (whether it be
an API or a concrete library). If there are any other parts of log4j-core
that rely on external dependencies that we think are popular enough to keep
in log4j-core, please share.

4. Due to how new these modules are, I'm proposing that log4j-streams and
log4j-camel both be slated for release in 2.1 or some future release.
Otherwise, these might hold back our 2.0 release a little bit. Where we
place the code depends on (1) (keep in trunk or make feature branches). Of
course, both modules are independently up for vote on whether to include
them in 2.0. Since I added the log4j-camel module as a sort of experimental
module largely based on the log module in camel-core (which uses SLF4J
instead), I'd like to see this part in 2.1, but not in 2.0 since I've
barely tested it yet (and still need to port more tests to it along with
some integration testing).

5. After addressing the modules thing from (3), we should probably vote on
an RC2 release sometime soon. I'd propose releasing RC2 in the beginning of
May, but I'm open for whenever.

6. What else is left for 2.0? The updated Marker API is almost complete (we
have our own code that needs to be updated to not use the deprecated APIs,
but that might only be unit tests at this point).
-- 
Matt Sicker <bo...@gmail.com>

Re: Let's talk about the roadmap to 2.0 and 2.1.

[Paul Benedict <pb...@apache.org>]

You can also take a page out of JUnit's playbook. They release an
"experimental" jar in each production release so you test out unfinished
features before they become officially supported.


On Thu, Apr 17, 2014 at 4:41 PM, Gary Gregory <ga...@gmail.com>wrote:

> On Thu, Apr 17, 2014 at 4:22 PM, Ralph Goers <ra...@dslextreme.com>wrote:
>
>> 1. I prefer trunk to be the stable branch.  In addition to the 2.0 tag I
>> would also cut a branch when 2.0 is finally released.
>>
>
> +1, ideally we can cut releases at any time out of trunk for log4j.
> Experimentation can be done in branches.
>
> Gary
>
>
>>
>> 2. I could swear we have always generated the OSGi MANIFEST.MF and people
>> said it wasn’t sufficient, but if they aren’t there then I guess I am wrong.
>>
>> 3. I would like to see a list of what would be broken out before we
>> actually do it.
>>
>> 4. I’d like to see 2.0 GA asap, so I agree.
>>
>> 5. A release can be cut at any time. We don’t vote to perform a release,
>> we vote that the release is good to go public.
>>
>> 6. The Marker stuff is done, except for removing the deprecated APIs. We
>> need to finalize the logo.  I don’t know if any outstanding issues are
>> blockers.
>>
>> Ralph
>>
>>
>>
>> On Apr 17, 2014, at 10:51 AM, Matt Sicker <bo...@gmail.com> wrote:
>>
>> I've got a few topics to mention.
>>
>> 1. Should we consider making a 2.0 release branch so that trunk can
>> continue to be the active development branch? That way we can work on new
>> things while just ironing out the remaining issues for 2.0 GA in the 2.0
>> branch. Unless you guys prefer a different branching workflow like trunk
>> being the stable branch, and then using feature branches.
>>
>> 2. OSGi support. What I'm thinking will be the easiest way to get this
>> working correctly without having to worry so much about duplicating bundles
>> would be to simply drop the log4j-osgi modules and just add the OSGi
>> MANIFEST.MF metadata to our normal releases. This would effectively be good
>> enough for supporting OSGi bundles in that regard. We can figure out how to
>> trim down log4j-core independently of anything OSGi. I've already began
>> work on this by updating the poms for log4j, log4j-api, and log4j-1.2-api.
>> I'll update the other smaller modules to reflect the updated build process
>> as well. There may be a slight issue with the log4j-slf4j-impl module due
>> to how SLF4J expects implementations to be packaged, so I'll take a look
>> into that as well (and possibly go complain to them if necessary). In fact,
>> supporting OSGi for some of these modules might not be possible due to
>> package splits and backwards compatibility.
>>
>> 3. Essentially, I'm thinking that we could separate out all the parts of
>> log4j-core that use external dependencies with the exception of AsyncLogger
>> (we could potentially fork lmax-disruptor into our own repository similar
>> to how Tomcat handles some of their dependencies). That way, we don't need
>> to worry about optional dependencies, either, because when they're split
>> up, the new modules can have required dependencies instead (whether it be
>> an API or a concrete library). If there are any other parts of log4j-core
>> that rely on external dependencies that we think are popular enough to keep
>> in log4j-core, please share.
>>
>> 4. Due to how new these modules are, I'm proposing that log4j-streams and
>> log4j-camel both be slated for release in 2.1 or some future release.
>> Otherwise, these might hold back our 2.0 release a little bit. Where we
>> place the code depends on (1) (keep in trunk or make feature branches). Of
>> course, both modules are independently up for vote on whether to include
>> them in 2.0. Since I added the log4j-camel module as a sort of experimental
>> module largely based on the log module in camel-core (which uses SLF4J
>> instead), I'd like to see this part in 2.1, but not in 2.0 since I've
>> barely tested it yet (and still need to port more tests to it along with
>> some integration testing).
>>
>> 5. After addressing the modules thing from (3), we should probably vote
>> on an RC2 release sometime soon. I'd propose releasing RC2 in the beginning
>> of May, but I'm open for whenever.
>>
>> 6. What else is left for 2.0? The updated Marker API is almost complete
>> (we have our own code that needs to be updated to not use the deprecated
>> APIs, but that might only be unit tests at this point).
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
Cheers,
Paul

Re: Let's talk about the roadmap to 2.0 and 2.1.

[Gary Gregory <ga...@gmail.com>]

On Thu, Apr 17, 2014 at 4:22 PM, Ralph Goers <ra...@dslextreme.com>wrote:

> 1. I prefer trunk to be the stable branch.  In addition to the 2.0 tag I
> would also cut a branch when 2.0 is finally released.
>

+1, ideally we can cut releases at any time out of trunk for log4j.
Experimentation can be done in branches.

Gary


>
> 2. I could swear we have always generated the OSGi MANIFEST.MF and people
> said it wasn’t sufficient, but if they aren’t there then I guess I am wrong.
>
> 3. I would like to see a list of what would be broken out before we
> actually do it.
>
> 4. I’d like to see 2.0 GA asap, so I agree.
>
> 5. A release can be cut at any time. We don’t vote to perform a release,
> we vote that the release is good to go public.
>
> 6. The Marker stuff is done, except for removing the deprecated APIs. We
> need to finalize the logo.  I don’t know if any outstanding issues are
> blockers.
>
> Ralph
>
>
>
> On Apr 17, 2014, at 10:51 AM, Matt Sicker <bo...@gmail.com> wrote:
>
> I've got a few topics to mention.
>
> 1. Should we consider making a 2.0 release branch so that trunk can
> continue to be the active development branch? That way we can work on new
> things while just ironing out the remaining issues for 2.0 GA in the 2.0
> branch. Unless you guys prefer a different branching workflow like trunk
> being the stable branch, and then using feature branches.
>
> 2. OSGi support. What I'm thinking will be the easiest way to get this
> working correctly without having to worry so much about duplicating bundles
> would be to simply drop the log4j-osgi modules and just add the OSGi
> MANIFEST.MF metadata to our normal releases. This would effectively be good
> enough for supporting OSGi bundles in that regard. We can figure out how to
> trim down log4j-core independently of anything OSGi. I've already began
> work on this by updating the poms for log4j, log4j-api, and log4j-1.2-api.
> I'll update the other smaller modules to reflect the updated build process
> as well. There may be a slight issue with the log4j-slf4j-impl module due
> to how SLF4J expects implementations to be packaged, so I'll take a look
> into that as well (and possibly go complain to them if necessary). In fact,
> supporting OSGi for some of these modules might not be possible due to
> package splits and backwards compatibility.
>
> 3. Essentially, I'm thinking that we could separate out all the parts of
> log4j-core that use external dependencies with the exception of AsyncLogger
> (we could potentially fork lmax-disruptor into our own repository similar
> to how Tomcat handles some of their dependencies). That way, we don't need
> to worry about optional dependencies, either, because when they're split
> up, the new modules can have required dependencies instead (whether it be
> an API or a concrete library). If there are any other parts of log4j-core
> that rely on external dependencies that we think are popular enough to keep
> in log4j-core, please share.
>
> 4. Due to how new these modules are, I'm proposing that log4j-streams and
> log4j-camel both be slated for release in 2.1 or some future release.
> Otherwise, these might hold back our 2.0 release a little bit. Where we
> place the code depends on (1) (keep in trunk or make feature branches). Of
> course, both modules are independently up for vote on whether to include
> them in 2.0. Since I added the log4j-camel module as a sort of experimental
> module largely based on the log module in camel-core (which uses SLF4J
> instead), I'd like to see this part in 2.1, but not in 2.0 since I've
> barely tested it yet (and still need to port more tests to it along with
> some integration testing).
>
> 5. After addressing the modules thing from (3), we should probably vote on
> an RC2 release sometime soon. I'd propose releasing RC2 in the beginning of
> May, but I'm open for whenever.
>
> 6. What else is left for 2.0? The updated Marker API is almost complete
> (we have our own code that needs to be updated to not use the deprecated
> APIs, but that might only be unit tests at this point).
> --
> Matt Sicker <bo...@gmail.com>
>
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: Let's talk about the roadmap to 2.0 and 2.1.

[Łukasz Dywicki <lu...@code-house.org>]

Ralph,

Wiadomość napisana przez Ralph Goers <ra...@dslextreme.com> w dniu 17 kwi 2014, o godz. 22:22:
> 2. I could swear we have always generated the OSGi MANIFEST.MF and people said it wasn’t sufficient, but if they aren’t there then I guess I am wrong.
Main reason why I joined log4j-dev is OSGi related stuff. So here I am!

Greetings,
Łukasz Dywicki
--
luke@code-house.org
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

Re: Let's talk about the roadmap to 2.0 and 2.1.

[Ralph Goers <ra...@dslextreme.com>]

1. I prefer trunk to be the stable branch.  In addition to the 2.0 tag I would also cut a branch when 2.0 is finally released.

2. I could swear we have always generated the OSGi MANIFEST.MF and people said it wasn’t sufficient, but if they aren’t there then I guess I am wrong.

3. I would like to see a list of what would be broken out before we actually do it. 

4. I’d like to see 2.0 GA asap, so I agree.

5. A release can be cut at any time. We don’t vote to perform a release, we vote that the release is good to go public.

6. The Marker stuff is done, except for removing the deprecated APIs. We need to finalize the logo.  I don’t know if any outstanding issues are blockers.

Ralph


On Apr 17, 2014, at 10:51 AM, Matt Sicker <bo...@gmail.com> wrote:

> I've got a few topics to mention.
> 
> 1. Should we consider making a 2.0 release branch so that trunk can continue to be the active development branch? That way we can work on new things while just ironing out the remaining issues for 2.0 GA in the 2.0 branch. Unless you guys prefer a different branching workflow like trunk being the stable branch, and then using feature branches.
> 
> 2. OSGi support. What I'm thinking will be the easiest way to get this working correctly without having to worry so much about duplicating bundles would be to simply drop the log4j-osgi modules and just add the OSGi MANIFEST.MF metadata to our normal releases. This would effectively be good enough for supporting OSGi bundles in that regard. We can figure out how to trim down log4j-core independently of anything OSGi. I've already began work on this by updating the poms for log4j, log4j-api, and log4j-1.2-api. I'll update the other smaller modules to reflect the updated build process as well. There may be a slight issue with the log4j-slf4j-impl module due to how SLF4J expects implementations to be packaged, so I'll take a look into that as well (and possibly go complain to them if necessary). In fact, supporting OSGi for some of these modules might not be possible due to package splits and backwards compatibility.
> 
> 3. Essentially, I'm thinking that we could separate out all the parts of log4j-core that use external dependencies with the exception of AsyncLogger (we could potentially fork lmax-disruptor into our own repository similar to how Tomcat handles some of their dependencies). That way, we don't need to worry about optional dependencies, either, because when they're split up, the new modules can have required dependencies instead (whether it be an API or a concrete library). If there are any other parts of log4j-core that rely on external dependencies that we think are popular enough to keep in log4j-core, please share.
> 
> 4. Due to how new these modules are, I'm proposing that log4j-streams and log4j-camel both be slated for release in 2.1 or some future release. Otherwise, these might hold back our 2.0 release a little bit. Where we place the code depends on (1) (keep in trunk or make feature branches). Of course, both modules are independently up for vote on whether to include them in 2.0. Since I added the log4j-camel module as a sort of experimental module largely based on the log module in camel-core (which uses SLF4J instead), I'd like to see this part in 2.1, but not in 2.0 since I've barely tested it yet (and still need to port more tests to it along with some integration testing).
> 
> 5. After addressing the modules thing from (3), we should probably vote on an RC2 release sometime soon. I'd propose releasing RC2 in the beginning of May, but I'm open for whenever.
> 
> 6. What else is left for 2.0? The updated Marker API is almost complete (we have our own code that needs to be updated to not use the deprecated APIs, but that might only be unit tests at this point).
> -- 
> Matt Sicker <bo...@gmail.com>