That the dates go backwards is a bit strange, I agree, but it's because we switched to using the jgit timestamp provider, so you're seeing the dates that content ACTALLY changed in git, rather than just getting a "when we built it" timestamp. This ensures that respins of the whole Locus project don't result in needlessly upversioned plugins if only one or two plugins change between respins/releases. https://github.com/mickaelistria/jbosstools-locus/commit/b8d577f1d35259a7... PR to move to the updated (but "older timestamped" versions): https://issues.jboss.org/browse/JBTIS-195 https://github.com/jbosstools/jbosstools-integration-stack/pull/137 > On 10/18/2013 11:23 AM, Paul Leacu wrote: >> >> Hey Mickael - >> Just checking on locus component versions - I'm currently >> picking up these: >> >> <unit id="org.jboss.tools.locus.jcip.annotations" >> version="1.0.0.Final-v20130820-2112-B41"/> >> <unit id="org.jboss.tools.locus.mockito" >> version="1.9.5.Final_patched_TEIIDDES-1681-v20130820-2112-B41"/> >> <unit id="org.jboss.tools.locus.sf.saxon" >> version="9.2.1.5j-Final-v20130820-2112-B41"/> >> >> from >> >> <repository >> location="http://download.jboss.org/jbosstools/updates/integration/l... >> >> >> Your released locus update site has these: >> >> >> org.jboss.tools.locus.jcip.annotations.source_1.0.0.Final-v20130711-1603-B54.jar >> >> >> org.jboss.tools.locus.jcip.annotations_1.0.0.Final-v20130711-1603-B54.jar >> >> org.jboss.tools.locus.mockito.source_1.9.5.Final_patched_TEIIDDES-1681-v20130711-1603-B54.jar >> >> >> org.jboss.tools.locus.mockito_1.9.5.Final_patched_TEIIDDES-1681-v20130711-1603-B54.jar >> >> >> Do I want to pick up the 07/11 in lieu of the 08/20? >> >> Thanks! >> --paull >> >> >> >> ----- Original Message ----- >>> From: "Mickael Istria" <mistria(a)redhat.com&gt; >>> To: "jbosstools-dev jbosstools-dev" <jbosstools-dev(a)lists.jboss.org&gt;, >>> "soa-tools-list" <soa-tools-list(a)redhat.com&gt; >>> Sent: Friday, October 18, 2013 10:53:25 AM >>> Subject: [Soa-tools-list] Locus 1.1.0 is released >>> >>> Hi all, >>> >>> To all Locus users: >>> Locus 1.1.0 has been released, and its URL is >>> https://repository.jboss.org/nexus/content/unzip/unzip/org/jboss/tools/lo... >>> >>> . Please use this URL instead of the previous ones. >>> Source has been tagged "1.1.0" and is available at >>> https://github.com/jbosstools/jbosstools-locus/tree/1.1.0 >>> >>> Master was updated to start a new stream 1.2.0-SNAPSHOT, snapshots >>> will be >>> available at >>> https://repository.jboss.org/nexus/content/unzip/unzip/org/jboss/tools/lo... >>> >>> -- >>> Mickael Istria >>> Eclipse developer at JBoss, by Red Hat >>> My blog - My Tweets >>> >>> _______________________________________________ >>> Soa-tools-list mailing list >>> Soa-tools-list(a)redhat.com >>> https://www.redhat.com/mailman/listinfo/soa-tools-list > -- 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

In a mid-term future, I'd like to avoid using the Git commit to generate timestamp and use a "replace with baseline if equivalent" strategy.

-- 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>

_______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

Guys, it's really simple. If you use a pre-release *integration* build, with "SNAPSHOT" or "Alpha" in its name [1], then there's a chance that anything can change, including version numbers going backwards. (It's not ideal, but sh!t happens.) [1] http://download.jboss.org/jbosstools/updates/integration/locus/1.1.0.Alph... On the other hand, if you use a .Final release (which curiously doesn't have .Final in its name), then we guarantee that something back-in-timey won't happen.

[2] https://repository.jboss.org/nexus/content/unzip/unzip/org/jboss/tools/lo... Aside: it's kind of too bad that the index.html page for that site [2] says "Nightly Build". Would have liked to have fixed that before releasing it to Nexus, where it can't be fixed. Also would have been nice to include .Final on there. Meanwhile, on download.jboss.org, I *CAN* fix those issues [3]. [3] http://download.jboss.org/jbosstools/updates/stable/locus/1.1.0.Final/ (Which is another reason I prefer apache server to nexus.)

Cheers, On 10/21/2013 08:08 AM, Max Rydahl Andersen wrote: > On Mon, Oct 21, 2013 at 01:34:18PM +0200, Mickael Istria wrote: >> In a mid-term future, I'd like to avoid using the Git commit to >> generate timestamp and use a "replace with baseline if equivalent" >> strategy. > > That doesn't remove the problem of validating the actual release - > if that was applied the build would have used the wrong/old bits instead ;) > > /max >> >> -- >> 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> > >> _______________________________________________ >> 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 > -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com

On 10/21/2013 04:59 PM, Max Rydahl Andersen wrote: >That looks like a bug....mickael - did you use wrong version (1.1.0 >vs 1.1.0.Final) when releasing ? I used 1.1.0.

-- 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>

_______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

On 10/22/2013 09:32 AM, Max Rydahl Andersen wrote: > Care to do a release that fixes this Ok. > and by consequence also gets new timestamp that should be never than > anything else ? :) It wouldn't have new timestamps by default as timestamps are computed from the last commit on the given module. As the change of Locus version don't change anything inside modules, it won't create new timestamps. This requires a dummy commit on each module, which is not very nice. Anyway, I'll make this commit to have newer timestamp and release 1.1.0.Final today. -- 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>

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>

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

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".

Don't you have to jump through hoops in the pom to get nexus dependencies incorporated into a tycho project? 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).

> 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?

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).

> 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 >

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... http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-site... http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-site... 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-site... http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-site... http://download.jboss.org/jbosstools/builds/staging/jbosstools-build-site... 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(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 >>> -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com

On 10/23/2013 10:18 PM, Nick Boldt wrote: > 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. > +1 to create metadata in a Mojo and attach the metadata files to the Maven artifact so they get published along with the p2 site. -- 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> _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

The p2 repo for Locus 1.1.1.Final has been staged. Before I click on the release button, I'd like to ask anyone interested in locus to have a look at this zip, which is the exact content of upcoming p2 repo if we agree on releasing it: https://repository.jboss.org/nexus/content/repositories/jboss_releases_st... -- 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> _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev