v1 artifacts: http://central.maven.org/maven2/org/apache/jena/jena-fuseki/1.1.1/
Almost any of those could in theory be used.. If somehow a Maven project before got jena-fuseki 1.1 the JAR and now upgrade to 2.0 the POM, that's not going to work very well :) (At least it should fail early!) The reason I backed Rob's v2 approach is that it's the least intrusive, and can be transient until fuseki1 is deprecated. It's slightly messier for the project "Why is the parent jena-fuseki2 and the module just jena-fuseki-*??" - but less impact for anyone else who should never need to care about the parent. You could also do a v2 variant where the parent is called jena-fuseki-parent instead of jena-fuseki / jena-fuseki2? Less confusion? If we think there are no-one using the fuseki 1 artifacts from Maven++, then v1 approach is probably still workable, even if it's more intrusive. On 2 March 2015 at 16:40, Andy Seaborne <a...@apache.org> wrote: > On 02/03/15 15:37, Rob Vesse 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 > > > It's just the release plugin at the moment. What i think is happening is > that when it rewrites the version ids after asking what to set them to, it > overwrites regardless. The dialog gets the right answer; it's the rewrite > stage that does not map current->release ids, just overwrites with release > ids. > > There may other lurking issues as well. It's supposed to work in a > sufficiently recent maven. That said, while it has been working in > development builds, relying on the version might be too clever. > >> jena-fuseki2 > > All the choices: > > 1/ (V1) jena-fuseki, (V2) jena-fuseki2, jena-fuseki-war, ... > Just the clashing artifact renamed. > > 2/ (V1) jena-fuseki, (V2) jena-fuseki2, jena-fuseki2-war, ... > Rename all V2, leave v1 > > 3/ (V1) jena-fuseki1, (V2) jena-fuseki, jena-fuseki-war, ... > Rename v1 only. > > 4/ (V1) jena-fuseki1, (V2) jena-fuseki2, jena-fuseki2-war, ... > All modules have the major version. > > I'd like to do it by making Fuseki v1 "jena-fuseki1", leave "jena-fuseki" > for Fuseki2 - option 3. 4's OK; 1 seems like trouble. 2 isn't clear to my > way of thinking. "jena-fuseki" is a > > Fuseki2 does have artifacts (WAR file; the server jar is done as an > artifact, not a classifier addition; an embedded version sometime). That > makes a second rename of Fuseki v2 artifact(s) less desirable. > > This isn't a strongly held position. The underlying assumption is that > Fuseki v1 is not used as an artifact -- only as a distribution. > > Of course, I can't be sure that is no one outside the build uses it as an > artifact so if anyone thinks it's a bad idea, do say so. > > There is an internal artifact use of Fuseki v1 by jena-jdbc-driver-remote > and jena-jdbc-driver-bundle (2 each). That causes a different, minor > problem, which I didn't understand. When resolving dependencies in > release:prepare, that useage causes a "you have SNAPSHOTs do you want to fix > them" dialog from the release plugin (inc dry run). You get 2 lots of two > requests to fix the SNAPSHOT version. In case that was the cause of the > major issue, I set it to a fixed 1.1.1 but it didn't change anything other > than removing the additional dialog. > > Andy > > >> >> 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
