I didn't mean the act of the generation, I know this is but executing a command - but if I need to develop on the implementation or the components source code and have to execute the command whenever I change something in the share classes, I promise this makes developing much more tedious, and this is probably not what we should encourage.
Rather than imposing this on the developers, I would impose on the users to either download and use myfaces-all.jar if they use components and implementation or myfaces-components.jar if they just use the components (and implicitly package share along with that). Not so much more inconvenience for the users, a lot more convenient for us developers! regards, Martin ---------- Forwarded message ---------- From: John Fallows <[EMAIL PROTECTED]> Date: Jun 9, 2005 4:38 PM Subject: Re: Proposed SVN Reorg To: [EMAIL PROTECTED] > Sounds tedious for developing, though... It is approximately as tedious as any other kind of Java source generation. :-) > If I do a change in the share package, I will need to run this > mechanism to generate the share packages from that. Right. Is that a frequent occurrence? > Plus: we really have two codebases then. How so? We generate two packages to avoid eclipsing, but we still have only one source of truth in the templates, right? > I'd rather have a possibility where we just program against the common > share package, and then, upon build, the share-code is moved to a new > package and the tomahawk code is refactored to use this package. The danger here is that we would be doing daily testing (during development) of different code than we ship. If we develop both Core and Tomahawk in the same IDE Workspace, wouldn't we still suffer from the class eclipsing problem? > I haven't got a clue though if this is possible with the available build > tools! Attempting to take this approach will make the Maven (or any build tool) integration difficult. Each Java source from Tomahawk that references a shared class in the Core package would have to be modified to reference that shared class in the repackaged Tomahawk location. However, it would be bad practice to modify those referencing sources in-place, because they would then look like local modifications to be committed to the source repository. Therefore, the modified referencing sources would need to be generated to a different location (such as "target/src/java". Unfortunately, Javac gets rather upset when a class is defined by multiple source files in the same source path, and fails compilation. But, the source path is defined by just the top-level source directories, such as "src/java" and "target/src/java". I think Javac automatically picks up any .java files under each source path root, but it might be possible to provide an exclusion list. So, either we'd have to use a different extension for files that reference the shared codebase (which will lead to poor IDE experience), or we need to track the exclusion list of files that reference the shared code base. IMHO, either of these would be more tedious than remembering to run codegen each time we modify the shared source templates. Kind Regards, John Fallows.
