[JBoss JIRA] (JBIDE-21012) Why do we deploy JBT components to Nexus snapshots repo?
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21012?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-21012 at 11/4/15 11:08 AM:
--------------------------------------------------------------
To get value out of deploying JBT components' update sites to Nexus,
a) component leads need to upversion their x.y.z+1 (3rd digit) for every milestone release, eg., in a task JIRA like JBIDE-20947
b) component leads need to ensure that every time they upversion and their Nexus URL changes, they submit a PR against jbosstools-build to change the URL in the parent pom. This will ensure all projects downstream use their correct latest bits
c) releng & QE need tools to audit when a component lead forgets to do (a) and (b)
d) releng & QE need tools to audit contents of JBT/JBDS update sites, since we will no longer be able to just visually inspect the list of features [1] to ensure they all have the same BUILD_ALIAS
[1] http://download.jboss.org/jbosstools/mars/snapshots/updates/core/4.3.mars...
-----
We could adopt a numerical convention that mimics Alpha/Beta/CR/Final nomenclature. For example... instead of having a project versioned with:
* 4.3.0.Alpha1
* 4.3.0.Alpha2
* 4.3.0.Beta1
* 4.3.0.Beta2
* 4.3.0.CR1
* 4.3.0.Final/GA
we might use
* 4.3.011 (1 = Alpha, 11 = Alpha1)
* 4.3.012
* 4.3.051 (5 = Beta, 51 = Beta1)
* 4.3.052
* 4.3.091 (9 = CR/Final/GA)
* 4.3.092
then for 4.3.1 maintenance...
* 4.3.151 (51 = Beta1)
* 4.3.152 (52 = Beta2)
* 4.3.191 (91 = CR1)
* 4.3.192 (92 = CR2, if needed)
By using fully numeric BUILD_ALIAS values in the third digit instead of alphanumeric strings in the 4th, we could potentially use Nexus more easily.
So, what if a component is already on 1.5.100? Well, we'd upversion it to 1.5.151 (Beta1). If it's already on 1.9.3, it'd be moved to 1.9.351.
Only thing I need to verify w.r.t. this plan is if we can set a <version>1.5.1$\{BUILD_ALIAS}</version> with <BUILD_ALIAS>51</BUILD_ALIAS> and have maven not complain about the idea of nesting a variable in the version field.
was (Author: nickboldt):
To get value out of deploying JBT components' update sites to Nexus,
a) component leads need to upversion their x.y.z+1 (3rd digit) for every milestone release, eg., in a task JIRA like JBIDE-20947
b) component leads need to ensure that every time they upversion and their Nexus URL changes, they submit a PR against jbosstools-build to change the URL in the parent pom. This will ensure all projects downstream use their correct latest bits
c) releng & QE need tools to audit when a component lead forgets to do (a) and (b)
d) releng & QE need tools to audit contents of JBT/JBDS update sites, since we will no longer be able to just visually inspect the list of features [1] to ensure they all have the same BUILD_ALIAS
[1] http://download.jboss.org/jbosstools/mars/snapshots/updates/core/4.3.mars...
-----
We could adopt a numerical convention that mimics Alpha/Beta/CR/Final nomenclature. For example... instead of having a project versioned with:
* 4.3.0.Alpha1
* 4.3.0.Alpha2
* 4.3.0.Beta1
* 4.3.0.Beta2
* 4.3.0.CR1
* 4.3.0.Final/GA
we might use
* 4.3.011 (1 = Alpha, 11 = Alpha1)
* 4.3.012
* 4.3.051 (5 = Beta, 51 = Beta1)
* 4.3.052
* 4.3.091 (9 = CR/Final/GA)
* 4.3.092
then for 4.3.1 maintenance...
* 4.3.151 (51 = Beta1)
* 4.3.152 (52 = Beta2)
* 4.3.191 (91 = CR1)
* 4.3.192 (92 = CR2, if needed)
By using fully numeric BUILD_ALIAS values in the third digit instead of alphanumeric strings in the 4th, we could potentially use Nexus more easily.
So, what if a component is already on 1.5.100? Well, we'd upversion it to 1.5.151 (Beta1). If it's already on 1.9.3, it'd be moved to 1.9.351.
Only thing I need to verify w.r.t. this plan is if we can set a <version>1.5.1${BUILD_ALIAS}</version> with <BUILD_ALIAS>51</BUILD_ALIAS> and have maven not complain about the idea of nesting a variable in the version field.
> Why do we deploy JBT components to Nexus snapshots repo?
> --------------------------------------------------------
>
> Key: JBIDE-21012
> URL: https://issues.jboss.org/browse/JBIDE-21012
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, updatesite
> Affects Versions: 4.3.0.Final, 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> Currently, we deploy our x.y.z-SNAPSHOT update sites to the JBoss Nexus snapshots repo.
> But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just:
> * eat disk space in Nexus
> * consume time/resources in Jenkins
> Since we have the custom profile deploy-to-jboss.org in place for all our artifacts, why don't we set *maven.deploy.skip=true* in the parent pom for all the projects (except of course Locus and Browsersim Standalone, which would use maven.deploy.skip=false) ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (JBIDE-21053) IndexOutOfBoundsException in scaffold generate wizard
by Pavol Srna (JIRA)
Pavol Srna created JBIDE-21053:
----------------------------------
Summary: IndexOutOfBoundsException in scaffold generate wizard
Key: JBIDE-21053
URL: https://issues.jboss.org/browse/JBIDE-21053
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: forge
Affects Versions: 4.3.0.Final
Reporter: Pavol Srna
Message: Unhandled event loop exception during blocked modal context.
{code}
org.eclipse.swt.SWTException: Failed to execute runnable (java.lang.IndexOutOfBoundsException: Index: 2, Size: 0)
at org.eclipse.swt.SWT.error(SWT.java:4491)
at org.eclipse.swt.SWT.error(SWT.java:4406)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:138)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:4024)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3700)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.block(ModalContext.java:172)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:387)
at org.eclipse.jface.wizard.WizardDialog.run(WizardDialog.java:1002)
at org.jboss.tools.forge.ui.internal.ext.dialog.ForgeCommandDialog.run(ForgeCommandDialog.java:56)
at org.jboss.tools.forge.ui.internal.ext.wizards.ForgeWizard.performFinish(ForgeWizard.java:97)
at org.jboss.tools.forge.ui.internal.ext.wizards.ForgeWizard.performFinish(ForgeWizard.java:87)
at org.eclipse.jface.wizard.WizardDialog.finishPressed(WizardDialog.java:799)
at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java:429)
at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:619)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:248)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4230)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1491)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1514)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1499)
at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1299)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4072)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3698)
at org.eclipse.jface.window.Window.runEventLoop(Window.java:827)
at org.eclipse.jface.window.Window.open(Window.java:803)
at org.jboss.tools.forge.ui.internal.ext.dialog.WizardDialogHelper.openWizard(WizardDialogHelper.java:210)
at org.jboss.tools.forge.ui.internal.ext.dialog.WizardDialogHelper.openWizard(WizardDialogHelper.java:102)
at org.jboss.tools.forge.ui.internal.ext.dialog.UICommandListDialog$1$1.handleElementSelected(UICommandListDialog.java:233)
at org.jboss.tools.forge.ui.internal.ext.quickaccess.QuickAccessContents.handleSelection(QuickAccessContents.java:322)
at org.jboss.tools.forge.ui.internal.ext.quickaccess.QuickAccessContents.access$0(QuickAccessContents.java:312)
at org.jboss.tools.forge.ui.internal.ext.quickaccess.QuickAccessContents$6.mouseUp(QuickAccessContents.java:461)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:220)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Display.sendEvent(Display.java:4230)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1491)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1514)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1499)
at org.eclipse.swt.widgets.Widget.notifyListeners(Widget.java:1299)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4072)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3698)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$4.run(PartRenderingEngine.java:1127)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:1018)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:156)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:654)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:337)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:598)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:139)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:134)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:380)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:235)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:669)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:608)
at org.eclipse.equinox.launcher.Main.run(Main.java:1515)
Caused by: java.lang.IndexOutOfBoundsException: Index: 2, Size: 0
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at org.jboss.forge.addon.ui.impl.controller.WizardCommandControllerImpl.getCurrentEntry(WizardCommandControllerImpl.java:486)
at org.jboss.forge.addon.ui.impl.controller.WizardCommandControllerImpl.getCurrentController(WizardCommandControllerImpl.java:497)
at org.jboss.forge.addon.ui.impl.controller.WizardCommandControllerImpl.validate(WizardCommandControllerImpl.java:214)
at org.jboss.forge.addon.ui.impl.controller.NoUIWizardControllerDecorator.validate(NoUIWizardControllerDecorator.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback$2.call(ClassLoaderAdapterCallback.java:123)
at org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:42)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.invoke(ClassLoaderAdapterCallback.java:96)
at org.jboss.forge.addon.ui.controller.CommandController_$$_javassist_c9e95bc0-f945-4ada-ae34-ecb5817baed3.validate(CommandController_$$_javassist_c9e95bc0-f945-4ada-ae34-ecb5817baed3.java)
at org.jboss.tools.forge.ui.internal.ext.wizards.ForgeWizardPage.validatePage(ForgeWizardPage.java:238)
at org.jboss.tools.forge.ui.internal.ext.wizards.ForgeWizardPage.access$5(ForgeWizardPage.java:233)
at org.jboss.tools.forge.ui.internal.ext.wizards.ForgeWizardPage$1$1.run(ForgeWizardPage.java:180)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35)
at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:135)
... 58 more
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (JBIDE-21012) Why do we deploy JBT components to Nexus snapshots repo?
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-21012?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-21012:
------------------------------------
To get value out of deploying JBT components' update sites to Nexus,
a) component leads need to upversion their x.y.z+1 (3rd digit) for every milestone release, eg., in a task JIRA like JBIDE-20947
b) component leads need to ensure that every time they upversion and their Nexus URL changes, they submit a PR against jbosstools-build to change the URL in the parent pom. This will ensure all projects downstream use their correct latest bits
c) releng & QE need tools to audit when a component lead forgets to do (a) and (b)
d) releng & QE need tools to audit contents of JBT/JBDS update sites, since we will no longer be able to just visually inspect the list of features [1] to ensure they all have the same BUILD_ALIAS
[1] http://download.jboss.org/jbosstools/mars/snapshots/updates/core/4.3.mars...
-----
We could adopt a numerical convention that mimics Alpha/Beta/CR/Final nomenclature. For example... instead of having a project versioned with:
* 4.3.0.Alpha1
* 4.3.0.Alpha2
* 4.3.0.Beta1
* 4.3.0.Beta2
* 4.3.0.CR1
* 4.3.0.Final/GA
we might use
* 4.3.011 (1 = Alpha, 11 = Alpha1)
* 4.3.012
* 4.3.051 (5 = Beta, 51 = Beta1)
* 4.3.052
* 4.3.091 (9 = CR/Final/GA)
* 4.3.092
then for 4.3.1 maintenance...
* 4.3.151 (51 = Beta1)
* 4.3.152 (52 = Beta2)
* 4.3.191 (91 = CR1)
* 4.3.192 (92 = CR2, if needed)
By using fully numeric BUILD_ALIAS values in the third digit instead of alphanumeric strings in the 4th, we could potentially use Nexus more easily.
So, what if a component is already on 1.5.100? Well, we'd upversion it to 1.5.151 (Beta1). If it's already on 1.9.3, it'd be moved to 1.9.351.
Only thing I need to verify w.r.t. this plan is if we can set a <version>1.5.1${BUILD_ALIAS}</version> with <BUILD_ALIAS>51</BUILD_ALIAS> and have maven not complain about the idea of nesting a variable in the version field.
> Why do we deploy JBT components to Nexus snapshots repo?
> --------------------------------------------------------
>
> Key: JBIDE-21012
> URL: https://issues.jboss.org/browse/JBIDE-21012
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, updatesite
> Affects Versions: 4.3.0.Final, 4.4.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.3.1.Beta1, 4.4.0.Alpha1
>
>
> Currently, we deploy our x.y.z-SNAPSHOT update sites to the JBoss Nexus snapshots repo.
> But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just:
> * eat disk space in Nexus
> * consume time/resources in Jenkins
> Since we have the custom profile deploy-to-jboss.org in place for all our artifacts, why don't we set *maven.deploy.skip=true* in the parent pom for all the projects (except of course Locus and Browsersim Standalone, which would use maven.deploy.skip=false) ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (JBTIS-531) Bouncy Castle causes Fuse Tooling full source TP build failure.
by Paul Leacu (JIRA)
[ https://issues.jboss.org/browse/JBTIS-531?page=com.atlassian.jira.plugin.... ]
Paul Leacu commented on JBTIS-531:
----------------------------------
Assigned to [~phantomjinx] to get the ball rolling.
> Bouncy Castle causes Fuse Tooling full source TP build failure.
> ---------------------------------------------------------------
>
> Key: JBTIS-531
> URL: https://issues.jboss.org/browse/JBTIS-531
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Components: target-platform
> Affects Versions: 9.0.0.Alpha2, 8.0.4.CR2
> Reporter: Paul Leacu
> Assignee: Paul Richardson
> Priority: Blocker
>
> Here is the issue. The JBTIS TP has a reliance on bouncycastle that was introduced as an indirect dependency by Teiid Designer because they needed the Apache directory features including the org.apache.directory.studio.connection.ui feature. The bcprov feature was removed from the JBTIS TP and Teiid Designer added a dummy feature to satisfy maven. This was built and everything in the IS builds and installs fine - no one directly needed bouncycastle.
> Fuse Tooling builds a local development-only full source target platform based on the JBTIS TP. This causes all dependencies to be fully resolved which causes them to fail their target platform development-only build:
> {code}
> mvn -Pmultiple2repo -U -Dmirror-target-to-repo.includeSources=true clean install
> ...
> [ERROR] Software being installed: org.apache.directory.studio.connection.ui 2.0.0.v20150618
> [ERROR] Missing requirement: org.apache.directory.studio.connection.ui 2.0.0.v20150618 requires 'package org.bouncycastle.x509.extension 0.0.0' but it could not be found
> {code}
> you may also see this error:
> {code}
> [ERROR] Software being installed: org.apache.directory.studio.connection.ui 2.0.0.v20150618
> [ERROR] Missing requirement: org.apache.directory.studio.connection.ui 2.0.0.v20150618 requires 'package org.bouncycastle.asn1 0.0.0' but it could not be found
> {code}
> Both of these plugins can be found (in stub form) here:
> http://download.jboss.org/jbosstools/updates/stable/luna/integration-stac...
> How should this be fixed? Both Teiid Designer and Fuse Tooling use the JBTIS TP. Fuse needs this development TP to debug Fuse and SAP issues. They shouldn't have to incur a dependency that has nothing to do with them. If we pull the entire Apache directory dependency block out of the IS TP then Teiid Des will have to go back to creating their own merged TP.
> WDYT?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (JBTIS-531) Bouncy Castle causes Fuse Tooling full source TP build failure.
by Paul Leacu (JIRA)
[ https://issues.jboss.org/browse/JBTIS-531?page=com.atlassian.jira.plugin.... ]
Paul Leacu updated JBTIS-531:
-----------------------------
Priority: Blocker (was: Major)
> Bouncy Castle causes Fuse Tooling full source TP build failure.
> ---------------------------------------------------------------
>
> Key: JBTIS-531
> URL: https://issues.jboss.org/browse/JBTIS-531
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Components: target-platform
> Affects Versions: 9.0.0.Alpha2, 8.0.4.CR2
> Reporter: Paul Leacu
> Priority: Blocker
>
> Here is the issue. The JBTIS TP has a reliance on bouncycastle that was introduced as an indirect dependency by Teiid Designer because they needed the Apache directory features including the org.apache.directory.studio.connection.ui feature. The bcprov feature was removed from the JBTIS TP and Teiid Designer added a dummy feature to satisfy maven. This was built and everything in the IS builds and installs fine - no one directly needed bouncycastle.
> Fuse Tooling builds a local development-only full source target platform based on the JBTIS TP. This causes all dependencies to be fully resolved which causes them to fail their target platform development-only build:
> {code}
> mvn -Pmultiple2repo -U -Dmirror-target-to-repo.includeSources=true clean install
> ...
> [ERROR] Software being installed: org.apache.directory.studio.connection.ui 2.0.0.v20150618
> [ERROR] Missing requirement: org.apache.directory.studio.connection.ui 2.0.0.v20150618 requires 'package org.bouncycastle.x509.extension 0.0.0' but it could not be found
> {code}
> you may also see this error:
> {code}
> [ERROR] Software being installed: org.apache.directory.studio.connection.ui 2.0.0.v20150618
> [ERROR] Missing requirement: org.apache.directory.studio.connection.ui 2.0.0.v20150618 requires 'package org.bouncycastle.asn1 0.0.0' but it could not be found
> {code}
> Both of these plugins can be found (in stub form) here:
> http://download.jboss.org/jbosstools/updates/stable/luna/integration-stac...
> How should this be fixed? Both Teiid Designer and Fuse Tooling use the JBTIS TP. Fuse needs this development TP to debug Fuse and SAP issues. They shouldn't have to incur a dependency that has nothing to do with them. If we pull the entire Apache directory dependency block out of the IS TP then Teiid Des will have to go back to creating their own merged TP.
> WDYT?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (JBTIS-531) Bouncy Castle causes Fuse Tooling full source TP build failure.
by Paul Leacu (JIRA)
[ https://issues.jboss.org/browse/JBTIS-531?page=com.atlassian.jira.plugin.... ]
Paul Leacu reassigned JBTIS-531:
--------------------------------
Assignee: Paul Richardson
> Bouncy Castle causes Fuse Tooling full source TP build failure.
> ---------------------------------------------------------------
>
> Key: JBTIS-531
> URL: https://issues.jboss.org/browse/JBTIS-531
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Components: target-platform
> Affects Versions: 9.0.0.Alpha2, 8.0.4.CR2
> Reporter: Paul Leacu
> Assignee: Paul Richardson
> Priority: Blocker
>
> Here is the issue. The JBTIS TP has a reliance on bouncycastle that was introduced as an indirect dependency by Teiid Designer because they needed the Apache directory features including the org.apache.directory.studio.connection.ui feature. The bcprov feature was removed from the JBTIS TP and Teiid Designer added a dummy feature to satisfy maven. This was built and everything in the IS builds and installs fine - no one directly needed bouncycastle.
> Fuse Tooling builds a local development-only full source target platform based on the JBTIS TP. This causes all dependencies to be fully resolved which causes them to fail their target platform development-only build:
> {code}
> mvn -Pmultiple2repo -U -Dmirror-target-to-repo.includeSources=true clean install
> ...
> [ERROR] Software being installed: org.apache.directory.studio.connection.ui 2.0.0.v20150618
> [ERROR] Missing requirement: org.apache.directory.studio.connection.ui 2.0.0.v20150618 requires 'package org.bouncycastle.x509.extension 0.0.0' but it could not be found
> {code}
> you may also see this error:
> {code}
> [ERROR] Software being installed: org.apache.directory.studio.connection.ui 2.0.0.v20150618
> [ERROR] Missing requirement: org.apache.directory.studio.connection.ui 2.0.0.v20150618 requires 'package org.bouncycastle.asn1 0.0.0' but it could not be found
> {code}
> Both of these plugins can be found (in stub form) here:
> http://download.jboss.org/jbosstools/updates/stable/luna/integration-stac...
> How should this be fixed? Both Teiid Designer and Fuse Tooling use the JBTIS TP. Fuse needs this development TP to debug Fuse and SAP issues. They shouldn't have to incur a dependency that has nothing to do with them. If we pull the entire Apache directory dependency block out of the IS TP then Teiid Des will have to go back to creating their own merged TP.
> WDYT?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months
[JBoss JIRA] (JBTIS-531) Bouncy Castle causes Fuse Tooling full source TP build failure.
by Paul Leacu (JIRA)
[ https://issues.jboss.org/browse/JBTIS-531?page=com.atlassian.jira.plugin.... ]
Paul Leacu commented on JBTIS-531:
----------------------------------
Sounds like we are in agreement. We need to:
1. Remove BC dummy from Teiid Designer (both Luna and Mars)
2. Add BC dummy into Locus
3. Modify/release both the Luna and Mars IS TPs to pick up the new Locus BC dummy.
[~phantomjinx] - since you're the author of the BC dummy plugin and a contributor to locus - can you take on 1 & 2 - I'll do 3 when you're ready.
> Bouncy Castle causes Fuse Tooling full source TP build failure.
> ---------------------------------------------------------------
>
> Key: JBTIS-531
> URL: https://issues.jboss.org/browse/JBTIS-531
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Components: target-platform
> Affects Versions: 9.0.0.Alpha2, 8.0.4.CR2
> Reporter: Paul Leacu
>
> Here is the issue. The JBTIS TP has a reliance on bouncycastle that was introduced as an indirect dependency by Teiid Designer because they needed the Apache directory features including the org.apache.directory.studio.connection.ui feature. The bcprov feature was removed from the JBTIS TP and Teiid Designer added a dummy feature to satisfy maven. This was built and everything in the IS builds and installs fine - no one directly needed bouncycastle.
> Fuse Tooling builds a local development-only full source target platform based on the JBTIS TP. This causes all dependencies to be fully resolved which causes them to fail their target platform development-only build:
> {code}
> mvn -Pmultiple2repo -U -Dmirror-target-to-repo.includeSources=true clean install
> ...
> [ERROR] Software being installed: org.apache.directory.studio.connection.ui 2.0.0.v20150618
> [ERROR] Missing requirement: org.apache.directory.studio.connection.ui 2.0.0.v20150618 requires 'package org.bouncycastle.x509.extension 0.0.0' but it could not be found
> {code}
> you may also see this error:
> {code}
> [ERROR] Software being installed: org.apache.directory.studio.connection.ui 2.0.0.v20150618
> [ERROR] Missing requirement: org.apache.directory.studio.connection.ui 2.0.0.v20150618 requires 'package org.bouncycastle.asn1 0.0.0' but it could not be found
> {code}
> Both of these plugins can be found (in stub form) here:
> http://download.jboss.org/jbosstools/updates/stable/luna/integration-stac...
> How should this be fixed? Both Teiid Designer and Fuse Tooling use the JBTIS TP. Fuse needs this development TP to debug Fuse and SAP issues. They shouldn't have to incur a dependency that has nothing to do with them. If we pull the entire Apache directory dependency block out of the IS TP then Teiid Des will have to go back to creating their own merged TP.
> WDYT?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 5 months