Re: [capra-dev] Notification system in artifact handler breaks support f

[ec@xxxxxxxxxxxxxxxx]

Hey Jens,

the build that succeeded was for patchset 2. The one for patchset 3 failed, probably because there is a dependency missing in the test project. Salome was working on a fix for that, but she is now back home and I haven’t heard from her. I have just run the tests locally from Eclipse and everything worked. Checking with Maven now. I’ll report back.

Best,
Jan-Philipp

PS: In such cases, you can pull the patchset from Gerrit and make changes yourself. This might expedite the process in cases such as this one. Still, sorry to keep you waiting so long.

> On 05 Jul 2017, at 12:40, Jens Lideström <jens.lidestrom@xxxxxxxxxxx> wrote:
> 
> 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
> 
> 
> 
> 
> _______________________________________________
> 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