Re: Proposed New Structure (starter for 10)

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

------------------------------------------------------------------------------