Re: [jbosstools-dev] [Soa-tools-list] Locus 1.1.0 is released

On Wed, Oct 23, 2013 at 10:06:08AM -0400, Rob Cernich wrote: >> Just since it seems a few key points about locus seem forgotten here >> are a >> few reminders: >> >> Locus is *not* an updatesite to use in a way that exposes it to users >> - it is >> to be used to be included in other updatesites. >> We used nexus to publish Locus so we can gather experience to use >> just pure >> mvn deploy, meaning: > > Don't you have to jump through hoops in the pom to get nexus > dependencies incorporated into a tycho project? we are not talking about nexus dependencies, we are talking about by deploying to nexus we get something everyone can do and via the unzip plugin you can use the nexus location directly as an updatesite in tycho or even from eclipse directly. It even works for snapshots: "normal" nexus/maven artifact (directory): https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... "unzipped" neexus/maven artifac: https://repository.jboss.org/nexus/content/unzip/unzip/org/jboss/tools/lo... This means alot of the "magic" of the shell scripts and jenkins jobs can be greatly reduced. > Is the use case that specific Locus plugins will be added to a target > platform, resolved through a normal dependency (as opposed to using a > p2 repo in the pom)? Sorry in advance for my ignorance here (seems > like I might learn something). You can see more here: https://issues.jboss.org/browse/JBIDE-15045 https://issues.jboss.org/browse/ORG-1710 Note, we are using locus to test this since locus is "just" a collection of plugins which gets aggregated directly into other sites and thus no "vanity urls" needed for it. If it turns out well we'll ask if we can start publish our eclipse plugins and possibly aggregate sites to nexus (i.e. do they have storage enough, can it handle the extra load etc.). We'll probably still aggregate/publish to a separate host for vanity/stable urls (i.e. download.jboss.org/*) but at least alot of complexity dissapears for component publishing etc. /max > >> a) no need for maintaining external buld scripts for publishing >> b) stop/reduce the amount needed for publishing (being able to have >> others >> than a few people do these releases) >> c) stop hiding or allowing "I can just edit the produced content >> manually >> on the running server" >> >> About C - if the html is so often wrong these needs to change then that >> should simply not be included in the published updatesite zip; >> or we simply do a basic respin to fix it - everything is tracked in >> git as >> opposed to "change it live on the server". >> >> I think doing a basic 1.1.1.Final (or even just 1.1.0.Final) with the >> current >> locus setup is a trivial excercise compared to any manual >> edits and tweaking which then gets lots for next time we build it. >> >> /max >> >> On Wed, Oct 23, 2013 at 12:04:27AM -0400, Max Andersen wrote: >> >Guys, >> > >> >Just do a 1.1.1.Final and get it over with. >> > >> >It really shouldn't be this long to get done. That is the same as >> doing the >> >mirroring and done much faster. >> > >> >It's just a quick update to fix minor issue for consistency. >> > >> >1.2.0.Final makes no sense since we didn't change anything >> functionality >> >wise. >> > >> >1.1.0.1.Final is just as borked to use as 1.1.0. >> > >> >And "lets just change the index html straight on apache" is >> pointless since >> >that is just continue doing things in a way that can't be reproduced >> easily >> >and hides the actual changes (no matter how small) >> > >> >/max >> > >> >/max (sent from my phone) >> > >> > >> >> On 22/10/2013, at 20.43, Rob Cernich <rcernich(a)redhat.com&gt; wrote: >> >> >> >> Maybe I've missed something in this whole discussion, but isn't a >> version >> >> of Locus simply a collection of specific versions of various >> OSGi-fied >> >> plugins? If so, a version of Locus is simply a version in a pom >> (that >> >> creates Locus), a tag in source control, some text in a p2 >> repository and >> >> a path segment in a URL. If it is that simple, can't we just mirror >> >> what's already out there to a different folder and everybody can >> simply >> >> update their Locus references to point to the new URL? >> >> >> >> ----- Original Message ----- >> >>> Since the change we're proposing is really a non-change (just >> cosmetic >> >>> alterations), why not 1.1.1.Final (maintenance) or even >> 1.1.0.1.Final >> >>> (trivial maintenance)? >> >>> >> >>> 1.2.0 suggests "we actually did something new" not "due to the >> limits of >> >>> Nexus / Maven we are required to bump the version simply to >> adhere to >> >>> versioning conventions that state we should have '.Final' as the >> >>> qualifier on a release even though there's no actual IU in the site >> >>> which contains this version, so it's entirely just a label". >> >>> >> >>> The more I think about this, the more the idea of having to respin >> >>> simply for a cosmetic alteration seems pointless. Bumping the >> version >> >>> means I'll have to push new bits onto download.jboss.org AND >> JBTIS will >> >>> have to (again) update their TP references in order to pull down >> *the >> >>> identical bits*. That's a lot of cascading work for a purely >> cosmetic >> >>> change. >> >>> >> >>> So, other than the fact that the site doesn't have .Final in >> Nexus, and >> >>> it says "Nightly" instead of "Stable", do we *REALLY* need to >> bother? >> >>> >> >>> Surely these are trivial problems we can fix in concert with some >> ACTUAL >> >>> fixes or new content in Locus, for the 1.2 release in the far-flung >> >>> future. >> >>> >> >>> WDYT? >> >>> >> >>>> On 10/22/2013 10:59 AM, Mickael Istria wrote: >> >>>>> On 10/22/2013 03:32 PM, Nick Boldt wrote: >> >>>>> -1 for fake commits just to bump the timestamp. A rebuild should >> >>>>> change nothing but the build ID (build timestamp + build number). >> >>>> I'm ok with that. >> >>>>> +1 for re-releasing the bits as 1.1.0.Final, with the corrected >> >>>>> index.html ("Stable Release" not "Nightly Build") >> >>>> What about 1.2.0.Final? I've already made 1.2.0-SNAPSHOT follow >> 1.1.0 so >> >>>> 1.2.0.Final would be easier. >> >>>> -- >> >>>> Mickael Istria >> >>>> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> >> >>>> My blog <http://mickaelistria.wordpress.com> - My Tweets >> >>>> <http://twitter.com/mickaelistria> >> >>> >> >>> -- >> >>> Nick Boldt :: JBoss by Red Hat >> >>> Productization Lead :: JBoss Tools & Dev Studio >> >>> http://nick.divbyzero.com >> >>> _______________________________________________ >> >>> jbosstools-dev mailing list >> >>> jbosstools-dev(a)lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> >> _______________________________________________ >> >> jbosstools-dev mailing list >> >> jbosstools-dev(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>