[forge-dev] reflection to access classes in project dependencies

John Franey jjfraney at gmail.com
Wed Mar 6 17:23:51 EST 2013 

Lincoln,

Yes I am interested.  Now, I am bogging down in the unit tests of the
wrappers.  I will skip ahead and build a facet as prototype for review then
circle round to the unit tests.  I would expect a prototype by end of week.

John



On Tue, Mar 5, 2013 at 2:26 PM, Lincoln Baxter, III <lincolnbaxter at gmail.com
> wrote:

> Hey John,
>
> Do you have any if it's plausible to throw together a prototype using the
> JavaCore binary functionality? How much do you think it would take? Is that
> something you're interested in?
>
> I think (based on some discussion,) that most people are OK with creating
> an "isEditable()" method for Forge 1, and doing some good ol'fashioned
> refactoring for Forge 2!
>
> Thoughts?
> ~Lincoln
>
>
> On Fri, Feb 22, 2013 at 10:14 AM, <ggastald at redhat.com> wrote:
>
>>  Hi !
>>
>> This seems like a good way to go.
>> I've updated the JIRA in https://issues.jboss.org/browse/FORGE-795 with
>> this info.
>>
>> Thanks !
>>
>>
>> On 02/22/2013 12:01 PM, John Franey wrote:
>>
>> Yes.  AST is a component of javacore, but javacore is more than AST.  So,
>> it would be more accurate to say: forge already uses a subset of JDT, the
>> ast parser.  Here is a short tutorial:
>> http://www.vogella.com/articles/EclipseJDT/article.html
>>
>>  JavaCore's features seems to be a union of forge's source code
>> features, and the class inspection features (either from reflection or
>> javaassit), and JavaCore component has very close proximity to the eclipse
>> AST parser already put to use by forge, and assuming the requirements of
>> forge java plugin can be met by eclipse javacore, and, I think I read
>> somewhere, there is prototype to integrate forge into eclipse, and also,
>> the forge team is open to refactoring the forge java model.  It is my
>> opinion, that a more than a casual look into javacore, as either the
>> implementation of, or a replacement to, the forge java model api, is
>> reasonable.
>>
>>  Here is the javacore project page:
>> http://www.eclipse.org/jdt/core/index.php
>> Here is the javacore api pages:
>> http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/JavaCore.html
>>
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Feb 22, 2013 at 12:30 AM, Lincoln Baxter, III <
>> lincolnbaxter at gmail.com> wrote:
>>
>>> The Forge JavaParser already uses JDT :) I think we are talking about
>>> the same thing. We haven't looked at the compilation stuff yet, that's
>>> actually an interesting idea.
>>>
>>>
>>> On Fri, Feb 22, 2013 at 12:28 AM, Lincoln Baxter, III <
>>> lincolnbaxter at gmail.com> wrote:
>>>
>>>> Wait, JavaCore is or is not related to JDT?
>>>>
>>>>
>>>> On Thu, Feb 21, 2013 at 7:18 PM, John Franey <jjfraney at gmail.com>wrote:
>>>>
>>>>>  Apache bcel hasn't had a release since 2006.  I'm wondering if the
>>>>> class file format has moved on beyond bcel's reach.  Its last official
>>>>> release is 5.2 in Feb 2006. Java 1.6 was released in December 2006, and
>>>>> nothing new from bcel project.  Java 1.7 in 2011, and still silence.  I
>>>>> wonder if it can support later class file formats somehow.
>>>>>
>>>>>  javassist's latest release is December 2012 and seems to have jboss
>>>>> backing.  Seems a safe choice on the face of it.
>>>>>
>>>>>  Then, there is eclipse JavaCore.  I wonder if JavaCore can be used
>>>>> without an eclipse workbench.  If so, JavaCore can provide a single api for
>>>>> both source and binary classes, so it could replace the forge java source
>>>>> parser, too.  I also wonder if forge could be a headless eclipse
>>>>> application - imagine the eclipse plugins available via forge's command
>>>>> line shell.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Feb 21, 2013 at 6:30 PM, Lincoln Baxter, III <
>>>>> lincolnbaxter at gmail.com> wrote:
>>>>>
>>>>>> What about something like this?
>>>>>>
>>>>>> https://issues.jboss.org/browse/FORGE-795
>>>>>> https://issues.jboss.org/browse/FORGE-796
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 20, 2013 at 11:11 AM, Lincoln Baxter, III <
>>>>>> lincolnbaxter at gmail.com> wrote:
>>>>>>
>>>>>>> Hmm... I'm not sure. I think it would probably still be slightly
>>>>>>> misleading to have mutable interfaces for immutable objects, without some
>>>>>>> kind of indicator. For instance, if someone were to pass the object beyond
>>>>>>> its "intended" scope.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Feb 19, 2013 at 7:41 PM, John Franey <jjfraney at gmail.com>wrote:
>>>>>>>
>>>>>>>> Thinking out loud, would isEditable still be needed if there were a
>>>>>>>> lookup that returned only editable java resources, and another query that
>>>>>>>> could return both binary and source resources?  Plugins that operate as
>>>>>>>> editors would use the former to find resources it knows it will edit, and
>>>>>>>> will use the latter in order to inspect other classes (to resolve super
>>>>>>>> class or throws declarations).  Plugins that operate as readers (like
>>>>>>>> scaffold plugins) would use only the latter.  Hmm...even with isEditable,
>>>>>>>> does it make sense to have these two kinds of methods?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Mon, Feb 18, 2013 at 9:43 PM, Lincoln Baxter, III <
>>>>>>>> lincolnbaxter at gmail.com> wrote:
>>>>>>>>
>>>>>>>>> I don't like it because it's not really optimal, but... I don't
>>>>>>>>> really see a better way forward that doesn't break every API we have.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>  On Mon, Feb 18, 2013 at 9:43 PM, Lincoln Baxter, III <
>>>>>>>>> lincolnbaxter at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>>  Well, I actually meant refactor the entire JavaParser so that
>>>>>>>>>> the types are immutable by default, but modifiable when desired by doing an
>>>>>>>>>> intanceof and cast. This would, as John said, be a fairly invasive, with a
>>>>>>>>>> fair amount of downstream API impact, since all users of these APIs would
>>>>>>>>>> now need to reference these new types instead. It would mean refactoring
>>>>>>>>>> all of Forge.
>>>>>>>>>>
>>>>>>>>>>  So from the perspective of Migration, it probably makes sense
>>>>>>>>>> to do something like add a method "isEditable()"
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Feb 14, 2013 at 2:19 PM, Thomas Frühbeck <
>>>>>>>>>> fruehbeck at aon.at> wrote:
>>>>>>>>>>
>>>>>>>>>>>  If I understood Lincoln correctly, he meant adding an
>>>>>>>>>>> interface EditableJavaSource, so no change in the existing implementations
>>>>>>>>>>> necessary.
>>>>>>>>>>> So the boolean is substitutable by instanceof, your graceful
>>>>>>>>>>> error handling would be supported.
>>>>>>>>>>>
>>>>>>>>>>> Am 14.02.2013 20:10, schrieb John Franey:
>>>>>>>>>>>
>>>>>>>>>>> I would follow my object-oriented instinct to agree that a
>>>>>>>>>>> editable/non-editable parallel of the model would make sense.  After all,
>>>>>>>>>>> an editable java source is kind of a non-editable java source, and adds
>>>>>>>>>>> editing behavior.....
>>>>>>>>>>>
>>>>>>>>>>>  However, the parallel model seems to be a significant
>>>>>>>>>>> undertaking, and has a negative characteristic, in my opinion.   Lets say
>>>>>>>>>>> there exists a method to search for and return a JavaClass, editable or
>>>>>>>>>>> not.  In a use case where the JavaClass is to be modified, this method is
>>>>>>>>>>> inadequate. 1)  The caller would have to check if the result is instance of
>>>>>>>>>>> EditableJavaClass, then cast, or 2) an alternate query method would be
>>>>>>>>>>> provided to return only EditableJavaClass and since methods cannot be
>>>>>>>>>>> overridden by return type the alternate query method would have to be
>>>>>>>>>>> defined in a different interface.  Not taht either of these are difficult
>>>>>>>>>>> to overcome, but I think the parallel model would increase overall
>>>>>>>>>>> complexity a little and add to the level of effort, and the benefit gained
>>>>>>>>>>> is merely type protection against the runtime error of attempting to modify
>>>>>>>>>>> a non-editable java component.
>>>>>>>>>>>
>>>>>>>>>>>  To go against that impulse just a second, consider the option
>>>>>>>>>>> of a property on the base class, a boolean: editable.  This would avoid the
>>>>>>>>>>> parallel model, avoid casting and support polymorphic calls.   The runtime
>>>>>>>>>>> error of attempting to modify a non-editable component can be handled in a
>>>>>>>>>>> few different ways: 1) a runtime exception, 2) a quiet no-op.  Without the
>>>>>>>>>>> editable property, I would not use a runtime exception.  There would be no
>>>>>>>>>>> chance for the forge plugin programmer to avoid the error gracefully.  With
>>>>>>>>>>> the property, the error is the programmer's and a runtime exception could
>>>>>>>>>>> be appropriate.
>>>>>>>>>>>
>>>>>>>>>>>  Regards,
>>>>>>>>>>> John
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Feb 14, 2013 at 1:11 PM, Lincoln Baxter, III <
>>>>>>>>>>> lincolnbaxter at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>>  As I understood it, we need a way of explicitly noting when a
>>>>>>>>>>>> JavaSource instance is mutable or not. Perhaps splitting the API into a
>>>>>>>>>>>> JavaSource an EditableJavaSource parallel.
>>>>>>>>>>>>
>>>>>>>>>>>>  It was also my understanding that proxies were going to be
>>>>>>>>>>>> used to do lazy-classloading for any JARs brought in via this system. I'm
>>>>>>>>>>>> not sure we need to worry about this just yet. We can get it working then
>>>>>>>>>>>> think about performance implications.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Feb 14, 2013 at 12:23 PM, John Franey <
>>>>>>>>>>>> jjfraney at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>  I have no intention of providing a way to modify the class
>>>>>>>>>>>>> definition of a java class defined within a dependency of the user's
>>>>>>>>>>>>> project.
>>>>>>>>>>>>>
>>>>>>>>>>>>>  Putting the question another way:
>>>>>>>>>>>>>
>>>>>>>>>>>>>  To date, the forge java model today supports only modifiable
>>>>>>>>>>>>> java components.  This effort introduces non-modifiable java components to
>>>>>>>>>>>>> the forge java model.   This raises the question:  Would the non-modifiable
>>>>>>>>>>>>> java components be inspected with the same api that supports the modifiable
>>>>>>>>>>>>> java components (JavaClass, and others).  If no, what api is used to
>>>>>>>>>>>>> inspect the non-modifiable java components?
>>>>>>>>>>>>>
>>>>>>>>>>>>>  My naive answer is: the non-modifiable java components would
>>>>>>>>>>>>> be inspected using the same api as the modifiable java components.  Methods
>>>>>>>>>>>>> of that api that expressly modify the java component would be inert for
>>>>>>>>>>>>> non-modifiable java components.
>>>>>>>>>>>>>
>>>>>>>>>>>>>  John
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Feb 14, 2013 at 12:05 PM, Thomas Frühbeck <
>>>>>>>>>>>>> fruehbeck at aon.at> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>>  Hmm, I expect loading of JARs not to the problem, is it? So
>>>>>>>>>>>>>> the loading and reflecting on the "external" class should be possible.
>>>>>>>>>>>>>> I was thinking of the next step, implementing kind of
>>>>>>>>>>>>>> writable JavaClass not just ignoring the changes, but making the modified
>>>>>>>>>>>>>> class available to the project.
>>>>>>>>>>>>>> Sorry if I misunderstood your quest? =)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thomas
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Am 14.02.2013 17:37, schrieb John Franey:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thomas,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  I have minimal exposure to proxy due to experience with
>>>>>>>>>>>>>> hibernate, but my understanding is not adequate to understand how they
>>>>>>>>>>>>>> would apply.  Do I understand correctly that the benefit of a dynamic proxy
>>>>>>>>>>>>>> is high when a temporary class implementation is needed, and when a method
>>>>>>>>>>>>>> of the proxy is invoked, some action is taken, perhaps instantiating
>>>>>>>>>>>>>> another implementation of the interface.  In this use case, we don't need
>>>>>>>>>>>>>> to invoke the methods of a project's class, we need to inspect the methods
>>>>>>>>>>>>>> (and other members) of the class, right?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>  John
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Feb 14, 2013 at 11:22 AM, Thomas Frühbeck <
>>>>>>>>>>>>>> fruehbeck at aon.at> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  exactly what I was looking for :-))
>>>>>>>>>>>>>>> Thanks George!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Am 14.02.2013 16:55, schrieb George Gastaldi:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Thomas,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  Have a look in Forge 2.0 source code. We're using
>>>>>>>>>>>>>>> javassist at it's best in the proxy module
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Em 14/02/2013, às 13:53, Thomas Frühbeck <fruehbeck at aon.at>
>>>>>>>>>>>>>>> escreveu:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>   Hi John,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> my two cents:
>>>>>>>>>>>>>>>     - this feature is a must-have, if Forge should be more
>>>>>>>>>>>>>>> than a tool to iniitialize projects, really great idea
>>>>>>>>>>>>>>>     - being pragmatic I would say this calls for proxy
>>>>>>>>>>>>>>> classes, similar to CDI decorators or the copy-on-write strategy
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (AFAIK the downside to CDI decorators is that they need
>>>>>>>>>>>>>>> interfaces on the base classes, thus again requiring changes of the classes
>>>>>>>>>>>>>>> if they hadnt been designed for it firstplace.)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have a very similar problem I am currently trying to solve
>>>>>>>>>>>>>>> with silly wrapper classes and was starting to think about dynamic proxy
>>>>>>>>>>>>>>> generation - unfortunately I have _no_ experience with such technology
>>>>>>>>>>>>>>> other than being simple user :-/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Have you thought about javassist? Is it an option at all?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thomas
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Am 14.02.2013 16:21, schrieb 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> forge-dev mailing listforge-dev at lists.jboss.orghttps://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 listforge-dev at lists.jboss.orghttps://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 listforge-dev at lists.jboss.orghttps://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
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> forge-dev mailing listforge-dev at lists.jboss.orghttps://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."
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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."
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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."
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>
>>
>>
>> _______________________________________________
>> forge-dev mailing listforge-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>> --
>> *George Gastaldi* | *Senior Software Engineer*
>> JBoss Forge Team
>> Red Hat
>>
>> _______________________________________________
>> 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/20130306/efddacd2/attachment-0001.html

More information about the forge-dev mailing list