b3 http://dev.eclipse.org/mhonarc/lists/b3/maillist.html b3 en-us Wed, 05 Jun 2013 19:20:14 GMT Wed, 05 Jun 2013 19:20:14 GMT http://blogs.law.harvard.edu/tech/rss MHonArc RSS 2.0 RCFile webmaster@eclipse.org (Webmaster) webmaster@eclipse.org (Webmaster) b3 http://www.eclipse.org/eclipse.org-common/themes/Phoenix/images/eclipse_home_header.jpg http://dev.eclipse.org/mhonarc/lists/b3/maillist.html [b3] Extrema - Lista aprovados http://dev.eclipse.org/mhonarc/lists/b3/msg00007.html Extrema ALANA ARAGAO VASCONCELOS, KARINE ESPINOLA CARDINS GOMES, EURIDEIA FERREIRA LEITE, MIRELA ALBUQUERQUE BRITO, JOÃO CARLOS MOREIRA DE CARVALHO, CAROLINE PINHEIRO ROCHA SAMPAIO, MANUELA SANTOS MARIANO, IGOR TORRES FERNANDES. ROGERIO MUNIZ DE LIMA, EDMI... Extrema ALANA ARAGAO VASCONCELOS, KARINE ESPINOLA CARDINS GOMES, EURIDEIA FERREIRA LEITE, MIRELA ALBUQUERQUE BRITO, JOÃO CARLOS MOREIRA DE CARVALHO, CAROLINE PINHEIRO ROCHA SAMPAIO, MANUELA SANTOS MARIANO, IGOR TORRES FERNANDES. ROGERIO MUNIZ DE LIMA, EDMILTON DE ALMEIDA LIMA, MARINA PESSOA MOTA, JOSE DEMETRIO CAVALCANTE NETO, TIAGO RIBEIRO BARBOSA. Cristalina. Campos Sales ANA FLÁVIA DA SILVA, LUAN MARLLUS MAIA RAULINO, FRANCISCO MARIO ROCHA DE MELO, PEDRO IGOR GARCIA COSTA, JOÃO CARLOS MOREIRA DE CARVALHO, DANIEL GUIMARAES CORDEIRO, MARIA IVONEIDE DE OLIVEIRA NASCIMENTO, JESICA FREITAS E SILVA. SILVONEIDE DE O, AYSLAN CORDEIRO DO SANTIAGO, LUCIANA SOARES F. DA SILVA, HARIANNE LEITE DE ALENCAR, REJANE SANTA CELESTINA DA SILVA. Itaúba. Bandeira do Sul ANA PAULA NEVES FERREIRA DE BARROS, LUCAS ALVES DE OLIVEIRA, GABRIEL ABREU SILVESTRE COSTA, PRISCILA MATOS DE ARAUJO SIQUEIRA, JOÃO CARLOS MOREIRA DE CARVALHO, DAVID DE LIMA RABELO, MARIA JOSÉ GERMARO PEREIRA LIMA, JOAO BRUNO FRAGA. SUELANE PAULINO CORREIA, BRUNO CASTRO DA SILVA, LUIZ GUSTAVO BEZERRA FEITOSA, HUGO IRVING DA SILVA, RICARDO LUIS JACOME DE OLIVEIRA FILHO. Itaúba. ]]> Wed, 05 Jun 2013 19:11:30 GMT http://dev.eclipse.org/mhonarc/lists/b3/msg00007.html davidanderson2374@xxxxxxx (David Anderson) Re: [b3] Cumulative aggregation http://dev.eclipse.org/mhonarc/lists/b3/msg00006.html As far as I know, this is exactly the way it will work if you never "CLEAN" your build output location. You might ask on the eclipse.b3 newsgroup/forum ... I'm don't think many follow this "users lists" and that news group is where I ask all my "user quest... As far as I know, this is exactly the way it will work if you never "CLEAN" your build output location.

You might ask on the eclipse.b3 newsgroup/forum ... I'm don't think many follow this "users lists" and that news group is where I ask all my "user questions" :) and get pretty good responses and response times.

I'm sure you are aware of all the additional issues this may raise:
 Sometimes you might _have_ to remove something (say, if its illegal, or contains an especially dangerous bug),
 Whether or not someone "gets the same thing" depends on features specifying exact versions for other features they include.
 It depends on stuff being added having unique version/qualifiers if the content has changed. For example, if someone submits something unsigned, gets added to your master repo, and then later wants to add a signed version (with same id and qualifier) the aggregator will think it already has it so won't replace it, as far as I know).
 Etc.

HTH





From:        Pascal Rapicault <pascal.rapicault@xxxxxxxxxxxx>
To:        "b3@xxxxxxxxxxx" <b3@xxxxxxxxxxx>,
Date:        03/11/2013 12:30 PM
Subject:        [b3] Cumulative aggregation
Sent by:        b3-bounces@xxxxxxxxxxx



Hi
 
I would like to know if it possible for the aggregation to keep accumulating content in the final repository rather than just pick the most recent version.
The situation I have is as follow, I aggregate content from an external update site and I want to make sure that for each run of the aggregator the most recent (and valid) version is added to the aggregate but the previous version retained because my users may still need those.
 
Thanks,
 
Pascal_______________________________________________
b3 mailing list
b3@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/b3
]]> Tue, 19 Mar 2013 04:52:11 GMT http://dev.eclipse.org/mhonarc/lists/b3/msg00006.html david_williams@xxxxxxx (David M Williams) [b3] Cumulative aggregation http://dev.eclipse.org/mhonarc/lists/b3/msg00005.html Hi I would like to know if it possible for the aggregation to keep accumulating content in the final repository rather than just pick the most recent version. The situation I have is as follow, I aggregate content from an external update site and I want...

Hi

 

I would like to know if it possible for the aggregation to keep accumulating content in the final repository rather than just pick the most recent version.

The situation I have is as follow, I aggregate content from an external update site and I want to make sure that for each run of the aggregator the most recent (and valid) version is added to the aggregate but the previous version retained because my users may still need those.

 

Thanks,

 

Pascal

]]> Mon, 11 Mar 2013 16:29:58 GMT http://dev.eclipse.org/mhonarc/lists/b3/msg00005.html pascal.rapicault@xxxxxxx (Pascal Rapicault) Re: [b3] Partial IUs http://dev.eclipse.org/mhonarc/lists/b3/msg00004.html Great thanks. From: b3-bounces@xxxxxxxxxxx [mailto:b3-bounces@xxxxxxxxxxx] On Behalf Of David M Williams Sent: March-06-13 11:05 PM To: B3 Users Subject: Re: [b3] Partial IUs Not sure that you mean by &quot;expand&quot;, but I think the answer is &quot;yes;. In Sim....

Great thanks.

 

From: b3-bounces@xxxxxxxxxxx [mailto:b3-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent: March-06-13 11:05 PM
To: B3 Users
Subject: Re: [b3] Partial IUs

 

Not sure that you mean by "expand", but I think the answer is "yes". In Sim. Release, when people used to use "legacy" site.xml files "by accident", the b3 aggregator "downloads everything", and "creates a local repo" (if that's the phrase) and then "picks from that" what's needed for aggregation. Much less efficient, but, it works (well, if there is an error from that site, the error messages are a little harder to understand, but, probably not for someone who is expecting a legacy site to be used).

HTH




From:        Pascal Rapicault <pascal.rapicault@xxxxxxxxxxxx>
To:        "b3@xxxxxxxxxxx" <b3@xxxxxxxxxxx>,
Date:        03/06/2013 04:52 PM
Subject:        [b3] Partial IUs
Sent by:        b3-bounces@xxxxxxxxxxx




Hi,
 
When b3 mirrors a legacy update site, will it expand the partial IUs that are generated by default by p2?
 
Pascal_______________________________________________
b3 mailing list
b3@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/b3

]]> Thu, 07 Mar 2013 14:28:38 GMT http://dev.eclipse.org/mhonarc/lists/b3/msg00004.html pascal.rapicault@xxxxxxx (Pascal Rapicault) Re: [b3] Partial IUs http://dev.eclipse.org/mhonarc/lists/b3/msg00003.html Not sure that you mean by &quot;expand&quot;, but I think the answer is &quot;yes&quot;. In Sim. Release, when people used to use &quot;legacy&quot; site.xml files &quot;by accident&quot;, the b3 aggregator &quot;downloads everything&quot;, and &quot;creates a local repo&quot; (if that's the phrase) and then quot;p... Not sure that you mean by "expand", but I think the answer is "yes". In Sim. Release, when people used to use "legacy" site.xml files "by accident", the b3 aggregator "downloads everything", and "creates a local repo" (if that's the phrase) and then "picks from that" what's needed for aggregation. Much less efficient, but, it works (well, if there is an error from that site, the error messages are a little harder to understand, but, probably not for someone who is expecting a legacy site to be used).

HTH




From:        Pascal Rapicault <pascal.rapicault@xxxxxxxxxxxx>
To:        "b3@xxxxxxxxxxx" <b3@xxxxxxxxxxx>,
Date:        03/06/2013 04:52 PM
Subject:        [b3] Partial IUs
Sent by:        b3-bounces@xxxxxxxxxxx



Hi,
 
When b3 mirrors a legacy update site, will it expand the partial IUs that are generated by default by p2?
 
Pascal_______________________________________________
b3 mailing list
b3@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/b3
]]> Thu, 07 Mar 2013 04:14:56 GMT http://dev.eclipse.org/mhonarc/lists/b3/msg00003.html david_williams@xxxxxxx (David M Williams) Re: [b3] Validate changes http://dev.eclipse.org/mhonarc/lists/b3/msg00002.html I don't think so, if you mean literally &quot;validate the content metadata constraints&quot;. If you really want one repo from 50, the whole &quot;validation&quot; takes place .. and, this is a good thing since something in one repo might invalidate something in other repos,... I don't think so, if you mean literally "validate the content metadata constraints". If you really want one repo from 50, the whole "validation" takes place .. and, this is a good thing since something in one repo might invalidate something in other repos, even though the changed repo is itself "self valid". But, if you mean "get all the artifacts again", then its a clear "yes", there is a "BUILD" and "CLEAN_BUILD" option ... the one just gets any new artifacts, the other removes all the artifacts and then re-fetches them.  Of course, you probably have already seen the VALIDATE option which doesn't fetch any artifacts, and that's probably what you  are asking about. Of course, the good news is the b3 aggregator uses pretty much pure p2 API so I assume it takes advantage of how ever p2 caches content meta-data ... so who better to find if any improvements are needed there? :)

I say "I don't think so", since you might be able to do more with dividing things into logical "validation sets" and then (externally) choose which you want to validate .... but, just guessing here. I've not worked much with validation sets.

But, I can say in "Simultaneous Release", we can routinely validate 50 or so repositories, and its pretty quick ... of course, as you know, depends on their size, network connections, etc. On the eclipse production server, we don't do/have any pure VALIDATE jobs ... just because I never got around to it or saw a need, but I have done that locally (slower network) and (from my vague memory) just takes 15 minutes or so.

HTH




From:        Pascal Rapicault <pascal.rapicault@xxxxxxxxxxxx>
To:        "b3@xxxxxxxxxxx" <b3@xxxxxxxxxxx>,
Date:        03/06/2013 04:48 PM
Subject:        [b3] Validate changes
Sent by:        b3-bounces@xxxxxxxxxxx



Hi,
 
Iâm new to b3 and would like to use it to create an aggregation repo from well over 50 p2 repos.
Given that there is not a lot changes in each repository, and I would like to run this process daily, I would like to know if it is possible to only validation of the content that has changed.
 
Thx
 
Pascal_______________________________________________
b3 mailing list
b3@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/b3
]]> Thu, 07 Mar 2013 03:58:09 GMT http://dev.eclipse.org/mhonarc/lists/b3/msg00002.html david_williams@xxxxxxx (David M Williams) [b3] Partial IUs http://dev.eclipse.org/mhonarc/lists/b3/msg00001.html Hi, When b3 mirrors a legacy update site, will it expand the partial IUs that are generated by default by p2? Pascal

Hi,

 

When b3 mirrors a legacy update site, will it expand the partial IUs that are generated by default by p2?

 

Pascal

]]> Wed, 06 Mar 2013 21:50:40 GMT http://dev.eclipse.org/mhonarc/lists/b3/msg00001.html pascal.rapicault@xxxxxxx (Pascal Rapicault) [b3] Validate changes http://dev.eclipse.org/mhonarc/lists/b3/msg00000.html Hi, I&#8217;m new to b3 and would like to use it to create an aggregation repo from well over 50 p2 repos. Given that there is not a lot changes in each repository, and I would like to run this process daily, I would like to know if it is possible to only val...

Hi,

 

I’m new to b3 and would like to use it to create an aggregation repo from well over 50 p2 repos.

Given that there is not a lot changes in each repository, and I would like to run this process daily, I would like to know if it is possible to only validation of the content that has changed.

 

Thx

 

Pascal

]]> Wed, 06 Mar 2013 21:46:22 GMT http://dev.eclipse.org/mhonarc/lists/b3/msg00000.html pascal.rapicault@xxxxxxx (Pascal Rapicault)