splitting packages across jar and build boundaries

[Paul Phillips]

Is there some really good reason for this? Among the consequences is that the files in "reflect" are built against whatever package object classfiles already exist, and then subsequently in the same build, the files in "compiler" are built against the current source of the package object.  If we were running out of confusing things to debug, it is a surefire way to alleviate our boredom.

% ls -l src/compiler/scala/tools/nsc/io

total 152

-rw-r--r--  1 paulp  admin    428 Aug 18 07:32 DaemonThreadFactory.scala

-rw-r--r--  1 paulp  admin   1119 Aug 18 07:32 Fileish.scala

-rw-r--r--  1 paulp  admin   6071 Aug 18 07:32 Jar.scala

-rw-r--r--  1 paulp  admin   9242 Dec  6  2011 Lexer.scala

-rw-r--r--  1 paulp  admin    480 Aug 18 07:32 MsilFile.scala

-rw-r--r--  1 paulp  admin  18586 Aug 18 07:32 Pickler.scala

-rw-r--r--  1 paulp  admin   1021 Jul 27 11:11 PrettyWriter.scala

-rw-r--r--  1 paulp  admin   1899 Aug 11 23:26 Replayer.scala

-rw-r--r--  1 paulp  admin   2535 Aug 18 07:32 Socket.scala

-rw-r--r--  1 paulp  admin   4813 Aug 18 07:32 SourceReader.scala

-rw-r--r--  1 paulp  admin   1503 Aug 18 07:32 package.scala

% ls -l src/reflect/scala/tools/nsc/io

total 136

-rw-r--r--  1 paulp  admin   8995 Aug 18 07:32 AbstractFile.scala

-rw-r--r--  1 paulp  admin   2931 Aug 18 07:32 Directory.scala

-rw-r--r--  1 paulp  admin   7573 Aug 18 07:32 File.scala

-rw-r--r--  1 paulp  admin    640 Aug 18 07:32 FileOperationException.scala

-rw-r--r--  1 paulp  admin    902 Aug 18 07:32 NoAbstractFile.scala

-rw-r--r--  1 paulp  admin  10611 Sep  1 07:17 Path.scala

-rw-r--r--  1 paulp  admin   3261 Aug 18 07:32 PlainFile.scala

-rw-r--r--  1 paulp  admin   4029 Aug 18 07:32 Streamable.scala

-rw-r--r--  1 paulp  admin   1911 Aug 18 07:32 VirtualDirectory.scala

-rw-r--r--  1 paulp  admin   2898 Aug 18 07:32 VirtualFile.scala

-rw-r--r--  1 paulp  admin   7584 Sep  1 07:17 ZipArchive.scala

[Eugene Burmako]

I split the package, because we do need some parts of it for positions in reflection api, but I didn't want to pull the entire scala.tools.nsc.io into scala-reflect.jar. 

But indeed this looks like a problem. How about moving the entire bunch to scala-reflect? Increasing the footprint of the public api is unfortunate, but seems inevitable.

[Heiko Seeberger]

Not sure if you care, but split packages cause issues for OSGi.

Heiko

[Eugene Burmako]

Didn't actually know that. Seems like another argument in favor of moving the rest of the package to scala-reflect.jar.

[Josh Suereth]

The huge point against is that anything in scala-reflect has to abide by binary compatibility restrictions and any packages exposed have to be supported/maintained as public.

If you put em in, let's make sure visibility is restricted!   I'd love to see an alternative solution too, assuming there is one.

[Paul Phillips]

On Sat, Sep 1, 2012 at 3:15 PM, Josh Suereth <joshua....@gmail.com> wrote:

The huge point against is that anything in scala-reflect has to abide by binary compatibility restrictions and any packages exposed have to be supported/maintained as public.

Yes, that was going to be my large (huge even) objection.  We should go the other way, putting as little as possible in the reflect jar.  There's no reason whatever is needed has to be in the same package as the stuff in the compiler jar; all that stuff is for internal use. I would never have voted to expose anything in scala.tools.nsc.io outside of the compiler.

[Josh Suereth]

+ countable infinity

Let's throw ourselves a forward pass and wait for a well formed IO library.

[Eugene Burmako]

We do need the full-fledged Position in scala-reflect.jar and that involves having the AbstractFile stuff. Though your arguments are indeed compelling.

Once I get a hold on my university assignment (next week), I'll try to think something out. My current plan is to: 1) reconcile the entire scala.tools.nsc.io in scala-reflect.jar, 2) abstract away the appearances of AbstractFile in the public API (currently there are only two iic), 3) hide scala.tools.nsc.io in Scaladoc. wdyt?

[iulian dragos]

On Sat, Sep 1, 2012 at 9:31 PM, Heiko Seeberger <heiko.s...@gmail.com> wrote:

Not sure if you care, but split packages cause issues for OSGi.

We should care, since Eclipse relies on OSGi. Split packages are a huge problem, so if you need to split the classes in different jars, can you rename the package in one of them? It would even be nicer: scala.reflect.io ;-)

iulian

--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

[Matthew Pocock]

Splitting packages across multiple jars also causes problems with containers that apply security. I can't remember exactly where I last fell over this, but some things require signed, sealed packages.

Matthew

--

Dr Matthew Pocock

Integrative Bioinformatics Group, School of Computing Science, Newcastle University

mailto: turingate...@gmail.com

gchat: turingate...@gmail.com

msn: matthew...@yahoo.co.uk

irc.freenode.net: drdozer

skype: matthew.pocock

tel: (0191) 2566550

mob: +447535664143