From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: IDE Date: Sun, 1 Nov 2015 19:49:39 +0200 Message-ID: <563650B3.7070605@yandex.ru> References: <561C2C17.3090503@cumego.com> <561DC1CA.6090901@siege-engine.com> <561E3FB6.8010407@yandex.ru> <561EEFDE.7000809@gmail.com> <561F29D0.3070605@yandex.ru> <561FA79C.30207@gmail.com> <56200D07.30206@yandex.ru> <5620A99E.7080009@cumego.com> <5620D109.2010006@yandex.ru> <5620DCCD.8030809@cumego.com> <87y4f2u5ef.fsf@fimbulvetr.bsc.es> <5621C701.5030608@yandex.ru> <87d1wdo1la.fsf@fimbulvetr.bsc.es> <5622D5A5.80801@yandex.ru> <87fv18hwau.fsf@fimbulvetr.bsc.es> <562410AD.2020204@yandex.ru> <87mvvff1qy.fsf@fimbulvetr.bsc.es> <56258EC6.7090706@yandex.ru> <5626E513.4000106@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1446400203 27091 80.91.229.3 (1 Nov 2015 17:50:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 Nov 2015 17:50:03 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 01 18:50:00 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZswlT-0006AP-CD for ged-emacs-devel@m.gmane.org; Sun, 01 Nov 2015 18:49:59 +0100 Original-Received: from localhost ([::1]:38224 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZswlS-00012k-Sc for ged-emacs-devel@m.gmane.org; Sun, 01 Nov 2015 12:49:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZswlF-00012V-TV for emacs-devel@gnu.org; Sun, 01 Nov 2015 12:49:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZswlC-0002qZ-NR for emacs-devel@gnu.org; Sun, 01 Nov 2015 12:49:45 -0500 Original-Received: from mail-wm0-x229.google.com ([2a00:1450:400c:c09::229]:33313) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZswlC-0002qU-EM for emacs-devel@gnu.org; Sun, 01 Nov 2015 12:49:42 -0500 Original-Received: by wmeg8 with SMTP id g8so43067814wme.0 for ; Sun, 01 Nov 2015 09:49:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=r0uBlXhciy4SWMI7OjQwH4cekuB9zKKGbtcv6UW3+Bw=; b=K+MG4zNEUYsEA5WZGF7GpHkoztnnDtJ2qEPqsYp4h5cf3hLiErEyrr1y0Q+IhamO3U mPLHZYEgGh5pTx6GUKJWLR6n62+dcX95UyQP+C3iHTSdVV1HIyE2XF/6NtqZARR7/8K0 3xPJYlMBiB9AqWg/NQ6a9M+e8AyMLVlCiqRGdZuXRWGi05v6mlcCNrDQlWlT6PJqc0Fh 6HKpT47FOOFWouUbos7kfjWoETFrXeRzljEv63H63hoLquX/ANmkOVplonCNtloFqYGt 2ugKRc6vVIlmCcz34PVLKLRwzaZ2pFiYU/IRp2Xdj4jIMh/vrYwYv/u+gx78FOc+2AEu p5lw== X-Received: by 10.28.144.138 with SMTP id s132mr8496012wmd.97.1446400181642; Sun, 01 Nov 2015 09:49:41 -0800 (PST) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id wx10sm17985813wjb.40.2015.11.01.09.49.40 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Nov 2015 09:49:41 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::229 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:193070 Archived-At: Hi Steinar, Sorry for the late response. On 10/27/2015 07:28 PM, Steinar Bang wrote: > (Classpath in maven is actually independent of the directory layout of > the checked out projects, but I won't get into that now) I meant that either we have several values: project-project, project-module1, project-module2, and each of those reports a different value of classpath, or we only have one value, project, and the accessor function project-classpath takes a additional argument, DIR, and can return different values, depending on which module, internally, DIR belongs to. Note that classpath itself is a pretty JVM-centric attribute. It points to jars, as well as directories (the latter less often), and reading the contents of jars, if we want to, will have to be handled specially. Overall, classpath will be more relevant for features that particularly target the JVM. More language agnostic attributes, which I'm more worried about, are sets of directories related to the project. We can search those directories, and we can list files in them (and implement, based on that, the feature "jump to file in the project", with completion). We have currently selected two attributes like that: "project roots", directories which contain the code of the current project, and "search path" (which would probably be more appropriately named as "library roots"). Those directories contain the code that the current project refers to. For C or C++ the closest analog would be the include path. For Ruby or Python - the directories in the current language installation where the libraries are installed. For JVM languages, the classpath seems to be the closest thing, but it contains compiled code. The same jars can also contain sources (I think?), but searching through them, as well as listing contained files, or visiting them, is tricker. We should probably consider that for a later stage. > (That means that as long as the projects are built in dependency order, > they can in *theory* be be checked out separately and built separately, > parent, and dependencies to other projects can be resolved against the > local cache. In practice, however, it is simpler to organize the maven > project in the recommended hierarchy and let maven handle built order > and stuff) This is all great, but as long as Maven knows how to build the project, is there a reason for the project API to know these details? > Depends on what you mean with important project attributes...? The full set will probably emerge incrementally, over time, as developers who want to use the project API complain that it covers too little. > If "project" is the parent pom.xml of the two modules, you can set > properties in "project" that are shared by module1 and module2. You can > also share plugin configurations in this way. All right. So either the project API will handle of property inheritance, or the implementations will need to do that. The latter imposes some difficulties on how the project values are constructed, but since the multi-module project model seem to be prevalent in the Maven world only, I think I'd rather have a simpler API. > eclipse m2e will still recognize that "module1" contains the dependency > of "module2" and build them in order (they will show up as project > dependencies in the project classpath in eclipse). So I take it the dependencies are mostly important for the "build everything" command. > The default search scope in eclipse is "workspace", which is the > projects seen in eclipse's package explorer. That's very interesting. Maybe we'll have a notion of a workspace (the set of the currently opened projects), as well as manual "open/visit/close project" commands. Like, in the second version.