[jbosstools-issues] [JBoss JIRA] (JBDS-2623) Create target platform for mirrored parts of Central / 3rd Party Extras

Wed Sep 25 10:10:02 EDT 2013

    [ https://issues.jboss.org/browse/JBDS-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12807331#comment-12807331 ] 

Nick Boldt commented on JBDS-2623:
----------------------------------

I asked Mickael:
{quote}
On JBDS-2623 I noticed that the new SpringIDE 3.3 site, after we fixed the metadata, does not list the no-longer-partial IU when browsed w/ the p2 browser. See attached.
Is this OK (bug in the p2 browser?), or do you think there's something else we need to do in the build.xml script?
https://github.com/jbosstools/jbosstools-download.jboss.org/blob/master/jbosstools/updates/requirements/springide/build.xml#L72
{quote}

And he replied:
{quote}
p2-browser is pretty basic and is just a TreeViewer for an IMetadataRepository. I don't think there can be such a bug. So it seems like this IU is not part of the repository.
It looks like the p2.remove.iu did work and removed the IU, but the p2.publish.featuresAndBundles probably didn't. I tend to think that it is not such a big deal since neither the TP nor Central seems to require this IU.
{quote}

So to verify, I did this:

1. unpack /home/nboldt/tmp/Eclipse_Bundles/eclipse-jee-kepler-R-linux-gtk-x86_64.tar.gz
2. launch Eclipse in a new workspace
3. Install JBoss Central Community feature 1.2.0.Final-v20130719-2050-B70 from http://download.jboss.org/jbosstools/updates/stable/kepler/
4. restart when prompted
5. launch Central, search for Spring IDE connector, and install it.
6. On restart, the only console message logged is this, which seems trivial and not a problem:

{code}
!ENTRY org.springsource.ide.eclipse.commons.frameworks.core 0 0 2013-09-25 10:02:08.875
!MESSAGE Result of converting legacy STS 2.x workspace preferences to 3.x
!SUBENTRY 1 org.springsource.ide.eclipse.commons.frameworks.core 0 0 2013-09-25 10:02:08.875
!MESSAGE Converted legacy STS plugin preferences
!SUBENTRY 1 unknown 0 0 2013-09-25 10:02:08.875
!MESSAGE OK
!SUBENTRY 1 org.springsource.ide.eclipse.commons.frameworks.core 0 0 2013-09-25 10:02:08.876
!MESSAGE Converted legacy Roo plugin state locations
!SUBENTRY 1 org.springsource.ide.eclipse.commons.frameworks.core 0 0 2013-09-25 10:02:08.876
!MESSAGE Converted legacy STS plugin state locations
{code}

Therefore I think we're good here. Next step is to release this new TP at the same time we release Alpha2.

> Create target platform for mirrored parts of Central / 3rd Party Extras
> -----------------------------------------------------------------------
>
>                 Key: JBDS-2623
>                 URL: https://issues.jboss.org/browse/JBDS-2623
>             Project: Developer Studio (JBoss Developer Studio)
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: 3rd-party-certification, 3rd-party-dependencies, central, requirements, updatesite, upstream
>    Affects Versions: 7.0.0.Beta1
>            Reporter: Nick Boldt
>            Assignee: Nick Boldt
>             Fix For: 7.1.0.Alpha2, 7.1.0.Beta1
>
>         Attachments: 2623-manual-hack.png, 2623-p2browser-shows-datanucleus-missing.png, 2623-remove-and-regen.png
>
>
> As discussed in JBDS-2486 ( https://issues.jboss.org/browse/JBDS-2486?focusedCommentId=12770186&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12770186 ) we need to produce a target file for use with Central.
> Goal here would be to build the Extras site (used by Central) as a TP update site rather than a composite of mirrors, which would provide us with a manifest of exactly which versions of these duped IUs were to be contained in the Extras site. If something bad happens, we can add duplicate versions of IUs to the TP and know exactly why we include both Jetty 8.1.3 and 8.1.9 (for example) or two different spins of WindowBuilder. This would mean it wouldn't matter if we filtered content out of the mirrors, because we'd be handling the filtering in a single place (extras.target) rather than multiple build.xml files.
> In future, we would:
> *    mirror the individual upstream projects into /updates/requirements/<project> [on dl.jb.org]
> *    mirror the individual upstream projects into /updates/requirements/<project> [on www.qa]
> *    produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on dl.jb.org]
> *    produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on www.qa]
> *    produce an aggregate of the stuff that Central needs, and publish that instead of the composite [on ds.jb.com]
> *    add a whole new aggregate for old + new content

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira