Re: Release planning : 2.13.0

[Andy Seaborne]

On 03/03/15 01:38, Stian Soiland-Reyes wrote:
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 technical part is clear -  it's the "could", "in theory" and 
"somehow" that matter.

Fuseki1 is in dist/binaries/ and mirrored.

In my experience, short-term mitigation worries can leave long-term 
legacy behind and it costs more in support.  If we can find a one-time 
change, I think it is less work for the project.  Users have to change 
sometime - let's make it once.

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.

As a server Fuseki2 is more compliant, and probably more stable than 
Fuseki1 because it uses Jetty9.

There is a issue with Jetty8, as Fuseki1 uses it, under high load. 
Jetty9 is radically different in the area of connectors and does not go 
into weird states (it's quite likely not Jetty directly, but the way 
Java 1.6 works - Jetty9 uses java7 features).

        Andy

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