Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [dash-dev] Athena: hide the "all" feature

Add a category.xml [0] into your .releng project.
[0]http://wiki.eclipse.org/Common_Build_Infrastructure/Update_Site

Thank you for pointing me to this link. I have created a category.xml in my releng project, and both categories and tests work now!
Thanks for your invaluable help.

On Wed, Dec 9, 2009 at 3:18 AM, Nick Boldt <nickboldt@xxxxxxxxx> wrote:
   (Also, have you tried using a custom site.xml or categories.xml to
   generate the update site?)
No, I didn't know I could. How would I do this with Athena?

Add a category.xml [0] into your .releng project.

[0]http://wiki.eclipse.org/Common_Build_Infrastructure/Update_Site

Or, if you prefer to generate everything, then slice n' dice it, there's the p2.mirror [1] application to partially mirror a repo into another place. But even better, there's the Buckminster Aggregator, which allows you to rewrite/reorg categories and merge update sites too. I have a sample script [2], [3] that does this for merging 3 update sites into the larger JBoss Tools repo, including moving runtime and sdk features into their correct categories.

[1]http://wiki.eclipse.org/Equinox/p2/Ant_Tasks
[2]http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.dash/athena/org.eclipse.dash.commonbuilder/org.eclipse.dash.common.releng/tools/scripts/aggregateRepos.xml?root=Technology_Project&view=markup
[3]http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.dash/athena/org.eclipse.dash.commonbuilder/org.eclipse.dash.common.releng/tools/scripts/aggregateRepos.properties?root=Technology_Project&view=markup


On Fri, Dec 4, 2009 at 8:26 PM, Nick Boldt <nickboldt@xxxxxxxxx <mailto:nickboldt@xxxxxxxxx>> wrote:

   You mean the *tests* fail with that error? That's because that
   feature is installed into the test runtime in order to be able to
   run the tests.

   To support what you want to do, we'd have to add another property
   into build.properties or testing.properties to allow a list of IUs
   to be installed for the test runtime.

   Or maybe setting "mainFeatureToBuildID" to something else in
   testing.properties will override the value used to build with some
   other feature for running the tests? Try it and let me know if that
   works.

   Why exactly do you not want this all-in-one feature on your update site?

   (Also, have you tried using a custom site.xml or categories.xml to
   generate the update site?)

   N

   Nicolas Bros wrote:

       Thanks for your help. I have removed the "bin.includes" from the
       feature, and added a "p2.inf" file with the 2 lines you gave,
       but the build now fails with this error:
       The installable unit org.eclipse.gmt.modisco.all.feature.group
       has not been found.

       On Thu, Dec 3, 2009 at 5:12 PM, Andrew Niefer
       <aniefer@xxxxxxxxxx <mailto:aniefer@xxxxxxxxxx>
       <mailto:aniefer@xxxxxxxxxx <mailto:aniefer@xxxxxxxxxx>>> wrote:


          This will depend on how Athena does its integration with p2.
        Nick
          should be able to clarify.

          - if using "generate.p2.metadata=true", this is generating p2
          metadata based on the binary results of the build.  In this case,
          simply not having a binary jar for this top level feature will do
          what you want.  This is done by making sure that the
          build.properties for the feature does not have a "bin.includes"
          property

          - if using "p2.gathering=true", this is generating p2 metadata
          directly from the source, in this case you will end up with a
          metadata group (but no artifact if you don't define
       bin.includes).
           In this case you will want to turn off the "group" property, do
          this by providing a p2.inf beside the feature.xml and adding the
          following:
          properties.1.name <http://properties.1.name>
          <http://properties.1.name>=org.eclipse.equinox.p2.type.group

          properties.1.value=false

          -Andrew

          From:       Nicolas Bros <nbros@xxxxxxxxxxxxxxxx
       <mailto:nbros@xxxxxxxxxxxxxxxx>
          <mailto:nbros@xxxxxxxxxxxxxxxx <mailto:nbros@xxxxxxxxxxxxxxxx>>>


          To:         Tools for Committer Community
       <dash-dev@xxxxxxxxxxx <mailto:dash-dev@xxxxxxxxxxx>
          <mailto:dash-dev@xxxxxxxxxxx <mailto:dash-dev@xxxxxxxxxxx>>>


          Date:       12/03/2009 04:52 AM
          Subject:    [dash-dev] Athena: hide the "all" feature
          Sent by:    dash-dev-bounces@xxxxxxxxxxx
       <mailto:dash-dev-bounces@xxxxxxxxxxx>
          <mailto:dash-dev-bounces@xxxxxxxxxxx
       <mailto:dash-dev-bounces@xxxxxxxxxxx>>



                ------------------------------------------------------------------------



          Hi,

          Athena takes a single feature to build (unless I am mistaken).
          So, I have created an "all" feature that references the other
          features, and that I choose as "mainFeatureToBuildID" in my
          build.properties.

          This works fine, but I would like this feature NOT to appear
       on the
          list of features available on the update site built by
       Athena. How
          would you do this?
          --    Nicolas Bros
          R&D
          tel: 06 75 09 19 88_
          __nbros@mia-software.com_ <mailto:nbros@xxxxxxxxxxxxxxxx
       <mailto:nbros@xxxxxxxxxxxxxxxx>>

          Mia-Software, 410 clos de la Courtine
          93160 Noisy-le-Grand_
          __http://www.mia-software.com_ <http://www.mia-software.com/>


          .: model driven agility
          :._______________________________________________

          dash-dev mailing list
          dash-dev@xxxxxxxxxxx <mailto:dash-dev@xxxxxxxxxxx>
       <mailto:dash-dev@xxxxxxxxxxx <mailto:dash-dev@xxxxxxxxxxx>>


          https://dev.eclipse.org/mailman/listinfo/dash-dev



          _______________________________________________
          dash-dev mailing list
          dash-dev@xxxxxxxxxxx <mailto:dash-dev@xxxxxxxxxxx>
       <mailto:dash-dev@xxxxxxxxxxx <mailto:dash-dev@xxxxxxxxxxx>>


          https://dev.eclipse.org/mailman/listinfo/dash-dev



       ------------------------------------------------------------------------

       _______________________________________________
       dash-dev mailing list
       dash-dev@xxxxxxxxxxx <mailto:dash-dev@xxxxxxxxxxx>
       https://dev.eclipse.org/mailman/listinfo/dash-dev


   --    Nick Boldt :: http://nick.divbyzero.com
   Release Engineer :: Eclipse Modeling & Dash Athena
   _______________________________________________
   dash-dev mailing list
--
Nicolas Bros
R&D
tel: 06 75 09 19 88
nbros@xxxxxxxxxxxxxxxx <mailto:nbros@xxxxxxxxxxxxxxxx>
nbros.mia@xxxxxxxxx <mailto:nbros.mia@xxxxxxxxx>

Mia-Software, 410 clos de la Courtine
93160 Noisy-le-Grand
http://www.mia-software.com
.: model driven agility :.


------------------------------------------------------------------------

_______________________________________________
dash-dev mailing list
dash-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dash-dev

--
Nick Boldt :: http://nick.divbyzero.com
Release Engineer :: Eclipse Modeling & Dash Athena
_______________________________________________
dash-dev mailing list
dash-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dash-dev



--
Nicolas Bros
R&D
tel: 06 75 09 19 88
nbros@xxxxxxxxxxxxxxxx
nbros.mia@xxxxxxxxx
Mia-Software, 410 clos de la Courtine
93160 Noisy-le-Grand
http://www.mia-software.com
.: model driven agility :.

Back to the top