[FtpServer] The road to M3

[Niklas Gustavsson <ni...@protocol7.com>]

Alright, with 1.0.0-M2 released later today, it's time to discuss what
to do for the next milestone. My wish is to have all major changes to
the API done by M3. Therefore, I suggest focusing on the following
three items:

* JSecurity integration - throw out our own security stuff and use
JSecurity instead. Work on this has already started
* OSGi support - restructure our package structure to better separate
our public API from the internal implementation. As part of that, we
should also make sure we work in a OSGi environment. This might
include exposing services to allow setting up FtpServer in a OSGi
runtime.
* Generic Ftplet - make the Ftplet interface generic in that it only
contains methods similar to that of Servlet.service(), possibly
beforeCommand() and afterCommand(). These would then be mapped to the
current methods, such as onMkdirStart() via a template class like
DefaultFtplet (compare with HttpServlet). The aim is to make Ftplets
generic and be able to respond to any command, not just those that we
have defined in the interface while making the transition easy for
those with existing Ftplets.

In addition, fixing bugs and making FtpServer more stable is of course
ongoing. Recently we've had a lot of great bug reports so I would like
to see these in M3 rather sooner than later. Hopefully we can do the
M3 release as soon as possible.

After M3, I would like to completely focus on stability and maturity
so that the next release can be an RC for 1.0.

What do you think? Would to like to include something else in M3? Or
exclude some of those proposed above?

/niklas

Re: [FtpServer] The road to M3

[Niklas Gustavsson <ni...@protocol7.com>]

On Tue, Aug 12, 2008 at 1:19 AM, Alex Karasulu <ak...@apache.org> wrote:
> Then again depending on the code released outside of the incubator might be
> best.

Yeah, or maybe delay the JSecurity integration until they have
graduated. In the meantime we could prepare ourselves by readying our
interface to fit with the JSecurity interfaces.

Anyways, I'll ask over at the incubator just to make sure.

/niklas

Re: [FtpServer] The road to M3

[Alex Karasulu <ak...@apache.org>]

Then again depending on the code released outside of the incubator might be
best.

Alex

On Mon, Aug 11, 2008 at 7:19 PM, Alex Karasulu <ak...@apache.org> wrote:

> On Mon, Aug 11, 2008 at 3:21 PM, Niklas Gustavsson <ni...@protocol7.com>wrote:
>
>> On Mon, Aug 11, 2008 at 4:54 PM, Alex Karasulu <ak...@apache.org>
>> wrote:
>> > On Mon, Aug 11, 2008 at 8:13 AM, Niklas Gustavsson <
>> niklas@protocol7.com>wrote:
>> >> * JSecurity integration - throw out our own security stuff and use
>> >> JSecurity instead. Work on this has already started
>> >
>> > I'd check and see if there are issues with having dependencies on
>> incubating
>> > project artifacts.  I don't think there is but sometime ago someone
>> raised
>> > this as a potential issue when we wanted to depend on Felix and it was
>> > incubating at the time.
>>
>> Good question. One option is of course to depend on 0.9 which is being
>> released outside of Apache. However, it would of course be beneficial
>> to be able to track the developments during the incubation period so
>> I'll make sure to check the policies. Do you think general@i.a.o is
>> the best place to start?
>>
>
> Yeah that would be best place.  If I remember correctly, releasing
> ftp-server using incubator code is OK but you have to assure diligence for
> jsecurity since the PMC is responsible for the ftp-server release.   You
> just cannot release independent jsecurity jars as part of ftp-server.  Now
> what this translates to in release mechanics is you'll have to replicate the
> jsecurity code as part of ftp-server and cannot depend on the jsecurity jar
> being in the maven repo.
>
> Then when they graduate I think you can shed the code and just rely on
> their dependencies.  Again tho this is just faint memories of what I
> gathered from past experiences.  The IPMC would
>
> Alex
>
> --
> Microsoft gives you Windows, Linux gives you the whole house ...
>



-- 
Microsoft gives you Windows, Linux gives you the whole house ...

Re: [FtpServer] The road to M3

[Alex Karasulu <ak...@apache.org>]

On Mon, Aug 11, 2008 at 3:21 PM, Niklas Gustavsson <ni...@protocol7.com>wrote:

> On Mon, Aug 11, 2008 at 4:54 PM, Alex Karasulu <ak...@apache.org>
> wrote:
> > On Mon, Aug 11, 2008 at 8:13 AM, Niklas Gustavsson <niklas@protocol7.com
> >wrote:
> >> * JSecurity integration - throw out our own security stuff and use
> >> JSecurity instead. Work on this has already started
> >
> > I'd check and see if there are issues with having dependencies on
> incubating
> > project artifacts.  I don't think there is but sometime ago someone
> raised
> > this as a potential issue when we wanted to depend on Felix and it was
> > incubating at the time.
>
> Good question. One option is of course to depend on 0.9 which is being
> released outside of Apache. However, it would of course be beneficial
> to be able to track the developments during the incubation period so
> I'll make sure to check the policies. Do you think general@i.a.o is
> the best place to start?
>

Yeah that would be best place.  If I remember correctly, releasing
ftp-server using incubator code is OK but you have to assure diligence for
jsecurity since the PMC is responsible for the ftp-server release.   You
just cannot release independent jsecurity jars as part of ftp-server.  Now
what this translates to in release mechanics is you'll have to replicate the
jsecurity code as part of ftp-server and cannot depend on the jsecurity jar
being in the maven repo.

Then when they graduate I think you can shed the code and just rely on their
dependencies.  Again tho this is just faint memories of what I gathered from
past experiences.  The IPMC would

Alex

-- 
Microsoft gives you Windows, Linux gives you the whole house ...

Re: [FtpServer] The road to M3

[Alex Karasulu <ak...@apache.org>]

On Mon, Aug 11, 2008 at 3:21 PM, Niklas Gustavsson <ni...@protocol7.com>wrote:

> On Mon, Aug 11, 2008 at 4:54 PM, Alex Karasulu <ak...@apache.org>
> wrote:
> > On Mon, Aug 11, 2008 at 8:13 AM, Niklas Gustavsson <niklas@protocol7.com
> >wrote:
> >> * JSecurity integration - throw out our own security stuff and use
> >> JSecurity instead. Work on this has already started
> >
> > I'd check and see if there are issues with having dependencies on
> incubating
> > project artifacts.  I don't think there is but sometime ago someone
> raised
> > this as a potential issue when we wanted to depend on Felix and it was
> > incubating at the time.
>
> Good question. One option is of course to depend on 0.9 which is being
> released outside of Apache. However, it would of course be beneficial
> to be able to track the developments during the incubation period so
> I'll make sure to check the policies. Do you think general@i.a.o is
> the best place to start?
>

Yeah that would be the best place.  If I remember correctly, releasing
ftp-server using incubator code is OK but you have to assure diligence for
jsecurity since the PMC is responsible for the ftp-server release.   You
just cannot release independent jsecurity jars as part of ftp-server.  Now
what this translates to in release mechanics is you'll have to replicate the
jsecurity code as part of ftp-server and cannot depend on the jsecurity jar
being in the maven repo.

Then when they graduate I think you can shed the code and just rely on their
dependencies.  Again tho this is just faint memories of what I gathered from
past experiences.  I'm no authority.  Others would know best.

Alex

-- 
Microsoft gives you Windows, Linux gives you the whole house ...

Re: [FtpServer] The road to M3

[Niklas Gustavsson <ni...@protocol7.com>]

On Mon, Aug 11, 2008 at 4:54 PM, Alex Karasulu <ak...@apache.org> wrote:
> On Mon, Aug 11, 2008 at 8:13 AM, Niklas Gustavsson <ni...@protocol7.com>wrote:
>> * JSecurity integration - throw out our own security stuff and use
>> JSecurity instead. Work on this has already started
>
> I'd check and see if there are issues with having dependencies on incubating
> project artifacts.  I don't think there is but sometime ago someone raised
> this as a potential issue when we wanted to depend on Felix and it was
> incubating at the time.

Good question. One option is of course to depend on 0.9 which is being
released outside of Apache. However, it would of course be beneficial
to be able to track the developments during the incubation period so
I'll make sure to check the policies. Do you think general@i.a.o is
the best place to start?

/niklas

Re: [FtpServer] The road to M3

[Alex Karasulu <ak...@apache.org>]

On Mon, Aug 11, 2008 at 8:13 AM, Niklas Gustavsson <ni...@protocol7.com>wrote:

> Alright, with 1.0.0-M2 released later today, it's time to discuss what
> to do for the next milestone. My wish is to have all major changes to
> the API done by M3. Therefore, I suggest focusing on the following
> three items:
>
> * JSecurity integration - throw out our own security stuff and use
> JSecurity instead. Work on this has already started


I'd check and see if there are issues with having dependencies on incubating
project artifacts.  I don't think there is but sometime ago someone raised
this as a potential issue when we wanted to depend on Felix and it was
incubating at the time.


>
> * OSGi support - restructure our package structure to better separate
> our public API from the internal implementation. As part of that, we
> should also make sure we work in a OSGi environment. This might
> include exposing services to allow setting up FtpServer in a OSGi
> runtime.
> * Generic Ftplet - make the Ftplet interface generic in that it only
> contains methods similar to that of Servlet.service(), possibly
> beforeCommand() and afterCommand(). These would then be mapped to the
> current methods, such as onMkdirStart() via a template class like
> DefaultFtplet (compare with HttpServlet). The aim is to make Ftplets
> generic and be able to respond to any command, not just those that we
> have defined in the interface while making the transition easy for
> those with existing Ftplets.
>
> In addition, fixing bugs and making FtpServer more stable is of course
> ongoing. Recently we've had a lot of great bug reports so I would like
> to see these in M3 rather sooner than later. Hopefully we can do the
> M3 release as soon as possible.
>
> After M3, I would like to completely focus on stability and maturity
> so that the next release can be an RC for 1.0.
>
> What do you think? Would to like to include something else in M3? Or
> exclude some of those proposed above?
>
> /niklas
>



-- 
Microsoft gives you Windows, Linux gives you the whole house ...