lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Irwin <pir...@feature23.com>
Subject Re: Lucene 4.0
Date Thu, 13 Jun 2013 12:39:56 GMT
Marcos,

That would be helpful. As far as I can tell, the 3.0 java code is only on
SVN here, before the lucene and solr projects were bundled together:
http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/

The SVN for 4.3 java is here:
http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_3/
And the GitHub for 4.3 java is here:
https://github.com/apache/lucene-solr/tree/lucene_solr_4_3

My fork/branch of Lucene.net for the 4.3 port is here:
https://github.com/paulirwin/lucene.net/commits/lucene_4_3_0

My fork is the "upstream" fork for my team members, and i'm remote merging
their changes in from their forks while they fetch/merge from mine to get
everyone else's changes, rather than using pull requests. James and I have
been working the past few days on the Util namespace ahead of tonight's
hackathon since that namespace is in common with the rest of the
namespaces. Tonight, we'll have at least 8 guys that I know of hacking on
porting 4.3, each with a different namespace or part of a namespace. Since
we're going class-by-class, namespace-by-namespace, the project does not
build as it is. Once we finish doing a translation of each file, then we'll
hammer out any remaining issues and get it to build again. I'm hoping that
we can get at least 75% done with Core tonight. Wish us luck!

But one thing to keep in mind is it looks like much functionality has been
moved out of core into the contrib modules, especially around analysis, for
4.0+. For example, there are no built-in analyzers in core anymore. So when
this is all done, we may want to include at least the analysis contrib
module in with the standard core NuGet package, because otherwise it's
practically useless unless you roll your own analyzer.

Paul


On Thu, Jun 13, 2013 at 1:08 AM, Marcos Lima <marcoslimagon@gmail.com>wrote:

> Hi everyone!
>
> Does someone know where can I find the 3.0.3 release from Lucene(java)?
>
> I`ll compare the following major versions: 3.03, 3.6.2 and 4.3.0 and make
> the diff between then and get all changes between releases... I gonna
> publish it here soon. (If you think there is another important release, let
> me know)
>
> Paul, are you dealing (i`m not sure about this word, sorry) with 4.3.0 port
> for .Net on github (last email)?
>
> See you,
>
>
> 2013/6/10 Paul Irwin <pirwin@feature23.com>
>
> > Thanks for the discussion points, Michael.
> >
> > I would vote for not worrying about trying to achieve portable
> > compatibility for WP8/WinRT/etc until *after* a port to 4.3+ is
> completed.
> > Otherwise it may delay the project and stall it further. That's just my
> > $0.02 based on my admittedly selfish need for 4.x features.
> >
> > I have started porting the changes from the core library (from the
> > java lucene_solr_4_3 branch) in my fork on github in a separate branch.
> > Since I need 4.3 ASAP, I am just going to keep going on my port until
> > there's changes to pull from upstream to work from. Also due to my time
> > constraints, I am not fully documenting new methods that I'm adding. But
> if
> > anyone wants to pull/copy/reference my changes while porting, that's
> > awesome. My branch currently does not build as I'm primarily going
> > class-by-class, starting with the util namespace. Once we get the ball
> > rolling on a community effort, I'll stop my rogue work and join in. But
> > hopefully my work will be useful to someone, if not as a pull request
> then
> > as a reference. I'm also going to be holding a hackathon this week with
> my
> > colleagues where we're all going to work on the port. I'm comparing files
> > and making changes as necessary, rather than starting from scratch. My
> > repo/branch is here:
> > https://github.com/paulirwin/lucene.net/tree/lucene_4_3_0
> >
> > Paul
> >
> >
> >
> >
> > On Fri, Jun 7, 2013 at 1:16 PM, mherndon michael <
> > mherndon@michaelherndon.com> wrote:
> >
> > > the guithub.com repo is a mirror to the git mirror that apache
> > maintains.
> > >
> > > The was some work at one time to move the official svn repository to
> > start
> > > using git one instead.  Was that actually finalized or not?
> > >
> > > The Lucene.Net_4e (e for experimental) is an old branch to see what
> kind
> > of
> > > work was involved using a portable libraries project. Some of it can
> > still
> > > be used but will need to be validated against the current version of
> > Java's
> > > Lucene.  It was also using .net 4.
> > >
> > > clean branch vs current.     Its going to depend on what we support. If
> > you
> > > support windows mobile 8, win RT, then the current code in trunk will
> not
> > > compile against those versions of the framework which would a
> frustrating
> > > starting point, then you couldn't even run tests, which would make
> taking
> > > patches very difficult.  Supporting those can almost mean larger gaps
> in
> > > design between Lucene.Net and its parent project.
> > >
> > > Also the  structure has changed significantly between the branches and
> > the
> > > side of the code base of Lucene 4 is bigger, uses Java 6, and seems
> > > significantly different.  That doesn't mean you can't cherry pick stuff
> > > from the other tags/branches that would still work as is.  A clean
> branch
> > > would also make it easier to get our build / tool chain in order as you
> > can
> > > then do them incrementally versus having to do all the stuff that I did
> > for
> > > the 3x branch which saps energy and desire to code.   It could also
> make
> > it
> > > easier to see which classes have been ported or not.
> > >
> > > The major downside to a clean branch is extra work it requires and the
> > > start up cost in time and energy of getting it in order, which can be
> > > daunting / intimidating and lower morale. And generally you want to use
> > > take your legacy code and refactor instead of in someways starting
> over.
> > >
> > > Are we going to port lucene 4 or 4.3 ?   If so I can do something
> similar
> > > to
> > >
> > >
> >
> https://cwiki.apache.org/LUCENENET/lucene-4x-port-progress.html#Lucene4xPortProgress-Lucene.NetCoreFolders
> > > where it tracks what needs to get ported / what has been ported.
> > >
> > > What are we going to support in the next version?
> > >
> > > Who is going to work on the next version?
> > >
> > > What would make the most sense and what would invigorate the community
> to
> > > get involved more and lower the barrier to entry?
> > >
> > > I think those are the questions that would make a lot of the decisions
> > for
> > > us so that we can get back to work on lucene.net.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Jun 6, 2013 at 10:13 PM, Marcos Lima <marcoslimagon@gmail.com
> > > >wrote:
> > >
> > > > Regarding the new branch, I'm a rookie with ASF projects...
> > > >
> > > > The https://svn.apache.org/repos/asf/lucene.net/ and
> > > > https://github.com/apache/lucene.net points to the same repository?
> > > (This
> > > > is new for me, pretty good) Which of them do you recommend (i'm used
> > with
> > > > SVN and its patterns).
> > > >
> > > > I'm checking the subversion right now.
> > > >
> > > > I can see the branches/Lucene.Net_4e. I think this is a old branch,
> i`m
> > > not
> > > > sure about its current status.
> > > >
> > > > Will we wipe the current solution from /trunk and start a new one?
> > > >
> > > > Thanks,
> > > >
> > > >
> > > >
> > > >
> > > > 2013/6/6 mherndon michael <mherndon@michaelherndon.com>
> > > >
> > > > > We may be forced to start with a clean/empty branch if people still
> > > want
> > > > to
> > > > > attempt supporting lucene.net for mobile devices, win RT, etc. The
> > are
> > > > > many
> > > > > classes that Lucene.net uses from the full framework that would not
> > be
> > > > > accessible in other versions of the .NET Framework.  It also might
> > > > require
> > > > > a design that differs even more from its parent project.
> > > > >
> > > > > It might be wise to poll what users most desire in the next version
> > > > through
> > > > > jira or user voice.
> > > > >
> > > > >
> > > > > On Thu, Jun 6, 2013 at 6:13 PM, Itamar Syn-Hershko <
> > itamar@code972.com
> > > > > >wrote:
> > > > >
> > > > > > inline
> > > > > >
> > > > > >
> > > > > > On Fri, Jun 7, 2013 at 1:09 AM, Paul Irwin <pirwin@feature23.com
> >
> > > > wrote:
> > > > > >
> > > > > > > Ah, I gotcha. Still getting used to git, I've been a TFS
guy
> for
> > so
> > > > > long
> > > > > > > :-)
> > > > > > >
> > > > > > > So to recap, the branch_3x will be used for any patches
or
> > anything
> > > > to
> > > > > > the
> > > > > > > current 3.0.3 release, while trunk is what we will branch
from
> > for
> > > 4x
> > > > > > dev.
> > > > > > > Correct?
> > > > > > >
> > > > > >
> > > > > > Yes - we can branch from it for 3.6 development if anyone will
be
> > > > > > interested in that
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Thanks for pushing the Version.cs. What's the deal with
the
> > github
> > > > > sync?
> > > > > > > Who could diagnose that?
> > > > > > >
> > > > > >
> > > > > > Not sure, Apache Infra, basically. Just use the apache repo
for
> now
> > > > while
> > > > > > we get that sorted out.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Thu, Jun 6, 2013 at 6:00 PM, Itamar Syn-Hershko <
> > > > itamar@code972.com
> > > > > > > >wrote:
> > > > > > >
> > > > > > > > Ok, haven't noticed that branch. Just use it then
for 3.x
> > > > > development.
> > > > > > > WRT
> > > > > > > > v4, yeah - just fork the repo and work on whatever
branch.
> When
> > > you
> > > > > > send
> > > > > > > us
> > > > > > > > PRs we will merge either to master or to a dedicated
repo.
> For
> > > now
> > > > it
> > > > > > > > doesn't really matter, thats the beauty of git.
> > > > > > > >
> > > > > > > > I pushed a new Version.cs file, you should see it
on the
> apache
> > > > > servers
> > > > > > > > (github sync seems to be off)
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Jun 7, 2013 at 12:44 AM, Paul Irwin <
> > > pirwin@feature23.com>
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Thanks Itamar. I can certainly start work on
4.3 version of
> > the
> > > > > > > Analysis
> > > > > > > > > namespace.
> > > > > > > > >
> > > > > > > > > Not sure the checkout command is what you intended
-- you
> > might
> > > > > have
> > > > > > > > meant
> > > > > > > > > trunk instead of master, and that would create
a new "3x"
> > > branch,
> > > > > > when
> > > > > > > > > there's already a "branch_3x" and that would
be misnamed...
> > so
> > > > > maybe
> > > > > > > > > checkout -b branch_4x trunk and start there aiming
for
> lucene
> > > > 4.3.x
> > > > > > > > > compatibility?
> > > > > > > > >
> > > > > > > > > Also, does someone with commit rights to the
upstream want
> to
> > > > > create
> > > > > > > the
> > > > > > > > > necessary Version.cs entries, so that we're not
all trying
> to
> > > > > create
> > > > > > > them
> > > > > > > > > and dealing with a merge?
> > > > > > > > >
> > > > > > > > > Paul
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Thu, Jun 6, 2013 at 5:32 PM, Itamar Syn-Hershko
<
> > > > > > itamar@code972.com
> > > > > > > > > >wrote:
> > > > > > > > >
> > > > > > > > > > Unless people here have a specific reason
to use 3.6.2 I
> > > would
> > > > > > highly
> > > > > > > > > > recommed putting all the efforts we can
towards v4
> > otherwise
> > > we
> > > > > > will
> > > > > > > > > never
> > > > > > > > > > make it...
> > > > > > > > > >
> > > > > > > > > > Fork the repo from apache servers or github
(same repo,
> > > > different
> > > > > > > > > remotes)
> > > > > > > > > > and checkout -b 3x -t origin/master , that
should work
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Fri, Jun 7, 2013 at 12:20 AM, Paul Irwin
<
> > > > > pirwin@feature23.com>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Itamar,
> > > > > > > > > > >
> > > > > > > > > > > I agree that from scratch is not the
best way to do
> it, I
> > > > just
> > > > > > > > thought
> > > > > > > > > > that
> > > > > > > > > > > was the "decision" that was made from
the discussion
> > > > previously
> > > > > > for
> > > > > > > > the
> > > > > > > > > > 4.x
> > > > > > > > > > > work. An incremental approach will
be much better.
> > > > > > > > > > >
> > > > > > > > > > > I've created a branch of the branch_3x
branch on my
> fork
> > > and
> > > > > will
> > > > > > > > begin
> > > > > > > > > > > working on bringing the Analysis namespace
up to speed
> to
> > > > > 3.6.2.
> > > > > > If
> > > > > > > > > > anyone
> > > > > > > > > > > wants to pull it or just reuse parts
once I'm done,
> have
> > at
> > > > it.
> > > > > > > > > > >
> > > > > > > > > > > If I shouldn't have branched off the
branch_3x branch,
> > > please
> > > > > let
> > > > > > > me
> > > > > > > > > know
> > > > > > > > > > > what I should have branched from (trunk?)
> > > > > > > > > > >
> > > > > > > > > > > Paul
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Jun 6, 2013 at 5:04 PM, Itamar
Syn-Hershko <
> > > > > > > > itamar@code972.com
> > > > > > > > > > > >wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Thanks Prescott for bringing this
up again :)
> > > > > > > > > > > >
> > > > > > > > > > > > Paul, the problem is no one can
really know what it
> > would
> > > > > take
> > > > > > > > until
> > > > > > > > > > they
> > > > > > > > > > > > have deep dived into the work,
and even then
> decisions
> > > > could
> > > > > > and
> > > > > > > > will
> > > > > > > > > > > > change. I will strongly advise
against starting from
> > > > scratch,
> > > > > > > > > although
> > > > > > > > > > I
> > > > > > > > > > > do
> > > > > > > > > > > > think a lot in the current structure
should change,
> but
> > > its
> > > > > > going
> > > > > > > > to
> > > > > > > > > be
> > > > > > > > > > > > much easier to change it in place,
refactoring where
> > > > needed,
> > > > > > than
> > > > > > > > > > > starting
> > > > > > > > > > > > all over again. Once we kicked
this off I personally
> > will
> > > > be
> > > > > > > happy
> > > > > > > > > with
> > > > > > > > > > > you
> > > > > > > > > > > > taking the analysis part of Lucene
and porting it,
> its
> > > > pretty
> > > > > > > much
> > > > > > > > > self
> > > > > > > > > > > > contained.
> > > > > > > > > > > > Re 3.6.2 work - you can just do
that on a fork and
> send
> > > us
> > > > > PRs,
> > > > > > > its
> > > > > > > > > > much
> > > > > > > > > > > > more straight forward than the
v4 upgrade
> > > > > > > > > > > >
> > > > > > > > > > > > Marcos, porting class by class
is the fastest way to
> do
> > > > this,
> > > > > > we
> > > > > > > > can
> > > > > > > > > > then
> > > > > > > > > > > > concentrate on .NETifying and
optimizing using .NET
> > > > > constructs.
> > > > > > > > > > > >
> > > > > > > > > > > > That said, I think the way to
go is create a branch
> out
> > > of
> > > > > the
> > > > > > > > > current
> > > > > > > > > > > git
> > > > > > > > > > > > master HEAD and label it "3.x",
and start working on
> > > master
> > > > > > > > towards a
> > > > > > > > > > 4.3
> > > > > > > > > > > > compatible version. The actual
port should be using a
> > > > process
> > > > > > > that
> > > > > > > > > > > ensures
> > > > > > > > > > > > all Java classes are ported with
their tests, and
> that
> > > > those
> > > > > > > tests
> > > > > > > > > > pass -
> > > > > > > > > > > > but I'm against committing any
Java code to our
> > > > repositories.
> > > > > > The
> > > > > > > > > > process
> > > > > > > > > > > > should probably be working on
classes in some order
> > > > > > > > (alphabetically,
> > > > > > > > > or
> > > > > > > > > > > > core classes first) and getting
each class to compile
> > > > before
> > > > > > > moving
> > > > > > > > > > > > forward. I don't mind about the
project not being
> > > > compilable
> > > > > > for
> > > > > > > a
> > > > > > > > > > month
> > > > > > > > > > > or
> > > > > > > > > > > > two.
> > > > > > > > > > > > Once this is done a process of
.NETifying and
> proofing
> > > the
> > > > > code
> > > > > > > can
> > > > > > > > > be
> > > > > > > > > > > > started, at which point we will
already have a
> working
> > v4
> > > > > > version
> > > > > > > > so
> > > > > > > > > it
> > > > > > > > > > > > will be easier to keep up with
the Java project.
> > > > > > > > > > > >
> > > > > > > > > > > > The first step IMO is to stabilize
the test suite so
> > > tests
> > > > > > could
> > > > > > > > more
> > > > > > > > > > or
> > > > > > > > > > > > less be copied and pasted (e.g.
implementing
> Java-like
> > > > > > > assertEquals
> > > > > > > > > > > methods
> > > > > > > > > > > > etc; I find xUnit to be much easier
to work with than
> > > > > NUnit). I
> > > > > > > > > already
> > > > > > > > > > > did
> > > > > > > > > > > > some work there but there's still
a lot to do.
> > > > > > > > > > > >
> > > > > > > > > > > > Unfortunately I can't dedicate
time myself at this
> > point,
> > > > > but I
> > > > > > > > > should
> > > > > > > > > > be
> > > > > > > > > > > > back in business in August, at
which point I can
> > dedicate
> > > > > > several
> > > > > > > > > > hours a
> > > > > > > > > > > > week. Until then I'll be happy
to watch closely and
> > even
> > > > > > > coordinate
> > > > > > > > > the
> > > > > > > > > > > > work to some extent.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Thu, Jun 6, 2013 at 10:41 PM,
Marcos Lima <
> > > > > > > > > marcoslimagon@gmail.com
> > > > > > > > > > > > >wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > It really sounds good to
me, this is a kick start
> > =). I
> > > > > > haven't
> > > > > > > > > > > > contributed
> > > > > > > > > > > > > anything
> > > > > > > > > > > > > yet, but I would like to
help you all to get this
> job
> > > > done.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'm completely agree with
Paul and Prescott.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I know that there is a high
commitment for keep the
> > > > > > > > > > retrocompatibility
> > > > > > > > > > > on
> > > > > > > > > > > > > Lucene. Does Java Lucene
API gets big changes every
> > > > > release?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Is the Lucene.Net a port
from a stable version
> from a
> > > > > Lucene
> > > > > > > > > version,
> > > > > > > > > > > > > right? If the Lucene API
gets only minor changes
> > every
> > > > > stable
> > > > > > > > > release
> > > > > > > > > > > (or
> > > > > > > > > > > > > keep most of its source-code),
we could compare the
> > > > > versions,
> > > > > > > > check
> > > > > > > > > > the
> > > > > > > > > > > > > differences and bring them
to Lucene.Net. Again, I
> > > > haven't
> > > > > > > > > > contributed
> > > > > > > > > > > > with
> > > > > > > > > > > > > yet, so I don't know how
it is (just an idea).
> > > > > > > > > > > > >
> > > > > > > > > > > > > What's your approach for
implement simple
> performance
> > > > > > > > improvements
> > > > > > > > > > > > (without
> > > > > > > > > > > > > adding references or changing
methods signatures)?
> > Does
> > > > it
> > > > > > > could
> > > > > > > > be
> > > > > > > > > > > done,
> > > > > > > > > > > > > or "follow the java version
only"?
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 2013/6/6 Paul Irwin <pirwin@feature23.com>
> > > > > > > > > > > > >
> > > > > > > > > > > > > > This is just an "outsider"
suggestion as I
> haven't
> > > > > > > contributed
> > > > > > > > > > > anything
> > > > > > > > > > > > > > yet, although I will
definitely help with the 4.x
> > > work
> > > > > as I
> > > > > > > > have
> > > > > > > > > a
> > > > > > > > > > > > vested
> > > > > > > > > > > > > > interest in seeing that
get completed. I think
> > there
> > > > > should
> > > > > > > be
> > > > > > > > > one
> > > > > > > > > > > > person
> > > > > > > > > > > > > > (or perhaps two) guiding
what the structure and
> > > > workflow
> > > > > > will
> > > > > > > > > look
> > > > > > > > > > > like
> > > > > > > > > > > > > to
> > > > > > > > > > > > > > avoid chaos. If the
4.x work is going to be
> > starting
> > > > from
> > > > > > > > scratch
> > > > > > > > > > as
> > > > > > > > > > > a
> > > > > > > > > > > > > > fresh port, that person
should set up the
> project,
> > > get
> > > > > > > > everything
> > > > > > > > > > > going
> > > > > > > > > > > > > in
> > > > > > > > > > > > > > source control, create
the folder structure,
> maybe
> > > stub
> > > > > out
> > > > > > > > some
> > > > > > > > > > > > classes,
> > > > > > > > > > > > > > etc. Then divide and
conquer with anyone
> interested
> > > in
> > > > > > > > > > contributing,
> > > > > > > > > > > > > > perhaps by namespace.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I like the idea of throwing
the java code in
> there
> > so
> > > > > it's
> > > > > > > easy
> > > > > > > > > to
> > > > > > > > > > > > > > reference.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Again, I can work on
Lucene.Net.Documents,
> > > > > > > Lucene.Net.Analysis,
> > > > > > > > > or
> > > > > > > > > > > > > > Lucene.Net.Store --
or any others, those are just
> > the
> > > > > ones
> > > > > > > I'm
> > > > > > > > > most
> > > > > > > > > > > > > > familiar with the inner
workings. Tell me what to
> > do
> > > > and
> > > > > > I'll
> > > > > > > > get
> > > > > > > > > > > > started
> > > > > > > > > > > > > > on my fork.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Paul Irwin
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Thu, Jun 6, 2013
at 2:38 PM, Prescott Nasser <
> > > > > > > > > > > geobmx540@hotmail.com
> > > > > > > > > > > > > > >wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hey guys -
> > > > > > > > > > > > > > > I know I've been
MIA a little while. We have a
> > > board
> > > > > > report
> > > > > > > > due
> > > > > > > > > > > soon
> > > > > > > > > > > > -
> > > > > > > > > > > > > I
> > > > > > > > > > > > > > > think it prudent
that we advise them that we
> seem
> > > to
> > > > > have
> > > > > > > > > stalled
> > > > > > > > > > > > > > somewhat.
> > > > > > > > > > > > > > > We've got a few
low hanging items out of of
> jira
> > > and
> > > > > have
> > > > > > > > been
> > > > > > > > > > > > > responsive
> > > > > > > > > > > > > > > on the mailing
list to community questions,
> but I
> > > > don't
> > > > > > > think
> > > > > > > > > > we've
> > > > > > > > > > > > > done
> > > > > > > > > > > > > > > anything to move
forward with 4.0.
> > > > > > > > > > > > > > > To that end - I'd
like to *try* and start us
> back
> > > up
> > > > > > moving
> > > > > > > > > > > forward.
> > > > > > > > > > > > > What
> > > > > > > > > > > > > > > is the best way
to accomplish this? If we took
> > the
> > > > java
> > > > > > > > lucene
> > > > > > > > > > 4.0
> > > > > > > > > > > > code
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > committed that
java to our branch and then just
> > let
> > > > > > people
> > > > > > > > pull
> > > > > > > > > > > that
> > > > > > > > > > > > > down
> > > > > > > > > > > > > > > and being changing
/ modifying is that one way
> to
> > > > maybe
> > > > > > > make
> > > > > > > > > some
> > > > > > > > > > > > > forward
> > > > > > > > > > > > > > > progress?
> > > > > > > > > > > > > > > ~P
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Marcos Lima
> > > > > > > > > > > > > Software Developer/Tech Lead
> > > > > > > > > > > > > marcoslimagon@gmail.com
> > > > > > > > > > > > > tel: +55 (19) 9798-9335
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > --
> > > > Marcos Lima
> > > > Software Developer/Tech Lead
> > > > marcoslimagon@gmail.com
> > > > tel: +55 (19) 9798-9335
> > > >
> > >
> >
>
>
>
> --
> --
> Marcos Lima
> Software Developer/Tech Lead
> marcoslimagon@gmail.com
> tel: +55 (19) 9798-9335
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message