You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@continuum.apache.org by Brett Porter <br...@apache.org> on 2008/04/27 16:02:17 UTC
refactoring the SCM
Hi,
I've started to do some refactoring - this is along the way to the
builder separation I mentioned earlier.
If you have a moment, please review r 651947. It's on a branch, but
I'd like to regularly merge to trunk if there are no objects to avoid
getting too distant. I have more tests to write for this first.
All I've done is pulled the DefaultContinuumScm class out into a
separate module, and decoupled it from the model. It already contained
some logic related to the SCMs (which may actually need to go back
into Maven SCM itself). I pulled the logging and database updates back
into the actions in code (this did result in some duplication, but I
can clean that up later). It also showed that some code was never
having its results used, and also started to expose some exception
handling bugs. I stopped wrapping exceptions and results, choosing to
use the Maven SCM API natively.
Thoughts?
Anyone that is knowledgable in Spring, please check my work :) Is
there a way to easily populate maps of beans, instead of hard coding
the providers?
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: refactoring next steps (was: refactoring the SCM)
Posted by Brett Porter <br...@apache.org>.
On 07/05/2008, at 6:29 AM, Emmanuel Venisse wrote:
> Hi Brett,
>
> Great work, I like it and I'm ok to merge it regularly to trunk.
Cool. I'll give it another day and a bit more of a spin then do that.
>
>
> I don't have idea about maps of beans.
>
> I think this branch is a good start to do more refactoring.
> 1- split DefaultBuildController to a controller + a builder
> The builder should be in it's own module and doesn't use/know the
> store, it
> checkout/update the working copy and build the project
agreed - this is one of the key objectives of the structure I brought
up before.
>
> The controller get an event from the UI, the scheduler or an other
> way and
> send and event to one or more builder (local or remote), JMS is
> probably the
> solution
yeah, I think the first stage is just to make sure the code is
separate enough that you could replace the implementation.
I think JMS might only be needed for the events - I like the idea of a
RESTful request model to the separate builder.
>
> 2- for each steps, the builder send the new project state
> notification, by
> JMS too and the Controller store it in memory, The project state
> must be
> transient instead of to store it in the db like today.
By state, do you mean "building", "checking out", "svn error" (which
are transient), or "success", "fail" (which are permanent and
historical?). I agree on the first ones - actually Marica mentioned
this in a previous mail and said she was going to start a new thread
for it :)
>
> When the build is done, the builder send a new event with the build
> result
Yep - we can probably send progress events too.
>
>
> I have a point that I don't know for the moment how to resolve. How to
> access to the working copy when the builder is a remote builder and
> how to
> do when we use more than one remote builder? But we'll can find a
> solution
> later.
well, I don't think the working copy belongs under the main interface
at that point - you should be able to go straight to the remote server
and access it over HTTP (we'll still need to wire in security, but
that's needed for any RESTful interface to them too). The aggregating
interface can probably link out to them or integrate the listing using
javascript or something.
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: refactoring the SCM
Posted by Emmanuel Venisse <em...@gmail.com>.
Hi Brett,
Great work, I like it and I'm ok to merge it regularly to trunk.
I don't have idea about maps of beans.
I think this branch is a good start to do more refactoring.
1- split DefaultBuildController to a controller + a builder
The builder should be in it's own module and doesn't use/know the store, it
checkout/update the working copy and build the project
The controller get an event from the UI, the scheduler or an other way and
send and event to one or more builder (local or remote), JMS is probably the
solution
2- for each steps, the builder send the new project state notification, by
JMS too and the Controller store it in memory, The project state must be
transient instead of to store it in the db like today.
When the build is done, the builder send a new event with the build result
I have a point that I don't know for the moment how to resolve. How to
access to the working copy when the builder is a remote builder and how to
do when we use more than one remote builder? But we'll can find a solution
later.
Emmanuel
On Tue, May 6, 2008 at 3:37 AM, Brett Porter <br...@apache.org> wrote:
> ok, fixed and committed :)
>
> Anyone able to take a look through?
>
> Cheers,
> Brett
>
>
> On 02/05/2008, at 2:53 PM, Brett Porter wrote:
>
> me too after cleaning up. Sorry about that, I'll look into it.
> >
> > - Brett
> >
> > On 30/04/2008, at 5:52 AM, Olivier Lamy wrote:
> >
> > Hi,
> > > I can't build the branch :
> > >
> > > /local/olamy/open-source/continuum-svn/builder-branch/continuum-core/src/main/java/org/apache/maven/continuum/core/action/AddProjectToCheckOutQueueAction.java:[60,16]
> > > cannot find symbol
> > > symbol : class CheckOutTask
> > > location: class
> > > org.apache.maven.continuum.core.action.AddProjectToCheckOutQueueAction
> > >
> > >
> > > 2008/4/27 Brett Porter <br...@apache.org>:
> > >
> > > > Hi,
> > > >
> > > > I've started to do some refactoring - this is along the way to the
> > > > builder
> > > > separation I mentioned earlier.
> > > >
> > > > If you have a moment, please review r 651947. It's on a branch, but
> > > > I'd
> > > > like to regularly merge to trunk if there are no objects to avoid
> > > > getting
> > > > too distant. I have more tests to write for this first.
> > > >
> > > > All I've done is pulled the DefaultContinuumScm class out into a
> > > > separate
> > > > module, and decoupled it from the model. It already contained some
> > > > logic
> > > > related to the SCMs (which may actually need to go back into Maven
> > > > SCM
> > > > itself). I pulled the logging and database updates back into the
> > > > actions in
> > > > code (this did result in some duplication, but I can clean that up
> > > > later).
> > > > It also showed that some code was never having its results used, and
> > > > also
> > > > started to expose some exception handling bugs. I stopped wrapping
> > > > exceptions and results, choosing to use the Maven SCM API natively.
> > > >
> > > > Thoughts?
> > > >
> > > > Anyone that is knowledgable in Spring, please check my work :) Is
> > > > there a
> > > > way to easily populate maps of beans, instead of hard coding the
> > > > providers?
> > > >
> > > >
> > > hehe it looks plexus have some nice features ;-)
> > >
> > > Cheers,
> > > > Brett
> > > >
> > > > --
> > > > Brett Porter
> > > > brett@apache.org
> > > > http://blogs.exist.com/bporter/
> > > >
> > > >
> > > >
> > --
> > Brett Porter
> > brett@apache.org
> > http://blogs.exist.com/bporter/
> >
> >
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: refactoring the SCM
Posted by Brett Porter <br...@apache.org>.
Ah... actually from memory I think they all throw ScmException, the
others are there for "more information", but afaik they won't impact
the contract.
- Brett
On 07/05/2008, at 11:19 AM, Rahul Thakur wrote:
>
> The motivation behind this was that layer/module should (ideally)
> expose limited number of granular exception(s). Having said that, I
> agree wrapping-unwrapping exceptions can get clunky and contract
> definition should be merited by the exception handling instances
> that we have observed in the code.
>
> I wasn't referring to nesting exceptions (may be wrong use of
> 'wrap'), but unifying the hierarchy of ScmExceptions, so clients can
> introspect using 'instanceof' to determine specific ones.
>
> Rahul
>
>
> Brett Porter wrote:
>>
>> On 07/05/2008, at 10:27 AM, Rahul Thakur wrote:
>>
>>>
>>> Cool! :)
>>>
>>> Just one note on exceptions - Can we wrap up all the SCM exceptions
>>> under one parent which is then exposed through the ContinuumScm API?
>>>
>>> Clients that need to do any special handling can introspect the
>>> extension.
>>>
>>> WDYT?
>>
>> One of the problems in the code that was just removed was that some
>> exceptions were getting swallowed or handled in the wrong place
>> because
>> it was trying to introspect a nested exception.
>>
>> I don't really think wrapping an exception without adding any
>> information, only to unwrap it later makes much sense.
>>
>> I think the caller should be able to deal with the Maven SCM
>> exceptions,
>> and the IOException resulting from passing a bad working directory.
>>
>> On the other hand, we don't really want to change interfaces in the
>> future, and a wrapped exception does provide that flexibility like
>> the
>> request parameter does.
>>
>> What do others think?
>>
>> - Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: refactoring the SCM
Posted by Rahul Thakur <ra...@gmail.com>.
The motivation behind this was that layer/module should (ideally) expose
limited number of granular exception(s). Having said that, I agree
wrapping-unwrapping exceptions can get clunky and contract definition
should be merited by the exception handling instances that we have
observed in the code.
I wasn't referring to nesting exceptions (may be wrong use of 'wrap'),
but unifying the hierarchy of ScmExceptions, so clients can introspect
using 'instanceof' to determine specific ones.
Rahul
Brett Porter wrote:
>
> On 07/05/2008, at 10:27 AM, Rahul Thakur wrote:
>
>>
>> Cool! :)
>>
>> Just one note on exceptions - Can we wrap up all the SCM exceptions
>> under one parent which is then exposed through the ContinuumScm API?
>>
>> Clients that need to do any special handling can introspect the
>> extension.
>>
>> WDYT?
>
> One of the problems in the code that was just removed was that some
> exceptions were getting swallowed or handled in the wrong place because
> it was trying to introspect a nested exception.
>
> I don't really think wrapping an exception without adding any
> information, only to unwrap it later makes much sense.
>
> I think the caller should be able to deal with the Maven SCM exceptions,
> and the IOException resulting from passing a bad working directory.
>
> On the other hand, we don't really want to change interfaces in the
> future, and a wrapped exception does provide that flexibility like the
> request parameter does.
>
> What do others think?
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: refactoring the SCM
Posted by Brett Porter <br...@apache.org>.
On 07/05/2008, at 10:27 AM, Rahul Thakur wrote:
>
> Cool! :)
>
> Just one note on exceptions - Can we wrap up all the SCM exceptions
> under one parent which is then exposed through the ContinuumScm API?
>
> Clients that need to do any special handling can introspect the
> extension.
>
> WDYT?
One of the problems in the code that was just removed was that some
exceptions were getting swallowed or handled in the wrong place
because it was trying to introspect a nested exception.
I don't really think wrapping an exception without adding any
information, only to unwrap it later makes much sense.
I think the caller should be able to deal with the Maven SCM
exceptions, and the IOException resulting from passing a bad working
directory.
On the other hand, we don't really want to change interfaces in the
future, and a wrapped exception does provide that flexibility like the
request parameter does.
What do others think?
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: refactoring the SCM
Posted by Rahul Thakur <ra...@gmail.com>.
Cool! :)
Just one note on exceptions - Can we wrap up all the SCM exceptions
under one parent which is then exposed through the ContinuumScm API?
Clients that need to do any special handling can introspect the extension.
WDYT?
Cheers,
Rahul
Brett Porter wrote:
> ok, fixed and committed :)
>
> Anyone able to take a look through?
>
> Cheers,
> Brett
>
> On 02/05/2008, at 2:53 PM, Brett Porter wrote:
>
>> me too after cleaning up. Sorry about that, I'll look into it.
>>
>> - Brett
>>
>> On 30/04/2008, at 5:52 AM, Olivier Lamy wrote:
>>
>>> Hi,
>>> I can't build the branch :
>>> /local/olamy/open-source/continuum-svn/builder-branch/continuum-core/src/main/java/org/apache/maven/continuum/core/action/AddProjectToCheckOutQueueAction.java:[60,16]
>>>
>>> cannot find symbol
>>> symbol : class CheckOutTask
>>> location: class
>>> org.apache.maven.continuum.core.action.AddProjectToCheckOutQueueAction
>>>
>>>
>>> 2008/4/27 Brett Porter <br...@apache.org>:
>>>> Hi,
>>>>
>>>> I've started to do some refactoring - this is along the way to the
>>>> builder
>>>> separation I mentioned earlier.
>>>>
>>>> If you have a moment, please review r 651947. It's on a branch, but I'd
>>>> like to regularly merge to trunk if there are no objects to avoid
>>>> getting
>>>> too distant. I have more tests to write for this first.
>>>>
>>>> All I've done is pulled the DefaultContinuumScm class out into a
>>>> separate
>>>> module, and decoupled it from the model. It already contained some
>>>> logic
>>>> related to the SCMs (which may actually need to go back into Maven SCM
>>>> itself). I pulled the logging and database updates back into the
>>>> actions in
>>>> code (this did result in some duplication, but I can clean that up
>>>> later).
>>>> It also showed that some code was never having its results used, and
>>>> also
>>>> started to expose some exception handling bugs. I stopped wrapping
>>>> exceptions and results, choosing to use the Maven SCM API natively.
>>>>
>>>> Thoughts?
>>>>
>>>> Anyone that is knowledgable in Spring, please check my work :) Is
>>>> there a
>>>> way to easily populate maps of beans, instead of hard coding the
>>>> providers?
>>>>
>>>
>>> hehe it looks plexus have some nice features ;-)
>>>
>>>> Cheers,
>>>> Brett
>>>>
>>>> --
>>>> Brett Porter
>>>> brett@apache.org
>>>> http://blogs.exist.com/bporter/
>>>>
>>>>
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: refactoring the SCM
Posted by Olivier Lamy <ol...@apache.org>.
Hi,
Looks fine.
Thanks,
--
Olivier
2008/5/6 Brett Porter <br...@apache.org>:
> ok, fixed and committed :)
>
> Anyone able to take a look through?
>
> Cheers,
> Brett
>
>
>
> On 02/05/2008, at 2:53 PM, Brett Porter wrote:
>
>
> > me too after cleaning up. Sorry about that, I'll look into it.
> >
> > - Brett
> >
> > On 30/04/2008, at 5:52 AM, Olivier Lamy wrote:
> >
> >
> > > Hi,
> > > I can't build the branch :
> > >
> /local/olamy/open-source/continuum-svn/builder-branch/continuum-core/src/main/java/org/apache/maven/continuum/core/action/AddProjectToCheckOutQueueAction.java:[60,16]
> > > cannot find symbol
> > > symbol : class CheckOutTask
> > > location: class
> > > org.apache.maven.continuum.core.action.AddProjectToCheckOutQueueAction
> > >
> > >
> > > 2008/4/27 Brett Porter <br...@apache.org>:
> > >
> > > > Hi,
> > > >
> > > > I've started to do some refactoring - this is along the way to the
> builder
> > > > separation I mentioned earlier.
> > > >
> > > > If you have a moment, please review r 651947. It's on a branch, but
> I'd
> > > > like to regularly merge to trunk if there are no objects to avoid
> getting
> > > > too distant. I have more tests to write for this first.
> > > >
> > > > All I've done is pulled the DefaultContinuumScm class out into a
> separate
> > > > module, and decoupled it from the model. It already contained some
> logic
> > > > related to the SCMs (which may actually need to go back into Maven SCM
> > > > itself). I pulled the logging and database updates back into the
> actions in
> > > > code (this did result in some duplication, but I can clean that up
> later).
> > > > It also showed that some code was never having its results used, and
> also
> > > > started to expose some exception handling bugs. I stopped wrapping
> > > > exceptions and results, choosing to use the Maven SCM API natively.
> > > >
> > > > Thoughts?
> > > >
> > > > Anyone that is knowledgable in Spring, please check my work :) Is
> there a
> > > > way to easily populate maps of beans, instead of hard coding the
> providers?
> > > >
> > > >
> > >
> > > hehe it looks plexus have some nice features ;-)
> > >
> > >
> > > > Cheers,
> > > > Brett
> > > >
> > > > --
> > > > Brett Porter
> > > > brett@apache.org
> > > > http://blogs.exist.com/bporter/
> > > >
> > > >
> > > >
> > >
> >
> > --
> > Brett Porter
> > brett@apache.org
> > http://blogs.exist.com/bporter/
> >
> >
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: refactoring the SCM
Posted by Brett Porter <br...@apache.org>.
ok, fixed and committed :)
Anyone able to take a look through?
Cheers,
Brett
On 02/05/2008, at 2:53 PM, Brett Porter wrote:
> me too after cleaning up. Sorry about that, I'll look into it.
>
> - Brett
>
> On 30/04/2008, at 5:52 AM, Olivier Lamy wrote:
>
>> Hi,
>> I can't build the branch :
>> /local/olamy/open-source/continuum-svn/builder-branch/continuum-
>> core/src/main/java/org/apache/maven/continuum/core/action/
>> AddProjectToCheckOutQueueAction.java:[60,16]
>> cannot find symbol
>> symbol : class CheckOutTask
>> location: class
>> org
>> .apache.maven.continuum.core.action.AddProjectToCheckOutQueueAction
>>
>>
>> 2008/4/27 Brett Porter <br...@apache.org>:
>>> Hi,
>>>
>>> I've started to do some refactoring - this is along the way to the
>>> builder
>>> separation I mentioned earlier.
>>>
>>> If you have a moment, please review r 651947. It's on a branch,
>>> but I'd
>>> like to regularly merge to trunk if there are no objects to avoid
>>> getting
>>> too distant. I have more tests to write for this first.
>>>
>>> All I've done is pulled the DefaultContinuumScm class out into a
>>> separate
>>> module, and decoupled it from the model. It already contained some
>>> logic
>>> related to the SCMs (which may actually need to go back into Maven
>>> SCM
>>> itself). I pulled the logging and database updates back into the
>>> actions in
>>> code (this did result in some duplication, but I can clean that up
>>> later).
>>> It also showed that some code was never having its results used,
>>> and also
>>> started to expose some exception handling bugs. I stopped wrapping
>>> exceptions and results, choosing to use the Maven SCM API natively.
>>>
>>> Thoughts?
>>>
>>> Anyone that is knowledgable in Spring, please check my work :) Is
>>> there a
>>> way to easily populate maps of beans, instead of hard coding the
>>> providers?
>>>
>>
>> hehe it looks plexus have some nice features ;-)
>>
>>> Cheers,
>>> Brett
>>>
>>> --
>>> Brett Porter
>>> brett@apache.org
>>> http://blogs.exist.com/bporter/
>>>
>>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: refactoring the SCM
Posted by Brett Porter <br...@apache.org>.
me too after cleaning up. Sorry about that, I'll look into it.
- Brett
On 30/04/2008, at 5:52 AM, Olivier Lamy wrote:
> Hi,
> I can't build the branch :
> /local/olamy/open-source/continuum-svn/builder-branch/continuum-core/
> src/main/java/org/apache/maven/continuum/core/action/
> AddProjectToCheckOutQueueAction.java:[60,16]
> cannot find symbol
> symbol : class CheckOutTask
> location: class
> org.apache.maven.continuum.core.action.AddProjectToCheckOutQueueAction
>
>
> 2008/4/27 Brett Porter <br...@apache.org>:
>> Hi,
>>
>> I've started to do some refactoring - this is along the way to the
>> builder
>> separation I mentioned earlier.
>>
>> If you have a moment, please review r 651947. It's on a branch, but
>> I'd
>> like to regularly merge to trunk if there are no objects to avoid
>> getting
>> too distant. I have more tests to write for this first.
>>
>> All I've done is pulled the DefaultContinuumScm class out into a
>> separate
>> module, and decoupled it from the model. It already contained some
>> logic
>> related to the SCMs (which may actually need to go back into Maven
>> SCM
>> itself). I pulled the logging and database updates back into the
>> actions in
>> code (this did result in some duplication, but I can clean that up
>> later).
>> It also showed that some code was never having its results used,
>> and also
>> started to expose some exception handling bugs. I stopped wrapping
>> exceptions and results, choosing to use the Maven SCM API natively.
>>
>> Thoughts?
>>
>> Anyone that is knowledgable in Spring, please check my work :) Is
>> there a
>> way to easily populate maps of beans, instead of hard coding the
>> providers?
>>
>
> hehe it looks plexus have some nice features ;-)
>
>> Cheers,
>> Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: refactoring the SCM
Posted by Olivier Lamy <ol...@apache.org>.
Hi,
I can't build the branch :
/local/olamy/open-source/continuum-svn/builder-branch/continuum-core/src/main/java/org/apache/maven/continuum/core/action/AddProjectToCheckOutQueueAction.java:[60,16]
cannot find symbol
symbol : class CheckOutTask
location: class
org.apache.maven.continuum.core.action.AddProjectToCheckOutQueueAction
2008/4/27 Brett Porter <br...@apache.org>:
> Hi,
>
> I've started to do some refactoring - this is along the way to the builder
> separation I mentioned earlier.
>
> If you have a moment, please review r 651947. It's on a branch, but I'd
> like to regularly merge to trunk if there are no objects to avoid getting
> too distant. I have more tests to write for this first.
>
> All I've done is pulled the DefaultContinuumScm class out into a separate
> module, and decoupled it from the model. It already contained some logic
> related to the SCMs (which may actually need to go back into Maven SCM
> itself). I pulled the logging and database updates back into the actions in
> code (this did result in some duplication, but I can clean that up later).
> It also showed that some code was never having its results used, and also
> started to expose some exception handling bugs. I stopped wrapping
> exceptions and results, choosing to use the Maven SCM API natively.
>
> Thoughts?
>
> Anyone that is knowledgable in Spring, please check my work :) Is there a
> way to easily populate maps of beans, instead of hard coding the providers?
>
hehe it looks plexus have some nice features ;-)
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: refactoring the SCM
Posted by Marica Tan <ct...@exist.com>.
On Thu, May 8, 2008 at 11:15 AM, Brett Porter <br...@apache.org> wrote:
>
> On 08/05/2008, at 12:58 PM, Marica Tan wrote:
>
>
>>> sounds good - how do you think we should represent the other types of
>>> errors when SVN is offline, or an update can't be initiated because the
>>> POM
>>> is bad, etc?
>>>
>>>
>>> I think if it's a failure related to the source, like POMs etc... then
>> it
>> should be represented by an "X" mark. But if it's related to scm
>> connections, hard drive failures, or anything related to infrastructure..
>> then either it will be represented by it's last build whether it's an "X"
>> or
>> check mark or we could create another symbol for that?
>>
>
> I'm undecided on two fronts :)
>
> - I think I can go either way on treating POM errors as transient (I
> couldn't even attempt to build) or failures (I tried to build and couldn't).
> It's more naturally the latter due to the location in source control, but it
> is just a step of build configuration, which can fail in other ways (or for
> ant, etc projects that don't auto update) and is "transient" there.
>
I guess we can treat POM errors as transient
> - should we replace the icon in the UI for the status, or have an
> additional one that indicates the last build couldn't run? I'm leaning
> towards the latter. The key difference I see is that we don't record a build
> result for transient errors - it's just a displayed state (and associated
> error message) that goes away later.
>
>
> I think additional icon will be better
- Marica
Re: refactoring the SCM
Posted by Brett Porter <br...@apache.org>.
On 08/05/2008, at 12:58 PM, Marica Tan wrote:
>>
>> sounds good - how do you think we should represent the other types of
>> errors when SVN is offline, or an update can't be initiated because
>> the POM
>> is bad, etc?
>>
>>
> I think if it's a failure related to the source, like POMs etc...
> then it
> should be represented by an "X" mark. But if it's related to scm
> connections, hard drive failures, or anything related to
> infrastructure..
> then either it will be represented by it's last build whether it's
> an "X" or
> check mark or we could create another symbol for that?
I'm undecided on two fronts :)
- I think I can go either way on treating POM errors as transient (I
couldn't even attempt to build) or failures (I tried to build and
couldn't). It's more naturally the latter due to the location in
source control, but it is just a step of build configuration, which
can fail in other ways (or for ant, etc projects that don't auto
update) and is "transient" there.
- should we replace the icon in the UI for the status, or have an
additional one that indicates the last build couldn't run? I'm leaning
towards the latter. The key difference I see is that we don't record a
build result for transient errors - it's just a displayed state (and
associated error message) that goes away later.
WDYT?
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: refactoring the SCM
Posted by Marica Tan <ct...@exist.com>.
On Thu, May 8, 2008 at 8:13 AM, Brett Porter <br...@apache.org> wrote:
>
> On 08/05/2008, at 9:55 AM, Marica Tan wrote:
>
> Hi,
> >
> > I'm thinking of adding a field in the build result that is transient
> > which
> > has the value of the last build result.
> >
> > This is currently how it looks in the project group page
> >
> > Icon Project
> > check mark successful build
> > x mark svn offline
> > check mark svn online, no changes
> >
>
> yep, the x might also mean the POM is bad or something which is then a
> configuration error, not a build failure
>
>
> >
> >
> > What I think would be better
> >
> > Icon Project
> > check mark successful build
> > (last build result) svn offline
> > check mark svn online, no changes
> >
>
> sounds good - how do you think we should represent the other types of
> errors when SVN is offline, or an update can't be initiated because the POM
> is bad, etc?
>
>
I think if it's a failure related to the source, like POMs etc... then it
should be represented by an "X" mark. But if it's related to scm
connections, hard drive failures, or anything related to infrastructure..
then either it will be represented by it's last build whether it's an "X" or
check mark or we could create another symbol for that?
Re: refactoring the SCM
Posted by Marica Tan <ct...@exist.com>.
On Wed, Aug 13, 2008 at 2:52 PM, Maria Odea Ching <oc...@apache.org> wrote:
> (Sorry, I just caught up now with discussions here in the list..)
>
> +1 on the proposal..
>
> On Fri, Aug 8, 2008 at 4:32 AM, Emmanuel Venisse <
> emmanuel.venisse@gmail.com
> > wrote:
>
> > +1 but few comments
> >
> > On Thu, Jul 31, 2008 at 9:46 AM, Marica Tan <ct...@exist.com> wrote:
> >
> > > Ok here's my new proposal :)
> > >
> > > SCM Errors
> > > 1. Separation of configuration/pre-build from actual build
> > > 2. Create new state for svn failure but will use ( x ) for the icon
> >
> >
> > In my vision, the icon for svn failures shouldn't be on the project,
> maybe
> > on the group.
> > With a scm failure, Continuum can't start the build so the project state
> > don't change
> >
>
Is this one svn state for the whole group or per scm root?
>
> > >
> > > 3. Still send a notification if there's an svn failure. ( I would still
> > > like
> > > to be notified if something like this happens )
> >
> >
> > Yes, but without a project context (project name, build definition), It
> > should be a general message and sent only one time for all projects. I
> > don't
> > want to be spammed by the same mail for all modules.
>
>
> +1 to Emmanuel's suggestion
>
>
> > >
> > > 4. Have a checkout/update error field on the project.
> >
> >
> > I don't think it is the best place. A new table with the list of all scm
> > root address with a state on each would be probably better.
> >
>
Will it be ok if we also move the scm result to a project level, so a
project will have an scm result and a build result? Right now, the scm
result is dependent on the build result, which should not be the case.
>
> >
> > >
> > > 5. Can release project even if it has a state of svn failure
> >
> >
> > With a scm failure, the release process can't run, you must check if the
> > scm
> > is back or not.
> >
> > >
> > > 6. Do not create a build result for transient errors
> > >
> > > Cancelling a build
> > > 7. Cancelled build will trigger a skip but will still have it's
> previous
> > > state.
> >
> >
> > what do you mean?
>
>
> I think this is for a project currently being built? If the build's
> cancelled, the previous state (e.g. before the cancelled build) would be
> retained?
>
> Yes
Thanks,
Marica
Re: refactoring the SCM
Posted by Maria Odea Ching <oc...@apache.org>.
(Sorry, I just caught up now with discussions here in the list..)
+1 on the proposal..
On Fri, Aug 8, 2008 at 4:32 AM, Emmanuel Venisse <emmanuel.venisse@gmail.com
> wrote:
> +1 but few comments
>
> On Thu, Jul 31, 2008 at 9:46 AM, Marica Tan <ct...@exist.com> wrote:
>
> > Ok here's my new proposal :)
> >
> > SCM Errors
> > 1. Separation of configuration/pre-build from actual build
> > 2. Create new state for svn failure but will use ( x ) for the icon
>
>
> In my vision, the icon for svn failures shouldn't be on the project, maybe
> on the group.
> With a scm failure, Continuum can't start the build so the project state
> don't change
>
> >
> > 3. Still send a notification if there's an svn failure. ( I would still
> > like
> > to be notified if something like this happens )
>
>
> Yes, but without a project context (project name, build definition), It
> should be a general message and sent only one time for all projects. I
> don't
> want to be spammed by the same mail for all modules.
+1 to Emmanuel's suggestion
> >
> > 4. Have a checkout/update error field on the project.
>
>
> I don't think it is the best place. A new table with the list of all scm
> root address with a state on each would be probably better.
>
>
> >
> > 5. Can release project even if it has a state of svn failure
>
>
> With a scm failure, the release process can't run, you must check if the
> scm
> is back or not.
>
> >
> > 6. Do not create a build result for transient errors
> >
> > Cancelling a build
> > 7. Cancelled build will trigger a skip but will still have it's previous
> > state.
>
>
> what do you mean?
I think this is for a project currently being built? If the build's
cancelled, the previous state (e.g. before the cancelled build) would be
retained?
>
>
> Emmanuel
Thanks,
Deng
Re: refactoring the SCM
Posted by Emmanuel Venisse <em...@gmail.com>.
+1 but few comments
On Thu, Jul 31, 2008 at 9:46 AM, Marica Tan <ct...@exist.com> wrote:
> Ok here's my new proposal :)
>
> SCM Errors
> 1. Separation of configuration/pre-build from actual build
> 2. Create new state for svn failure but will use ( x ) for the icon
In my vision, the icon for svn failures shouldn't be on the project, maybe
on the group.
With a scm failure, Continuum can't start the build so the project state
don't change
>
> 3. Still send a notification if there's an svn failure. ( I would still
> like
> to be notified if something like this happens )
Yes, but without a project context (project name, build definition), It
should be a general message and sent only one time for all projects. I don't
want to be spammed by the same mail for all modules.
>
> 4. Have a checkout/update error field on the project.
I don't think it is the best place. A new table with the list of all scm
root address with a state on each would be probably better.
>
> 5. Can release project even if it has a state of svn failure
With a scm failure, the release process can't run, you must check if the scm
is back or not.
>
> 6. Do not create a build result for transient errors
>
> Cancelling a build
> 7. Cancelled build will trigger a skip but will still have it's previous
> state.
what do you mean?
Emmanuel
>
>
> WDYT?
>
> - Marica
>
> On Thu, Jul 31, 2008 at 2:09 PM, Brett Porter <br...@apache.org> wrote:
>
> >
> > On 31/07/2008, at 3:54 PM, Marica Tan wrote:
> >
> > On Thu, Jul 31, 2008 at 11:00 AM, Brett Porter <br...@apache.org>
> wrote:
> >>
> >> The more I think about it, the current (x) really signifies the right
> >>> thing, but the way it is treated needs to be improved as you've
> >>> described.
> >>> WDYT?
> >>>
> >>>
> >> You mean putting the error in the session? I think if there is a
> transient
> >> error then we put it into session so that even if you leave the group
> >> summary page while it's still updating/checking out and an svn failure
> >> occur, it's still possible to show the (x) and the error message. But
> once
> >> you leave the page again or make a refresh, the error will be gone ( we
> >> removed the error from the session once it is displayed ) and the status
> >> will be the previous status of the project.
> >>
> >
> > Sorry, no - I still think we should track it on the server (it's still
> > relevant until it's fixed) - just not as part of the build history for
> the
> > project.
> >
> > I think we used to have a separate checkout error field on the project -
> it
> > is probably a generalisation of that?
> >
> > - Brett
> >
> > --
> > Brett Porter
> > brett@apache.org
> > http://blogs.exist.com/bporter/
> >
> >
>
Re: refactoring the SCM
Posted by Olivier Lamy <ol...@apache.org>.
2008/7/31 Marica Tan <ct...@exist.com>:
> Ok here's my new proposal :)
>
> SCM Errors
> 1. Separation of configuration/pre-build from actual build
> 2. Create new state for svn failure but will use ( x ) for the icon
> 3. Still send a notification if there's an svn failure. ( I would still like
> to be notified if something like this happens )
IMHO should be configurable ? (off by default ?) (if configurable
global configuration or per projectGroup ? )
> 4. Have a checkout/update error field on the project.
> 5. Can release project even if it has a state of svn failure
> 6. Do not create a build result for transient errors
>
> Cancelling a build
> 7. Cancelled build will trigger a skip but will still have it's previous
> state.
>
> WDYT?
>
> - Marica
>
> On Thu, Jul 31, 2008 at 2:09 PM, Brett Porter <br...@apache.org> wrote:
>
>>
>> On 31/07/2008, at 3:54 PM, Marica Tan wrote:
>>
>> On Thu, Jul 31, 2008 at 11:00 AM, Brett Porter <br...@apache.org> wrote:
>>>
>>> The more I think about it, the current (x) really signifies the right
>>>> thing, but the way it is treated needs to be improved as you've
>>>> described.
>>>> WDYT?
>>>>
>>>>
>>> You mean putting the error in the session? I think if there is a transient
>>> error then we put it into session so that even if you leave the group
>>> summary page while it's still updating/checking out and an svn failure
>>> occur, it's still possible to show the (x) and the error message. But once
>>> you leave the page again or make a refresh, the error will be gone ( we
>>> removed the error from the session once it is displayed ) and the status
>>> will be the previous status of the project.
>>>
>>
>> Sorry, no - I still think we should track it on the server (it's still
>> relevant until it's fixed) - just not as part of the build history for the
>> project.
>>
>> I think we used to have a separate checkout error field on the project - it
>> is probably a generalisation of that?
>>
>> - Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
>
Re: refactoring the SCM
Posted by Brett Porter <br...@apache.org>.
+1
It must also be possible to view the error from the UI
What do others think? Emmanuel - I know you worked on this area before
to ensure builds in error got retriggered?
Cheers,
Brett
On 31/07/2008, at 5:46 PM, Marica Tan wrote:
> Ok here's my new proposal :)
>
> SCM Errors
> 1. Separation of configuration/pre-build from actual build
> 2. Create new state for svn failure but will use ( x ) for the icon
> 3. Still send a notification if there's an svn failure. ( I would
> still like
> to be notified if something like this happens )
> 4. Have a checkout/update error field on the project.
> 5. Can release project even if it has a state of svn failure
> 6. Do not create a build result for transient errors
>
> Cancelling a build
> 7. Cancelled build will trigger a skip but will still have it's
> previous
> state.
>
> WDYT?
>
> - Marica
>
> On Thu, Jul 31, 2008 at 2:09 PM, Brett Porter <br...@apache.org>
> wrote:
>
>>
>> On 31/07/2008, at 3:54 PM, Marica Tan wrote:
>>
>> On Thu, Jul 31, 2008 at 11:00 AM, Brett Porter <br...@apache.org>
>> wrote:
>>>
>>> The more I think about it, the current (x) really signifies the
>>> right
>>>> thing, but the way it is treated needs to be improved as you've
>>>> described.
>>>> WDYT?
>>>>
>>>>
>>> You mean putting the error in the session? I think if there is a
>>> transient
>>> error then we put it into session so that even if you leave the
>>> group
>>> summary page while it's still updating/checking out and an svn
>>> failure
>>> occur, it's still possible to show the (x) and the error message.
>>> But once
>>> you leave the page again or make a refresh, the error will be gone
>>> ( we
>>> removed the error from the session once it is displayed ) and the
>>> status
>>> will be the previous status of the project.
>>>
>>
>> Sorry, no - I still think we should track it on the server (it's
>> still
>> relevant until it's fixed) - just not as part of the build history
>> for the
>> project.
>>
>> I think we used to have a separate checkout error field on the
>> project - it
>> is probably a generalisation of that?
>>
>> - Brett
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: refactoring the SCM
Posted by Marica Tan <ct...@exist.com>.
Ok here's my new proposal :)
SCM Errors
1. Separation of configuration/pre-build from actual build
2. Create new state for svn failure but will use ( x ) for the icon
3. Still send a notification if there's an svn failure. ( I would still like
to be notified if something like this happens )
4. Have a checkout/update error field on the project.
5. Can release project even if it has a state of svn failure
6. Do not create a build result for transient errors
Cancelling a build
7. Cancelled build will trigger a skip but will still have it's previous
state.
WDYT?
- Marica
On Thu, Jul 31, 2008 at 2:09 PM, Brett Porter <br...@apache.org> wrote:
>
> On 31/07/2008, at 3:54 PM, Marica Tan wrote:
>
> On Thu, Jul 31, 2008 at 11:00 AM, Brett Porter <br...@apache.org> wrote:
>>
>> The more I think about it, the current (x) really signifies the right
>>> thing, but the way it is treated needs to be improved as you've
>>> described.
>>> WDYT?
>>>
>>>
>> You mean putting the error in the session? I think if there is a transient
>> error then we put it into session so that even if you leave the group
>> summary page while it's still updating/checking out and an svn failure
>> occur, it's still possible to show the (x) and the error message. But once
>> you leave the page again or make a refresh, the error will be gone ( we
>> removed the error from the session once it is displayed ) and the status
>> will be the previous status of the project.
>>
>
> Sorry, no - I still think we should track it on the server (it's still
> relevant until it's fixed) - just not as part of the build history for the
> project.
>
> I think we used to have a separate checkout error field on the project - it
> is probably a generalisation of that?
>
> - Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: refactoring the SCM
Posted by Brett Porter <br...@apache.org>.
On 31/07/2008, at 3:54 PM, Marica Tan wrote:
> On Thu, Jul 31, 2008 at 11:00 AM, Brett Porter <br...@apache.org>
> wrote:
>
>> The more I think about it, the current (x) really signifies the right
>> thing, but the way it is treated needs to be improved as you've
>> described.
>> WDYT?
>>
>
> You mean putting the error in the session? I think if there is a
> transient
> error then we put it into session so that even if you leave the group
> summary page while it's still updating/checking out and an svn failure
> occur, it's still possible to show the (x) and the error message.
> But once
> you leave the page again or make a refresh, the error will be gone
> ( we
> removed the error from the session once it is displayed ) and the
> status
> will be the previous status of the project.
Sorry, no - I still think we should track it on the server (it's still
relevant until it's fixed) - just not as part of the build history for
the project.
I think we used to have a separate checkout error field on the project
- it is probably a generalisation of that?
- Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: refactoring the SCM
Posted by Marica Tan <ct...@exist.com>.
On Thu, Jul 31, 2008 at 11:00 AM, Brett Porter <br...@apache.org> wrote:
> The more I think about it, the current (x) really signifies the right
> thing, but the way it is treated needs to be improved as you've described.
> WDYT?
>
You mean putting the error in the session? I think if there is a transient
error then we put it into session so that even if you leave the group
summary page while it's still updating/checking out and an svn failure
occur, it's still possible to show the (x) and the error message. But once
you leave the page again or make a refresh, the error will be gone ( we
removed the error from the session once it is displayed ) and the status
will be the previous status of the project.
- Marica
Re: refactoring the SCM
Posted by Brett Porter <br...@apache.org>.
The more I think about it, the current (x) really signifies the right
thing, but the way it is treated needs to be improved as you've
described. WDYT?
- Brett
On 31/07/2008, at 9:21 AM, Marica Tan wrote:
> Hi Brett
>
> Do I still need to add new status icon for transient errors?
>
> Thanks,
> Marica
>
> On Wed, Jul 30, 2008 at 2:58 PM, Brett Porter <br...@apache.org>
> wrote:
>
>> Hi Marica!
>>
>> I like the idea, though I think it could be a bit simpler. I'm a
>> bit unsure
>> why it's coupled to the state and build results at all? Do we need
>> to track
>> these for historical purposes?
>>
>> I think at the moment we already have the error state, which AFAICT
>> are
>> always the result of configuration or transient errors. Perhaps we
>> could
>> replace that with this?
>>
>> The types of things I want to see it achieve are:
>> - same notification mechanism as the rest, but ability to separate
>> handling
>> (which we have with error types already)
>> - if it is corrected, it is as if it never happened - ie, no build
>> result,
>> no notification if it wouldn't have if it hadn't have happened (eg
>> SUCCESS
>> -> SVN FAIL -> SUCCESS should just report the SVN failure needs
>> fixing)
>> - make it possible for Continuum to know it needs to try something
>> again.
>>
>> I hope this makes sense... basically I think we should separate the
>> configuration/pre-build from the actual build.
>>
>> I'm still not sure if POM errors are really transient :)
>>
>> Thanks,
>> Brett
>>
>>
>> On 30/07/2008, at 12:06 PM, Marica Tan wrote:
>>
>> Hi All,
>>>
>>> I would like to work on the transient state.
>>>
>>> Here's what I'm proposing to do:
>>>
>>> 1. Add two new states: SVN_FAILURE and BAD_POM
>>> * thought of adding just one state: TRANSIENT_ERROR but it's not
>>> descriptive
>>>
>>> 2. When an error occur due to svn failure or bad pom configuration
>>> then
>>> a. create a build result and set the state to #1
>>> b. retain the old state and latestBuildId of the project ( before
>>> building / updating )
>>>
>>> 3. Add a new status icon for transient errors. ( No idea yet how
>>> it will
>>> look like. Any suggestions? )
>>>
>>> 4. In the ProjectGroupAction#summary class:
>>> a. check if there is a build result having SVN_FAILURE or BAD_POM
>>> state
>>> b. if exists, put it in the session for 5 mins and delete the build
>>> result from the database.
>>> c. if not, check if it's still in the session
>>> d. set project state = build result state
>>> e. display the state and associated error message
>>>
>>>
>>> WDYT?
>>>
>>> Thanks,
>>> Marica
>>>
>>
>> --
>> Brett Porter
>> brett@apache.org
>> http://blogs.exist.com/bporter/
>>
>>
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: refactoring the SCM
Posted by Marica Tan <ct...@exist.com>.
Hi Brett
Do I still need to add new status icon for transient errors?
Thanks,
Marica
On Wed, Jul 30, 2008 at 2:58 PM, Brett Porter <br...@apache.org> wrote:
> Hi Marica!
>
> I like the idea, though I think it could be a bit simpler. I'm a bit unsure
> why it's coupled to the state and build results at all? Do we need to track
> these for historical purposes?
>
> I think at the moment we already have the error state, which AFAICT are
> always the result of configuration or transient errors. Perhaps we could
> replace that with this?
>
> The types of things I want to see it achieve are:
> - same notification mechanism as the rest, but ability to separate handling
> (which we have with error types already)
> - if it is corrected, it is as if it never happened - ie, no build result,
> no notification if it wouldn't have if it hadn't have happened (eg SUCCESS
> -> SVN FAIL -> SUCCESS should just report the SVN failure needs fixing)
> - make it possible for Continuum to know it needs to try something again.
>
> I hope this makes sense... basically I think we should separate the
> configuration/pre-build from the actual build.
>
> I'm still not sure if POM errors are really transient :)
>
> Thanks,
> Brett
>
>
> On 30/07/2008, at 12:06 PM, Marica Tan wrote:
>
> Hi All,
>>
>> I would like to work on the transient state.
>>
>> Here's what I'm proposing to do:
>>
>> 1. Add two new states: SVN_FAILURE and BAD_POM
>> * thought of adding just one state: TRANSIENT_ERROR but it's not
>> descriptive
>>
>> 2. When an error occur due to svn failure or bad pom configuration then
>> a. create a build result and set the state to #1
>> b. retain the old state and latestBuildId of the project ( before
>> building / updating )
>>
>> 3. Add a new status icon for transient errors. ( No idea yet how it will
>> look like. Any suggestions? )
>>
>> 4. In the ProjectGroupAction#summary class:
>> a. check if there is a build result having SVN_FAILURE or BAD_POM state
>> b. if exists, put it in the session for 5 mins and delete the build
>> result from the database.
>> c. if not, check if it's still in the session
>> d. set project state = build result state
>> e. display the state and associated error message
>>
>>
>> WDYT?
>>
>> Thanks,
>> Marica
>>
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
Re: refactoring the SCM
Posted by Brett Porter <br...@apache.org>.
Hi Marica!
I like the idea, though I think it could be a bit simpler. I'm a bit
unsure why it's coupled to the state and build results at all? Do we
need to track these for historical purposes?
I think at the moment we already have the error state, which AFAICT
are always the result of configuration or transient errors. Perhaps we
could replace that with this?
The types of things I want to see it achieve are:
- same notification mechanism as the rest, but ability to separate
handling (which we have with error types already)
- if it is corrected, it is as if it never happened - ie, no build
result, no notification if it wouldn't have if it hadn't have happened
(eg SUCCESS -> SVN FAIL -> SUCCESS should just report the SVN failure
needs fixing)
- make it possible for Continuum to know it needs to try something
again.
I hope this makes sense... basically I think we should separate the
configuration/pre-build from the actual build.
I'm still not sure if POM errors are really transient :)
Thanks,
Brett
On 30/07/2008, at 12:06 PM, Marica Tan wrote:
> Hi All,
>
> I would like to work on the transient state.
>
> Here's what I'm proposing to do:
>
> 1. Add two new states: SVN_FAILURE and BAD_POM
> * thought of adding just one state: TRANSIENT_ERROR but it's not
> descriptive
>
> 2. When an error occur due to svn failure or bad pom configuration
> then
> a. create a build result and set the state to #1
> b. retain the old state and latestBuildId of the project ( before
> building / updating )
>
> 3. Add a new status icon for transient errors. ( No idea yet how it
> will
> look like. Any suggestions? )
>
> 4. In the ProjectGroupAction#summary class:
> a. check if there is a build result having SVN_FAILURE or BAD_POM
> state
> b. if exists, put it in the session for 5 mins and delete the build
> result from the database.
> c. if not, check if it's still in the session
> d. set project state = build result state
> e. display the state and associated error message
>
>
> WDYT?
>
> Thanks,
> Marica
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: refactoring the SCM
Posted by Marica Tan <ct...@exist.com>.
Hi All,
I would like to work on the transient state.
Here's what I'm proposing to do:
1. Add two new states: SVN_FAILURE and BAD_POM
* thought of adding just one state: TRANSIENT_ERROR but it's not
descriptive
2. When an error occur due to svn failure or bad pom configuration then
a. create a build result and set the state to #1
b. retain the old state and latestBuildId of the project ( before
building / updating )
3. Add a new status icon for transient errors. ( No idea yet how it will
look like. Any suggestions? )
4. In the ProjectGroupAction#summary class:
a. check if there is a build result having SVN_FAILURE or BAD_POM state
b. if exists, put it in the session for 5 mins and delete the build
result from the database.
c. if not, check if it's still in the session
d. set project state = build result state
e. display the state and associated error message
WDYT?
Thanks,
Marica
Re: refactoring the SCM
Posted by Brett Porter <br...@apache.org>.
On 16/05/2008, at 5:55 AM, Emmanuel Venisse wrote:
> I think build status must be totally independent of the svn status.
Cool, I think we all agree on that then.
>
> My point of view is:
> - svn offline ==> nothing to do (maybe an alert to send)
I would still like to see this in the UI somewhere so it's not
confusing why it didn't build.
>
> - build ok ==> green icon
> - test failures ==> orange icon
> - compilation/packaging failure ==> red icon
I'm no sure if it's necessary to differentiate between test failures
and other failures - that's like saying it's less important if your
tests fail than if your code compiles :)
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: refactoring the SCM
Posted by Emmanuel Venisse <em...@gmail.com>.
On Thu, May 8, 2008 at 2:13 AM, Brett Porter <br...@apache.org> wrote:
>
> On 08/05/2008, at 9:55 AM, Marica Tan wrote:
>
> Hi,
>>
>> I'm thinking of adding a field in the build result that is transient which
>> has the value of the last build result.
>>
>> This is currently how it looks in the project group page
>>
>> Icon Project
>> check mark successful build
>> x mark svn offline
>> check mark svn online, no changes
>>
>
> yep, the x might also mean the POM is bad or something which is then a
> configuration error, not a build failure
>
>
>>
>>
>> What I think would be better
>>
>> Icon Project
>> check mark successful build
>> (last build result) svn offline
>> check mark svn online, no changes
>>
>
> sounds good - how do you think we should represent the other types of
> errors when SVN is offline, or an update can't be initiated because the POM
> is bad, etc?
I think build status must be totally independent of the svn status.
My point of view is:
- svn offline ==> nothing to do (maybe an alert to send)
- build ok ==> green icon
- test failures ==> orange icon
- compilation/packaging failure ==> red icon
Emmanuel
Re: refactoring the SCM
Posted by Brett Porter <br...@apache.org>.
On 08/05/2008, at 9:55 AM, Marica Tan wrote:
> Hi,
>
> I'm thinking of adding a field in the build result that is transient
> which
> has the value of the last build result.
>
> This is currently how it looks in the project group page
>
> Icon Project
> check mark successful build
> x mark svn offline
> check mark svn online, no changes
yep, the x might also mean the POM is bad or something which is then a
configuration error, not a build failure
>
>
>
> What I think would be better
>
> Icon Project
> check mark successful build
> (last build result) svn offline
> check mark svn online, no changes
sounds good - how do you think we should represent the other types of
errors when SVN is offline, or an update can't be initiated because
the POM is bad, etc?
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: refactoring the SCM
Posted by Marica Tan <ct...@exist.com>.
Hi,
I'm thinking of adding a field in the build result that is transient which
has the value of the last build result.
This is currently how it looks in the project group page
Icon Project
check mark successful build
x mark svn offline
check mark svn online, no changes
What I think would be better
Icon Project
check mark successful build
(last build result) svn offline
check mark svn online, no changes
Wdyt?
Thanks,
Marica
Re: refactoring the SCM
Posted by Carlos Sanchez <ca...@apache.org>.
I have just committed a solution to the map of beans.
Unfortunately is Spring-dependent so it may make sense to put it in a
separate continuum-spring module, maybe just in the future if there
are more support classes like it.
On Sun, Apr 27, 2008 at 7:02 AM, Brett Porter <br...@apache.org> wrote:
> Hi,
>
> I've started to do some refactoring - this is along the way to the builder
> separation I mentioned earlier.
>
> If you have a moment, please review r 651947. It's on a branch, but I'd
> like to regularly merge to trunk if there are no objects to avoid getting
> too distant. I have more tests to write for this first.
>
> All I've done is pulled the DefaultContinuumScm class out into a separate
> module, and decoupled it from the model. It already contained some logic
> related to the SCMs (which may actually need to go back into Maven SCM
> itself). I pulled the logging and database updates back into the actions in
> code (this did result in some duplication, but I can clean that up later).
> It also showed that some code was never having its results used, and also
> started to expose some exception handling bugs. I stopped wrapping
> exceptions and results, choosing to use the Maven SCM API natively.
>
> Thoughts?
>
> Anyone that is knowledgable in Spring, please check my work :) Is there a
> way to easily populate maps of beans, instead of hard coding the providers?
>
> Cheers,
> Brett
>
> --
> Brett Porter
> brett@apache.org
> http://blogs.exist.com/bporter/
>
>
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride