This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | better support for checking of up-to-date status when the build is running | ||
---|---|---|---|
Product: | platform | Reporter: | Pavel Buzek <pbuzek> |
Component: | -- Other -- | Assignee: | David Konecny <dkonecny> |
Status: | CLOSED FIXED | ||
Severity: | blocker | CC: | jtulach, ottati |
Priority: | P3 | Keywords: | API |
Version: | 3.x | ||
Hardware: | PC | ||
OS: | Windows 3.1/NT | ||
Issue Type: | ENHANCEMENT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 19670, 21553 |
Description
Pavel Buzek
2002-01-22 13:45:45 UTC
There is another requirement: In some cases the dependent object needs to get the list of objects that
have change since the dependent object has been last compiled.
copy of the discussion about this requirement:
> > More precisely, I need the lists of files that have changed, files that are
> > new, and files that are no longer necessary.
> >
> > Presumably I can keep a list of files in the current version of the archive
> > that I know about, so as long as I can make the above lists at every
> > deployment, this is enough.
> >
> > I'm not sure that the compiler API is sufficient. This solution works well if
> > the only compiles run start from the application root, in which case I can
> > collect all the information necessary. But what if in between application
> > compiles there are smaller compiles of subsets of the application? I need the
> > change lists for the smaller compiles included in the change lists for the
> > deployment compilation.
> >
> > --George
>
> George,
> I agree that the Compiler API is not adequate now, but I think that with
> the proposed enhancement it would be.
>
> As I proposed earlier, the API would be extended to compare the times
> when objects have been last compiled. So the dependent objects will keep
> the timestamp when they were last compiled (e.g. last deployment to
> server) and compare it to the last compilation timestamp of objects they
> depend on (e.g. java classes). This way if you compile some objects
> between two project builds they will tell the compilation engine that
> they are newer.
>
> The timestamp will be provided by the object and by default it will be
> timestamp of files, but it can be overriden.
>
> A small example:
> Your object A (deplyment) will express dependencies on objects B, C, D
> (jars). First you build from scratch at 4:30am. Objects will be last
> compiled at:
> B 4:30:00am
> C 4:30:02am
> D 4:30:05am
> A 4:30:23am
>
> Then you change something in C and recompile it, so C will be 'Last
> compiled at 4:34:00am'.
>
> Then you change something in B and you call 'deploy' (i.e. compile
> action on object A). A will put the the dependency info in the compiler,
> so the task for compiler will be:
> "Compile A which depends on (Compile B, Compile C, Compile D)"
> The compiler will ask B, C, D to compile. C and D is up-to-date so they
> will not compile. B will compile.
> Last compile times are:
> D 4:30:05am
> A 4:30:23am
> C 4:34:00am
> B 4:43:15am
> So A will be notified the it has to be rebuild because some dependencies
> were updated. It will be able to get the list of changed objects - B, C.
>
> BTW: Since the check is done after the first step of compilation, this
> architecture would also cover the case when D would have changed as a
> side-effect of compilation of B (this is not the case for jar, but it
> happens e.g. with jikes -- as Michael pointed in one of his previous
> mails).
Proposal: <http://openide.netbeans.org/proposals/compiler/> Discussion: <http://openide.netbeans.org/servlets/ReadMsg?msgId=283724&listName=de v> Fixed in files: Checking in openide-spec-vers.properties; new revision: 1.55; previous revision: 1.54 Checking in api/doc/changes/apichanges.xml; new revision: 1.60; previous revision: 1.59 Checking in src/org/openide/compiler/Compiler.java; new revision: 1.23; previous revision: 1.22 Checking in src/org/openide/compiler/CompilerJob.java; new revision: 1.18; previous revision: 1.17 Checking in src/org/openide/compiler/Graph.java; new revision: 1.9; previous revision: 1.8 Checking in test/cfg-unit.xml; new revision: 1.43; previous revision: 1.42 Checking in test/unit/src/org/openide/compiler/CompilationEngineTest.java; new revision: 1.2; previous revision: 1.1 Checking in test/unit/src/org/openide/compiler/CompilerJobTest.java; new revision: 1.2; previous revision: 1.1 Checking in test/unit/src/org/openide/compiler/DummyCompiler.java; new revision: 1.2; previous revision: 1.1 ok, verified Resolved for 3.4.x or earlier, no new info since then -> closing. |