Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] MORE Issues !!! ... Re: Is it acceptable to have two com.google.common.collect providers?

David,

(Ok, The OCL milestones repository is in order again).

Thanks for your tip, I'll identify the plugins which need their qualifier version need increased for M5.

On the other hand, is not there any way to make the aggregator fail in case the bundles which feed it are not signed ?

Cheers,
Adolfo.

El 15/12/2011 16:04, David M Williams escribió:
Yes, for M4, unsigned content wouldn't justify a respin. Its not a
"blocking" problem nor (directly) causes harm. Its not great ... but ...
not so bad progress can't continue.

One problem, if you have unsigned content, with one version/qualifier, once
you get it signed (e.g. next milestone) you'll need to be sure the
version/qualifiers all increase or else someone who "picked up" old,
unsigned one, might not get new signed one installed into their workbench
or product.  Just a general principle.

And, it seems you are not the only one with unsigned content in M4 :(
http://build.eclipse.org/juno/simrel/reports/verifydiroutput/unsigned.txt

Tip for all: Even if you do everything exactly right, the signing process
can occasionally fail, so its recommended you double check all is signed
from your build, especially for milestones and releases.
For more information, see
http://wiki.eclipse.org/JAR_Signing#Can_the_signing_process_fail.3F

Thanks for the care,







From:	Adolfo Sánchez-Barbudo Herrera <adolfosbh@xxxxxxxxxxxxxxxx>
To:	cross-project-issues-dev@xxxxxxxxxxx,
Date:	12/15/2011 10:21 AM
Subject:	[cross-project-issues-dev] MORE Issues !!! ... Re: Is it
            acceptable to have two com.google.common.collect providers?
Sent by:	cross-project-issues-dev-bounces@xxxxxxxxxxx



David,

I've detected more problems, which I'm not sure it merits a respin or it
doesn't in a milestone.

Don't ask me about the reasons (Honestly, I don't know them right know) but
as you may check in the attachment that our milestones repository (used to
contribute to the simultaneous release) has a corrupted M4 repository:

1. It contains two bundles per source project ( xxx-1639 and xxx-1651).
2. worse, one of them (xxx-1639) is not signed.
3. worse, the bundle caught by the aggregator is the unsigned one :(

That means that the M4 staging repository contains unsigned content, which
I'm not sure is a strong cause for a respin. In any case, I'm doing a new
OCL Core and Tools M4a builds, just in case is necessary for the respin. In
any case, we will remove the corrupted OCL Core repository and create a new
one for our consumers.

More guesses about the cause of this damned milestones repository later.

Regards and apologies for the inconveniences,
Adolfo.

El 15/12/2011 14:25, Ed Willink escribió:
      Hi

      In Indigo, the com.google.common.collect package was (and still is)
      provided by the com.google.collect plugin.

      It is now also provided by the com.google.guava plugin.

      For M4, Xtext 2.2.1 switched to Guava and so switched provider, but
      the old provider is still available in repositories for downstream
      projects that neglect to update their dependencies accurately.

      As a consequence, the M4 OCL Tools contribution provides broken
      editors. Since these are technically 'Examples', a respin is clearly
      not merited, so MDT/OCL will be providing an M4a.

      However it seems appropriate to at least warn the community of this
      hazard, and ask whether this is a serious breach of versioning
      principles.

          Regards

              Ed Willink
      _______________________________________________
      cross-project-issues-dev mailing list
      cross-project-issues-dev@xxxxxxxxxxx
      https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


--
                                               
    Open     Adolfo Sánchez-Barbudo Herrera    
  Canarias,  adolfosbh(at)opencanarias(dot)com 
    S.L.     C/Elías Ramos González, 4, ofc.   
             304                               
             38001 SANTA CRUZ DE TENERIFE      
             Tel.: +34 922 240231              
                                               

[attachment "Snapshot.PNG" deleted by David M Williams/Raleigh/IBM]
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


--
Open Canarias, S.L.
Adolfo Sánchez-Barbudo Herrera
adolfosbh(at)opencanarias(dot)com
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231

Back to the top