On 01/30/2013 12:08 PM, Nick Boldt wrote: > 1. > > It was decided today that because we can't build ALL of JBoss Tools > using Juno, we should build everything with Kepler instead. (Hibernate > Tools depends on Dali, which broke API again. Since JavaEE project > depends on Hibernate Tools, this affects a large chunk of our stack.) > > This is in keeping with past years, where each release is not > backwards-compatible w/ its previous due to changes at Eclipse > preventing it. (eg., in JBT 4.0, we tried to build on both Indigo and > Juno, and ultimately decided we should be building on Juno. Again, > Hibernate Tools / Dali caused this.) > > If you want to build locally against Juno instead of Kepler for your own > tests/sanity checks, use this: > > mvn verify -DTARGET_PLATFORM_VERSION=4.20.5.Final-SNAPSHOT #JunoSR0 > mvn verify -DTARGET_PLATFORM_VERSION=4.21.3.Final-SNAPSHOT #JunoSR1 Would be good to have something easy to remember like mvn verify -PJunoSR0 mvn verify -PJunoSR1 > > This is now the default behaviour (-D flag not needed): > > mvn verify -DTARGET_PLATFORM_VERSION=4.30.0.Alpha1-SNAPSHOT #KeplerM4 > > -- > > 2. > > Next week, I will be moving TARGET_PLATFORM_VERSION to > 4.30.1.Alpha1-SNAPSHOT, which will include updated Kepler M5 bits > (including m2e/m2e-wtp updates). > > -- > > 3. > > In addition to moving to Kepler M5, I will also be removing UML2, > Graphiti & Zest, which will hereinafter be included on the new JBTIS > (Integration Stack, formerly SOA Tooling) target platform. This will be > done for *BOTH JUNO and KEPLER TARGET PLATFORMS.* > > If you are in charge of a JBoss Tools 4.1 or 4.0 (Core) project and need > UML2, Graphiti, or Zest, let me know BEFORE next week, and we can > discuss keeping those reqs in the target platform for your use. > Otherwise I'll assume no one needs them, and they're safe to purge. > > -- > > Once the cruft has been cleaned, new TPs will be released & linked into > the usual places [1], [2]: > > 4.20.6.Final-SNAPSHOT #JunoSR0 (6th respin) > 4.21.4.Final-SNAPSHOT #JunoSR1 (4th respin) > 4.30.1.Alpha1-SNAPSHOT #KeplerSR0, 1rst respin Why are you releasing versions with SNAPSHOT suffix? What is wrong with just 4.20.6.Final? Denis > > [1] http://download.jboss.org/jbosstools/updates/juno/ > [2] http://download.jboss.org/jbosstools/updates/kepler/ > > By the way, if you're looking to pull a target platform site zip and use > it locally, we've relocated them here: > > http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/ > > Question, comments, fear & loathing, or any other feedback... send it > here. > > Cheers, >

> >> mvn verify -DTARGET_PLATFORM_VERSION=4.20.5.Final-SNAPSHOT #JunoSR0 >> mvn verify -DTARGET_PLATFORM_VERSION=4.21.3.Final-SNAPSHOT #JunoSR1 >> > Would be good to have something easy to remember like > > mvn verify -PJunoSR0 > mvn verify -PJunoSR1 > This would add a lot of crap to parent pom for something that we won't use. So there won't be some profiles for unsupported stuff. -DTARGET_PLATFORM_VERSION is easy to remember as well, and in case you forget it, feel free to ask.

>> Once the cruft has been cleaned, new TPs will be released & linked into >> the usual places [1], [2]: >> >> 4.20.6.Final-SNAPSHOT #JunoSR0 (6th respin) >> 4.21.4.Final-SNAPSHOT #JunoSR1 (4th respin) >> 4.30.1.Alpha1-SNAPSHOT #KeplerSR0, 1rst respin >> > Why are you releasing versions with SNAPSHOT suffix? What is wrong with > just 4.20.6.Final? > That's something we are investigating as part of https://issues.jboss.org/browse/JBIDE-13316 . But this is not our highest priority yet. If we remove the "-SNAPSHOT", we'll probably drop the Alpha1/Final qualifier as well.

Mickael, how about we add a profile that does this: $ mvn verify -Phelp [info] Max, if you're trying to override the target platform version [info] use -DTARGET_PLATFORM_VERSION=x.yz.a.quality-SNAPSHOT, eg., [info] mvn verify -DTARGET_PLATFORM_VERSION=4.21.3.Final-SNAPSHOT or $ mvn verify -Phelp [info] Fetching a copy of the parent pom from master branch... [info] Opening parent pom in your default text editor so you can [info] `egrep -i "target|platform" and figure out the property [info] you need to override. :P

Seriously, though, Max, if you can't remember that the maven/tycho variable for the target platform version is TARGET_PLATFORM_VERSION then making you memorize a new profile might not be the best solution.

In fact, you only need to provide an override if the following two usecases don't work for you: a) you want the default minimum: mvn verify b) you want the default maximum mvn verify -Pmaximum Because, while the idea of having profiles for each and every TP stream is *somewhat* reasonable, it doesn't solve the usecase where there are multiple Juno SR0 based target platforms (eg., we have 4.20.5 now and will have 4.20.6 soon - do we have to update the parent pom every time there's a newer SR0 version created? And what if a user wants to use the previous one? -PJunoSR0.previous and -PJunoSR0 ? -PJunoSR0d and -PJunoSR0e ?

Besides, the whole point of refactoring the GAVs for the TPs was to get AWAY from using names like JunoSR0 in favour of 4.20.x. --- > Without [removing -SNAPSHOT] we don't have the option of building a component with a stable parent pom This is true, but we have some time here since M4/M5 are still under development. It's not until M7 that the bits are stable enough to be called .CR or .Final, or to remove the -SNAPSHOT suffix. So... all components, even if they're "done" this week, should be rebuilding w/ updated TPs all the way through M7 to verify they still work against the newer Kepler stuff.

I've bumped https://issues.jboss.org/browse/JBIDE-13408 to Blocker, but I'm leaving it on Alpha2 for now. Cheers, Nick On 01/31/2013 08:43 AM, Max Rydahl Andersen wrote: >>> >>>> mvn verify -DTARGET_PLATFORM_VERSION=4.20.5.Final-SNAPSHOT #JunoSR0 >>>> mvn verify -DTARGET_PLATFORM_VERSION=4.21.3.Final-SNAPSHOT #JunoSR1 >>>> >>> Would be good to have something easy to remember like >>> >>> mvn verify -PJunoSR0 >>> mvn verify -PJunoSR1 >>> >> This would add a lot of crap to parent pom for something that we won't use. So there won't be some profiles for unsupported stuff. >> -DTARGET_PLATFORM_VERSION is easy to remember as well, and in case you forget it, feel free to ask. > > I'm sorry but TARGET_PLATFORM_VERSION is not easy to remember nor is it nice to type. All other user properties in maven is not uppercase and a mile long ;) > >>>> Once the cruft has been cleaned, new TPs will be released & linked into >>>> the usual places [1], [2]: >>>> >>>> 4.20.6.Final-SNAPSHOT #JunoSR0 (6th respin) >>>> 4.21.4.Final-SNAPSHOT #JunoSR1 (4th respin) >>>> 4.30.1.Alpha1-SNAPSHOT #KeplerSR0, 1rst respin >>>> >>> Why are you releasing versions with SNAPSHOT suffix? What is wrong with >>> just 4.20.6.Final? >>> >> That's something we are investigating as part of https://issues.jboss.org/browse/JBIDE-13316 . But this is not our highest priority yet. If we remove the "-SNAPSHOT", we'll probably drop the Alpha1/Final qualifier as well. > > > I think this *is* high priority. > > Without it we don't have the option of building a component with a stable parent pom. If it stays -SNAPSHOT we still have to rebuild the component again and again since the parent is always moving. > > /max > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev > -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com