First of all, Wayne, Raphael, Stehpen, big thanks for your answers. 1.) Regarding maven-3 and pom inheritance (that's what you meant, isn't?): I think this behaviour hasn't been finally decided, isn't? There is still the (imho good) argument around of how should one adopt the plugin version in a depending pom in this case? [1][2].
2.) Regardless of using the openjpa-version inside the plugins name or as dedicated version, we'd have to perform a plugin build for each openjpa build. I'm not sure about how others handle multi module builds with JPA, but in all projects I'm working on we really take _much_ care about only having one explizit JPA implementation for ALL involved steps and modules. At the end, only ONE JPA will either be injected via spring or JNDI and all of the modules are working on the same database. So having various JPA implementations around in the build would probably break the whole system. This is even more important since OpenJPA has a slightly different behaviour when using runtime enhancement vs class enhancement [3][4][5] in different versions. So imho the system gets nearly non-deterministic if one module uses OpenJPA-1.1.0 compiletime enhancement and the other one uses OpenJPA-1.2.0 This reminds me of another way we could go: Make OpenJPA and all dependencies an optional dependency, so each user has to declare the dependency to the OpenJPA version explicitely. pro: more explizit con: more work needed for standard behaviour LieGrue, strub [1] http://jira.codehaus.org/browse/MNG-3866 [2] http://markmail.org/message/x7rmizebilxjkvyk [3] https://issues.apache.org/jira/browse/OPENJPA-398 [4] https://issues.apache.org/jira/browse/OPENJPA-722 [5] https://issues.apache.org/jira/browse/OPENJPA-733 --- Stephen Connolly <[EMAIL PROTECTED]> schrieb am Di, 2.12.2008: > Von: Stephen Connolly <[EMAIL PROTECTED]> > Betreff: Re: [mojo-dev] [VOTE] align version schema of openjpa-maven-plugin > with openjpa versions? > An: [email protected] > Datum: Dienstag, 2. Dezember 2008, 9:39 > 0: > > That was what I was thinking too... > > for example, at least until M3, what if you have a > multi-module build that > uses different versions of openjpa? > > (OK, so why would this crazyness apply I'm not sure) > > Personally, pick the scheme you prefer, you are the ones > maintaining it. > > To argue the other side, if you have a multi-module with > different versions > of the openjpa plugin invoked in each module... I think you > might want to > know about that real fast, so keeping the same artifactId > will expose the > version mis-match, while including the version in the > artifactId will hide > the fact. > > 2008/12/2 Raphaël Piéroni > <[EMAIL PROTECTED]> > > > Hi, > > > > I am +0 as i dont use this plugin. > > > > But isn't openjpa-<jpaversion>-maven-plugin > a better scheme ? > > > > Regards, > > > > Raphaël > > > > 2008/11/26 Mark Struberg <[EMAIL PROTECTED]>: > > > Hi folks! > > > > > > The current version of the openjpa-maven-plugin > is 1.0-SNAPSHOT. > > > > > > Today, Rahul and I had a discussion about whether > to change the current > > version schema of the openjpa-maven-plugin to be align > with the versions of > > openjpa itself. > > > > > > The openjpa-maven-plugin uses openjpa for compile > time enhancement, SQL > > creation and schema-mapping creation. So although > there may be no change in > > the source needed, this has a really deep impact on > how it behaves. > > > (See e.g. the following openjpa bugs: > > > https://issues.apache.org/jira/browse/OPENJPA-722 > > > https://issues.apache.org/jira/browse/OPENJPA-733 > > > ) > > > > > > I'd like to change the version schema (and > release the plugins) to: > > > > > > .) openjpa-maven-plugin-1.1.0 -> openjpa-1.1.0 > > > .) openjpa-maven-plugin-1.2.0 -> openjpa-1.2.0 > > > .) openjpa-maven-plugin-1.2.1 -> openjpa-1.2.1 > > > > > > PRO: > > > + this will explicitly show the openjpa version > used > > > + no need to fumble around with > <dependencies> sections in the plugin > > config > > > + no more surprises because the plugin uses > openjpa-1.2.0 but the > > project uses 1.1.0 and one simply forgot to pommel the > dependency > > > > > > CON: > > > + in case of bugs, we'd have to use e.g. > 1.2.0.1, 1.2.0.2 etc > > > + in case of bugs, we'd have to run multiple > release (1.2.0.1, 1.1.0.1, > > etc) > > > > > > > > > please vote: > > > +1: yes, let's change the version schema > > > 0: I don't care, either one will work > > > -1: nope, I see some problems, let's release > 1.0, 1.1 and so on > > > > > > txs and LieGrue, > > > strub > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe from this list, please visit: > > > > > > http://xircles.codehaus.org/manage_email > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
