Hi Sainath, certainly, I'll create the GEP 2.1.2 branch this weekend and you can
start making your changes to trunk when you are ready. Thanks again for your
assistance.
Sainath Chowdary wrote:
Hi Tim, I would be returning to college by 10th of August and I will
start on this as soon as possible. If we need to start working from now,
can you help me with the sandbox or branching the trunk for 2.1.2?
On Fri, Jul 25, 2008 at 1:39 AM, Donald Woods <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Maybe it's time to copy trunk over to branches/2.1 and finish any
2.1.2 work items there.... Why are we slowing down GEP
enhancements, when we could be using trunk for 2.2.0 and a branch
for 2.1.x releases, like we do for the server?
-Donald
Ted Kirby wrote:
Depending on the timing, Tim's suggestion of starting now in the
sandbox was a good one. Tim, maybe you can help Sainath get started
there?
Ted
On Thu, Jul 24, 2008 at 2:59 PM, Tim McConnell
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
Hi Sainath, that would be wonderful if you're going to have
the time. When
are you returning to college ??
Sainath Chowdary wrote:
Thanks Ted and Tim for your feedback. I agree with both
of you that we
cannot attempt this in trunk as next release is ahead of
us in few weeks.
I would be happy to work on the proposed architecture
for GEP once I get
back to my college. Also by that time I guess 2.1.2
would have been
released.
On Thu, Jul 24, 2008 at 6:49 AM, Tim McConnell
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
Hi Sainath, I agree with Ted as well. Your ideas seem
sound but I
don't think we should attempt this in GEP trunk, which
will soon be
released in conjunction with the 2.1.2 Geronimo
server. As an
alternative, could you possibly work on this in the
devtools sandbox ??
Sainath Chowdary wrote:
I think that current architecture of GEP is too
rigid in a way
which produces very redundant code if we extend it
for future
versions of Geronimo. Also it is not compliant
with multiple
version of schemas.The UI elements are also
somewhat implemented
in a hacky way where v20 UI depends on v21 UI
which should be
the opposite. We need to introduce proper
hierarchy levels
according to schema/server versions in GEP MVC at
this level
before GEP becomes overly complicated.
For this I propose we change the architecture of
our JAXB model
to provide support for multiple versions of
schemas. With the
help of slight customizations we can easily make
JAXB model
tailored for our purpose. The main task would be
to create a
common pool of classes between the versions and
initializing the
JAXB context properly. Assuming we support both
v2.0 and v2.1
which respectively have geronimo-web-2.0.xsd &
geronimo-web-2.0.1.xsd, we will create a Interface
that will be
implemented by both WebAppTypes so that in commn
UI section we
can directly cast to the interface and in version
specific UI we
can cast it to the particular version we are
working in.
After that we may need to refactor the code in ui
plugins to
utilize the new hierarchy levels and extra
functionality added.
Current architecture will easily achieve its
bottleneck if the
schema changes frequently. I find it this is the
ideal time to
reorganize the whole of GEP.
Any comments?
-- Thanks,
Sainath Chowdary
B.Tech III yr, Spring Semester
Electronics & Communication Engg
Indian Institute of Technology Roorkee
-- Thanks,
Tim McConnell
--
Thanks,
Sainath Chowdary
B.Tech III yr, Spring Semester
Electronics & Communication Engg
Indian Institute of Technology Roorkee
--
Thanks,
Tim McConnell
--
Thanks,
Sainath Chowdary
B.Tech III yr, Spring Semester
Electronics & Communication Engg
Indian Institute of Technology Roorkee
--
Thanks,
Tim McConnell
