NOTICE: trunk may be buggy this morning.

[Maciej Szefler <mb...@intalio.com>]

We are doing a merge of some changes this morning which may lead to an
buggy trunk for the next few hours.
-maciej

Re: NOTICE: trunk may be buggy this morning.

[Alex Boisvert <bo...@intalio.com>]

Lance Waterman wrote:
> I am trying to understand expectations around how the ODE project 
> plans to
> work. Based on past exchanges you made the following comment:
>
>>> I think the versioning changes will require an understanding of how the
>>> feature would be implemented -- a design reveiew. As for the scratch vs
>>> patch, scratch is called for when multiple developers are going to be
>>> involved in developing a feature.
>
> and Alex made the following comment:
>
>>> An idea: you could also create a temporary branch to make it easier to
>>> share, collaborate and merge/synchronize the code if you think the 
>>> scope
>>> warrants it.
>
> Now I think I hear you saying that the interface is not stable and folks
> should not be surprised if it should change ( i.e. adding versioning )
> without notification/discussion and at some future point in time we may
> decide to lock it down.
>

Lance,

Just to be clear, I did not request that you create a separate branch.  
In that earlier thread, you were saying that you would develop something 
outside of the repository and commit it when completed.   I merely 
suggested that you could work in a branch if you wanted to increase your 
chances of collaboration/help/feedback before integration into the trunk.

At this point in time, I'm more in favor of a fluid (read: less formal) 
development methodology.   A lot of pieces are still in flux and we're 
trying to get to something working in order to allow people to start 
using and contributing to Ode.   Apache projects typically favor working 
code over grand ideas because this is how things actually get done.  
This being said, nothing is set in stone so there's always an 
opportunity to comment on what has been done and improve the code if it 
doesn't suit your purposes.  Your feedback is important and I'm sure we 
can work things out if you think we can improve (PM API or anything 
else).  I actually like the fact that we get things quickly integrated 
in the trunk since it allows for good measure and validation of the 
various changes we're making.

Later on when things stabilize I agree changes to public interfaces 
(incl. configuration and database schemas) should be discussed with the 
community before they are effected.   This will be an important 
"contract" with the community of users and developers who will most 
likely want a smooth evolution of their environments.

cheers,
alex

Re: NOTICE: trunk may be buggy this morning.

[Alex Boisvert <bo...@intalio.com>]

Maciej Szefler wrote:
> In general I'd prefer less discussion rather than more, applying the
> following rules:
>
> 1. deviations that get us closer to an established goal do not require
> discussion
>   

Let's not forget that friendly courtesy notices are always appreciated :)

> 2. ditto for refactors / improvements of existing functionality
>   

As long as test cases continue to work!  And bonus points are awarded 
for new test cases covering new/existing functionality.

> 3. new core features where there may be disagreement as to the
> requirements require some discussion beforehand.
>
> 4. non-core features should not require discussion unless they are found
> be a nuisance or until it is determined that they are in fact core
> features.
>   
I think there are some subtleties and nuances that can be applied here.  
Without going into details let's just say that I believe more 
communication is better than less communication... assuming, of course, 
a good signal-to-noise ratio!

> All these are subjective of course. If something more rigid is called
> for then we might consider establishing ownership responsibilities for
> certain areas of the project so that we don't have to get bogged down in
> endless discussions. Of course there would always be recourse to
> democracy: if for example there is a big disagreement that cannot be
> worked out between someone working on the engine, and the API owner,
> then this nuclear option is always available. 
>   
I'd be interested to hear our mentors on this subject.

My understanding of the Apache meritocracy is that you don't really want 
to assign "owners" to areas.  People who actually contribute, maintain 
and support specific areas become owners as a matter of act, not 
attribution.   In that sense, ownership is not an inherent right but 
rather a privilege that is implicitly and temporarily granted based on 
the work being done and its value to the community.    We should always 
seek consensus but in difficult situations, actions speak louder than words.

cheers,
alex

Re: NOTICE: trunk may be buggy this morning.

[Maciej Szefler <mb...@intalio.com>]

In general I'd prefer less discussion rather than more, applying the
following rules:

1. deviations that get us closer to an established goal do not require
discussion

2. ditto for refactors / improvements of existing functionality

3. new core features where there may be disagreement as to the
requirements require some discussion beforehand.

4. non-core features should not require discussion unless they are found
be a nuisance or until it is determined that they are in fact core
features.

Examples:
1. e.g. my tweaks to deployment
2. e.g. go through BpelServerImpl and fix the multi-threaded concurrency
issues
3. e.g. versioning, content api, business transactions, etc...
4. e.g. implement a debugging facility, support additional query
language, etc..

All these are subjective of course. If something more rigid is called
for then we might consider establishing ownership responsibilities for
certain areas of the project so that we don't have to get bogged down in
endless discussions. Of course there would always be recourse to
democracy: if for example there is a big disagreement that cannot be
worked out between someone working on the engine, and the API owner,
then this nuclear option is always available. 

-maciej


On Tue, 2006-08-15 at 10:37 -0600, Lance Waterman wrote:
> Maciej,
> 
> I am trying to understand expectations around how the ODE project
> plans to work. Based on past exchanges you made the following comment:
> 
> >>I think the versioning changes will require an understanding of how
> the 
> >>feature would be implemented -- a design reveiew. As for the scratch
> vs
> >>patch, scratch is called for when multiple developers are going to
> be
> >>involved in developing a feature.
> 
> and Alex made the following comment: 
> 
> >>An idea: you could also create a temporary branch to make it easier
> to
> >>share, collaborate and merge/synchronize the code if you think the
> scope
> >>warrants it. 
> 
> 
> Now I think I hear you saying that the interface is not stable and
> folks should not be surprised if it should change ( i.e. adding
> versioning ) without notification/discussion and at some future point
> in time we may decide to lock it down. 
> 
> I find the following comment subjective:
> 
> >>but on the whole I feel
> >>that the changes I made were only getting us closer to the intent of
> the
> >>group WRT deployment.
> 
> So I am struggling with expectations around design/interface changes.
> I personally would like to see discussion around changes to the public
> interface before being checked into the trunk. For example; I would
> like more information around some questions I had on methods added to
> the BpelServer interface. 
> 
> However, if there is consensus that the group would rather work within
> a more fluid environment that is fine with me. In this more fluid
> environment I don't think we can fault folks for their subjective view
> on interface/implementation changes and the only thing we can do is
> ask questions and make suggestions after the fact. 
> 
> Again, I can work in either environment but I would really like to
> hear from folks and come up with a consensus on how they see the
> development process working.
> 
> Thanks,
> 
> Lance
> 

Re: NOTICE: trunk may be buggy this morning.

[Lance Waterman <la...@gmail.com>]

Maciej,

I am trying to understand expectations around how the ODE project plans to
work. Based on past exchanges you made the following comment:

>>I think the versioning changes will require an understanding of how the
>>feature would be implemented -- a design reveiew. As for the scratch vs
>>patch, scratch is called for when multiple developers are going to be
>>involved in developing a feature.

and Alex made the following comment:

>>An idea: you could also create a temporary branch to make it easier to
>>share, collaborate and merge/synchronize the code if you think the scope
>>warrants it.

Now I think I hear you saying that the interface is not stable and folks
should not be surprised if it should change ( i.e. adding versioning )
without notification/discussion and at some future point in time we may
decide to lock it down.

I find the following comment subjective:

>>but on the whole I feel
>>that the changes I made were only getting us closer to the intent of the
>>group WRT deployment.

So I am struggling with expectations around design/interface changes. I
personally would like to see discussion around changes to the public
interface before being checked into the trunk. For example; I would like
more information around some questions I had on methods added to the
BpelServer interface.

However, if there is consensus that the group would rather work within a
more fluid environment that is fine with me. In this more fluid environment
I don't think we can fault folks for their subjective view on
interface/implementation changes and the only thing we can do is ask
questions and make suggestions after the fact.

Again, I can work in either environment but I would really like to hear from
folks and come up with a consensus on how they see the development process
working.

Thanks,

Lance



On 8/15/06, Maciej Szefler <mb...@intalio.com> wrote:
>
> Lance,
>
> We previously discussed the fact that the deployment methods on the
> BpelServer interface were not stable / final. These changes were driven
> by the fact that we had earlier introduced a new deployment descriptor /
> packaging format that was more in-line with the DeploymentAPI document
> and as a practical matter needed to eliminate the old PXE deployment
> descriptor format to prevent confusion and maintain compatibility with
> the JBI IL. I think on the deployment end we still have some ways to go
> before we can consider the API to be stable, but on the whole I feel
> that the changes I made were only getting us closer to the intent of the
> group WRT deployment.
>
> -Maciej
>
>
> On Mon, 2006-08-14 at 23:47 -0600, Lance Waterman wrote:
> > With this refactor I now see a public interface "DeploymentUnit" ( add
> > into the trunk on 8/2 ) is no longer referenced by either of the IL
> > implementations and so I question its use as a public interface. Also,
> > BpelServer.deploy () has changed as well.
> >
> > I feel like the public API is thrashing  and I would like to formally
> > ask that changes to the API be proposed on the mailing list. I think
> > review is necessary on the public API.
> >
> > Thoughts - other suggests?
> >
>
>

Re: Proposed API change -- DAO

[Matthieu Riou <ma...@gmail.com>]

Looks like an agreement. I'll create a Jira issue for this.

On 8/15/06, Matthieu Riou <ma...@gmail.com> wrote:
>
> +1 but maybe with a nice default value?
>
> I'm not a great fan of long configuration properties when in the 80% case
> they can be much shorter (or even inexistant).
>
>
> On 8/15/06, Lance Waterman <la...@gmail.com> wrote:
> >
> > Agreed, and it would be nice if the factory could be expressed as an
> > engine
> > configuration property.
> >
> > On 8/15/06, Maciej Szefler <mb...@intalio.com> wrote:
> > >
> > > While walking through the bpel-api module I have become convinced that
> >
> > > the DAO interfaces do not really belong there: the sole dependency on
> > > these interfaces is in the BpelServer.setDAOConnectionFactory method
> > and
> > > really the DAO represents an implementation detail of the server
> > rather
> > > than a genuine concern of the integration layer using the IAPI. Hence,
> > > I'd like to propose that we move the DAO interfaces to a separate
> > module
> > > and eliminate the setDAOConnectionFactory method from the public
> > > BpelServer interface.
> > >
> > > -maciej
> > >
> > >
> > > >
> > > On Tue, 2006-08-15 at 11:32 -0400, Maciej Szefler wrote:
> > > > Lance,
> > > >
> > > > We previously discussed the fact that the deployment methods on the
> > > > BpelServer interface were not stable / final. These changes were
> > driven
> > > > by the fact that we had earlier introduced a new deployment
> > descriptor /
> > > > packaging format that was more in-line with the DeploymentAPI
> > document
> > > > and as a practical matter needed to eliminate the old PXE deployment
> > > > descriptor format to prevent confusion and maintain compatibility
> > with
> > > > the JBI IL. I think on the deployment end we still have some ways to
> > go
> > > > before we can consider the API to be stable, but on the whole I feel
> > > > that the changes I made were only getting us closer to the intent of
> > the
> > > > group WRT deployment.
> > > >
> > > > -Maciej
> > > >
> > > >
> > > > On Mon, 2006-08-14 at 23:47 -0600, Lance Waterman wrote:
> > > > > With this refactor I now see a public interface "DeploymentUnit" (
> > add
> > > > > into the trunk on 8/2 ) is no longer referenced by either of the
> > IL
> > > > > implementations and so I question its use as a public interface.
> > Also,
> > > > > BpelServer.deploy () has changed as well.
> > > > >
> > > > > I feel like the public API is thrashing  and I would like to
> > formally
> > > > > ask that changes to the API be proposed on the mailing list. I
> > think
> > > > > review is necessary on the public API.
> > > > >
> > > > > Thoughts - other suggests?
> > > > >
> > > >
> > >
> > >
> >
> >
>

Re: Proposed API change -- DAO

[Matthieu Riou <ma...@gmail.com>]

+1 but maybe with a nice default value?

I'm not a great fan of long configuration properties when in the 80% case
they can be much shorter (or even inexistant).

On 8/15/06, Lance Waterman <la...@gmail.com> wrote:
>
> Agreed, and it would be nice if the factory could be expressed as an
> engine
> configuration property.
>
> On 8/15/06, Maciej Szefler <mb...@intalio.com> wrote:
> >
> > While walking through the bpel-api module I have become convinced that
> > the DAO interfaces do not really belong there: the sole dependency on
> > these interfaces is in the BpelServer.setDAOConnectionFactory method and
> > really the DAO represents an implementation detail of the server rather
> > than a genuine concern of the integration layer using the IAPI. Hence,
> > I'd like to propose that we move the DAO interfaces to a separate module
> > and eliminate the setDAOConnectionFactory method from the public
> > BpelServer interface.
> >
> > -maciej
> >
> >
> > >
> > On Tue, 2006-08-15 at 11:32 -0400, Maciej Szefler wrote:
> > > Lance,
> > >
> > > We previously discussed the fact that the deployment methods on the
> > > BpelServer interface were not stable / final. These changes were
> driven
> > > by the fact that we had earlier introduced a new deployment descriptor
> /
> > > packaging format that was more in-line with the DeploymentAPI document
> > > and as a practical matter needed to eliminate the old PXE deployment
> > > descriptor format to prevent confusion and maintain compatibility with
> > > the JBI IL. I think on the deployment end we still have some ways to
> go
> > > before we can consider the API to be stable, but on the whole I feel
> > > that the changes I made were only getting us closer to the intent of
> the
> > > group WRT deployment.
> > >
> > > -Maciej
> > >
> > >
> > > On Mon, 2006-08-14 at 23:47 -0600, Lance Waterman wrote:
> > > > With this refactor I now see a public interface "DeploymentUnit" (
> add
> > > > into the trunk on 8/2 ) is no longer referenced by either of the IL
> > > > implementations and so I question its use as a public interface.
> Also,
> > > > BpelServer.deploy () has changed as well.
> > > >
> > > > I feel like the public API is thrashing  and I would like to
> formally
> > > > ask that changes to the API be proposed on the mailing list. I think
> > > > review is necessary on the public API.
> > > >
> > > > Thoughts - other suggests?
> > > >
> > >
> >
> >
>
>

Re: Proposed API change -- DAO

[Lance Waterman <la...@gmail.com>]

Agreed, and it would be nice if the factory could be expressed as an engine
configuration property.

On 8/15/06, Maciej Szefler <mb...@intalio.com> wrote:
>
> While walking through the bpel-api module I have become convinced that
> the DAO interfaces do not really belong there: the sole dependency on
> these interfaces is in the BpelServer.setDAOConnectionFactory method and
> really the DAO represents an implementation detail of the server rather
> than a genuine concern of the integration layer using the IAPI. Hence,
> I'd like to propose that we move the DAO interfaces to a separate module
> and eliminate the setDAOConnectionFactory method from the public
> BpelServer interface.
>
> -maciej
>
>
> >
> On Tue, 2006-08-15 at 11:32 -0400, Maciej Szefler wrote:
> > Lance,
> >
> > We previously discussed the fact that the deployment methods on the
> > BpelServer interface were not stable / final. These changes were driven
> > by the fact that we had earlier introduced a new deployment descriptor /
> > packaging format that was more in-line with the DeploymentAPI document
> > and as a practical matter needed to eliminate the old PXE deployment
> > descriptor format to prevent confusion and maintain compatibility with
> > the JBI IL. I think on the deployment end we still have some ways to go
> > before we can consider the API to be stable, but on the whole I feel
> > that the changes I made were only getting us closer to the intent of the
> > group WRT deployment.
> >
> > -Maciej
> >
> >
> > On Mon, 2006-08-14 at 23:47 -0600, Lance Waterman wrote:
> > > With this refactor I now see a public interface "DeploymentUnit" ( add
> > > into the trunk on 8/2 ) is no longer referenced by either of the IL
> > > implementations and so I question its use as a public interface. Also,
> > > BpelServer.deploy () has changed as well.
> > >
> > > I feel like the public API is thrashing  and I would like to formally
> > > ask that changes to the API be proposed on the mailing list. I think
> > > review is necessary on the public API.
> > >
> > > Thoughts - other suggests?
> > >
> >
>
>

Re: Proposed API change -- DAO

[Assaf Arkin <ar...@intalio.com>]

+1

Assaf

On 8/15/06, Maciej Szefler <mb...@intalio.com> wrote:
>
> While walking through the bpel-api module I have become convinced that
> the DAO interfaces do not really belong there: the sole dependency on
> these interfaces is in the BpelServer.setDAOConnectionFactory method and
> really the DAO represents an implementation detail of the server rather
> than a genuine concern of the integration layer using the IAPI. Hence,
> I'd like to propose that we move the DAO interfaces to a separate module
> and eliminate the setDAOConnectionFactory method from the public
> BpelServer interface.
>
> -maciej
>
>
> >
> On Tue, 2006-08-15 at 11:32 -0400, Maciej Szefler wrote:
> > Lance,
> >
> > We previously discussed the fact that the deployment methods on the
> > BpelServer interface were not stable / final. These changes were driven
> > by the fact that we had earlier introduced a new deployment descriptor /
> > packaging format that was more in-line with the DeploymentAPI document
> > and as a practical matter needed to eliminate the old PXE deployment
> > descriptor format to prevent confusion and maintain compatibility with
> > the JBI IL. I think on the deployment end we still have some ways to go
> > before we can consider the API to be stable, but on the whole I feel
> > that the changes I made were only getting us closer to the intent of the
> > group WRT deployment.
> >
> > -Maciej
> >
> >
> > On Mon, 2006-08-14 at 23:47 -0600, Lance Waterman wrote:
> > > With this refactor I now see a public interface "DeploymentUnit" ( add
> > > into the trunk on 8/2 ) is no longer referenced by either of the IL
> > > implementations and so I question its use as a public interface. Also,
> > > BpelServer.deploy () has changed as well.
> > >
> > > I feel like the public API is thrashing  and I would like to formally
> > > ask that changes to the API be proposed on the mailing list. I think
> > > review is necessary on the public API.
> > >
> > > Thoughts - other suggests?
> > >
> >
>
>


-- 
CTO, Intalio
http://www.intalio.com

Proposed API change -- DAO

[Maciej Szefler <mb...@intalio.com>]

While walking through the bpel-api module I have become convinced that
the DAO interfaces do not really belong there: the sole dependency on
these interfaces is in the BpelServer.setDAOConnectionFactory method and
really the DAO represents an implementation detail of the server rather
than a genuine concern of the integration layer using the IAPI. Hence,
I'd like to propose that we move the DAO interfaces to a separate module
and eliminate the setDAOConnectionFactory method from the public
BpelServer interface. 

-maciej


> 
On Tue, 2006-08-15 at 11:32 -0400, Maciej Szefler wrote:
> Lance,
> 
> We previously discussed the fact that the deployment methods on the
> BpelServer interface were not stable / final. These changes were driven
> by the fact that we had earlier introduced a new deployment descriptor /
> packaging format that was more in-line with the DeploymentAPI document
> and as a practical matter needed to eliminate the old PXE deployment
> descriptor format to prevent confusion and maintain compatibility with
> the JBI IL. I think on the deployment end we still have some ways to go
> before we can consider the API to be stable, but on the whole I feel
> that the changes I made were only getting us closer to the intent of the
> group WRT deployment.
> 
> -Maciej
> 
> 
> On Mon, 2006-08-14 at 23:47 -0600, Lance Waterman wrote:
> > With this refactor I now see a public interface "DeploymentUnit" ( add
> > into the trunk on 8/2 ) is no longer referenced by either of the IL
> > implementations and so I question its use as a public interface. Also,
> > BpelServer.deploy () has changed as well.
> > 
> > I feel like the public API is thrashing  and I would like to formally
> > ask that changes to the API be proposed on the mailing list. I think
> > review is necessary on the public API.
> > 
> > Thoughts - other suggests? 
> > 
> 

Re: NOTICE: trunk may be buggy this morning.

[Maciej Szefler <mb...@intalio.com>]

Lance,

We previously discussed the fact that the deployment methods on the
BpelServer interface were not stable / final. These changes were driven
by the fact that we had earlier introduced a new deployment descriptor /
packaging format that was more in-line with the DeploymentAPI document
and as a practical matter needed to eliminate the old PXE deployment
descriptor format to prevent confusion and maintain compatibility with
the JBI IL. I think on the deployment end we still have some ways to go
before we can consider the API to be stable, but on the whole I feel
that the changes I made were only getting us closer to the intent of the
group WRT deployment.

-Maciej


On Mon, 2006-08-14 at 23:47 -0600, Lance Waterman wrote:
> With this refactor I now see a public interface "DeploymentUnit" ( add
> into the trunk on 8/2 ) is no longer referenced by either of the IL
> implementations and so I question its use as a public interface. Also,
> BpelServer.deploy () has changed as well.
> 
> I feel like the public API is thrashing  and I would like to formally
> ask that changes to the API be proposed on the mailing list. I think
> review is necessary on the public API.
> 
> Thoughts - other suggests? 
> 

Re: NOTICE: trunk may be buggy this morning.

[Lance Waterman <la...@gmail.com>]

With this refactor I now see a public interface "DeploymentUnit" ( add into
the trunk on 8/2 ) is no longer referenced by either of the IL
implementations and so I question its use as a public interface. Also,
BpelServer.deploy() has changed as well.

I feel like the public API is thrashing  and I would like to formally ask
that changes to the API be proposed on the mailing list. I think review is
necessary on the public API.

Thoughts - other suggests?

Lance

On 8/14/06, Maciej Szefler <mb...@intalio.com> wrote:
>
> We are doing a merge of some changes this morning which may lead to an
> buggy trunk for the next few hours.
> -maciej
>
>
>