groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keegan Witt <keeganw...@gmail.com>
Subject Re: Looking for testers & feedback: new Groovy binaries for Windows
Date Tue, 18 Oct 2016 02:53:08 GMT
Thanks Paco,
It looks like it's related to @GrabConfig(systemClassLoader=true), I'm
looking into it.

-Keegan

On Mon, Oct 17, 2016 at 12:20 PM, Paco Zarate <contacto@nazcasistemas.com>
wrote:

> Hey Keegan,
> Looks like there is a problem with Grapes and the .exe files:
> I am attaching the test code (a sqlite example from SO)
>
> When i use the groovy.bat i got:
> c:\Data\Samples\Groovy\sqlite>groovy.bat samplesqlite.groovy
> id=1, name= leo
> id=2, name= yui
>
> When i use the groovy.exe i got this error:
> c:\Data\Samples\Groovy\sqlite>groovy.exe samplesqlite.groovy
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> General error during conversion: No suitable ClassLoader found for grab
>
> java.lang.RuntimeException: No suitable ClassLoader found for grab
>     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>     at sun.reflect.NativeConstructorAccessorImpl.newInstance(
> NativeConstructorAccessorImpl.java:62)
>     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(
> DelegatingConstructorAccessorImpl.java:45)
>     at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>     at org.codehaus.groovy.reflection.CachedConstructor.
> invoke(CachedConstructor.java:83)
>     at org.codehaus.groovy.runtime.callsite.ConstructorSite$
> ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
>     at org.codehaus.groovy.runtime.callsite.CallSiteArray.
> defaultCallConstructor(CallSiteArray.java:60)
>     at org.codehaus.groovy.runtime.callsite.AbstractCallSite.
> callConstructor(AbstractCallSite.java:235)
>     at org.codehaus.groovy.runtime.callsite.AbstractCallSite.
> callConstructor(AbstractCallSite.java:247)
>     at groovy.grape.GrapeIvy.chooseClassLoader(GrapeIvy.groovy:184)
>     at groovy.grape.GrapeIvy$chooseClassLoader.callCurrent(Unknown Source)
>     at org.codehaus.groovy.runtime.callsite.CallSiteArray.
> defaultCallCurrent(CallSiteArray.java:52)
>     at org.codehaus.groovy.runtime.callsite.AbstractCallSite.
> callCurrent(AbstractCallSite.java:154)
>     at org.codehaus.groovy.runtime.callsite.AbstractCallSite.
> callCurrent(AbstractCallSite.java:166)
>     at groovy.grape.GrapeIvy.grab(GrapeIvy.groovy:251)
>     at groovy.grape.Grape.grab(Grape.java:167)
>     at groovy.grape.GrabAnnotationTransformation.visit(
> GrabAnnotationTransformation.java:378)
>     at org.codehaus.groovy.transform.ASTTransformationVisitor$3.
> call(ASTTransformationVisitor.java:321)
>     at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(
> CompilationUnit.java:931)
>     at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(
> CompilationUnit.java:593)
>     at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(
> CompilationUnit.java:569)
>     at org.codehaus.groovy.control.CompilationUnit.compile(
> CompilationUnit.java:546)
>     at groovy.lang.GroovyClassLoader.doParseClass(
> GroovyClassLoader.java:298)
>     at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.
> java:268)
>     at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
>     at groovy.lang.GroovyShell.run(GroovyShell.java:517)
>     at groovy.lang.GroovyShell.run(GroovyShell.java:507)
>     at groovy.ui.GroovyMain.processOnce(GroovyMain.java:653)
>     at groovy.ui.GroovyMain.run(GroovyMain.java:384)
>     at groovy.ui.GroovyMain.process(GroovyMain.java:370)
>     at groovy.ui.GroovyMain.processArgs(GroovyMain.java:129)
>     at groovy.ui.GroovyMain.main(GroovyMain.java:109)
>
> 1 error
>
> Thanks!
> Paco.
>
>
>
> On Tue, Oct 11, 2016 at 4:50 PM, Keegan Witt <keeganwitt@gmail.com> wrote:
>
>> Well there's the bat file in bin.  Might be good to keep it there at
>> least initially, as a transition though.
>>
>> -Keegan
>>
>> On Oct 11, 2016 4:58 PM, "Paco Zarate" <contacto@nazcasistemas.com>
>> wrote:
>>
>>> I would suggest to keep the gant.exe, it makes really clear that you can
>>> execute that one on Windows. Otherwise I would not know that the
>>> application is there. (as in Linux where you can see the .sh files)
>>>
>>> On Tue, Oct 11, 2016 at 2:49 PM, Keegan Witt <keeganwitt@gmail.com>
>>> wrote:
>>>
>>>> Actually question I guess would be whether we even need a gant.exe.
>>>> Nobody really doubleclicks gant files that I'm aware of.
>>>>
>>>> -Keegan
>>>>
>>>> On Tue, Oct 11, 2016 at 4:34 PM, Keegan Witt <keeganwitt@gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Paco,
>>>>> Thanks again for your help.  Yea, it assumes Gant will be installed in
>>>>> the lib directory with the rest of the Groovy jars since that's how it's
>>>>> installed by the Windows installer.  If you drop the jar in there, it
>>>>> should work.
>>>>>
>>>>> I'm mostly liking these so far.  The only thing I might be able to
>>>>> improve on is that all the jars in lib are included in the classpath
>>>>> currently, whereas the C binaries I think were more explicit in some
cases
>>>>> (gant I think being one of them).  I want to think through some more
>>>>> whether there's any issues there.
>>>>>
>>>>> -Keegan
>>>>>
>>>>> On Mon, Oct 10, 2016 at 5:57 PM, Paco Zarate <
>>>>> contacto@nazcasistemas.com> wrote:
>>>>>
>>>>>> Keegan,
>>>>>> The new .exe files look really good, I will keep using them. Even
>>>>>> with a record in the PATH that includes an & (in a non-groovy
related
>>>>>> folder) it is working fine.
>>>>>>
>>>>>> The only error was:
>>>>>> paco@DEVELOPER2 C:\Users\paco
>>>>>> > gant
>>>>>> Error: Could not find or load main class gant.Gant
>>>>>>
>>>>>> paco@DEVELOPER2 C:\Users\paco
>>>>>> > gant.exe
>>>>>> Error: Could not find or load main class gant.Gant
>>>>>>
>>>>>> paco@DEVELOPER2 C:\Users\paco
>>>>>> > gant.exe -v
>>>>>> Error: Could not find or load main class gant.Gant
>>>>>>
>>>>>> But i think i am missing the gant install, i will read more about
how
>>>>>> to install gant correctly later today and let you know.
>>>>>>
>>>>>> Paco.
>>>>>>
>>>>>> On Mon, Sep 26, 2016 at 12:18 PM, Keegan Witt <keeganwitt@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I started experimenting with launch4j, and have put that experiment
>>>>>>> in this repo: https://github.com/keeganwitt/groovy-launch4j.
 I've
>>>>>>> uploaded binaries into same place I previous linked.  The first
binaries I
>>>>>>> uploaded are in batWrapper.zip, and the new launch4j based binaries
are in
>>>>>>> launch4j.zip if anyone wants to try them out.  At the moment,
I only have
>>>>>>> binaries that call Java (i.e. not bundled with Java).
>>>>>>>
>>>>>>> -Keegan
>>>>>>>
>>>>>>> On Fri, Sep 9, 2016 at 10:43 PM, Keegan Witt <keeganwitt@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hmm, maybe the bat files aren't as robust as I assumed and
I should
>>>>>>>> rethink the approach.
>>>>>>>>
>>>>>>>> If we went the GCJ route, we'd still have to implement our
own
>>>>>>>> logic to locate Java binaries (similar to how C code does
today), right?
>>>>>>>> That'd be an option, though I'm a little hesitant to start
relying on
>>>>>>>> something that looks like hasn't been updated in in several
years and only
>>>>>>>> supports Java 1.4 and some of Java 5.
>>>>>>>> Another option would be Launch4J, which is what I was originally
>>>>>>>> considering.  If we did that, we could even create 2 sets
of binaries -- 1
>>>>>>>> with a bundled JRE, and 1 without.  What kinda drew me to
that approach was
>>>>>>>> that it already had its own logic for locating Java.  I'll
do some reading
>>>>>>>> on both options.
>>>>>>>>
>>>>>>>> -Keegan
>>>>>>>>
>>>>>>>> On Thu, Sep 8, 2016 at 8:27 AM, Jochen Theodorou <blackdrag@gmx.org
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Maybe a stupid question... but couldn't we write an exe
in Java
>>>>>>>>> and compile using gcj. The exe would spawn a new "normal"
JVM and do the
>>>>>>>>> argument handling. Unlike the C variant there would be
more people able to
>>>>>>>>> handle this.
>>>>>>>>>
>>>>>>>>> bye Jochen
>>>>>>>>>
>>>>>>>>> On 08.09.2016 11:13, Paul King wrote:
>>>>>>>>>
>>>>>>>>>> I think there are numerous problems with the argument
passing in
>>>>>>>>>> the
>>>>>>>>>> batch files. That was one of the things that the
exe files aimed
>>>>>>>>>> to
>>>>>>>>>> improve on. I must admit to having reservations about
the new
>>>>>>>>>> approach.
>>>>>>>>>> Not so much with the concept but more about relying
on the
>>>>>>>>>> current bat
>>>>>>>>>> files. That said, I am not sure staying with the
current approach
>>>>>>>>>> is
>>>>>>>>>> ideal either.
>>>>>>>>>>
>>>>>>>>>> Cheers, Paul.
>>>>>>>>>>
>>>>>>>>>> On Thu, Sep 8, 2016 at 4:57 PM, Paco Zarate <
>>>>>>>>>> contacto@nazcasistemas.com
>>>>>>>>>> <mailto:contacto@nazcasistemas.com>> wrote:
>>>>>>>>>>
>>>>>>>>>>     Hello Keegan
>>>>>>>>>>     groovy and groovyc are working for me now! thanks!!
>>>>>>>>>>
>>>>>>>>>>     The bat file seems to have an issue on Windows
though:
>>>>>>>>>>
>>>>>>>>>>     When the JAVA_HOME is not defined, and the PATH
has an
>>>>>>>>>> element with
>>>>>>>>>>     & (ampersand), the groovy invocation seems
to try to execute
>>>>>>>>>> the
>>>>>>>>>>     code after the & (eg. if mysql is installed
there is a PATH
>>>>>>>>>> defined to
>>>>>>>>>>     "c:\Program Files (x86)\MySQL\MySQL Fabric 1.5
& MySQL
>>>>>>>>>> Utilities 1.5")
>>>>>>>>>>     This is the output:
>>>>>>>>>>     C:\WINDOWS\system32>groovy.bat -v
>>>>>>>>>>     'MySQL' is not recognized as an internal or external
command,
>>>>>>>>>>     operable program or batch file.
>>>>>>>>>>     'MySQL' is not recognized as an internal or external
command,
>>>>>>>>>>     operable program or batch file.
>>>>>>>>>>     Groovy Version: 2.4.7 JVM: 1.8.0_101 Vendor:
Oracle
>>>>>>>>>> Corporation OS:
>>>>>>>>>>     Windows 10
>>>>>>>>>>
>>>>>>>>>>     I did this another test: I created an empty folder
>>>>>>>>>>     "c:\Programs\sample1 & sample2" and added
it to the PATH just
>>>>>>>>>> before
>>>>>>>>>>     "%GROOVY_HOME%\bin"
>>>>>>>>>>
>>>>>>>>>>     When i run:
>>>>>>>>>>     C:\WINDOWS\system32> groovy.bat -v
>>>>>>>>>>     'sample2' is not recognized as an internal or
external
>>>>>>>>>> command,
>>>>>>>>>>     operable program or batch file.
>>>>>>>>>>     Groovy Version: 2.4.7 JVM: 1.8.0_101 Vendor:
Oracle
>>>>>>>>>> Corporation OS:
>>>>>>>>>>     Windows 10
>>>>>>>>>>
>>>>>>>>>>     So it looks like an ampersand in an element in
the PATH can
>>>>>>>>>> affect
>>>>>>>>>>     the groovy invocation.
>>>>>>>>>>
>>>>>>>>>>     Paco
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>     On Wed, Sep 7, 2016 at 8:39 PM, Keegan Witt <
>>>>>>>>>> keeganwitt@gmail.com
>>>>>>>>>>     <mailto:keeganwitt@gmail.com>> wrote:
>>>>>>>>>>
>>>>>>>>>>         I've uploaded new executables to fix the
issue with
>>>>>>>>>> invoking
>>>>>>>>>>         without .exe suffix.
>>>>>>>>>>
>>>>>>>>>>         -Keegan
>>>>>>>>>>
>>>>>>>>>>         On Wed, Sep 7, 2016 at 5:21 PM, Keegan Witt
>>>>>>>>>>         <keeganwitt@gmail.com <mailto:keeganwitt@gmail.com>>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>             Paco,
>>>>>>>>>>             Good catch.  I'll correct that.
>>>>>>>>>>
>>>>>>>>>>             Raviteja,
>>>>>>>>>>             That's correct, they are just wrappers.
 The
>>>>>>>>>> advantage is
>>>>>>>>>>             that you can set file associations in
Windows to an
>>>>>>>>>> exe, but
>>>>>>>>>>             you can't associate a file type with
a bat file.  If
>>>>>>>>>> you
>>>>>>>>>>             could, than you'd be right -- there'd
be no reason to
>>>>>>>>>> have a
>>>>>>>>>>             wrapper.
>>>>>>>>>>
>>>>>>>>>>             -Keegan
>>>>>>>>>>
>>>>>>>>>>             On Wed, Sep 7, 2016 at 1:57 PM, Raviteja
Lokineni
>>>>>>>>>>             <raviteja.lokineni@gmail.com
>>>>>>>>>>             <mailto:raviteja.lokineni@gmail.com>>
wrote:
>>>>>>>>>>
>>>>>>>>>>                 I just glanced over the code and
found that the
>>>>>>>>>> cpp code
>>>>>>>>>>                 just seems to be a wrapper on top
of existing bat
>>>>>>>>>> file.
>>>>>>>>>>                 Although it is good that you wanted
to
>>>>>>>>>> contribute, I
>>>>>>>>>>                 don't see the advantage in using
exe file iff all
>>>>>>>>>> it
>>>>>>>>>>                 does is wrap existing bat file.
>>>>>>>>>>
>>>>>>>>>>                 Thanks,
>>>>>>>>>>                 Raviteja
>>>>>>>>>>
>>>>>>>>>>                 On Wed, Sep 7, 2016 at 5:45 AM, Paco
Zarate
>>>>>>>>>>                 <contacto@nazcasistemas.com
>>>>>>>>>>                 <mailto:contacto@nazcasistemas.com>>
wrote:
>>>>>>>>>>
>>>>>>>>>>                     Hello Keegan!
>>>>>>>>>>
>>>>>>>>>>                     I was trying the new .exe files
and i receive
>>>>>>>>>> these
>>>>>>>>>>                     errors when using the commands
without .exe:
>>>>>>>>>>
>>>>>>>>>>                     C:\WINDOWS\system32>groovyc
-v
>>>>>>>>>>                     'groobat' is not recognized as
an internal or
>>>>>>>>>>                     external command,
>>>>>>>>>>                     operable program or batch file.
>>>>>>>>>>
>>>>>>>>>>                     C:\WINDOWS\system32>groovy
-v
>>>>>>>>>>                     'grobat' is not recognized as
an internal or
>>>>>>>>>>                     external command,
>>>>>>>>>>                     operable program or batch file.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     Including the .exe seems  to
work fine:
>>>>>>>>>>
>>>>>>>>>>                     C:\WINDOWS\system32>groovy.exe
-v
>>>>>>>>>>                     Groovy Version: 2.4.7 JVM: 1.8.0_101
Vendor:
>>>>>>>>>> Oracle
>>>>>>>>>>                     Corporation OS: Windows 10
>>>>>>>>>>
>>>>>>>>>>                     C:\WINDOWS\system32>groovyc.exe
-v
>>>>>>>>>>                     Groovy compiler version 2.4.7
>>>>>>>>>>                     Copyright 2003-2016 The Apache
Software
>>>>>>>>>> Foundation.
>>>>>>>>>>                     http://groovy-lang.org/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                     If i remove the JAVA_HOME env
variable I get
>>>>>>>>>> these
>>>>>>>>>>                     responses:
>>>>>>>>>>                     C:\WINDOWS\system32>groovy.exe
-v
>>>>>>>>>>                     'MySQL' is not recognized as
an internal or
>>>>>>>>>> external
>>>>>>>>>>                     command,
>>>>>>>>>>                     operable program or batch file.
>>>>>>>>>>                     'MySQL' is not recognized as
an internal or
>>>>>>>>>> external
>>>>>>>>>>                     command,
>>>>>>>>>>                     operable program or batch file.
>>>>>>>>>>                     Groovy Version: 2.4.7 JVM: 1.8.0_101
Vendor:
>>>>>>>>>> Oracle
>>>>>>>>>>                     Corporation OS: Windows 10
>>>>>>>>>>
>>>>>>>>>>                     C:\WINDOWS\system32>groovyc.exe
-v
>>>>>>>>>>                     'MySQL' is not recognized as
an internal or
>>>>>>>>>> external
>>>>>>>>>>                     command,
>>>>>>>>>>                     operable program or batch file.
>>>>>>>>>>                     'MySQL' is not recognized as
an internal or
>>>>>>>>>> external
>>>>>>>>>>                     command,
>>>>>>>>>>                     operable program or batch file.
>>>>>>>>>>                     Groovy compiler version 2.4.7
>>>>>>>>>>                     Copyright 2003-2016 The Apache
Software
>>>>>>>>>> Foundation.
>>>>>>>>>>                     http://groovy-lang.org/
>>>>>>>>>>
>>>>>>>>>>                     Thanks!!
>>>>>>>>>>
>>>>>>>>>>                     Paco.
>>>>>>>>>>
>>>>>>>>>>                     On Thu, Sep 1, 2016 at 2:05 PM,
Keegan Witt
>>>>>>>>>>                     <keeganwitt@gmail.com <mailto:
>>>>>>>>>> keeganwitt@gmail.com>>
>>>>>>>>>>                     wrote:
>>>>>>>>>>
>>>>>>>>>>                         I'm building some new binaries
for Windows
>>>>>>>>>>                         (groovy.exe, groovyConsole.exe,
etc) and
>>>>>>>>>> am
>>>>>>>>>>                         looking for some folks to
test and code
>>>>>>>>>> review
>>>>>>>>>>                         it.  Their temporary home
is here:
>>>>>>>>>>                         https://github.com/keeganwitt/
>>>>>>>>>> groovy-binaries
>>>>>>>>>>                         <https://github.com/keeganwitt
>>>>>>>>>> /groovy-binaries>.  After
>>>>>>>>>>                         I've incorporated any feedback
I get, I'll
>>>>>>>>>>                         transfer it to a repo under
the groovy
>>>>>>>>>> org on
>>>>>>>>>>                         Github (haven't decided yet
whether that
>>>>>>>>>> should
>>>>>>>>>>                         begroovy-windows-installer
>>>>>>>>>>                         <https://github.com/groovy/gro
>>>>>>>>>> ovy-windows-installer> orgroovy-native-launcher
>>>>>>>>>>                         <https://github.com/groovy/gro
>>>>>>>>>> ovy-native-launcher>).
>>>>>>>>>>
>>>>>>>>>>                         To make it easy to test,
you can download
>>>>>>>>>> the
>>>>>>>>>>                         compiled binaries from here
>>>>>>>>>>                         (https://drive.google.com/fold
>>>>>>>>>> erview?id=0B_uOQFeu84v0TDVkS00xeE5yNHc&usp=sharing
>>>>>>>>>>                         <https://drive.google.com/fold
>>>>>>>>>> erview?id=0B_uOQFeu84v0TDVkS00xeE5yNHc&usp=sharing>)
>>>>>>>>>>
>>>>>>>>>>                         and put them in your current
Groovy
>>>>>>>>>> installation
>>>>>>>>>>                         (whether from zip or installer).
>>>>>>>>>>
>>>>>>>>>>                         The overall approach is to
have an exe
>>>>>>>>>> that
>>>>>>>>>>                         calls the matching .bat file.
 This
>>>>>>>>>> approach was
>>>>>>>>>>                         to avoid a few things I didn't
like about
>>>>>>>>>> the
>>>>>>>>>>                         current binaries, namely
>>>>>>>>>>                         Windows installer determines
32 or 64 bit
>>>>>>>>>>                         version of Java at install
time and
>>>>>>>>>> installs the
>>>>>>>>>>                         appropriate groovy.exe, but
if you change
>>>>>>>>>> your
>>>>>>>>>>                         Java version later, exe won't
be able to
>>>>>>>>>> run
>>>>>>>>>>                         Groovy because it won't be
able to find
>>>>>>>>>> right
>>>>>>>>>>                         Java to invoke.
>>>>>>>>>>                         Binaries have their own logic
to find
>>>>>>>>>> Java,
>>>>>>>>>>                         which adds unnecessary complexity
since
>>>>>>>>>> the
>>>>>>>>>>                         batch files maintained by
the Groovy team
>>>>>>>>>>                         already have this logic.
>>>>>>>>>>                         Parameters are hard-coded
into the
>>>>>>>>>> binaries,
>>>>>>>>>>                         coupling any change in parameters
between
>>>>>>>>>> Groovy
>>>>>>>>>>                         versions to that binary.
>>>>>>>>>>                         I'm not a Windows or C++
guy, so there
>>>>>>>>>> are some
>>>>>>>>>>                         things I'd like somebody's
thoughts on:
>>>>>>>>>>                         Am I following best practices
in C++
>>>>>>>>>> source and
>>>>>>>>>>                         Makefile?
>>>>>>>>>>                         Would it be better to have
wmain()
>>>>>>>>>> instead of
>>>>>>>>>>                         main()?
>>>>>>>>>>                         Any better way to have done
resource
>>>>>>>>>> templating
>>>>>>>>>>                         other than/sed/?
>>>>>>>>>>                         Would there be a reason to
have chosen C
>>>>>>>>>> over C++?
>>>>>>>>>>                         Any non-ASCII character hangups?
>>>>>>>>>>                         Runninggroovy.exe 象.groovy
象 seemed to
>>>>>>>>>> invoke
>>>>>>>>>>                         and pass argument in fine,
but it printed
>>>>>>>>>> the
>>>>>>>>>>                         arg as a question mark. 
Although the
>>>>>>>>>> current
>>>>>>>>>>                         binaries binaries do the
same thing,
>>>>>>>>>>                         so maybe it's a limitation
of/cmd.exe/.
>>>>>>>>>>                         Does my strategy of passing
args from exe
>>>>>>>>>> to bat
>>>>>>>>>>                         have any edge cases to worry
about with
>>>>>>>>>> the use
>>>>>>>>>>                         of system() andCreateProcess()?
>>>>>>>>>>
>>>>>>>>>>                         -Keegan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>                 --
>>>>>>>>>>                 *Raviteja Lokineni* | Business Intelligence
>>>>>>>>>> Developer
>>>>>>>>>>                 TD Ameritrade
>>>>>>>>>>
>>>>>>>>>>                 E: raviteja.lokineni@gmail.com
>>>>>>>>>>                 <mailto:raviteja.lokineni@gmail.com>
>>>>>>>>>>
>>>>>>>>>>                 View Raviteja Lokineni's profile
on LinkedIn
>>>>>>>>>>                 <http://in.linkedin.com/in/ravitejalokineni>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>

Mime
View raw message