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

Lincoln Baxter, III lincolnbaxter at gmail.com
Tue Mar 5 14:26:17 EST 2013 

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."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20130305/b07df68d/attachment-0001.html

More information about the forge-dev mailing list