Hi Sebb, sebb wrote:
> On 4 June 2013 11:16, Jörg Schaible <joerg.schai...@scalaris.com> wrote: >> sebb wrote: >> >>> DBCP is complicated to release, because the source has to be >>> pre-processed in order to build additional versions of the code. >>> (unlike the rest of Java, JDBC is not generally upwards compatible). >>> >>> The source code in SVN is for the latest JDBC version we support, and >>> can be built and deployed using Maven the same as any other normal >>> Commons component. >>> [At least I assume that is the case; if not that ought to be fixed >>> [first] >>> >>> Previous versions are currently built and deployed using Ant which has >>> to pre-process the source before doing the build. >>> >>> Now component RCs should ideally be built from a fresh checkout of the >>> tag, so one possible approach would be to use Ant to create the tag >>> and workspace and then use Maven as before. >>> It would mean using multiple workspaces, but it does not take huge >>> amounts of disk space. >>> >>> The process for previous JDBC versions would be: >>> >>> Checkout a fresh workspace from SVN. >>> Run Ant to fix up the source code >>> Create the RC tag directly from the workspace >>> Use Maven to build and deploy the jars. >>> >>> Does that sound like a possible approach? >> >> Why not use the antrun plugin in a profile in the generate-sources phase >> to filter the sources into a new directory in target/generates-sources >> and also set the path to the Java source in that profile to this >> directory? You can even reuse our existing profiles for the Java runtime: > > Would the generated source jars contain the updated source? > Ditto Javadoc? Yes, because of the modified sourceDirectory setting. However, our assembly creating the source distribution might have to be adjusted. > I presume one would then just need to run the Maven build/deploy once > for each JDBC version? Right. > Seems worth a try. > > Might also be worth considering using a classifier to distinguish the > jars, rather than a version number? Then you loose again the matching sources and javadoc artifacts. And from customer's side you will have to add/modify/remove suddenly such a classifier in case you're updating your Java runtime. Even more headache with transitive dependencies, because then you might have more than one artifact in the classpath and you cannot even exclude them separately, because an exclusion can only be defined for all artifacts of groupId:artifactId, you cannot specify a classifier. With version numbers only, I can simply use a dependencyManagement section to select what I need. Cheers, Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
