+1 Bhupendra Sent from phone
On 05-Mar-2015, at 8:32 PM, Mark Struberg <[email protected]> wrote: > I like JLouis original proposal regarding aligning it with the EE versions. > > OpenEJB was EJB centric. Thus it was very closely bound to EJB spec versions. > TomEE is EE umbrella centric. Thus it is closely bound to the EE umbrella > spec version > > TomEE-1.7.x -> TomEE-6.0.x > TomEE-2.0 -> TomEE-7.x > > That way it is really easy for users to know what they get! > > Maybe we let 1.7.x as it is, but we should really go for TomEE-7.0.0 instead > of 2.0 > > LieGrue, > strub > > >> Am 05.01.2015 um 20:17 schrieb Jean-Louis Monteiro >> <[email protected]>: >> >> Definitely useful thoughts Jon. >> Thx for sharing. >> >> -- >> Jean-Louis Monteiro >> http://twitter.com/jlouismonteiro >> http://www.tomitribe.com >> >> On Mon, Jan 5, 2015 at 4:18 PM, Jonathan Gallimore < >> [email protected]> wrote: >> >>> Just wanted to chip in with my $0.02... I'll try not to flame anyone or >>> propose anything too controversial :). >>> >>> What are the release tools in question - is this the Maven Release plugin >>> or a TomEE specific tool (I'm thinking along the lines of: >>> >>> https://svn.apache.org/repos/asf/tomee/sandbox/release-tools/src/main/java/org/apache/openejb/tools/release/Release.java >>> )? >>> I ask as I'm wondering whether improving / fixing the tool is good option? >>> >>> That said, I have no objection to aligning the TomEE and OpenEJB numbers. >>> My personal opinion is that I'd avoid going back numerically (might be >>> perceived as a step back, and we previously had OpenEJB 2 which looked >>> quite different to OpenEJB >= 3 if I remember correctly). Jumping both to a >>> version 5 might look like a substantial update for TomEE that would require >>> some explanation. I'm less keen on aligning to the Tomcat version, but >>> aligning to the Java EE version could make it quite simple. So, TomEE 1.7.x >>> / OpenEJB 4.7.x would become TomEE/OpenEJB 6.x and TomEE 2.0 / OpenEJB 5.0 >>> would becoming TomEE/OpenEJB 7.0. >>> >>> Personally I'm not in favour of splitting the release cycles of OpenEJB and >>> TomEE - I think splitting them might create more work in managing >>> dependencies, and might introduce some confusion between what versions of >>> OpenEJB and TomEE are compatible with each other. I would also be concerned >>> that there might be even more overhead in trying to actually do the >>> releases than there is now, as we'd effectively have to do a release for >>> OpenEJB and another for TomEE, with one being dependent on the other. >>> >>> Hope that these are useful thoughts. >>> >>> Jon >>> >>> On Sat, Jan 3, 2015 at 12:00 PM, Romain Manni-Bucau <[email protected] >>> wrote: >>> >>>> We can for sure downgrade openejb since we would use org.apache.tomee as >>>> groupid and finally be almost consistent - what we are not since tomee is >>>> the openejb name. >>>> >>>> We can do it for tomee 2. We can even rename all openejb artifacts to >>> tomee >>>> and assume we cant split both. >>>> Le 3 janv. 2015 11:06, "Jean-Louis Monteiro" <[email protected]> >>> a >>>> écrit : >>>> >>>>> I do mainly agree on the result and the consequences to have 2 >>> different >>>>> versions in the same tree. >>>>> The best would have been to have OpenEJB as a separate subproject with >>>> its >>>>> own lifecycle and versioning and to use it in TomEE like any other dep >>>>> (openjpa, cxf to name a few). >>>>> >>>>> Because usually we update in both sides OpenEJB and TomEE, we decided >>> to >>>>> stick with one tree only containing TomEE, the Maven plugin, OpenEJB, >>> etc >>>>> with the consequences you mentioned Andy. It definitely has some >>> benefits >>>>> but yes the drawbacks are heavy as well. >>>>> >>>>> That said, I'm wondering if OpenEJB and TomEE at least have a different >>>>> lifecycle. If not, then at least they should have the same version in >>> the >>>>> same tree. >>>>> >>>>> The problem I can see. >>>>> - bumping TomEE version to 4.x for example is quite "dangerous". TomEE >>> by >>>>> itself is pretty young even if most of the codebase is old. Switching >>>> from >>>>> 1.x to 4.x without anything in the middle is doable but hard to argue >>>>> considering we only released less than 10 TomEE versions. >>>>> >>>>> - using tomcat versioning, I'm -1 for this. Same drawbacks as previous >>>> and >>>>> no real benefits. We could use the Java EE web profile versions or Java >>>> EE >>>>> versions, like TomEE 6.x for Java EE 6 Web Profile, TomEE 7.x for Java >>>> EE 7 >>>>> Web Profile, etc >>>>> >>>>> - downgrading OpenEJB version is even more complicated in my opinion >>> and >>>> as >>>>> we kept the same groupId / artifactId, it can be a big Maven hell. >>>>> >>>>> What's "the less worst" solution we could use? >>>>> Considering OpenEJB and TomEE have their own lifecycle, I'd then keep >>> the >>>>> versions and split the source tree and the releases >>>>> Considering OpenEJB and TomEE have different lifecycle, I'd go with the >>>>> same versioning, probably using OpenEJB versions or better EE version. >>>>> >>>>> >>>>> >>>>> -- >>>>> Jean-Louis Monteiro >>>>> http://twitter.com/jlouismonteiro >>>>> http://www.tomitribe.com >>>>> >>>>> On Sat, Jan 3, 2015 at 10:46 AM, Andy Gumbrecht < >>>> [email protected]> >>>>> wrote: >>>>> >>>>>> I know this is a flamed subject, but here goes. >>>>>> >>>>>> A major problem on release is the double barrelled version of OpenEJB >>>> 4.x >>>>>> and TomEE 1.x and 5.x / 2.x. This makes using release tools >>> virtually >>>>>> impossible and the whole process has to have manual interaction. We >>>> shoot >>>>>> ourselves in the foot with this one every time. >>>>>> >>>>>> I know project separation is a no go area for some, so another option >>>>>> would be to get versions aligned. Also a huge point of contention. >>> The >>>>>> issue is the version to use? >>>>>> >>>>>> So this is just to throw a rabbit into the lions den - How about >>>> aligning >>>>>> with the underlying Tomcat major version, something like >>> TomEE/OpenEJB >>>>> 7.x >>>>>> for Tomcat 7.x and 8.x for Tomcat 8? >>>>>> >>>>>> Andy. >>>>>> >>>>>> -- >>>>>> Andy Gumbrecht >>>>>> https://twitter.com/AndyGeeDe >>>>>> http://www.tomitribe.com >
