Refactorings and Architecture
9 views
Skip to first unread message
Daniel Luebke
Apr 26, 2012, 4:32:06 PM4/26/12
to bpel...@googlegroups.com
Hi,
as some of you might have seen, I'm pushing lots of refactoring changes in the last days. I have looked at the Sonar reports (https://neptuno.uca.es/sonar/dashboard/index/592?did=1&period=) and there are MANY things that should be addressed over time. In addition, there are some serious architectural problems right now.
I think we should fix the coding issues as we have time and already touch a certain package, so that we can get the Sonar problems on coding issues down over time.
However, there are at least these architectural problems which need investigation:
- dependency between TestCaseRunner and TestSuite: There seems to be an unclear distribution of reponsibilities between these classes,
- IDeployment and IBPELDeployer: The IDeployment interface needs much improvement in order to decouple engine specific details better. Currently, instrumentation knows too much about the engine used. The deployer should not have get/setArchiveLocation anymore. Instead, IDeployment should transparently handle access to BPEL processes,
- Runner architecture: Every runner has its own run() implementation. IMO it would be better to have one runner which completely implements the test running logic and notifies UI observers which will then update their UI or print something etc.
- Instrumentation: There needs to much cleanup in the code and some tests wouldn't hurt... It's a huge field.
I have started some brainstorming about a new IDeployment interface. I will try to do this as part of enhancing the ActiveVOS deployer. If somebody has input to this or to the other or even new topics, please post :-)
Daniel
as some of you might have seen, I'm pushing lots of refactoring changes in the last days. I have looked at the Sonar reports (https://neptuno.uca.es/sonar/dashboard/index/592?did=1&period=) and there are MANY things that should be addressed over time. In addition, there are some serious architectural problems right now.
I think we should fix the coding issues as we have time and already touch a certain package, so that we can get the Sonar problems on coding issues down over time.
However, there are at least these architectural problems which need investigation:
- dependency between TestCaseRunner and TestSuite: There seems to be an unclear distribution of reponsibilities between these classes,
- IDeployment and IBPELDeployer: The IDeployment interface needs much improvement in order to decouple engine specific details better. Currently, instrumentation knows too much about the engine used. The deployer should not have get/setArchiveLocation anymore. Instead, IDeployment should transparently handle access to BPEL processes,
- Runner architecture: Every runner has its own run() implementation. IMO it would be better to have one runner which completely implements the test running logic and notifies UI observers which will then update their UI or print something etc.
- Instrumentation: There needs to much cleanup in the code and some tests wouldn't hurt... It's a huge field.
I have started some brainstorming about a new IDeployment interface. I will try to do this as part of enhancing the ActiveVOS deployer. If somebody has input to this or to the other or even new topics, please post :-)
Daniel
Daniel Luebke
Apr 26, 2012, 4:35:21 PM4/26/12
to bpel...@googlegroups.com
And not to forget the huge SpecificationLoader... With strange dependencies and too many lines of code in one class..
Antonio García Domínguez
Apr 27, 2012, 6:19:25 AM4/27/12
to bpel...@googlegroups.com
Hi Daniel,
On 26 April 2012 22:32, Daniel Luebke <daniel...@gmail.com> wrote:
> as some of you might have seen, I'm pushing lots of refactoring changes in
> the last days. I have looked at the Sonar reports
> (https://neptuno.uca.es/sonar/dashboard/index/592?did=1&period=) and there
> are MANY things that should be addressed over time. In addition, there are
> some serious architectural problems right now.
I'm glad you find the Sonar reports useful :-). Yes, the package
tangle index is much higher than what I'd normally like.
> I think we should fix the coding issues as we have time and already touch a
> certain package, so that we can get the Sonar problems on coding issues down
> over time.
Sounds sensible to me.
> - IDeployment and IBPELDeployer: The IDeployment interface needs much
> improvement in order to decouple engine specific details better. Currently,
> instrumentation knows too much about the engine used. The deployer should
> not have get/setArchiveLocation anymore. Instead, IDeployment should
> transparently handle access to BPEL processes,
I ran into these issues when I first tried to integrate BPR generation
into the ActiveBPEL deployer. It should be better with the refactored
bpel-packager, but in general I found that it was too focused on
Apache ODE.
> - Runner architecture: Every runner has its own run() implementation. IMO it
> would be better to have one runner which completely implements the test
> running logic and notifies UI observers which will then update their UI or
> print something etc.
We have some custom runners based on that design: we might need to
have more fine-grained test listeners if we switch to a fixed run()
implementation. By the way, we could also really use knowing when a
certain activity in a partner track is done. That should help speed up
execution quite a bit.
> - Instrumentation: There needs to much cleanup in the code and some tests
> wouldn't hurt... It's a huge field.
We definitely need tests on the coverage bits, yes.
> I have started some brainstorming about a new IDeployment interface. I will
> try to do this as part of enhancing the ActiveVOS deployer. If somebody has
> input to this or to the other or even new topics, please post :-)
I can't really think of many other topics, but I'll have a look at
your new version of IDeployment and let you know my thoughts on it
:-).
Cheers,
Antonio
On 26 April 2012 22:32, Daniel Luebke <daniel...@gmail.com> wrote:
> as some of you might have seen, I'm pushing lots of refactoring changes in
> the last days. I have looked at the Sonar reports
> (https://neptuno.uca.es/sonar/dashboard/index/592?did=1&period=) and there
> are MANY things that should be addressed over time. In addition, there are
> some serious architectural problems right now.
tangle index is much higher than what I'd normally like.
> I think we should fix the coding issues as we have time and already touch a
> certain package, so that we can get the Sonar problems on coding issues down
> over time.
> - IDeployment and IBPELDeployer: The IDeployment interface needs much
> improvement in order to decouple engine specific details better. Currently,
> instrumentation knows too much about the engine used. The deployer should
> not have get/setArchiveLocation anymore. Instead, IDeployment should
> transparently handle access to BPEL processes,
into the ActiveBPEL deployer. It should be better with the refactored
bpel-packager, but in general I found that it was too focused on
Apache ODE.
> - Runner architecture: Every runner has its own run() implementation. IMO it
> would be better to have one runner which completely implements the test
> running logic and notifies UI observers which will then update their UI or
> print something etc.
have more fine-grained test listeners if we switch to a fixed run()
implementation. By the way, we could also really use knowing when a
certain activity in a partner track is done. That should help speed up
execution quite a bit.
> - Instrumentation: There needs to much cleanup in the code and some tests
> wouldn't hurt... It's a huge field.
> I have started some brainstorming about a new IDeployment interface. I will
> try to do this as part of enhancing the ActiveVOS deployer. If somebody has
> input to this or to the other or even new topics, please post :-)
your new version of IDeployment and let you know my thoughts on it
:-).
Cheers,
Antonio
Daniel Luebke
Apr 27, 2012, 1:42:53 PM4/27/12
to bpel...@googlegroups.com
Hi Antonio,
Am Freitag, 27. April 2012 12:19:25 UTC+2 schrieb Antonio García Domínguez:
I love tools supporting you! However, the number is one thing but if you look at the dependencies it is even worse than the number indicates.
Oh, then you should pay attention: I moves the Extension Registry because I wasn't aware that you have custom runners. It is just a move. Either discard the commit or just re-organize the imports. Sorry.
Till summer ;-)
It's not everything in there yet. However, my vision is to make it a facade that can fetch BPEL XML and offers modification method where changes will also impact the deployment descriptors (like adding a new service, partnerlink, changing endpoints...)
Daniel
Am Freitag, 27. April 2012 12:19:25 UTC+2 schrieb Antonio García Domínguez:
Hi Daniel,
On 26 April 2012 22:32, Daniel Luebke <daniel...@gmail.com> wrote:
[...]
I'm glad you find the Sonar reports useful :-). Yes, the package
tangle index is much higher than what I'd normally like.
I love tools supporting you! However, the number is one thing but if you look at the dependencies it is even worse than the number indicates.
[...]
> - Runner architecture: Every runner has its own run() implementation. IMO it
> would be better to have one runner which completely implements the test
> running logic and notifies UI observers which will then update their UI or
> print something etc.
We have some custom runners based on that design: we might need to
have more fine-grained test listeners if we switch to a fixed run()
implementation. By the way, we could also really use knowing when a
certain activity in a partner track is done. That should help speed up
execution quite a bit.
Oh, then you should pay attention: I moves the Extension Registry because I wasn't aware that you have custom runners. It is just a move. Either discard the commit or just re-organize the imports. Sorry.
> - Instrumentation: There needs to much cleanup in the code and some tests
> wouldn't hurt... It's a huge field.
We definitely need tests on the coverage bits, yes.
Till summer ;-)
> I have started some brainstorming about a new IDeployment interface. I will
> try to do this as part of enhancing the ActiveVOS deployer. If somebody has
> input to this or to the other or even new topics, please post :-)
I can't really think of many other topics, but I'll have a look at
your new version of IDeployment and let you know my thoughts on it
:-).
It's not everything in there yet. However, my vision is to make it a facade that can fetch BPEL XML and offers modification method where changes will also impact the deployment descriptors (like adding a new service, partnerlink, changing endpoints...)
Daniel
Antonio García Domínguez
Apr 29, 2012, 5:14:33 AM4/29/12
to bpel...@googlegroups.com
Hi Daniel,
On 27 April 2012 19:42, Daniel Luebke <daniel...@gmail.com> wrote:
> I love tools supporting you! However, the number is one thing but if you
> look at the dependencies it is even worse than the number indicates.
Yes, I agree with you on that.
> Oh, then you should pay attention: I moves the Extension Registry because I
> wasn't aware that you have custom runners. It is just a move. Either discard
> the commit or just re-organize the imports. Sorry.
Shall we release v1.6.0 with a commit from before all these
refactorings? I think it's about time we did one, and it'll give us
more leeway when doing all these changes. What do you think?
> It's not everything in there yet. However, my vision is to make it a facade
> that can fetch BPEL XML and offers modification method where changes will
> also impact the deployment descriptors (like adding a new service,
> partnerlink, changing endpoints...)
Yes, a more neutral interface would be very useful. We should specify
it as abstract changes and let the implementations map it to concrete
deployment archives and processes.
Cheers,
Antonio
On 27 April 2012 19:42, Daniel Luebke <daniel...@gmail.com> wrote:
> I love tools supporting you! However, the number is one thing but if you
> look at the dependencies it is even worse than the number indicates.
> Oh, then you should pay attention: I moves the Extension Registry because I
> wasn't aware that you have custom runners. It is just a move. Either discard
> the commit or just re-organize the imports. Sorry.
refactorings? I think it's about time we did one, and it'll give us
more leeway when doing all these changes. What do you think?
> It's not everything in there yet. However, my vision is to make it a facade
> that can fetch BPEL XML and offers modification method where changes will
> also impact the deployment descriptors (like adding a new service,
> partnerlink, changing endpoints...)
it as abstract changes and let the implementations map it to concrete
deployment archives and processes.
Cheers,
Antonio
Daniel Luebke
May 2, 2012, 4:38:58 PM5/2/12
to bpel...@googlegroups.com
Hi Antonio,
Am Sonntag, 29. April 2012 11:14:33 UTC+2 schrieb Antonio García Domínguez:
Would probably a good idea. We should then make a list of features we want to have in 2.0 incl. refactorings, deployers, documentation, ...
Exactly.
I have made another refactoring for moving ITestResultListener. I will push this only to my private repo until the release is made.
Daniel
Am Sonntag, 29. April 2012 11:14:33 UTC+2 schrieb Antonio García Domínguez:
[...]
> Oh, then you should pay attention: I moves the Extension Registry because I
> wasn't aware that you have custom runners. It is just a move. Either discard
> the commit or just re-organize the imports. Sorry.
Shall we release v1.6.0 with a commit from before all these
refactorings? I think it's about time we did one, and it'll give us
more leeway when doing all these changes. What do you think?
Would probably a good idea. We should then make a list of features we want to have in 2.0 incl. refactorings, deployers, documentation, ...
> It's not everything in there yet. However, my vision is to make it a facade
> that can fetch BPEL XML and offers modification method where changes will
> also impact the deployment descriptors (like adding a new service,
> partnerlink, changing endpoints...)
Yes, a more neutral interface would be very useful. We should specify
it as abstract changes and let the implementations map it to concrete
deployment archives and processes.
Exactly.
I have made another refactoring for moving ITestResultListener. I will push this only to my private repo until the release is made.
Daniel
Antonio García Domínguez
May 3, 2012, 2:50:13 AM5/3/12
to bpel...@googlegroups.com
Hi Daniel,
On 2 May 2012 22:38, Daniel Luebke <daniel...@gmail.com> wrote:
> Would probably a good idea. We should then make a list of features we want
> to have in 2.0 incl. refactorings, deployers, documentation, ...
I'm on it then :-). Let's discuss that when the 1.6 release is done.
> I have made another refactoring for moving ITestResultListener. I will push
> this only to my private repo until the release is made.
Sounds good!
Antonio
On 2 May 2012 22:38, Daniel Luebke <daniel...@gmail.com> wrote:
> Would probably a good idea. We should then make a list of features we want
> to have in 2.0 incl. refactorings, deployers, documentation, ...
> I have made another refactoring for moving ITestResultListener. I will push
> this only to my private repo until the release is made.
Antonio
Antonio García Domínguez
May 3, 2012, 3:57:18 AM5/3/12
to bpel...@googlegroups.com
Hi Daniel,
I've just pushed a new 1.6.0 tag to the official repo, and I've used
it to release BPELUnit 1.6.0. It wasn't the very latest commit (it was
from 2 o 3 days ago), but it was well tested :-).
I've promoted the release, so it should be synced to Maven Central by
tomorrow. I've also updated the bpelunit.github.com website with a
news post and some updated download links. These won't work until
BPELUnit 1.6.0 is synced into Maven Central, though.
By the way, what should we do with update.bpelunit.net? Could you
update it with the contents of [1]? It works with Galileo, I believe.
[1]: https://oss.sonatype.org/service/local/artifact/maven/redirect?r=releases&g=net.bpelunit&a=eclipse-update-site&v=1.6.0&e=zip&c=assembly
Cheers,
Antonio
I've just pushed a new 1.6.0 tag to the official repo, and I've used
it to release BPELUnit 1.6.0. It wasn't the very latest commit (it was
from 2 o 3 days ago), but it was well tested :-).
I've promoted the release, so it should be synced to Maven Central by
tomorrow. I've also updated the bpelunit.github.com website with a
news post and some updated download links. These won't work until
BPELUnit 1.6.0 is synced into Maven Central, though.
By the way, what should we do with update.bpelunit.net? Could you
update it with the contents of [1]? It works with Galileo, I believe.
[1]: https://oss.sonatype.org/service/local/artifact/maven/redirect?r=releases&g=net.bpelunit&a=eclipse-update-site&v=1.6.0&e=zip&c=assembly
Cheers,
Antonio
Daniel Luebke
May 3, 2012, 4:02:23 AM5/3/12
to bpel...@googlegroups.com
Hi Antonio,
great news and thank you. I will update the "official" page and the update site in the evening. Although I'm really thinking of just making a redirect from bpelunit.net -> bpelunit.github.com
Afterwards I will push the changes from my private repo to the official one. Sonar is really nice to easily walk through the problems of the code since my CAP plug-in isn't working anymore :-(
Daniel
great news and thank you. I will update the "official" page and the update site in the evening. Although I'm really thinking of just making a redirect from bpelunit.net -> bpelunit.github.com
Afterwards I will push the changes from my private repo to the official one. Sonar is really nice to easily walk through the problems of the code since my CAP plug-in isn't working anymore :-(
Daniel
Daniel Luebke
May 3, 2012, 3:53:04 PM5/3/12
to bpel...@googlegroups.com
Hi,
I uploaded the update site to http://update.bpelunit.net. The 1.5 version is still accessible unter http://update.bpelunit.net/bpelunit-1.5.
I also added the redirect from http://www.bpelunit.net -> http://bpelunit.github.com
And I will change my last commit to the master repo :-)
Regards,
Daniel
I uploaded the update site to http://update.bpelunit.net. The 1.5 version is still accessible unter http://update.bpelunit.net/bpelunit-1.5.
I also added the redirect from http://www.bpelunit.net -> http://bpelunit.github.com
And I will change my last commit to the master repo :-)
Regards,
Daniel
Tammo van Lessen
May 3, 2012, 5:16:27 PM5/3/12
to bpel...@googlegroups.com
Hi Daniel,
Is there a reason why a redirect is better than a DNS record? Github
supports vhosts directly, so the best possible option would be to set
the A/NAME record to github.
Cheers,
Tammo
On 03.05.2012 21:53, Daniel Luebke wrote:
> Hi,
>
> I uploaded the update site to http://update.bpelunit.net. The 1.5
> version is still accessible unter http://update.bpelunit.net/bpelunit-1.5.
>
> I also added the redirect from http://www.bpelunit.net ->
> http://bpelunit.github.com
>
> And I will change my last commit to the master repo :-)
>
> Regards,
> Daniel
>
> Am Donnerstag, 3. Mai 2012 10:02:23 UTC+2 schrieb Daniel Luebke:
>
> Hi Antonio,
>
> great news and thank you. I will update the "official" page and the
> update site in the evening. Although I'm really thinking of just
> making a redirect from bpelunit.net <http://bpelunit.net> ->
> bpelunit.github.com <http://bpelunit.github.com>
>
>
> Cheers,
> Antonio
>
--
Tammo van Lessen - http://www.taval.de
Is there a reason why a redirect is better than a DNS record? Github
supports vhosts directly, so the best possible option would be to set
the A/NAME record to github.
Cheers,
Tammo
On 03.05.2012 21:53, Daniel Luebke wrote:
> Hi,
>
> I uploaded the update site to http://update.bpelunit.net. The 1.5
> version is still accessible unter http://update.bpelunit.net/bpelunit-1.5.
>
> I also added the redirect from http://www.bpelunit.net ->
> http://bpelunit.github.com
>
> And I will change my last commit to the master repo :-)
>
> Regards,
> Daniel
>
> Am Donnerstag, 3. Mai 2012 10:02:23 UTC+2 schrieb Daniel Luebke:
>
> Hi Antonio,
>
> great news and thank you. I will update the "official" page and the
> update site in the evening. Although I'm really thinking of just
> bpelunit.github.com <http://bpelunit.github.com>
> Afterwards I will push the changes from my private repo to the
> official one. Sonar is really nice to easily walk through the
> problems of the code since my CAP plug-in isn't working anymore :-(
>
> Daniel
>
> Am Donnerstag, 3. Mai 2012 09:57:18 UTC+2 schrieb Antonio García
> Domínguez:
>
> Hi Daniel,
>
> I've just pushed a new 1.6.0 tag to the official repo, and I've
> used
> it to release BPELUnit 1.6.0. It wasn't the very latest commit
> (it was
> from 2 o 3 days ago), but it was well tested :-).
>
> I've promoted the release, so it should be synced to Maven
> Central by
> tomorrow. I've also updated the bpelunit.github.com
> <http://bpelunit.github.com> website with a
> official one. Sonar is really nice to easily walk through the
> problems of the code since my CAP plug-in isn't working anymore :-(
>
> Daniel
>
> Am Donnerstag, 3. Mai 2012 09:57:18 UTC+2 schrieb Antonio García
> Domínguez:
>
> Hi Daniel,
>
> I've just pushed a new 1.6.0 tag to the official repo, and I've
> used
> it to release BPELUnit 1.6.0. It wasn't the very latest commit
> (it was
> from 2 o 3 days ago), but it was well tested :-).
>
> I've promoted the release, so it should be synced to Maven
> Central by
> tomorrow. I've also updated the bpelunit.github.com
> news post and some updated download links. These won't work until
> BPELUnit 1.6.0 is synced into Maven Central, though.
>
> By the way, what should we do with update.bpelunit.net
> <http://update.bpelunit.net>? Could you
> BPELUnit 1.6.0 is synced into Maven Central, though.
>
> By the way, what should we do with update.bpelunit.net
> update it with the contents of [1]? It works with Galileo, I
> believe.
>
> [1]:
> https://oss.sonatype.org/service/local/artifact/maven/redirect?r=releases&g=net.bpelunit&a=eclipse-update-site&v=1.6.0&e=zip&c=assembly
> <https://oss.sonatype.org/service/local/artifact/maven/redirect?r=releases&g=net.bpelunit&a=eclipse-update-site&v=1.6.0&e=zip&c=assembly>
> believe.
>
> [1]:
> https://oss.sonatype.org/service/local/artifact/maven/redirect?r=releases&g=net.bpelunit&a=eclipse-update-site&v=1.6.0&e=zip&c=assembly
>
>
> Cheers,
> Antonio
>
--
Tammo van Lessen - http://www.taval.de
Daniel Luebke
May 9, 2012, 5:38:35 PM5/9/12
to bpel...@googlegroups.com
Hi Tammo,
the only reason is that either the hoster doesn't offer this or that I couldn't find out how to set such DNS records.
Daniel
the only reason is that either the hoster doesn't offer this or that I couldn't find out how to set such DNS records.
Daniel
Reply all
Reply to author
Forward
0 new messages