Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [capra-dev] Notification system in artifact handler breaks support for external models
Jan-Philipp:

You wrote this on the Gerrit change:

> Salome, could you please check the issue with the dependency of the test project and upload a new change set so Hudson can verify the change? Thanks!

Is there really a problem? The last build seems to have gone well?

I see that the Hudson "reviewer" reports a failure. But maybe that is just a bug and it will be fine with the build is re-run.

It would be good to have this merged as soon as possible. I can put the latest build as a dependency of ReqTool before I go on validation.


Jens Lideström
Software developer
rt-labs

2017-07-03 16:26 GMT+02:00 Jens Lideström <jens.lidestrom@xxxxxxxxxxx>:

The latest version of the change looks fine to me.

Now we have a ReqTool version which is update to date with latest Capra at it seems to be working fine, that feels good.

Thank you both of you. :)

I hope you'll have a nice summer!


Jens Lideström
Software developer
rt-labs

2017-06-30 16:12 GMT+02:00 Jens Lideström <jens.lidestrom@xxxxxxxxxxx>:
Oh, great!

> Can you remove them and make the push?

It seems like you managed to do this after all? Otherwise I can do it. I'll have a look on Monday and see if there is something else that needs to be done.

Have a nice trip!

Jens Lideström
Software developer
rt-labs

2017-06-30 10:14 GMT+02:00 Salome Maro <salome.maro@xxxxxxxxx>:

Hi Jens,

 

The dependencies to the generic artefact model in org.eclipse.capra.ui and in org.eclipse.capra.ui.notification can just be removed as they are left overs from previous commits.

 

I tried this and it works locally but I cannot push since my connection at the airport is super slow today. Can you remove them and make the push?

 

I am travelling today so will not be reachable for at least the next 24 hours.

 

Regards,

 

Salome.

 

From: <capra-dev-bounces@xxxxxxxxxxx> on behalf of Jens Lideström <jens.lidestrom@xxxxxxxxxxx>
Reply-To: capra developer discussions <capra-dev@xxxxxxxxxxx>
Date: Thursday, 29 June 2017 at 15:49


To: capra developer discussions <capra-dev@xxxxxxxxxxx>
Subject: Re: [capra-dev] Notification system in artifact handler breaks support for external models

 

That's great! Thanks! It look good to me after a quick glance, but I'll spend some more time looking at it.

> The only thing that remains is the dependency to org.eclipse.capra.ui.notification. Will this cause a problem?

I don't think so, since that bundle no longer depends on the generic model.

We will not be able to use the notification system with our current implementation. But that's our problem, maybe we can find a solution. The reason is that our ArtifactMetaModelAdapter can't implement getAllArtifacts. The reason for that is that we don't assume the existence of a central model location; in ReqTool there can be multiple model files located anywhere in the workspace.


> Jens, could you please review the commit? I hope you have the necessary rights, but if not, please communicate any changes you might want to see to Salome.

I'll do so!

 

/Jens

 

2017-06-29 15:34 GMT+02:00 <ec@xxxxxxxxxxxxxxxx>:

Thanks Salome! I have rebased the commit and the Hudson builds are currently running. Jens, could you please review the commit? I hope you have the necessary rights, but if not, please communicate any changes you might want to see to Salome.

Best,
Jan-Philipp


> On 29 Jun 2017, at 15:30, Salome Maro <salome.maro@xxxxxxxxx> wrote:
>
> I have pushed a change to gerrit https://git.eclipse.org/r/#/c/100357/ to remove the dependency to artefact handler.
>
> The only thing that remains is the dependency to org.eclipse.capra.ui.notification. Will this cause a problem?
>
> Regards,
>
> Salome.
>
> From: <capra-dev-bounces@xxxxxxxxxxx> on behalf of Jens Lideström <jens.lidestrom@xxxxxxxxxxx>
> Reply-To: capra developer discussions <capra-dev@xxxxxxxxxxx>
> Date: Thursday, 29 June 2017 at 14:39
> To: capra developer discussions <capra-dev@xxxxxxxxxxx>
> Subject: Re: [capra-dev] Notification system in artifact handler breaks support for external models
>
> > Is this a similar problem with the trace model? How do you currently ensure that the right trace model is selected?
>
> Yes, it's the same problem with trace models. We can run with the trace models from the generic model, or any other model.
>
> Jens Lideström
> Software developer
> rt-labs
>
> 2017-06-29 14:33 GMT+02:00 Salome Maro <salome.maro@xxxxxxxxx>:
> Is this a similar problem with the trace model? How do you currently ensure that the right trace model is selected?
>
> Regards,
>
> Salome.
>
> From: <capra-dev-bounces@xxxxxxxxxxx> on behalf of Jens Lideström <jens.lidestrom@xxxxxxxxxxx>
> Reply-To: capra developer discussions <capra-dev@xxxxxxxxxxx>
> Date: Thursday, 29 June 2017 at 14:30
> To: capra developer discussions <capra-dev@xxxxxxxxxxx>
> Subject: Re: [capra-dev] Notification system in artifact handler breaks support for external models
>
> > The generic models can be avoided by not installing the org.eclipse.capra.generic.feature
>
> Yes, that has been our strategy so far. But this doesn't work any more since now the important artifact handlers can't be installed without the generic model.
>
> The motivation for my quick fix solution thoughts in the previous mail was this:
>
> Maybe we can find a way to have Capra choose the ReqTool model in case both the generic model and the ReqTool model are installed. Maybe that is easier and quicker that to get rid of all uses of the generic model in all the artifact handlers.
>
> /Jens
>
> 2017-06-29 14:16 GMT+02:00 Hans-Erik Floryd <hans-erik.floryd@xxxxxxxxxxx>:
> On 29 June 2017 at 13:57, Jens Lideström <jens.lidestrom@xxxxxxxxxxx> wrote:
> > But we would still need a way to specify that we want the ReqTool model to
> > be used, even if the generic model is present. Right now its a matter of
> > chance I think. Sometimes it works because the ReqTool model happens to be
> > first in the list of extension point contributions; sometimes it doesn't
> > work.
>
> The generic models can be avoided by not installing the
> org.eclipse.capra.generic.feature feature. If the user installs
> reqtool it should be possible to avoid pulling in that feature. Of
> course if the user installs that feature explicitly then things will
> break.
>
> /Hans-Erik
> _______________________________________________
> capra-dev mailing list
> capra-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/capra-dev
>
>
> _______________________________________________
> capra-dev mailing list
> capra-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/capra-dev
>
>
> _______________________________________________
> capra-dev mailing list
> capra-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/capra-dev

_______________________________________________
capra-dev mailing list
capra-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/capra-dev

 


_______________________________________________
capra-dev mailing list
capra-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/capra-dev




Back to the top