Re: Proposed New Structure (starter for 10)
Troy Daniels <[email protected]> Mon, 26 Oct 2015 22:31:06 -0400
| Newsgroups | gmane.emacs.jdee.devel |
|---|---|
| Message-ID | <CALSS3zMTot2eTph+83Cr20LJdDpd_puLQUgLNToK=y_wuPTPfw@mail.gmail.com> |
--===============0754930525049628110== Content-Type: multipart/alternative; boundary=001a113de12ad89ce905230cdfeb --001a113de12ad89ce905230cdfeb Content-Type: text/plain; charset=UTF-8 We also need to know about the classpath, so we can do completion and imports. Although tying in the classpath is the main focus of what I am doing at the moment. Troy On Mon, Oct 26, 2015 at 12:43 PM, Phillip Lord <[email protected]> wrote: > > Yes, if I wanted to make a standalone jar, that's how I'd do it. For use > within ant or from a shell-script/batch this would be a good way to go. > For projects already using maven, then I'd leave it as. > > For me, at the moment, though, this is not an issue. My code is not > maven-centric, it's just where I have started. Support other mechanisms > of launch I do not think is hard. > > As I have said, the issue comes when we need to know about stuff > the project knows about, but the JVM doesn't -- source paths being the > obvious one. Are there many other settings like this? At the moment, I > don't know for sure, but nothing leaps to mind. > > > > > Paul Landes <[email protected]> writes: > > > If we're tightly coupling with clojure we _could_ also make it a > leiningen > > project, bake in the repl (add deps and API call in main) and compile an > AOT > > uberjar. > > > > > > On Oct 26, 2015, at 6:56 AM, Phillip Lord <[email protected]> > wrote: > > > >> > >> > >> It's worth noting that the only thing I am using maven for is pulling in > >> the clojure dependencies and launch the JVM with the appropriate project > >> settings. > >> > >> Getting another build tool to do the same thing would be > >> straight-forward enough. Even a shell script would work with a prebuilt > >> jar (of clojure and the nrepl server). The current code is not really > >> maven-centric. I just happen to have used maven. > >> > >> Phil > >> > >> Paul Landes <[email protected]> writes: > >> > >>> I agree with Phillip writes and add that supporting two back ends at > >>> this point would be burdensome. > >>> > >>> For those that dislike maven there isn't any reason some template > config (pom) > >>> file couldn't be used in a temp directory (or even memory). Either way > it > >>> would be pretty small since at best you'd only be (re)configuring the > >>> source/build/test paths. > >>> > >>> > >>> On Oct 23, 2015, at 4:00 AM, Phillip Lord <[email protected]> > wrote: > >>> > >>>> Troy Daniels <[email protected]> writes: > >>>> > >>>>> I checked out the clojure backend branch last night and played > around with > >>>>> it some. I had some trouble getting it to build, but eventually > solved > >>>>> those problems. I submitted a pull request with the changes I made, > if you > >>>>> want to incorporate them. > >>>> > >>>> Bit spammed at the moment, but will do this. I tend not to use melpa > >>>> but melpa stable, though, so there many be some version issues. > >>>> > >>>> > >>>>> I'd like to start integrating this into the main code base. > >>>>> > >>>>> I did have an idea for transition as well. The code that Phillip > wrote is > >>>>> maven-centric, and will not work without additional effort in a > project > >>>>> with an ant build, or various other build tools. So my idea was to > use the > >>>>> nrepl if we can find a pom file, but otherwise fall back to the > existing > >>>>> code. This also means that functionality can be converted piecemeal. > >>>> > >>>> This sounds reasonable, but I would say that maintaining two backends > is > >>>> going to be a pain. I've tried in my code to separate out the > >>>> "maven-centric" and "everything else" part. This is why "jde-nrepl" is > >>>> in a different package. > >>>> > >>>> Ultimately, I think a decision needs to be made. If this is the root > we > >>>> go, then I would say it should be on the basis that we move > >>>> functionality out of the existing setup and into the clojure based on. > >>>> > >>>> An alternative transition path would be to run beanshell from inside > the > >>>> clojure middleware. Not thought that through, but maybe it would work. > >>>> > >>>> > >>>>> For example, there is a cider function to get the classpath, so > >>>>> replacing jdee-*-classpath is fairly simple. Replacing the import and > >>>>> completion functionality is more complicated, so would take longer to > >>>>> replace. > >>>> > >>>> One issue I have is whether to run nrepl in the project environment or > >>>> the maven environment. Unfortunately this makes a difference -- maven, > >>>> for example, knows about source locations while the project does not > (it > >>>> only needs the classpath). > >>>> > >>>> > >>>>> Phillips branch also has three (non-test) projects in a single > repository: > >>>>> java, lisp and clojure. I think this makes sense for several > reasons. It > >>>>> makes it obvious which version of the java code works with which > version of > >>>>> the lisp code. It also makes it simple to package the jars and > clojure > >>>>> with the lisp code to put on MELPA. It would be good to have > something > >>>>> better than the current top level build script, which is just a shell > >>>>> script. > >>>> > >>>> Actually, there's a bunch of make files in there which work pretty > well. > >>>> > >>>> > >>>>> Does this all make sense? > >>>> > >>>> It does. > >>>> > >>>> Phil > >>>> > >>>> > ------------------------------------------------------------------------------ > >>>> _______________________________________________ > >>>> jdee-devel mailing list > >>>> [email protected] > >>>> https://lists.sourceforge.net/lists/listinfo/jdee-devel > --001a113de12ad89ce905230cdfeb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">We also need to know about the classpath, so we can do com= pletion and imports.=C2=A0 Although tying in the classpath is the main focu= s of what I am doing at the moment. =C2=A0<div>Troy</div></div><div class= =3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Oct 26, 2015 at 12:= 43 PM, Phillip Lord <span dir=3D"ltr"><<a href=3D"mailto:phillip.lord@ru= sset.org.uk" target=3D"_blank">[email protected]</a>></span> wr= ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border= -left:1px #ccc solid;padding-left:1ex"><br> Yes, if I wanted to make a standalone jar, that's how I'd do it. Fo= r use<br> within ant or from a shell-script/batch this would be a good way to go.<br> For projects already using maven, then I'd leave it as.<br> <br> For me, at the moment, though, this is not an issue. My code is not<br> maven-centric, it's just where I have started. Support other mechanisms= <br> of launch I do not think is hard.<br> <br> As I have said, the issue comes when we need to know about stuff<br> the project knows about, but the JVM doesn't -- source paths being the<= br> obvious one. Are there many other settings like this? At the moment, I<br> don't know for sure, but nothing leaps to mind.<br> <div class=3D"HOEnZb"><div class=3D"h5"><br> <br> <br> <br> Paul Landes <<a href=3D"mailto:[email protected]">[email protected]</a>>= ; writes:<br> <br> > If we're tightly coupling with clojure we _could_ also make it a l= einingen<br> > project, bake in the repl (add deps and API call in main) and compile = an AOT<br> > uberjar.<br> ><br> ><br> > On Oct 26, 2015, at 6:56 AM, Phillip Lord <<a href=3D"mailto:philli= [email protected]">[email protected]</a>> wrote:<br> ><br> >><br> >><br> >> It's worth noting that the only thing I am using maven for is = pulling in<br> >> the clojure dependencies and launch the JVM with the appropriate p= roject<br> >> settings.<br> >><br> >> Getting another build tool to do the same thing would be<br> >> straight-forward enough. Even a shell script would work with a pre= built<br> >> jar (of clojure and the nrepl server). The current code is not rea= lly<br> >> maven-centric. I just happen to have used maven.<br> >><br> >> Phil<br> >><br> >> Paul Landes <<a href=3D"mailto:[email protected]">[email protected]= et</a>> writes:<br> >><br> >>> I agree with Phillip writes and add that supporting two back e= nds at<br> >>> this point would be burdensome.<br> >>><br> >>> For those that dislike maven there isn't any reason some t= emplate config (pom)<br> >>> file couldn't be used in a temp directory (or even memory)= . Either way it<br> >>> would be pretty small since at best you'd only be (re)conf= iguring the<br> >>> source/build/test paths.<br> >>><br> >>><br> >>> On Oct 23, 2015, at 4:00 AM, Phillip Lord <<a href=3D"mailt= o:[email protected]">[email protected]</a>> wrote:<br> >>><br> >>>> Troy Daniels <<a href=3D"mailto:udalrich.schermer@gmail= .com">[email protected]</a>> writes:<br> >>>><br> >>>>> I checked out the clojure backend branch last night an= d played around with<br> >>>>> it some.=C2=A0 I had some trouble getting it to build,= but eventually solved<br> >>>>> those problems.=C2=A0 I submitted a pull request with = the changes I made, if you<br> >>>>> want to incorporate them.<br> >>>><br> >>>> Bit spammed at the moment, but will do this. I tend not to= use melpa<br> >>>> but melpa stable, though, so there many be some version is= sues.<br> >>>><br> >>>><br> >>>>> I'd like to start integrating this into the main c= ode base.<br> >>>>><br> >>>>> I did have an idea for transition as well.=C2=A0 The c= ode that Phillip wrote is<br> >>>>> maven-centric, and will not work without additional ef= fort in a project<br> >>>>> with an ant build, or various other build tools.=C2=A0= So my idea was to use the<br> >>>>> nrepl if we can find a pom file, but otherwise fall ba= ck to the existing<br> >>>>> code.=C2=A0 This also means that functionality can be = converted piecemeal.<br> >>>><br> >>>> This sounds reasonable, but I would say that maintaining t= wo backends is<br> >>>> going to be a pain. I've tried in my code to separate = out the<br> >>>> "maven-centric" and "everything else" = part. This is why "jde-nrepl" is<br> >>>> in a different package.<br> >>>><br> >>>> Ultimately, I think a decision needs to be made. If this i= s the root we<br> >>>> go, then I would say it should be on the basis that we mov= e<br> >>>> functionality out of the existing setup and into the cloju= re based on.<br> >>>><br> >>>> An alternative transition path would be to run beanshell f= rom inside the<br> >>>> clojure middleware. Not thought that through, but maybe it= would work.<br> >>>><br> >>>><br> >>>>> For example, there is a cider function to get the clas= spath, so<br> >>>>> replacing jdee-*-classpath is fairly simple. Replacing= the import and<br> >>>>> completion functionality is more complicated, so would= take longer to<br> >>>>> replace.<br> >>>><br> >>>> One issue I have is whether to run nrepl in the project en= vironment or<br> >>>> the maven environment. Unfortunately this makes a differen= ce -- maven,<br> >>>> for example, knows about source locations while the projec= t does not (it<br> >>>> only needs the classpath).<br> >>>><br> >>>><br> >>>>> Phillips branch also has three (non-test) projects in = a single repository:<br> >>>>> java, lisp and clojure.=C2=A0 I think this makes sense= for several reasons.=C2=A0 It<br> >>>>> makes it obvious which version of the java code works = with which version of<br> >>>>> the lisp code.=C2=A0 It also makes it simple to packag= e the jars and clojure<br> >>>>> with the lisp code to put on MELPA.=C2=A0 It would be = good to have something<br> >>>>> better than the current top level build script, which = is just a shell<br> >>>>> script.<br> >>>><br> >>>> Actually, there's a bunch of make files in there which= work pretty well.<br> >>>><br> >>>><br> >>>>> Does this all make sense?<br> >>>><br> >>>> It does.<br> >>>><br> >>>> Phil<br> >>>><br> >>>> ----------------------------------------------------------= --------------------<br> >>>> _______________________________________________<br> >>>> jdee-devel mailing list<br> >>>> <a href=3D"mailto:[email protected]">jdee-d= [email protected]</a><br> >>>> <a href=3D"https://lists.sourceforge.net/lists/listinfo/jd= ee-devel" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.ne= t/lists/listinfo/jdee-devel</a><br> </div></div></blockquote></div><br></div> --001a113de12ad89ce905230cdfeb-- --===============0754930525049628110== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ --===============0754930525049628110== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ jdee-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jdee-devel --===============0754930525049628110==--