That's the style used by Apache Commons (+ Java package rename) - but there it is not for build reasons but for co-existence as a Maven dependency.
In Jena, both fuseki versions use the package name org.apache.jena.fuseki and so can't co-exist on the classpath. Done "proper" this should probably just be two branches in a separate jena-fuseki repository.. but as you always would want to release both Fusekis whenever there's a new Jena (but not necessarily a new Jena when there's a new Fuseki) I understand why you have put them all together. Would it make sense for fuseki to be used as a Maven dependency? If it is, then I would stick with whatever artifactId it ends up with, so if becomes jena-fuseki2 now, then that's it. If not - perhaps just take jena-fuseki2 out of the master pom.xml and build+tag it separately (longer release process, easier to forget). Release plugin should ask you how to settle the SNAPSHOT dependencies on Jena. When time comes, you can swap around so that jena-fuseki2 is in the master pom.xml instead of fuseki 1. This (which is almost like splitting to a separate git repo) might make sense if there will be further work on Fuseki 2 that is independent from Jena (specially as we move to Jena 3?) -- it does need some more to be complete on the UI side, which seems to be what people fall in love with. On 2 March 2015 at 15:37, Rob Vesse <rve...@dotnetrdf.org> wrote: > I think it is a more general limitation of Maven > > Probably easiest thing is to call it jena-fuseki2 for the time being and > then at such time as 2.x is sufficiently stable to replace 1.x we can > rename again > > Rob > > On 28/02/2015 16:59, "Andy Seaborne" <a...@apache.org> wrote: > >>There'll be a bit of a delay in building Jena 2.13.0. >> >>In our setup, the release process can't not handle having multiple >>versions of the same artifact (org.apache.jena:jena-fuseki). Then the >>reactor has duplicates and maven stops with an error. >> >>Looks like it is the release plugin. >> >>Whether this is because we are using an old(ish) apache parent or >>whether it's an on-going problem, isn't clear yet. Trying things out is >>a slow process. Maybe a change of artifact name is needed, which itself >>then needs checking in case that cascades in any way. Or two build >>cycles. >> >>Works: >> mvn -s settings.xml release:prepare -DdryRun=true >>then fails >> mvn -s settings.xml release:prepare >> >>Bother. >> >> Andy >> > > > > -- Stian Soiland-Reyes Apache Taverna (incubating) http://orcid.org/0000-0001-9842-9718
