[forge-dev] Obtaining project name in persistence provider

[George Gastaldi]

Yes, however it should work in a @CommandScoped object.
My pull request is not working like this because I can't ensure that the CommandScopedContext (that implements UIContextListener) is executed before others. 

I have created another JIRA to support ordering in the Furnace's Imported object.

> Em 26/01/2014, às 01:09, "Lincoln Baxter, III" <lincolnbaxter at gmail.com> escreveu:
> 
> I don't think Project should be injectable in Forge 2. Doesn't make sense with the new design. There is no "current project". Not sure we will have such a concept other than what the UISelection provides (as we have done in the AbstractProjectCommand :)
> 
> 
>> On Sat, Jan 25, 2014 at 5:25 PM, George Gastaldi <ggastald at redhat.com> wrote:
>> And yes, it was possible to do that in Forge 1. Shouldn't be too hard to implemebt though. All you need to do is implement UIContextListener and listen for UIContext started events :)
>> 
>>> Em 25/01/2014, às 20:21, "Ivan St. Ivanov" <ivan.st.ivanov at gmail.com> escreveu:
>>> 
>> 
>>> Ah, now I found this MetadataFacet. Is it always available? I see that it uses the Maven facet under the hood.
>>> 
>>> 
>>>> On Sun, Jan 26, 2014 at 12:17 AM, Ivan St. Ivanov <ivan.st.ivanov at gmail.com> wrote:
>>>> I think it was possible to do that in Forge 1?
>>>> 
>>>> BTW, how do you get a project name from the Project object? Is it through the Maven facet? Do we always have that on a project?
>>>> 
>>>> 
>>>>> On Sun, Jan 26, 2014 at 12:06 AM, George Gastaldi <ggastald at redhat.com> wrote:
>>>>> I'd rather pass as a param than injecting tbh. This allows the object to be reused as a singleton without aby thread issues.
>>>>> 
>>>>> Btw Project is not yet available for injection. Should we create a JIRA for it?
>>>>> 
>>>>>> Em 25/01/2014, às 20:02, "Ivan St. Ivanov" <ivan.st.ivanov at gmail.com> escreveu:
>>>>>> 
>>>>> 
>>>>>> OK, but what does the JavaEEDefaultProvider::configure method do? It produces the content of persistence.xml. Why would you need Project object to pollute the interface if it's used in just one of the implementations? And we can even do without it, as you noted.
>>>>>> 
>>>>>> When I asked this question in the first message of this thread, I was thinking of somehow injecting the project, not changing the interface.
>>>>>> 
>>>>>> But if you say it's reasonable, I will do that, it's not a big deal.
>>>>>> 
>>>>>> 
>>>>>>> On Sat, Jan 25, 2014 at 11:00 PM, George Gastaldi <ggastald at redhat.com> wrote:
>>>>>>> However since we are on CR1, and other requirements may appear, perhaps it's wise to change the interface definition now than later. :)
>>>>>>> 
>>>>>>>> Em 25/01/2014, às 18:58, "Ivan St. Ivanov" <ivan.st.ivanov at gmail.com> escreveu:
>>>>>>>> 
>>>>>>> 
>>>>>>>> Thanks, George! 
>>>>>>>> 
>>>>>>>> As I am not really keen to change the interface definition, I would do it as you proposed: without the project name.
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> Ivan
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Sat, Jan 25, 2014 at 10:52 PM, George Gastaldi <ggastald at redhat.com> wrote:
>>>>>>>>> Hey Ivan,
>>>>>>>>> You could change the configure method signature to pass the project as a parameter, but remember that it may be null.
>>>>>>>>> 
>>>>>>>>> However, I think it would be better to not add the projectName to the DDL file in order to keep it simple and easier to find.
>>>>>>>>> 
>>>>>>>>> Best Regards,
>>>>>>>>> 
>>>>>>>>> George Gastaldi
>>>>>>>>> 
>>>>>>>>>> Em 25/01/2014, às 18:42, "Ivan St. Ivanov" <ivan.st.ivanov at gmail.com> escreveu:
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> Hi folks,
>>>>>>>>>> 
>>>>>>>>>> I am working on https://issues.jboss.org/browse/FORGE-1443. It's not a big deal, it's a matter of adding a few lines to the JavaEEDefaultProvider class.
>>>>>>>>>> 
>>>>>>>>>> One of the requirements is that the create and drop scripts should bear the name of the project: <projectName>Creade.ddl and <projectName>Drop.ddl. I wonder is there a way to pass that somehow to the persistence provider?
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> Ivan
>>>>>>>>>> _______________________________________________
>>>>>>>>>> forge-dev mailing list
>>>>>>>>>> forge-dev at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>>>> 
>>>>>>>>> _______________________________________________
>>>>>>>>> forge-dev mailing list
>>>>>>>>> forge-dev at lists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> forge-dev mailing list
>>>>>>>> forge-dev at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> forge-dev mailing list
>>>>>>> forge-dev at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>>> 
>>>>>> _______________________________________________
>>>>>> forge-dev mailing list
>>>>>> forge-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>>> 
>>>>> _______________________________________________
>>>>> forge-dev mailing list
>>>>> forge-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>> 
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>> 
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
> 
> 
> 
> -- 
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20140125/42b107a8/attachment.html