I suppose that at this time the best that you can do is break out the
clean bits into small projects and leave the rest as one big compile.
Ron
On 25/07/2013 12:43 AM, Russell Gold wrote:
It builds now because Javac is able to handle this case - as long as it all
happens in the same compile.
It builds now because Javac is able to handle this case - as long as it all
happens in the same compile. For those of us used to older languages that
compiled one class at a time under the covers, and proceeded in order through
each source file, it sounds odd, but javac has been doing this since
Hi Curtis, sadly, it's in the API. I've oversimplified. In general, one of the
classes in the chain actually has direct API references to hundreds of others.
It turns out that at least some of the links are through deprecated classes. I
am hoping that in the next version, we can remove them - an
On 24/07/2013 10:56 PM, Russell Gold wrote:
Exactly. Which I cannot do because these classes are public and our customers
rely on them. If I break the graph, that means changing a behavior that a
customer might be using, and that would be a serious problem.
I am pushing to deprecate the entire
Hi Russell,
Is the circular dependency in the API itself (i.e., method signatures) or
merely in usage of the classes in implementation? If only usage, one
strategy to break compile-time dependencies is the java.lang.reflect API.
It's not ideal -- your modules will still have a runtime circular
dep
Exactly. Which I cannot do because these classes are public and our customers
rely on them. If I break the graph, that means changing a behavior that a
customer might be using, and that would be a serious problem.
I am pushing to deprecate the entire graph and provide a completely different
api
On 25 July 2013 12:06, Russell Gold wrote:
> Or let me rephrase that. In simple terms, I have dependency graphs like this:
>
> A > B > C
> ^ |
> \--- D
> How do I put these classes into separate modules?
Short answer is:
Break the graph.
--
Or let me rephrase that. In simple terms, I have dependency graphs like this:
A > B > C
^ |
\--- D
> On Jul 24, 2013, at 8:36 PM, Ron Wheeler
> wro
On Jul 24, 2013, at 8:36 PM, Ron Wheeler wrote:
>
> On 24/07/2013 4:40 PM, Russell Gold wrote:
>> Oh, you underestimate the coupling of this code. Yes, there are packages,
>> but the classes in those packages reference one another willy-nilly. It's
>> not a problem with recompiling - it's tha
On 24/07/2013 4:40 PM, Russell Gold wrote:
Oh, you underestimate the coupling of this code. Yes, there are
packages, but the classes in those packages reference one another
willy-nilly. It's not a problem with recompiling - it's that there
don't appear to be any good, sensible subset of classe
Oh, you underestimate the coupling of this code. Yes, there are packages, but
the classes in those packages reference one another willy-nilly. It's not a
problem with recompiling - it's that there don't appear to be any good,
sensible subset of classes in this group of 10,000 or so which can be
On 24/07/2013 12:35 PM, Russell Gold wrote:
I wish I could break it up. Among the problems with this code is the extreme
bit of coupling. The scripts list 300 files to compile because that's all that
we would have wanted, but they pull in other files, which pull in yet others.
Trying to compil
I wish I could break it up. Among the problems with this code is the extreme
bit of coupling. The scripts list 300 files to compile because that's all that
we would have wanted, but they pull in other files, which pull in yet others.
Trying to compile this fairly small subsystem winds up buildin
> The case I'm wondering about now is one where we have over 10,000
> source files in a directory, and compile them bit-by-bit. One step specifies
> about 300 files, and thanks to javac dependency logic, actually compiles
> about 4000 files in ant.
Is there any way you can break that into 10 proje
On Wed, Jul 24, 2013 at 4:28 PM, Russell Gold wrote:
> Hi,
>
> Maybe somebody else has run into this. I'm converting a really messy
> 200-ant-script build to maven, and some steps seems to run a lot slower, now.
>
> The case I'm wondering about now is one where we have over 10,000 source
> files
Memory parameters maybe ?
On Wed, Jul 24, 2013 at 4:28 PM, Russell Gold wrote:
> Hi,
>
> Maybe somebody else has run into this. I'm converting a really messy
> 200-ant-script build to maven, and some steps seems to run a lot slower,
> now.
>
> The case I'm wondering about now is one where we ha
Hi,
Maybe somebody else has run into this. I'm converting a really messy
200-ant-script build to maven, and some steps seems to run a lot slower, now.
The case I'm wondering about now is one where we have over 10,000 source files
in a directory, and compile them bit-by-bit. One step specifies a
17 matches
Mail list logo
