I am looking for a build tool that fulfills the following requirements:
1) Must handle Clojure namespaces that are AOT-compiled. 2) Must handle Clojure namespaces that are not AOT-compiled. 3) Must handle Java source code files. 4) Must handle dependencies in the form of on-disk jar files (not in any repository) 5) No XML configuration files.
Candidates that I have tried and found insufficient include - Leiningen (no dependencies without repositories) - Cake (doesn't handle Java source files) - Eclipse/Counterclockwise (doesn't handle AOT compilation) - ant, maven: XML configuration files - scons: incomplete Java support, no Clojure support
On Sun, Jul 3, 2011 at 21:57, Konrad Hinsen <konrad.hin...@fastmail.net> wrote: > I am looking for a build tool that fulfills the following requirements:
> 1) Must handle Clojure namespaces that are AOT-compiled. > 2) Must handle Clojure namespaces that are not AOT-compiled. > 3) Must handle Java source code files. > 4) Must handle dependencies in the form of on-disk jar files (not in any > repository) > 5) No XML configuration files.
> Candidates that I have tried and found insufficient include > - Leiningen (no dependencies without repositories) > - Cake (doesn't handle Java source files) > - Eclipse/Counterclockwise (doesn't handle AOT compilation) > - ant, maven: XML configuration files > - scons: incomplete Java support, no Clojure support
> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en
> On Sun, Jul 3, 2011 at 21:57, Konrad Hinsen <konrad.hin...@fastmail.net> wrote: >> I am looking for a build tool that fulfills the following requirements:
>> 1) Must handle Clojure namespaces that are AOT-compiled. >> 2) Must handle Clojure namespaces that are not AOT-compiled. >> 3) Must handle Java source code files. >> 4) Must handle dependencies in the form of on-disk jar files (not in any >> repository) >> 5) No XML configuration files.
>> Candidates that I have tried and found insufficient include >> - Leiningen (no dependencies without repositories) >> - Cake (doesn't handle Java source files) >> - Eclipse/Counterclockwise (doesn't handle AOT compilation) >> - ant, maven: XML configuration files >> - scons: incomplete Java support, no Clojure support
> Speaking for zero actual experience: > Have you tried Gradle? > http://www.gradle.org/
Speaking with a bit of experience: gradle has a check for all of your points, although clojuresque doesn't handle mixed 1) and 2) points. At the moment it's either or. Since you are screwed anyway when you have to use AOT-compilation. But I'm open for arguments why one would want to mix points 1) and 2).
Konrad Hinsen <konrad.hin...@fastmail.net> writes: > I am looking for a build tool that fulfills the following requirements: > 4) Must handle dependencies in the form of on-disk jar files (not in > any repository)
For the record, leiningen can do this by adding a repository with a file:/// URL; it's just not documented because I think it's a bad idea.
<konrad.hin...@fastmail.net> wrote: > I am looking for a build tool that fulfills the following requirements:
> 1) Must handle Clojure namespaces that are AOT-compiled. > 2) Must handle Clojure namespaces that are not AOT-compiled. > 3) Must handle Java source code files. > 4) Must handle dependencies in the form of on-disk jar files (not in any > repository) > 5) No XML configuration files.
> Candidates that I have tried and found insufficient include > - Leiningen (no dependencies without repositories) > - Cake (doesn't handle Java source files) > - Eclipse/Counterclockwise (doesn't handle AOT compilation) > - ant, maven: XML configuration files > - scons: incomplete Java support, no Clojure support
> Is there anything else worth trying?
> Thanks in advance, > Konrad.
> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your > first post. > To unsubscribe from this group, send email to > clojure+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en
Cake can indeed handle Java source files. Throw them in src/jvm, I believe. Leiningen and cake can both handle on-disk jar files, but (at least in cakes case) they need to be installed in the local repository.
On Sun, Jul 3, 2011 at 6:06 PM, Phil Hagelberg <p...@hagelb.org> wrote: > Konrad Hinsen <konrad.hin...@fastmail.net> writes:
>> I am looking for a build tool that fulfills the following requirements:
>> 4) Must handle dependencies in the form of on-disk jar files (not in >> any repository)
> For the record, leiningen can do this by adding a repository with a > file:/// URL; it's just not documented because I think it's a bad idea.
Why?
One pillar of Clojure philosophy is to get out of the way and let programmers get the job done, with a minimum of fuss and ceremony. Unlike Java.
Requiring any project that has dependencies, even if these are only other local projects, have a repository adds gratuitous ceremony.
And this is especially true if the user has little or no prior experience setting up and working with repositories, as they grow their programming skillset. Ordinarily, they would gradually progress from single-file projects to multi-file projects to projects with common, locally-installed third-party libraries and/or other local projects as dependencies, and eventually to projects that use and are hosted on repositories of some sort. Your "I think it's a bad idea" amounts to thinking that forcing the third and fourth steps in that progression to be combined into one single giant leap is a *good* idea, and I'm rather dubious of any such claim. One new source of complexity should be mastered at a time, in my view, absent a *very* good reason, and repositories are definitely a humongous source of complexity, so an especially strong case can be made that that *particular* new source of complexity should be tackled separately from any other.
(Just consider: starting out using repositories requires mastering a whole new client/server app type on a par with email, newsgroups, ftp, and the web; then there's all these different hosting alternatives -- maven, github, sourceforge, google code, etc. and sometimes software of the same name or closely related like maven and git, as well as other software like rcs, cvs, and svn; then there's the associated terminology: commits, pull requests, push requesus, branches, masters, forks, checkouts and checkins, and so forth, not all of them applicable to each individual variation on the theme; then there's individual projects' often-partly-unwritten rules regarding forking, commit access, pull/push requests, and what-have-you; and setting up a local repository of one's own means installing a server, securing it, installing a client, learning how to use it, and so on and so forth.
Indeed, a lot of people will never before have installed and secured a server of any kind in their entire lives, I expect; that itself is something whose learning I think should probably be tackled separately, but if you haven't already done something like run your own listserv or web server (not just site, you own httpd process which if hacked means your own computer is violated), then starting to use local version control means tackling that at the same time as a load of other new and moderately complex things. To which your recommendation adds a third group of complicated new things. So, it's not even two *steps* combining into one giant leap; it's a step followed by an already-fairly-large *leap* combining into one *ridiculous* leap.)
-- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age.
The other option is Polyglot Maven, which hasn't really seen much movement lately, but gives you maven power without the XML ( clojure source, yaml, etc. )
I'm not sure what the current state is in, and I think since I last committed to it the clojure support has been updated/rewritten ( I believe the wiki docs are out of date now as well ).
-- "Great artists are extremely selfish and arrogant things" Steven Wilson, Porcupine Tree
On Mon, Jul 4, 2011 at 7:57 AM, Konrad Hinsen <konrad.hin...@fastmail.net>wrote:
On Jul 4, 10:16 am, Ken Wesson <kwess...@gmail.com> wrote:
> Requiring any project that has dependencies, even if these are only
> other local projects, have a repository adds gratuitous ceremony.
I don't know what it is like with leiningen, but with maven a
"repository" doesn't necessarily mean you're running a client/server
app on a machine - there's a directory (~/.m2/repository) on your
machine that maven checks for artifacts that is considered a local
repository. When you run "mvn install" they get added to this
directory and then your other projects can depend on them.
So if you've already made the leap to using maven with one project,
using it for another is not a big deal.
On Sun, Jul 3, 2011 at 9:51 PM, Steve <stephen.a.lind...@gmail.com> wrote: > On Jul 4, 10:16 am, Ken Wesson <kwess...@gmail.com> wrote:
>> Requiring any project that has dependencies, even if these are only >> other local projects, have a repository adds gratuitous ceremony.
> I don't know what it is like with leiningen, but with maven a > "repository" doesn't necessarily mean you're running a client/server > app on a machine - there's a directory (~/.m2/repository) on your > machine that maven checks for artifacts that is considered a local > repository. When you run "mvn install" they get added to this > directory and then your other projects can depend on them.
> So if you've already made the leap to using maven with one project, > using it for another is not a big deal.
OK...ridiculous leap reduced to merely huge leap then, if you only have to learn 2 of these three things at once: big, interdependent groups of projects, maven/etc. repository-accessing tools, and server administration. :)
-- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age.
> On Sun, Jul 3, 2011 at 6:06 PM, Phil Hagelberg <p...@hagelb.org> wrote: >> Konrad Hinsen <konrad.hin...@fastmail.net> writes:
>>> I am looking for a build tool that fulfills the following requirements:
>>> 4) Must handle dependencies in the form of on-disk jar files (not in >>> any repository)
>> For the record, leiningen can do this by adding a repository with a >> file:/// URL; it's just not documented because I think it's a bad idea.
> Why?
> One pillar of Clojure philosophy is to get out of the way and let > programmers get the job done, with a minimum of fuss and ceremony. > Unlike Java.
> Requiring any project that has dependencies, even if these are only > other local projects, have a repository adds gratuitous ceremony.
> And this is especially true if the user has little or no prior > experience setting up and working with repositories, as they grow > their programming skillset. Ordinarily, they would gradually progress > from single-file projects to multi-file projects to projects with > common, locally-installed third-party libraries and/or other local > projects as dependencies, and eventually to projects that use and are > hosted on repositories of some sort. Your "I think it's a bad idea" > amounts to thinking that forcing the third and fourth steps in that > progression to be combined into one single giant leap is a *good* > idea, and I'm rather dubious of any such claim. One new source of > complexity should be mastered at a time, in my view, absent a *very* > good reason, and repositories are definitely a humongous source of > complexity, so an especially strong case can be made that that > *particular* new source of complexity should be tackled separately > from any other.
> (Just consider: starting out using repositories requires mastering a > whole new client/server app type on a par with email, newsgroups, ftp, > and the web; then there's all these different hosting alternatives -- > maven, github, sourceforge, google code, etc. and sometimes software > of the same name or closely related like maven and git, as well as > other software like rcs, cvs, and svn; then there's the associated > terminology: commits, pull requests, push requesus, branches, masters, > forks, checkouts and checkins, and so forth, not all of them > applicable to each individual variation on the theme; then there's > individual projects' often-partly-unwritten rules regarding forking, > commit access, pull/push requests, and what-have-you; and setting up a > local repository of one's own means installing a server, securing it, > installing a client, learning how to use it, and so on and so forth.
> Indeed, a lot of people will never before have installed and secured a > server of any kind in their entire lives, I expect; that itself is > something whose learning I think should probably be tackled > separately, but if you haven't already done something like run your > own listserv or web server (not just site, you own httpd process which > if hacked means your own computer is violated), then starting to use > local version control means tackling that at the same time as a load > of other new and moderately complex things. To which your > recommendation adds a third group of complicated new things. So, it's > not even two *steps* combining into one giant leap; it's a step > followed by an already-fairly-large *leap* combining into one > *ridiculous* leap.)
> -- > Protege: What is this seething mass of parentheses?! > Master: Your father's Lisp REPL. This is the language of a true > hacker. Not as clumsy or random as C++; a language for a more > civilized age.
> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with your first post. > To unsubscribe from this group, send email to > clojure+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en
On Sun, Jul 3, 2011 at 10:27 PM, Phil Hagelberg <p...@hagelb.org> wrote: > Encouraging "works on my machine" builds is by definition antithetical to > the very idea of build automation. Leiningen is not a "yes tool".
That presupposes that nobody will ever use leiningen for any case that's intermediate between, or orthogonal to, "personal project, single file, no unusual deps, just load in REPL in IDE and use" and "publicly visible large open source project with many deps that everyone and his great-aunt should be able to build". For example, "personal project, many files and local/third party deps" is not covered and neither is "closed-source project for small-to-medium-sized company without own version control server". For the former, and arguably the latter, anything involving the word "repository" in any way shape or form strikes me as potentially-unnecessary ceremony. (Larger businesses will presumably have in-house version control and keep proprietary code bases in a repository, so there's no issue there. Also, larger businesses can generally just buy their way out of any problem, inconvenience, or excess of ceremony by hiring an extra person or two to deal with it. :) Meanwhile, large FOSS projects all seem these days to have public version control repositories, either freely provided by sites like github and sourceforge or, in the most high profile and especially business-backed cases, their very own server farms with project web sites and repository.)
-- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age.
> I am looking for a build tool that fulfills the following requirements:
> 1) Must handle Clojure namespaces that are AOT-compiled.
> 2) Must handle Clojure namespaces that are not AOT-compiled.
> 3) Must handle Java source code files.
> 4) Must handle dependencies in the form of on-disk jar files (not in
> any repository)
> 5) No XML configuration files.
> Candidates that I have tried and found insufficient include
> - Leiningen (no dependencies without repositories)
> - Cake (doesn't handle Java source files)
> - Eclipse/Counterclockwise (doesn't handle AOT compilation)
> - ant, maven: XML configuration files
> - scons: incomplete Java support, no Clojure support
> Is there anything else worth trying?
Maven works, but if you don't want XML why not just use Leiningen?
Split your code base into various modules (each module having its own
project.clj) and have a shell script (or PowerShell script if you're
on Windows) to take care of the dependencies while building across
modules.
For example, take this use-case of modules A, B, C and D:
function mod {
cd $p_home/modules/$1 # arg is module dir
lein deps && lein jar && lein install
}
# To build A (all)
mod "C" && mod "B" && mod "D" && mod "A"
--------------------------------
If AOT gives you trouble, factor those source files out into a
dependency module and so on. IMHO this approach gives much more
flexibility than any constrained multi-module feature of a build tool.
On Mon, Jul 4, 2011 at 1:16 AM, Shantanu Kumar <kumar.shant...@gmail.com> wrote:
> On Jul 4, 12:57 am, Konrad Hinsen <konrad.hin...@fastmail.net> wrote: >> I am looking for a build tool that fulfills the following requirements:
>> 1) Must handle Clojure namespaces that are AOT-compiled. >> 2) Must handle Clojure namespaces that are not AOT-compiled. >> 3) Must handle Java source code files. >> 4) Must handle dependencies in the form of on-disk jar files (not in >> any repository) >> 5) No XML configuration files.
>> Candidates that I have tried and found insufficient include >> - Leiningen (no dependencies without repositories) >> - Cake (doesn't handle Java source files) >> - Eclipse/Counterclockwise (doesn't handle AOT compilation) >> - ant, maven: XML configuration files >> - scons: incomplete Java support, no Clojure support
>> Is there anything else worth trying?
> Maven works, but if you don't want XML why not just use Leiningen? > Split your code base into various modules (each module having its own > project.clj) and have a shell script (or PowerShell script if you're > on Windows) to take care of the dependencies while building across > modules.
> For example, take this use-case of modules A, B, C and D:
> A --> B --> C > `-> D
> (A depends on B and D, B depends on C)
> Write a shell script ...
And this is how leiningen making users jump through hoops to do fairly simple builds with local dependencies *itself* can encourage "works on my machine" builds. :) Which is preferable from that stand point, after all: a leiningen build script or lots of idiosyncratic shell scripts?
-- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age.
Ken Wesson <kwess...@gmail.com> writes: >> For example, take this use-case of modules A, B, C and D:
>> A --> B --> C >> `-> D
>> (A depends on B and D, B depends on C)
>> Write a shell script ...
> And this is how leiningen making users jump through hoops to do fairly > simple builds with local dependencies *itself* can encourage "works on > my machine" builds. :) Which is preferable from that stand point, > after all: a leiningen build script or lots of idiosyncratic shell > scripts?
Implementation of projects-in-dir left as an exercise for the reader. Shouldn't be more than four lines. Push the lein-subs plugin to clojars: problem solved in a repeatable, maintainable way.
> I am looking for a build tool that fulfills the following > requirements:
> 1) Must handle Clojure namespaces that are AOT-compiled. > 2) Must handle Clojure namespaces that are not AOT-compiled. > 3) Must handle Java source code files. > 4) Must handle dependencies in the form of on-disk jar files (not in > any repository) > 5) No XML configuration files.
Thanks for everyone's suggestions and comments!
Some remarks:
Gradle/clojuresque: I never tried them, but it looks like I should!
AOT compilation: My case is probably a bit complex in this respect. I need AOT compilation only because I want to produce an executable jar, so there is at least one namespace that must be AOT compiled. For building that executable jar, it doesn't matter if everything else is AOT compiled as well. But I want to be able to build a standard library jar with just the Clojure code to make sure it works with future Clojure releases. One solution would be to have two completely different builds, one for the executable jar and one for the library version, but using the same set of source code files.
On 4 Jul 2011, at 00:06, Phil Hagelberg wrote:
>> 4) Must handle dependencies in the form of on-disk jar files (not in >> any repository)
> For the record, leiningen can do this by adding a repository with a > file:/// URL; it's just not documented because I think it's a bad > idea.
With absolute filenames in a URL, it's indeed a bad idea because the project becomes specific to a machine/installation. What I'd like to see instead is a project-local repository, e.g. a "deps" folder with jar files and source code directories.
There are several reasons why I want dependencies outside of repositories:
1) Simplicity. I want to distribute a single tar file to collaborators (who are new to Clojure and the JVM world) containing all dependencies and build scripts. I want to tell them "install <name of build tool>, take this file, play with the source code, and just type <build- command> to build an executable". They will struggle with a new language and a new environment already, there's no need to add the complexities of repositories. To make it worse, we all live behind proxies that require messy configuration for tools like Maven.
2) Network independence. I often work without Internet access, and I don't want to be blocked at some point because some build tool wants to access some repository to see if my version is still current.
3) Confidentiality. Sometimes I work with unpublished code that I promised not to give to anyone else. I can't keep that promise if the code leaves my machine in any way. For that case, the file:/// repository would of course be fine.
> On 4 Jul 2011, at 01:30, Anthony Grimes wrote:
>> Cake can indeed handle Java source files. Throw them in src/jvm, I >> believe. Leiningen and cake can both handle on-disk jar files, but >> (at least in cakes case) they need to be installed in the local >> repository.
Having used cake in the past for simpler projects, I know that it can handle project-local dependencies. Just add a classpath setting to .cake/config (I'd have to look up the exact name of that variable). If cake can indeed handle Java code, then it might be just fine for my needs.
On 4 Jul 2011, at 03:29, Mark Derricutt wrote:
> The other option is Polyglot Maven, which hasn't really seen much > movement lately, but gives you maven power without the XML ( clojure > source, yaml, etc. )
Being Maven, this would still require repositories, right? Even a local Maven repository is more than I'd like to impose on my collaborators.
On 4 Jul 2011, at 07:16, Shantanu Kumar wrote:
> Maven works, but if you don't want XML why not just use Leiningen? > Split your code base into various modules (each module having its own > project.clj) and have a shell script (or PowerShell script if you're > on Windows) to take care of the dependencies while building across > modules.
I'd prefer one build system to two separate layers, one of which I'd write myself. Moreover, most of my dependencies are not projects, but simply jar files picked up from various sources.
Thanks again to everyone! I'll look at Java with cake, and also at Gradle.
while the tutorial is written for gradle 1.0.x milestone releases. I use gradle 0.9.2, and it works fine for me.
On Mon, Jul 4, 2011 at 3:14 AM, Konrad Hinsen
<konrad.hin...@fastmail.net> wrote: > 1) Simplicity. I want to distribute a single tar file to collaborators (who > are new to Clojure and the JVM world) containing all dependencies and build > scripts. I want to tell them "install <name of build tool>, take this file, > play with the source code, and just type <build-command> to build an > executable". They will struggle with a new language and a new environment > already, there's no need to add the complexities of repositories. To make it > worse, we all live behind proxies that require messy configuration for tools > like Maven.
Am Montag, 4. Juli 2011 09:14:01 UTC+2 schrieb konrad...@laposte.net:
> Thanks for everyone's suggestions and comments!
> Some remarks:
> Gradle/clojuresque: I never tried them, but it looks like I should!
> AOT compilation: My case is probably a bit complex in this respect. I
> need AOT compilation only because I want to produce an executable jar,
> so there is at least one namespace that must be AOT compiled. For
> building that executable jar, it doesn't matter if everything else is
> AOT compiled as well. But I want to be able to build a standard
> library jar with just the Clojure code to make sure it works with
> future Clojure releases. One solution would be to have two completely
> different builds, one for the executable jar and one for the library
> version, but using the same set of source code files.
I would do it like this:
Split the source in two parts: the library part and the application
part. This would help to maintain a clean library API, because you
could use your application as real customer. You could build both
parts independently if desired and so on.
On the other hand this is not a requirement. You could just as well
have everything in one tree and create two jars from it. But my
gradle-fu is too limited to suggest a quick solution for that way.
First the former way the source layout would be something like this:
root directory of the project
│
├─ build.gradle (see below)
│
├─ lib
│ │
│ ├─ build (clojuresque, other stuff needed for buildscript)
│ │
│ └─ runtime (your dependencies go here)
│
├─ library (library subproject)
│
└─ app (application subproject)
You need only the following central build.gradle. It will build a
normal library jar for the library subproject and a AOT-compiled
jar for the application.
// If you want a fat jar with all dependencies included...
uberjar.enabled = true
configurations.compile.transitive = true
dependencies {
compile project(':library')
}
// more stuff here for main class definition etc.
}
Although not completely working out of the box this should give
you a feeling of how things would look like with gradle. So you
can hopefully quickly evaluate whether it is worth a look at all.
I'm open for any support request to get you going with clojuresque.
Mail me or put the discussions on the newly created google
group: http://groups.google.com/group/clojuresque.
<konrad.hin...@fastmail.net> wrote: > AOT compilation: My case is probably a bit complex in this respect. I need > AOT compilation only because I want to produce an executable jar, so there > is at least one namespace that must be AOT compiled. For building that > executable jar, it doesn't matter if everything else is AOT compiled as > well. But I want to be able to build a standard library jar with just the > Clojure code to make sure it works with future Clojure releases. One > solution would be to have two completely different builds, one for the > executable jar and one for the library version, but using the same set of > source code files.
You seem to want to make two things: a library and an application. For that, I think it's only proper if you have two build scripts, since you have two build artifacts. Indeed, the application may be better off depending on the library than directly incorporating its source code as some of its own.
>> For the record, leiningen can do this by adding a repository with a >> file:/// URL; it's just not documented because I think it's a bad idea.
> With absolute filenames in a URL, it's indeed a bad idea because the project > becomes specific to a machine/installation. What I'd like to see instead is > a project-local repository, e.g. a "deps" folder with jar files and source > code directories.
> There are several reasons why I want dependencies outside of repositories:
> 1) Simplicity. I want to distribute a single tar file to collaborators (who > are new to Clojure and the JVM world) containing all dependencies and build > scripts. I want to tell them "install <name of build tool>, take this file, > play with the source code, and just type <build-command> to build an > executable". They will struggle with a new language and a new environment > already, there's no need to add the complexities of repositories.
This is what I meant about avoiding unnecessary ceremony.
> To make it worse, we all live behind proxies that require messy configuration > for tools like Maven.
> 2) Network independence. I often work without Internet access, and I don't > want to be blocked at some point because some build tool wants to access > some repository to see if my version is still current.
The above provide some reasons why the build process should not *require* an internet connection if all dependencies are already available locally. I don't have a problem if some build tool checks for updates, so long as it treats a failed check the same as finding there's no update, give or take a non-fatal warning or two.
On the other hand, the result on actually finding an update should probably be a user prompt in interactive mode and a build without the update in batch mode. Otherwise the update, if it breaks backward compatibility, could break the build. A build that worked yesterday and breaks today without one having changed any local files, neither the build script nor the sources nor anything else, is going to be a head-scratcher to deal with, and in many contexts time is money.
> 3) Confidentiality. Sometimes I work with unpublished code that I promised > not to give to anyone else. I can't keep that promise if the code leaves my > machine in any way. For that case, the file:/// repository would of course > be fine.
Presumably also for network-independence and avoiding annoying proxies. But if it needs an absolute path, that may* break the "just tar up the source tree and mail it to someone" capability and forces even small collaborative projects to set up and use some kind of code repository instead. As I've argued elsewhere, repository use scales poorly at the small-project end, unsurprisingly since repositories were specifically invented as a tool to make large-scale projects with huge numbers of collaborators and vast reams of code manageable. Using a high-falutin' version control system for 12kloc and three developers is like using a bazooka to swat a fly, a top-of-the-line Oracle database product on expensive iron to track your personal expenses and balance your checkbook, or hashmaps instead of arraymaps to store little three-key objects that number in the tens of thousands. :)
* Unix filesystems seem to be standardized enough in layout that using absolute paths of \usr\src\whatever and suchlike may be viable. Except that it won't work for a collaborator whose machine runs Windows, and, worse, it requires working as root or else letting unprivileged users create executables in world-readable places -- ick.
> I'd prefer one build system to two separate layers, one of which I'd write > myself. Moreover, most of my dependencies are not projects, but simply jar > files picked up from various sources.
Indeed, Maven-based stuff seems oriented around the assumption that any third-party dependencies you will have, in particular, will generally be publicly hosted on Maven repositories themselves rather than just a ten-cent web site or Blogspot article or Facebook page with a .jar download link. Another case of not scaling well at the low-size end of things, or at the shallow end of the skill pool or the low end of the budget scale for that matter. (Setting up a Facebook profile or a blog on an existing service: free and easy. Uploading a jar file you built to Rapidshare or some other such site and posting the link: free and easy. Setting up some kind of publicly-visible code repository: expensive and complex. Using an existing repository service site: perhaps free and perhaps less complex, but still fairly complex.) But this time biting the small-time library's users rather than its small-time developer...
-- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age.
On Jul 3, 10:01 pm, Ken Wesson <kwess...@gmail.com> wrote:
> OK...ridiculous leap reduced to merely huge leap then, if you only
> have to learn 2 of these three things at once: big, interdependent
> groups of projects, maven/etc. repository-accessing tools, and server
> administration. :)
It's really not that hard. If you use Enclojure/Netbeans there are
wizards for creating maven clojure projects (I assume so for other
IDEs as well). You create one project, write some code, mvn install.
Create another one, right click on the dependency folder, add the
details for the first project and it's ready for you to use. No
repositories to create or manage, maven handles all that stuff for
you.
I wouldn't normally defend maven, but there are some things it does
well and for this sort of simple "local Project A depends on local
Project B" stuff it's a no-brainer (esp. when the IDEs do most of the
config creation work).
On Mon, Jul 4, 2011 at 6:29 AM, Steve <stephen.a.lind...@gmail.com> wrote: > On Jul 3, 10:01 pm, Ken Wesson <kwess...@gmail.com> wrote:
>> OK...ridiculous leap reduced to merely huge leap then, if you only >> have to learn 2 of these three things at once: big, interdependent >> groups of projects, maven/etc. repository-accessing tools, and server >> administration. :)
> It's really not that hard. If you use Enclojure/Netbeans there are > wizards for creating maven clojure projects (I assume so for other > IDEs as well). You create one project, write some code, mvn install. > Create another one, right click on the dependency folder, add the > details for the first project and it's ready for you to use. No > repositories to create or manage, maven handles all that stuff for > you.
That's actually a bit worrying. I'm not sure I want a potential security hole into my computer, such as a repository, being "handled for me" without having *some* input into the matter. For example if I intend to use it purely locally I'd want to firewall the port it's using to make sure it's unreachable from any address other than 127.0.0.1.
On the one hand, manually managing stuff like that is hard, and it's complex to learn the first time.
On the other, making it *too* simple, at least when it has implications for the machine's security, is not generally a good thing.
> I wouldn't normally defend maven, but there are some things it does > well and for this sort of simple "local Project A depends on local > Project B" stuff it's a no-brainer (esp. when the IDEs do most of the > config creation work).
There's also the fact that everything remains simple (maybe too simple; see above) only so long as you remain inside the cushioned box of the particular IDE. As soon as you try to do anything else -- tweak something from vi or Notepad, significantly refactor and rename and restructure stuff in a manner that changes some file paths, move to or sync with another machine, share with a collaborator, even just find the source files to back them up somewhere safe -- you're in the deep woods, possibly without a good map. :)
-- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age.
> Implementation of projects-in-dir left as an exercise for the
> reader. Shouldn't be more than four lines. Push the lein-subs plugin to
> clojars: problem solved in a repeatable, maintainable way.
IMHO such a thing can be added to Lein proper as a feature. It's very
useful. Maybe with a :sub key in project.clj:
> On Mon, Jul 4, 2011 at 6:29 AM, Steve <stephen.a.lind...@gmail.com> wrote: >> On Jul 3, 10:01 pm, Ken Wesson <kwess...@gmail.com> wrote:
>>> OK...ridiculous leap reduced to merely huge leap then, if you only >>> have to learn 2 of these three things at once: big, interdependent >>> groups of projects, maven/etc. repository-accessing tools, and server >>> administration. :)
>> It's really not that hard. If you use Enclojure/Netbeans there are >> wizards for creating maven clojure projects (I assume so for other >> IDEs as well). You create one project, write some code, mvn install. >> Create another one, right click on the dependency folder, add the >> details for the first project and it's ready for you to use. No >> repositories to create or manage, maven handles all that stuff for >> you.
> That's actually a bit worrying. I'm not sure I want a potential > security hole into my computer, such as a repository, being "handled > for me" without having *some* input into the matter. For example if I > intend to use it purely locally I'd want to firewall the port it's > using to make sure it's unreachable from any address other than > 127.0.0.1.
"Repository" need not imply anything to do with networking. I'm sure someone will correct me if I'm wrong, but I am pretty sure that the repository Steve is talking about above is just a hierarchy of files in your home directory.
> 2) Network independence. I often work without Internet access, and I
> don't want to be blocked at some point because some build tool wants
> to access some repository to see if my version is still current.
For the record, this is easily doable with both Leiningen and Cake
(which both use Maven under the hood). One just has to create
a ~/.m2/settings.xml with the following content:
<konrad.hin...@fastmail.net> wrote: > AOT compilation: My case is probably a bit complex in this respect. I > need AOT compilation only because I want to produce an executable jar, > so there is at least one namespace that must be AOT compiled. For > building that executable jar, it doesn't matter if everything else is > AOT compiled as well. But I want to be able to build a standard library > jar with just the Clojure code to make sure it works with future Clojure > releases. One solution would be to have two completely different builds, > one for the executable jar and one for the library version, but using > the same set of source code files.
You might be able to use the :impl-ns option in gen-class to limit the extent of AOT compilation.
