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

Wed Oct 23 16:18:46 EDT 2013

Bear in mind too that OOTB the Nexus publish experience lacks all the 
extra metadata that publish.sh creates at build time to track stuff like 
git version used in the build, Jenkins slave & workspace path used, 
target platform(s) involved in the build, etc.

http://download.jboss.org/jbosstools/builds/staging/SwitchYard-Tools/logs/build.properties

http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-sites.aggregate.site_41/logs/ALL_REVISIONS.txt
http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-sites.aggregate.site_41/logs/build.properties

For the case of aggregate builds, we also collect things like zips and 
MD5sums for the component sites used to build the aggregate:

http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-sites.aggregate.site_41/logs/md5sums.txt
http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-sites.aggregate.site_41/logs/zip.list.txt
http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-sites.aggregate.site_41/components/

All that metadata, if still useful, would have to migrate to a mojo in 
order to be done at release-time instead of at build-time, if the plan 
is to trash publish.sh as the bridge between Jenkins job and resulting 
build folder.

N

On 10/23/2013 02:17 PM, Max Andersen wrote:
> 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/jboss/tools/locus/update.site/1.2.0-SNAPSHOT/
>
> "unzipped" neexus/maven artifac:
> https://repository.jboss.org/nexus/content/unzip/unzip/org/jboss/tools/locus/update.site/1.2.0-SNAPSHOT/update.site-1.2.0-SNAPSHOT.zip-unzip/
>
>
> 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 at redhat.com> 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 at lists.jboss.org
>>> >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>> >> _______________________________________________
>>> >> jbosstools-dev mailing list
>>> >> jbosstools-dev at 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