Details
-
Type:
Sub-task
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: 3.3.0.M4
-
Component/s: central
-
Labels:None
Gliffy Diagrams
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
Still waiting on upstream components to finish churning so we can get a new aggregate build.
Nick Boldt
added a comment - Still waiting on upstream components to finish churning so we can get a new aggregate build. The org.jboss.tools.central.discovery plugin isn't part of any build/distribution. It can, but doesn't have to be included in any feature, but mustn't be included in a build. It just needs to be built and saved in a location mentioned in the discovery.xml file. The discovery.xml file can contain more such plugins. I have built this plugin and saved it in the http://download.jboss.org/jbosstools/examples/org.jboss.tools.central.discovery_3.3.0.jar.
You can create a job to build this plugin when it is changed.
If this location isn't an appropriate location, we can change it. The entry in the directory.xml file will also have to be changed.
This way, we will be able to add extensions after releasing a distribution.
The Eclipse OSGi engine doesn't load this plugin and its version isn't important. It doesn't need a qualifier. It is only important that its name (including its version) matches the name mentioned in the directory.xml file so that the Mylyn discovery engine can find it.
JBDS can have other discovery.xml as well as other discovery plugin.
We can introduce a new discovery.xml and discovery plugin when changing a release or milestone if a new release/milestone contains different features/extensions that the user could update.
M2e uses this way to maintain the discovery feature. Their discovery jar is org.eclipse.m2e.discovery.oss-catalog.jar (there is no such a plugin in the m2e build). They use the Mylyn extension point, but don't use the Mylyn API. This jar is even not an OSGi plugin.
STS 2.7.1/2.7.2 uses the com.springsource.sts.discovery-2.7.1.jar, com.tasktop.discovery-3.6.jar and org.eclipse.mylyn.discovery-3.6.jar plugin. No one is included in the build. They use the Mylyn API.
STS 2.8.0 uses the com.springsource.sts.discovery-2.8.0.jar, com.tasktop.discovery-3.6.jar and org.eclipse.mylyn.discovery-3.6.jar plugin. They aren't included in the build.
The Mylyn distribution also doesn't include their org.eclipse.mylyn.discovery plugin.
This plugin doesn't contain source so that you don't need to create any source plugin for it.If you add a non-existing source folder to the build.properties file, the plugin won't be built in the PDE.
Snjezana Peco
added a comment - The org.jboss.tools.central.discovery plugin isn't part of any build/distribution. It can, but doesn't have to be included in any feature, but mustn't be included in a build. It just needs to be built and saved in a location mentioned in the discovery.xml file. The discovery.xml file can contain more such plugins. I have built this plugin and saved it in the http://download.jboss.org/jbosstools/examples/org.jboss.tools.central.discovery_3.3.0.jar .
You can create a job to build this plugin when it is changed.
If this location isn't an appropriate location, we can change it. The entry in the directory.xml file will also have to be changed.
This way, we will be able to add extensions after releasing a distribution.
The Eclipse OSGi engine doesn't load this plugin and its version isn't important. It doesn't need a qualifier. It is only important that its name (including its version) matches the name mentioned in the directory.xml file so that the Mylyn discovery engine can find it.
JBDS can have other discovery.xml as well as other discovery plugin.
We can introduce a new discovery.xml and discovery plugin when changing a release or milestone if a new release/milestone contains different features/extensions that the user could update.
M2e uses this way to maintain the discovery feature. Their discovery jar is org.eclipse.m2e.discovery.oss-catalog.jar (there is no such a plugin in the m2e build). They use the Mylyn extension point, but don't use the Mylyn API. This jar is even not an OSGi plugin.
STS 2.7.1/2.7.2 uses the com.springsource.sts.discovery-2.7.1.jar, com.tasktop.discovery-3.6.jar and org.eclipse.mylyn.discovery-3.6.jar plugin. No one is included in the build. They use the Mylyn API.
STS 2.8.0 uses the com.springsource.sts.discovery-2.8.0.jar, com.tasktop.discovery-3.6.jar and org.eclipse.mylyn.discovery-3.6.jar plugin. They aren't included in the build.
The Mylyn distribution also doesn't include their org.eclipse.mylyn.discovery plugin.
This plugin doesn't contain source so that you don't need to create any source plugin for it.If you add a non-existing source folder to the build.properties file, the plugin won't be built in the PDE.
OK, how about this new approach involving a new Hudson job which will:
a) fetch sources from ~/trunk/central/plugins/ and ~/trunk/build/parent; check for changes at interval of 6hrs (like other components do)
b) build the discovery jar using a generated suffix (and timestamp) if changes found or upstream job runs successfully
c) generate a new directory.xml
d) push both new files into http://download.jboss.org/jbosstools/discovery
Nick Boldt
added a comment - OK, how about this new approach involving a new Hudson job which will:
a) fetch sources from ~/trunk/central/plugins/ and ~/trunk/build/parent; check for changes at interval of 6hrs (like other components do)
b) build the discovery jar using a generated suffix (and timestamp) if changes found or upstream job runs successfully
c) generate a new directory.xml
d) push both new files into http://download.jboss.org/jbosstools/discovery Upon yet further discussion... the simplest approach has been to keep building the jar as part of the Cental component, aggregating it into the JBT Aggregate, and when it's time to publish from /nightly/ to /development/, updating a file in SVN here:
to point at the absolute http path to the latest version of the jar.
Nick Boldt
added a comment - Upon yet further discussion... the simplest approach has been to keep building the jar as part of the Cental component, aggregating it into the JBT Aggregate, and when it's time to publish from /nightly/ to /development/, updating a file in SVN here:
https://svn.jboss.org/repos/jbosstools/trunk/download.jboss.org/jbosstools/updates/development/indigo/
to point at the absolute http path to the latest version of the jar. OK, so here's what we have now:
http://svn.jboss.org/repos/jbosstools/branches/jbosstools-3.3.0.M4/central/plugins/org.jboss.tools.central/src/org/jboss/tools/central/JBossCentralActivator.java -> http://download.jboss.org/jbosstools/updates/development/indigo/jbosstools-directory.xml (manually placed there for now w/ manually placed jar committed to SVN)
http://svn.jboss.org/repos/jbosstools/trunk/central/plugins/org.jboss.tools.central/src/org/jboss/tools/central/JBossCentralActivator.java -> http://download.jboss.org/jbosstools/updates/nightly/trunk/jbosstools-directory.xml
These jobs will control creation of replacement xml and jar:
https://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.component--central/
https://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.aggregate/
https://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_stable_branch.component--central/
https://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_stable_branch.aggregate/
When it's time to push M4 into development/indigo folder, I just need to remember to update https://svn.jboss.org/repos/jbosstools/trunk/download.jboss.org/jbosstools/updates/development/indigo/jbosstools-directory.xml to point at jar included in the M4 aggregate site. Note added here:
Nick Boldt
added a comment - - edited OK, so here's what we have now:
http://svn.jboss.org/repos/jbosstools/branches/jbosstools-3.3.0.M4/central/plugins/org.jboss.tools.central/src/org/jboss/tools/central/JBossCentralActivator.java -> http://download.jboss.org/jbosstools/updates/development/indigo/jbosstools-directory.xml (manually placed there for now w/ manually placed jar committed to SVN)
http://svn.jboss.org/repos/jbosstools/trunk/central/plugins/org.jboss.tools.central/src/org/jboss/tools/central/JBossCentralActivator.java -> http://download.jboss.org/jbosstools/updates/nightly/trunk/jbosstools-directory.xml
These jobs will control creation of replacement xml and jar:
https://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.component--central/
https://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.aggregate/
https://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_stable_branch.component--central/
https://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_stable_branch.aggregate/
When it's time to push M4 into development/indigo folder, I just need to remember to update https://svn.jboss.org/repos/jbosstools/trunk/download.jboss.org/jbosstools/updates/development/indigo/jbosstools-directory.xml to point at jar included in the M4 aggregate site. Note added here:
https://svn.jboss.org/repos/devstudio/trunk/documentation/Release_Guide/Releng_And_Release_Guide.pdf.Chapter.8.Release.addenda_2011-JBT.txt Closing.
Nick Boldt
added a comment - Closing. Closing so QE won't worry about this.
Nick Boldt
added a comment - Closing so QE won't worry about this. 
feature added to central site; added as hidden feature to aggregate site.
Waiting on respins to verify workflow:
https://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.component--central/ 24+
https://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.aggregate/ 4033+