Should there be a 'builder' code tree?

Project:JNode Builder
Component:Code
Category:feature request
Priority:normal
Assigned:Unassigned
Status:won't fix
Description

Correct me if I'm wrong, but I think that the current classlib6 versus trunk/jnode split has resulted in copies of some of the builder code in both the classlib6 and trunk/jnode trees. (And there would be more if the configure subtree hadn't been pruned from classlib6.)

Code duplication is not "best practice". For instance, if someone finds and fixes a bug in the trunk/jnode copy, they may forget to fix the bug in the classlib copy. Indeed, they even know it exists.

Once the classlib6 to cl6 reorg is done, and the issues with checking in big JARs have been resolved, we should consider creating a separate tree for the "common" build and test tools (including Ant tasks) that don't actually depend on the rest of the classlib + tree/jnode codebase. This would include many of the custom ant tasks (but maybe not those for plugin / boot image building), plus the 'configure' app and a lot of the test framework code we have created. The tree would produce a couple of small JAR files which could be handled the same way that we ultimately handle the classlib JARs ... or simply checked in, cos they are small.

[Aside: can someone please remind me why we need to rebuild the classlib6 tree to cl6? I'm sure there's a good reason, but if I heard or seen it, I've forgotten it.]

#1

Submitted by lsantha on Thu, 05/07/2009 - 10:20.

Actually classlib6 and JNode trunk have quite different needs in the build system with little overlaps if any, so it doesn't seem to justify the creation of a new top level project for the builder.

cl6 was a temporary location for importing the contents of classlib6 to get rid of the history.

#2

Submitted by Stephen Crawley on Thu, 05/07/2009 - 13:40.

So why do we need to erase the svn history for classlib6? I thought the history erasure was an unfortunate side-effect of the reorganization ... not the reason for the reorganization.

#3

Submitted by lsantha on Thu, 05/07/2009 - 14:02.

The history of classlib6 is only ereased from classlib6. It is still availabe in the history of trunk up to the point where classlib6 was sapareted from trunk. The history of classlib6 was ereased because statistic tools like Ohloh having in their scope both trunk and classlib6 would duplicate the commits in their reports up to the point where classlib6 was sapareated from trunk, this can lead to confusion as it already did.

#4

Submitted by Stephen Crawley on Thu, 05/07/2009 - 14:14.

Wouldn't it be simpler (and better for developers) to just create a different ohloh project for classlib6?

#5

Submitted by Stephen Crawley on Thu, 05/07/2009 - 14:45.

I see that you made the switch a few hours ago. So (unless you have a backup) it is too late. Oh well.

#6

Submitted by Stephen Crawley on Fri, 05/08/2009 - 07:39.
Status:active» won't fix

Actually classlib6 and JNode trunk have quite different needs in the build system with little overlaps if any, so it doesn't seem to justify the creation of a new top level project for the builder.

I guess the answer to the original question is "no" at the moment. However, if we do get some significant overlap (like for example, common test tools, common configuration tools, common Ant tasks) this issue will need to be revisited.

Marking as 'won't fix'.