Bug 334753

Comment 1 Chris Frost 2011-01-19 06:02:07 EST

Adding in Ben's comments.

"Three-fold.  First, it's unneeded.  A project is a lightweight thing and I'm a fan of breaking out utility code into separate projects as needed.  No one questions why the OSGi Stubs are a separate project, I'm not sure what the opposition to a project of test-utility code would be.

Secondly, it's just giving the developers enough rope to hang themselves.  Adding this feature means that you'll be just moments away from a developer having 'production' code dependent on another project's test code.  This is already possible to do in Eclipse and led to a fair amount of lost time during the dm Server days.  Adding the ability to do this from the command line is a recipe for a lot more lost time.

Finally, it'll actually slow down your builds quite a bit :)  Currently projects don't depend on one another via the target/classes and target/test-classes directories.  Instead they depend on the completely built JAR files in the integration-repo and the ivy-cache (via the EBR).  To properly change the build to allow one project to depend on another project's test code would require the packaging and publication (integration-repo first but the EBR for a publishing build) of test JARs for each packaging.

-Ben"

Comment 2 Glyn Normington 2011-01-19 06:24:01 EST

(In reply to comment #1)
> Adding in Ben's comments.
> 
> "Three-fold.  First, it's unneeded.  A project is a lightweight thing and I'm a
> fan of breaking out utility code into separate projects as needed.  No one
> questions why the OSGi Stubs are a separate project, I'm not sure what the
> opposition to a project of test-utility code would be.

There are three problems with separating a stub into a separate project from its interface.

Firstly, it will be more likely to get out of step, especially if methods are removed from the interface as this won't cause the stub to fail to compile.

The extra project is an overhead to create and maintain. The cost of creation is probably incurred by the first person to use the stub outside the project that defines the interface and the temptation is to copy stub code.

To avoid a build cycle between projects, any tests using the stub must reside in projects other than the project containing the interface. This is odd for the project which defines the interface as its tests must now move to another project and so they lose default ("package private") access to the classes they are testing.

> 
> Secondly, it's just giving the developers enough rope to hang themselves. 
> Adding this feature means that you'll be just moments away from a developer
> having 'production' code dependent on another project's test code.  This is
> already possible to do in Eclipse and led to a fair amount of lost time during
> the dm Server days.  Adding the ability to do this from the command line is a
> recipe for a lot more lost time.

Yes, the solution must avoid the possibility of production code depending on test code.

> 
> Finally, it'll actually slow down your builds quite a bit :)  Currently
> projects don't depend on one another via the target/classes and
> target/test-classes directories.  Instead they depend on the completely built
> JAR files in the integration-repo and the ivy-cache (via the EBR).  To properly
> change the build to allow one project to depend on another project's test code
> would require the packaging and publication (integration-repo first but the EBR
> for a publishing build) of test JARs for each packaging.

I think we should publish test JARs to the integration repo but probably not to the EBR as it's normal practice, and one which we can reasonably require, for developers to build a whole repo and thereby populate the integration repo.

Comment 3 Chris Frost 2011-01-19 06:35:38 EST

(In reply to comment #2)

1. By adding the @Override annotation to the Stubs methods it will fail to compile when the method is removed from the interface. This doesn't work in Java 5 but we don't support Java 5 so not a problem.

2. I don't understand the second problem, the stubs project already exists. The overhear is simply creating the stub in another project instead of creating it in the same project as the interface.

3. This is the big problem for me, I can't think of a good solution. I don't like the tests depending on tests solution for the reasons Ben outlines I just can't think of a third solution.


I Agree that test jars should not be published to the EBR and that production code should never be allowed to depend on test code.

Comment 4 Glyn Normington 2011-01-19 10:46:03 EST

Steve Powell observes that we would need to make test dependencies follow the same structure as runtime dependencies since we typically compile all projects and then visit each project in the same order building and executing the tests.

Comment 5 Glyn Normington 2011-01-21 12:56:15 EST

Let's discuss face to face, but meanwhile...

(In reply to comment #3)
> (In reply to comment #2)
> 
> 1. By adding the @Override annotation to the Stubs methods it will fail to
> compile when the method is removed from the interface. This doesn't work in
> Java 5 but we don't support Java 5 so not a problem.

Fair point.

> 
> 2. I don't understand the second problem, the stubs project already exists. The
> overhear is simply creating the stub in another project instead of creating it
> in the same project as the interface.

It would be unstructured to put all stubs in a single project. Creating a new project takes time and when push comes to shove, it won't happen.

> 
> 3. This is the big problem for me, I can't think of a good solution. I don't
> like the tests depending on tests solution for the reasons Ben outlines I just
> can't think of a third solution.

Let's discuss.

> 
> 
> I Agree that test jars should not be published to the EBR and that production
> code should never be allowed to depend on test code.

Comment 6 Glyn Normington 2011-08-02 11:26:13 EDT

See http://www.eclipse.org/forums/index.php?t=rview&goto=707363#msg_707363 for a related issue.