ah but hang on.. in fuseki 1 there's just "jena-fuseki". In Fuseki 2 "jena-fuseki" is just the parent pom, the "actual" artifacts are jena-fuseki-core, etc.. so the parent can be called anything - in many ways "jena-fuseki2" is even more correct as it matches its folder name.
So a full +1 to that workaround. On 2 March 2015 at 16:46, Andy Seaborne <a...@apache.org> wrote: > On 02/03/15 16:07, Stian Soiland-Reyes wrote: >> >> 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. > > > Co-existence is NOT going to work for all sorts of reasons ... > > > >> >> In Jena, both fuseki versions use the package name >> org.apache.jena.fuseki and so can't co-exist on the classpath. > > > And the dependencies like Jetty ... something Apache Commons does not have > to deal with. > >> 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. > > > v1 - not really (see other email). > v2 - yes > >> 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. > > > As the v1 UI is basic, I think "need" is a bit out of place. > > v2 UI should be at least as good as v1. > > >> >> >> >> 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
