<div dir="ltr"><div><div><div>Hey John,<br><br></div>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?<br>
<br>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!<br><br></div>Thoughts?<br></div>~Lincoln<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 22, 2013 at 10:14 AM, <span dir="ltr"><<a href="mailto:ggastald@redhat.com" target="_blank">ggastald@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Hi !<br>
<br>
This seems like a good way to go. <br>
I've updated the JIRA in <a href="https://issues.jboss.org/browse/FORGE-795" target="_blank">https://issues.jboss.org/browse/FORGE-795</a>
with this info.<br>
<br>
Thanks !<br>
<br>
<br>
On 02/22/2013 12:01 PM, John Franey wrote:
<blockquote type="cite">
<div dir="ltr">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: <a href="http://www.vogella.com/articles/EclipseJDT/article.html" target="_blank">http://www.vogella.com/articles/EclipseJDT/article.html</a>
<div>
<br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Here is the javacore project page: <a href="http://www.eclipse.org/jdt/core/index.php" target="_blank">http://www.eclipse.org/jdt/core/index.php</a></div>
<div>Here is the javacore api pages: <a href="http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/JavaCore.html" target="_blank">http://help.eclipse.org/juno/index.jsp?topic=/org.eclipse.jdt.doc.isv/reference/api/org/eclipse/jdt/core/JavaCore.html</a></div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Fri, Feb 22, 2013 at 12:30 AM,
Lincoln Baxter, III <span dir="ltr"><<a href="mailto:lincolnbaxter@gmail.com" target="_blank">lincolnbaxter@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.<br>
</div>
<div>
<div>
<div class="gmail_extra">
<br>
<br>
<div class="gmail_quote">On Fri, Feb 22, 2013 at 12:28
AM, Lincoln Baxter, III <span dir="ltr"><<a href="mailto:lincolnbaxter@gmail.com" target="_blank">lincolnbaxter@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Wait, JavaCore is or is not related
to JDT? <br>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Feb 21,
2013 at 7:18 PM, John Franey <span dir="ltr"><<a href="mailto:jjfraney@gmail.com" target="_blank">jjfraney@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>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.</div>
<div><br>
</div>
<div>javassist's latest release is
December 2012 and seems to have
jboss backing. Seems a safe choice
on the face of it.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu,
Feb 21, 2013 at 6:30 PM, Lincoln
Baxter, III <span dir="ltr"><<a href="mailto:lincolnbaxter@gmail.com" target="_blank">lincolnbaxter@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">What about
something like this?<br>
<br>
<a href="https://issues.jboss.org/browse/FORGE-795" target="_blank">https://issues.jboss.org/browse/FORGE-795</a><br>
<a href="https://issues.jboss.org/browse/FORGE-796" target="_blank">https://issues.jboss.org/browse/FORGE-796</a><br>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On
Wed, Feb 20, 2013 at
11:11 AM, Lincoln
Baxter, III <span dir="ltr"><<a href="mailto:lincolnbaxter@gmail.com" target="_blank">lincolnbaxter@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.<br>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On
Tue, Feb 19,
2013 at 7:41
PM, John
Franey <span dir="ltr"><<a href="mailto:jjfraney@gmail.com" target="_blank">jjfraney@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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?
<div>
<br>
</div>
<div><br>
</div>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On
Mon, Feb 18,
2013 at 9:43
PM, Lincoln
Baxter, III <span dir="ltr"><<a href="mailto:lincolnbaxter@gmail.com" target="_blank">lincolnbaxter@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.<br>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">
On Mon, Feb
18, 2013 at
9:43 PM,
Lincoln
Baxter, III <span dir="ltr"><<a href="mailto:lincolnbaxter@gmail.com" target="_blank">lincolnbaxter@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>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.<br>
<br>
</div>
<div>So from
the
perspective of
Migration, it
probably makes
sense to do
something like
add a method
"isEditable()"<br>
</div>
</div>
<div>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On
Thu, Feb 14,
2013 at 2:19
PM, Thomas
Frühbeck <span dir="ltr"><<a href="mailto:fruehbeck@aon.at" target="_blank">fruehbeck@aon.at</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>If I
understood
Lincoln
correctly, he
meant adding
an interface
EditableJavaSource,
so no change
in the
existing
implementations
necessary.<br>
So the boolean
is
substitutable
by instanceof,
your graceful
error handling
would be
supported.<br>
<br>
Am 14.02.2013
20:10, schrieb
John Franey:<br>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">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.....
<div> <br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>Regards,</div>
<div>John</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On
Thu, Feb 14,
2013 at 1:11
PM, Lincoln
Baxter, III <span dir="ltr"><<a href="mailto:lincolnbaxter@gmail.com" target="_blank">lincolnbaxter@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>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.<br>
<br>
</div>
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.<br>
</div>
<div class="gmail_extra">
<div>
<div><br>
<br>
<div class="gmail_quote">On
Thu, Feb 14,
2013 at 12:23
PM, John
Franey <span dir="ltr"><<a href="mailto:jjfraney@gmail.com" target="_blank">jjfraney@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">
<div>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.</div>
<div><br>
</div>
<div>Putting
the question
another way:</div>
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>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.</div>
<span><font color="#888888">
<div><br>
</div>
<div>John</div>
<div><br>
</div>
</font></span></div>
<div>
<div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On
Thu, Feb 14,
2013 at 12:05
PM, Thomas
Frühbeck <span dir="ltr"><<a href="mailto:fruehbeck@aon.at" target="_blank">fruehbeck@aon.at</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hmm, I
expect loading
of JARs not to
the problem,
is it? So the
loading and
reflecting on
the "external"
class should
be possible. <br>
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.<br>
Sorry if I
misunderstood
your quest? =)<br>
<br>
Thomas<br>
<br>
Am 14.02.2013
17:37, schrieb
John Franey:<br>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">Thomas,
<div><br>
</div>
<div>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?</div>
<div><br>
</div>
<div>John</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On
Thu, Feb 14,
2013 at 11:22
AM, Thomas
Frühbeck <span dir="ltr"><<a href="mailto:fruehbeck@aon.at" target="_blank">fruehbeck@aon.at</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>exactly
what I was
looking for
:-))<br>
Thanks George!<br>
<br>
Am 14.02.2013
16:55, schrieb
George
Gastaldi:<br>
</div>
<div>
<div>
<blockquote type="cite">
<div>Hi
Thomas,</div>
<div><br>
</div>
<div>Have a
look in Forge
2.0 source
code. We're
using
javassist at
it's best in
the proxy
module</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
Em 14/02/2013,
às 13:53,
Thomas
Frühbeck <<a href="mailto:fruehbeck@aon.at" target="_blank">fruehbeck@aon.at</a>>
escreveu:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div>Hi John,<br>
<br>
my two cents:
<br>
- this
feature is a
must-have, if
Forge should
be more than a
tool to
iniitialize
projects,
really great
idea<br>
- being
pragmatic I
would say this
calls for
proxy classes,
similar to CDI
decorators or
the
copy-on-write
strategy<br>
<br>
(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.)<br>
<br>
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 :-/<br>
<br>
Have you
thought about
javassist? Is
it an option
at all?<br>
<br>
Thomas<br>
<br>
<br>
Am 14.02.2013
16:21, schrieb
John Franey:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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.
<div><br>
</div>
<div>I have
written a
prototype:</div>
<div>1) an
implementation
of the forge
java api
interfaces
which
delegates to
java's
reflection,
offering a
read only
perspective of
java
components.</div>
<div>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.</div>
<div><br>
</div>
<div>These are
demonstrable
in a unit
test.</div>
<div><br>
</div>
<div>My
dilemma now is
how to
integrate
these into the
forge project.
There are a
few different
areas, but
I'll start
with this:</div>
<div><br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>So, I'm
looking for
discussion and
consensus on
the above.
Any thoughts?</div>
<div><br>
</div>
<div>Regards,</div>
<div>John</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
forge-dev mailing list
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a></pre>
</blockquote>
<br>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>forge-dev
mailing list</span><br>
<span><a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a></span><br>
<span><a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a></span></div>
</blockquote>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
forge-dev mailing list
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a></pre>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
forge-dev
mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
forge-dev mailing list
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a></pre>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
forge-dev
mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
forge-dev
mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
</div>
</div>
<span><font color="#888888">--
<br>
Lincoln
Baxter, III<br>
<a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>
"Simpler is
better." </font></span></div>
<br>
_______________________________________________<br>
forge-dev
mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
forge-dev mailing list
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a></pre>
</blockquote>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
forge-dev
mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Lincoln
Baxter, III<br>
<a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>
"Simpler is
better."
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Lincoln
Baxter, III<br>
<a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>
"Simpler is
better."
</div>
</div>
</div>
<br>
_______________________________________________<br>
forge-dev
mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
forge-dev
mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Lincoln
Baxter, III<br>
<a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>
"Simpler is
better."
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Lincoln Baxter, III<br>
<a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>
"Simpler is better."
</div>
</div>
</div>
<br>
_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Lincoln Baxter, III<br>
<a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>
"Simpler is better."
</div>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Lincoln Baxter, III<br>
<a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>
"Simpler is better."
</div>
</div>
</div>
<br>
_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
forge-dev mailing list
<a href="mailto:forge-dev@lists.jboss.org" target="_blank">forge-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a></pre><span class="HOEnZb"><font color="#888888">
</font></span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<div>-- <br>
<b>George Gastaldi</b> | <i>Senior Software Engineer</i> <br>
JBoss Forge Team<br>
Red Hat<br>
</div>
</font></span></div>
<br>_______________________________________________<br>
forge-dev mailing list<br>
<a href="mailto:forge-dev@lists.jboss.org">forge-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/forge-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/forge-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>
"Simpler is better."
</div>