ClasspathWorkspaceResolver
by Lincoln Baxter, III
I think this is another issue. Looks like duplicate addons being installed?
This (I think) is causing container hangs *uergh*
lb3@quadshark:~/Projects/jboss/forge/core$ ls
/tmp/forge4361231800560189609test-addon-dir -la
total 4
drwxrwxr-x 6 lb3 lb3 140 Mar 12 18:28 .
drwxrwxrwt 73 root root 1800 Mar 12 18:28 ..
drwxrwxr-x 2 lb3 lb3 140 Mar 12 18:28
-DEFAULT-4588358c-a401-42fa-9b46-93f0295f10c4
-rw-rw-r-- 1 lb3 lb3 355 Mar 12 18:28 installed.xml
drwxrwxr-x 3 lb3 lb3 140 Mar 12 18:28
org-jboss-forge-facets-2-0-0-20130312-201651-45
drwxrwxr-x 3 lb3 lb3 140 Mar 12 18:28
org-jboss-forge-resources-2-0-0-20130308-141036-39
drwxrwxr-x 2 lb3 lb3 40 Mar 12 18:28
org-jboss-forge-resources-2-0-0-SNAPSHOT
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
11 years, 2 months
Forge Scaffold x-Project { Aerogear, Arquillian, Errai, Java EE, RichFaces, Spring } - inputs and meetings
by Vineet Reynolds Pereira
Hello all,
This is more of a follow up on Lincoln's mail sent earlier on the cross-project scaffold team.
Sebastian and I have been working on fleshing out the details of the new scaffold plugin to handle several requirements, as part of the single collaborative scaffold initiative. We're going to attempt making this work on Forge 1, and port the design over to Forge 2. While our work so far has covered fairly decent ground, it is mostly due to the commonalities in the scaffolds we work on - AngularJS and Aerogear. JSF/RichFaces, Errai are notable exceptions, and I'd like to propose a weekly/bi-weekly cross-scaffold team meeting to pour over the details of this new scaffold plugin, so that design decisions will attempt to accomodate all projects (instead of only HTML5 ones). 30 mins should be fine to start with, stretching to a maximum of an hour (if there are too many topics to discuss).
I'd like to know what time would be suitable for this discussion. If we cannot find a suitable time for everyone to join in, or if you schedules are busy, we could have impromptu meetings.
Thanks,
Vineet
11 years, 2 months
reflection to access classes in project dependencies
by John Franey
My motivation for this email is to satisfy FORGE-773. However, this is
also related to FORGE-563 and FORGE-424, and resolution could enable other
features.
I have written a prototype:
1) an implementation of the forge java api interfaces which delegates to
java's reflection, offering a read only perspective of java components.
2) a forge module, currently a facet, to search for a given binary class in
the project's dependencies and returns the result wrapped in the above
delegate.
These are demonstrable in a unit test.
My dilemma now is how to integrate these into the forge project. There are
a few different areas, but I'll start with this:
For some callers, a java class is a java class, whether it originates as
source code (from the current forge project) or is a class from the
dependency set. For example, scaffolding primarily is a read only
operation. In this use case, it would be simpler for these clients to have
a single interface to resolve classes because whether a class is source or
binary is not relevant to the use case.
On the other hand, there is a set of classes in a user's project that are
modifiable. In these cases, a java class is not a java class. Forge
components might want the distinction somehow. There ought the be some
distinction of which class is modifiable and which is not.
Naively, I took the first thinking that the existing forge java model would
be adequate. To have separate java api for read-only and read-write java
model objects seems a fundamental addition to the java model which requires
much more effort. In absence of such a model, I though to implement
'no-op' for those code changing methods (e.g., Named.setName() would be
inert). I assumed that forge component that change source code would have
necessary context to know when it is operating on a source code module,
avoiding attempts to modify a binary class.
So, I'm looking for discussion and consensus on the above. Any thoughts?
Regards,
John
11 years, 2 months
Forge Meeting minutes from 2013-03-06
by ggastald＠redhat.com
==============
#forge Meeting
==============
Meeting started by lincolnthree at 14:59:31 UTC. The full logs are
available at
http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2013/forge.20...
.
Meeting summary
---------------
* Agenda (lincolnthree, 15:01:16)
* Forge 2 Status (lincolnthree, 15:01:29)
* x-Project Scaffold meetings? (lincolnthree, 15:02:27)
* Forge 2.0 Status (lincolnthree, 15:04:06)
* Forge 2 Alpha1 target release date Mar 15th (lincolnthree,
15:15:53)
* HELP: (lincolnthree, 15:19:15)
* AGREED: We will try CTRL-5 as Forge 2 hotkey for a while
(lincolnthree, 15:19:34)
* x-Project Scaffold Meetings (lincolnthree, 15:20:05)
* ACTION: Discuss the new scaffold plugin with the x-project scaffold
team (vineetreynolds, 15:39:52)
* ACTION: Resolve the bidi and cyclical relationship problem with the
rest plugin. Coordinate with Koen on changes to options
(vineetreynolds, 15:40:35)
* ACTION: Communicate test-harness-web requirements to x-project
scaffold team (vineetreynolds, 15:40:59)
* ACTION: review tests with aerogear (sblanc, 15:41:35)
* ACTION: Decide on the browser support matrix for wfk constituents
that have scaffold providers (vineetreynolds, 15:45:51)
* ACTION: Email engineering ops to enquire of browser support in
Jenkins (vineetreynolds, 15:47:51)
Meeting ended at 15:50:08 UTC.
Action Items
------------
* Discuss the new scaffold plugin with the x-project scaffold team
* Resolve the bidi and cyclical relationship problem with the rest
plugin. Coordinate with Koen on changes to options
* Communicate test-harness-web requirements to x-project scaffold team
* review tests with aerogear
* Decide on the browser support matrix for wfk constituents that have
scaffold providers
* Email engineering ops to enquire of browser support in Jenkins
Action Items, by person
-----------------------
* **UNASSIGNED**
* Discuss the new scaffold plugin with the x-project scaffold team
* Resolve the bidi and cyclical relationship problem with the rest
plugin. Coordinate with Koen on changes to options
* Communicate test-harness-web requirements to x-project scaffold team
* review tests with aerogear
* Decide on the browser support matrix for wfk constituents that have
scaffold providers
* Email engineering ops to enquire of browser support in Jenkins
People Present (lines said)
---------------------------
* lincolnthree (66)
* vineetreynolds (60)
* gastaldi (31)
* koentsje (27)
* jbossbot (12)
* jbott (6)
* sblanc (4)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
11 years, 2 months
Meeting minutes 2013-03-06
by Lincoln Baxter, III
(10:54:15 AM) jbott: Meeting ended Wed Mar 6 15:50:08 2013 UTC. Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
(10:54:15 AM) jbott: Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2013/forge.20...
(10:54:15 AM) jbott: Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2013/forge.20...
(10:54:15 AM) jbott: Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/forge/2013/forge.20...
==============
#forge Meeting
==============
Meeting started by lincolnthree at 14:59:31 UTC. The full logs are
available athttp://transcripts.jboss.org/meeting/irc.freenode.org/forge/2013/forge....
.
Meeting summary
---------------
* Agenda (lincolnthree, 15:01:16)
* Forge 2 Status (lincolnthree, 15:01:29)
* x-Project Scaffold meetings? (lincolnthree, 15:02:27)
* Forge 2.0 Status (lincolnthree, 15:04:06)
* Forge 2 Alpha1 target release date Mar 15th (lincolnthree,
15:15:53)
* HELP: (lincolnthree, 15:19:15)
* AGREED: We will try CTRL-5 as Forge 2 hotkey for a while
(lincolnthree, 15:19:34)
* x-Project Scaffold Meetings (lincolnthree, 15:20:05)
* ACTION: Discuss the new scaffold plugin with the x-project scaffold
team (vineetreynolds, 15:39:52)
* ACTION: Resolve the bidi and cyclical relationship problem with the
rest plugin. Coordinate with Koen on changes to options
(vineetreynolds, 15:40:35)
* ACTION: Communicate test-harness-web requirements to x-project
scaffold team (vineetreynolds, 15:40:59)
* ACTION: review tests with aerogear (sblanc, 15:41:35)
* ACTION: Decide on the browser support matrix for wfk constituents
that have scaffold providers (vineetreynolds, 15:45:51)
* ACTION: Email engineering ops to enquire of browser support in
Jenkins (vineetreynolds, 15:47:51)
Meeting ended at 15:50:08 UTC.
Action Items
------------
* Discuss the new scaffold plugin with the x-project scaffold team
* Resolve the bidi and cyclical relationship problem with the rest
plugin. Coordinate with Koen on changes to options
* Communicate test-harness-web requirements to x-project scaffold team
* review tests with aerogear
* Decide on the browser support matrix for wfk constituents that have
scaffold providers
* Email engineering ops to enquire of browser support in Jenkins
Action Items, by person
-----------------------
* **UNASSIGNED**
* Discuss the new scaffold plugin with the x-project scaffold team
* Resolve the bidi and cyclical relationship problem with the rest
plugin. Coordinate with Koen on changes to options
* Communicate test-harness-web requirements to x-project scaffold team
* review tests with aerogear
* Decide on the browser support matrix for wfk constituents that have
scaffold providers
* Email engineering ops to enquire of browser support in Jenkins
People Present (lines said)
---------------------------
* lincolnthree (66)
* vineetreynolds (60)
* gastaldi (31)
* koentsje (27)
* jbossbot (12)
* jbott (6)
* sblanc (4)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
11 years, 2 months
Forge Tools descriptions look wrong in Update Site
by Lincoln Baxter, III
Hey Koen,
The Forge Tools project descriptions look a bit off in the nightly update
site. I think this is something we will need to fix. Could you take a look
at this when you get a chance? (Pic attached)
Thanks,
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
11 years, 2 months
Re: [forge-dev] Forge Scaffold x-Project { Aerogear, Arquillian, Errai, Java EE, RichFaces, Spring } - Forge
by Thomas Frühbeck
Hi Jonathan,
thanks for your ideas and remarks, some comments inside..
Am 01.03.2013 21:39, schrieb Jonathan Fuerth:
> Hi again Thomas,
>
> I just want to ask again up front: can we have this discussion on
> errai-dev or forge-dev? I think there are a bunch of interested people
> who could provide additional valuable feedback.
>
> On Thu, Feb 28, 2013 at 5:14 PM, Thomas Frühbeck <fruehbeck(a)aon.at
> <mailto:fruehbeck@aon.at>> wrote:
>
> Hi Jonathan,
> you shouldnt count _every_ artifact related to an entity:
> - 1 Service Interface
> - 1 Service Impl (1 serivce impl is to be omitted)
> - 1 Mapping
> - 1 Wrapper
> - 1 Reference for relationship transport
> - 1 edit form
> - 1 search form
> - 1 html file
> did I miss something? you cant do CRUD on server w/o some server
> logic, and honestly, do you mean to stuff all UI into one class?
> can't imagine that. It's feasable, I tried to go that direction,
> but the handling of @Bound (@Data) fields becomes quite tricky,
> taking into account all the validation and compilation steps.
>
>
> No, I wouldn't want to stuff all the UI into one class. I like the
> idea of having a separate @Templated form for each entity. For that
> matter, I even like the idea of keeping separate search, edit, and
> read-only @Templated classes. But I don't think I would end up needing
> all of those for each entity type.
Hm, on one side there are entity specific DataField / search related
elements that simply aren't generic.
On the other side I tried to rely on inheritance, but as I understood
"Errai Marshalling always works from fields when discovering
properties." - which means _declared fields_, this may be seen also in
the DefaultJavaDefinitionMapper.map().
Although I can imagine that this may be necessary, it doesn't help to
write generic nonredundant code.
>
> But I agree, quite verbose :-/ Just now I am extending a generated
> project for a real world project, and I start to suffer already :-)
>
>
> Yes. As a practical example, I'm imagining what I would do to improve
> the usability of the Sakila app. Starting with the scaffolding as
> generated, I would probably delete more than half of what was
> generated. Quick brain dump:
>
> I'd keep the Films, Actors, Stores, Staffs and Customers as top-level
> places in the UI.
>
> I'd make Address, Language, Category, Country, and City work as
> auto-complete fields instead of hard references that you have to
> create first. Maybe in an admin screen, there could be the opportunity
> to list these things and delete them.. but probably not. I'd probably
> just write a routine that deletes the orphaned entries periodically.
>
Good point! Perhaps I could identify such entities by number of
attributes and references?
Simple entities could well be used in this way.
> I'd integrate Rentals and Inventories into the Films, Stores, and
> Customers views, showing the details appropriate to each of those
> contexts (for example, in a list of Stores, we'd just see the rental
> count; in an individual store page, we could see more details perhaps
> in a table of Rental entries grouped by film title and sorted by %
> inventory utilization or something).
>
>
> One thing that I notice from this little thought experiment: it would
> be useful to have a generator for an autocomplete textbox for a
> particular entity type. This would search by one or more attributes of
> the entity, resolving the existing entry if the user picks a
> completion, or creating a new one if the user doesn't pick a
> completion. I've already had to implement this a few times by hand in
> various Errai demos. For example, see the 'department' field in
> ItemForm:
> https://github.com/errai/errai/blob/master/errai-jpa/demos/errai-jpa-demo...
>
> The other thing I notice is that composability of the @Templated
> components is really important. I think they're already nicely
> composable, so this is more of an observation than a recommendation. :)
One thing makes me uneasy: I have to provide a data-field for _every_
@DataField property I could possibly use, so the template and the
@Templated is tied together.
But modularity is great here.
>
> It _really should_ be possible to hide complexity and boiler plate
> at least for the Wrapper/EntityReference classes, they are really bad!
>
>
> Yes, I think we should lean on the Errai framework itself to deal with
> these issues (either by 3-way diff or generated proxies or a mix of
> both). I don't think it's good to have the generated proxies (or
> really any generated code that's not meant to be edited by hand) mixed
> in with the application sources.
>
I had a look at the code generation, I will try to start on it.
>
>
> Let me say: Errai is really great, I'm glad we met!!
> But there are hard limits, which are not easy to come by (no
> server only code, static factory, field dependency for mapping
> generation)
>
>
> I don't understand what you're referring to here. (but I do agree
> there will inevitably be hard limits to what the framework can do)
>
The point is:
- static factory method of entities: "Otherwise, if the entity has a
public static method where every argument is annotated with |@MapsTo"
you just don't get JPA entites readily supplied that way, and I
do not want to alter JPA entity code - think of EJB Jars supplying entities
|||||
- even if I implement a static factory method, it cannot contain
"server only" non GWT-compatible code, there is no clean way to pass a
Builder to the MappingDefinitionFactory
| - field dependency: see "declaredField" vs. inheritance above
|
>
>
> Regarding entity relationship: I will have a look at generated
> proxies, I hadn't seen the dynamic code generation yet. I am just
> starting reading about it.
> Do you think it is possible to generate a proxy object for an
> entity, which "unfolds" itself when accessed by retrieving its
> data on demand from server?
> Perhaps you have an example?
>
>
> Yes, it's definitely possible to do that, but the fetching of new data
> would have to be asynchronous. The proxies wouldn't be terribly
> transparent.. code that uses them would need to use callbacks when
> traversing lazy-loaded relationships.
>
> A feature like this would overlap the capabilities of the datasync
> feature I'm planning quite a bit. That's not necessarily a bad thing,
> of course!
Yes, definitely a positive overlap :-) I am looking forward to.
>
>
> I do not really like the "wrappers", but they are at least
> manageable, controllable.
> Even if I used dynamic proxies, how can I assure, that the
> relationship is transparently transportable? Are you sure this is
> not becoming EJB 1.1 RemoteEntityBeans Revival?
>
>
> That's a good point. I still want to continue forward with the
> syncable dataset idea and see how far it can take us. As I imagine it,
> we can make it work without any proxies at all.
>
>
> One more problem I see coming is transaction/atomicity/validation
> of updates. For JSF and other request/response systems (like my
> plugin) it's easy to tell, where transaction and validation should
> take place. When doing continous updates of small changes, when is
> the correct time to lock/refresh/merge - that's already difficult
> for a JSF application when working with multiple related entities.
>
>
> I'd generally want to merge as early and as often as possible. Each
> merge would have three pieces: the new requested state, the state the
> client thinks the entity has on the server, and the state actual
> current state on the server. If the expected state (from the client)
> differs from the actual state (from the server-side entity manager),
> then the update is rejected and sent back to the client along with the
> new server state.
>
> I'd probably avoid locking entirely. Just optimistic refresh/merge.
> For atomicity, we'd simply guarantee that all updates that come
> together in the same message will be committed or rolled back (eg. due
> to merge conflict) as a unit.
>
>
> Thanks for your feedback, looking forward to some tips regarding
> code generation!
>
>
> The documentation on Errai's code generation API is still pretty
> sparse, unfortunately. Probably the best place to start out would be
> to look at Errai code that uses errai-codegen to generate proxies.
> BindableProxyGenerator and JaxrsProxyGenerator are two such examples.
>
> Cheers,
> Jonathan
>
> Regards,
> Thomas
>
> Am 28.02.2013 22:32, schrieb Jonathan Fuerth:
>> Hi again Thomas,
>>
>> I spent this morning trying to feel my way through the use of
>> your plugin on a simple data model (2 tables with a FK
>> relationship) that I created yesterday. I was able to use the
>> hibernate-tools forge plugin to generate entities, but I couldn't
>> quite figure out how to use your scaffolding plugin to generate
>> Errai code. Anyway, I know this wasn't really the part you were
>> looking for input on; I'm new to Forge and I'm sure it will be
>> easy enough to figure out when there's a getting started doc for
>> your plugin.
>>
>> So next, I turned to the Sakila project you emailed me. I got it
>> imported into Eclipse no problem, and I deployed it to AS7
>> equally easily.
>>
>> The first thing that struck me is that I think there are too many
>> types being generated for each entity. By my count, there are 9
>> files generated for every one entity in the datamodel. Based on
>> your README.md, I understand you need a way of controlling which
>> parts of the object graph get sent to the client, and also which
>> attributes are overwritten when the updates are merged back into
>> the server. I see that a number of these files are being
>> generated in support of these concerns.
>>
>> I think my ideal situation would be to generate just 2 files per
>> entity: a .html template and the corresponding @Templated java
>> class. This would leave the framework responsible for tree
>> pruning (eg. through JPA fetch rules), fine-grained merging of
>> attributes (by diffing or transparent proxies generated at GWT
>> rebind time) and more. I know a proxy is a proxy, but if we can
>> keep it out of the application's src/main/java folder, I think
>> that's a win.
>>
>> I think we should keep discussing this. Sorry it took me so long
>> to respond... I'll try to be more responsive in the future.
>>
>> -Jonathan
>>
>> PS: it would be nice to have these discussions on a public
>> mailing list of some sort. What about errai-dev or a Forge dev list?
>>
>> On Wed, Feb 27, 2013 at 11:00 PM, Jonathan Fuerth
>> <fuerth(a)fuerth.ca <mailto:fuerth@fuerth.ca>> wrote:
>>
>> Hi Thomas,
>>
>> I still have to play more with your errai scaffolding plugin
>> to give feedback. I created a toy data model today (as a
>> testbed for trying out your plugin), installed the latest
>> Forge, and installed your plugin into it. I have not yet used
>> your plugin to scaffold anything. I expect I will have time
>> tomorrow morning to continue that.
>>
>> Until then, here are my thoughts on
>> https://github.com/shadogray/plugin-errai/blob/master/README.md:
>>
>> == Merging in updates from the client ==
>>
>> I agree EntityManager.merge() is too much of a sledgehammer
>> when it comes to accepting updates from clients. We need a
>> way to detect updates that only affected one or two
>> attributes–perhaps even just an attribute of a related child
>> entity reachable from the main subject of the sync request.
>>
>> I also think that for scalability reasons we have to make the
>> client responsible for tracking the state of the object it
>> thinks it's merging into. This is the approach I'm taking
>> with my data sync efforts so far: when the client submits an
>> update to the server, it reports not only the new state it's
>> requesting, but the 'expected state' that the server should
>> have now. Any mismatch between the expected state and the
>> actual current state on the server means there is a potential
>> merge conflict. By receiving both the expected state and the
>> requested new state, the server can compute the actual
>> field-by-field difference in the update, and decide if a real
>> merge conflict took place. If so, it can respond to the
>> client with the actual new state, and client code can do what
>> it wants to resolve it (probably by presenting some sort of
>> yes/no decision or even a merge UI to the user).
>>
>> == Handling of Entity References ==
>>
>> Yes, this is a major concern. Since my initial plan is to
>> define syncable data sets using JPQL named queries, I thought
>> it would be easiest to use the FETCH clause to define the
>> limits of what gets synced and what stays behind (lazy fetch
>> == don't sync to client).
>>
>> Since then, the EntityGraph API has found its way into JPA
>> 2.1. As far as I can tell, this is pretty much purpose-built
>> to solve this problem without the need for wrapper DTOs. We
>> could build Errai's Data Sync features against this today;
>> the only downside is that it's going to take a while before
>> we can count on JPA 2.1 APIs being available on the server side.
>>
>> == Short and Char as ID types ==
>>
>> Errai JPA does support all numeric types for IDs, but I
>> purposely stopped short of implementing ID Generators for
>> byte, short, and char. I'm happy to add these ID Generators
>> if you've got a use case for them.
>>
>> Thanks for your patience!
>>
>> Jonathan
>>
>>
>
>
11 years, 2 months