Hi, that is the usual expected 1 time failure after publishing a release (and we just are publishing q4).
The developers needing to take action are already notified automatically. an i have also asked them to work on that today. Stefan On Tue, Dec 30, 2014 at 11:47 AM, <[email protected]> wrote: > int-api - Build # 1051 - Failure: > > Check console output at https://ci.openbravo.com/job/int-api/1051/ to view > the results. > > > Committers since last success: > > Changes for Build #1051 > > RM packaging bot [email protected]_ null > Merge back from main > > RM packaging bot [email protected]_ null > Added signature for changeset 53cc6ea75bb1 > .hgsigs > > RM packaging bot [email protected]_ null > Added tag 3.0PR14Q4 for changeset ed3565630685 > .hgtags > > RM packaging bot [email protected]_ null > Update AD_MODULE version to 3.0PR14Q4 > > modules/org.openbravo.advpaymentmngt/src-db/database/sourcedata/AD_MODULE.xml > > modules/org.openbravo.advpaymentmngt/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml > > modules/org.openbravo.base.weld/src-db/database/sourcedata/AD_MODULE.xml > > modules/org.openbravo.base.weld/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml > > modules/org.openbravo.client.application/src-db/database/sourcedata/AD_MODULE.xml > > modules/org.openbravo.client.application/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml > > modules/org.openbravo.client.htmlwidget/src-db/database/sourcedata/AD_MODULE.xml > > modules/org.openbravo.client.htmlwidget/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml > > modules/org.openbravo.client.kernel/src-db/database/sourcedata/AD_MODULE.xml > > modules/org.openbravo.client.kernel/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml > > modules/org.openbravo.client.myob/src-db/database/sourcedata/AD_MODULE.xml > > modules/org.openbravo.client.myob/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml > > modules/org.openbravo.client.querylist/src-db/database/sourcedata/AD_MODULE.xml > > modules/org.openbravo.client.querylist/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml > > modules/org.openbravo.client.widgets/src-db/database/sourcedata/AD_MODULE.xml > > modules/org.openbravo.client.widgets/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml > > modules/org.openbravo.financial.paymentreport/src-db/database/sourcedata/AD_MODULE.xml > > modules/org.openbravo.financial.paymentreport/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml > > modules/org.openbravo.reports.ordersawaitingdelivery/src-db/database/sourcedata/AD_MODULE.xml > > modules/org.openbravo.reports.ordersawaitingdelivery/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml > > modules/org.openbravo.service.datasource/src-db/database/sourcedata/AD_MODULE.xml > > modules/org.openbravo.service.datasource/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml > > modules/org.openbravo.service.integration.google/src-db/database/sourcedata/AD_MODULE.xml > > modules/org.openbravo.service.integration.google/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml > > modules/org.openbravo.service.integration.openid/src-db/database/sourcedata/AD_MODULE.xml > > modules/org.openbravo.service.integration.openid/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml > > modules/org.openbravo.service.json/src-db/database/sourcedata/AD_MODULE.xml > > modules/org.openbravo.service.json/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml > > modules/org.openbravo.userinterface.selector/src-db/database/sourcedata/AD_MODULE.xml > > modules/org.openbravo.userinterface.selector/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml > > modules/org.openbravo.userinterface.skin.250to300Comp/src-db/database/sourcedata/AD_MODULE.xml > > modules/org.openbravo.userinterface.skin.250to300Comp/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml > > modules/org.openbravo.userinterface.smartclient/src-db/database/sourcedata/AD_MODULE.xml > > modules/org.openbravo.userinterface.smartclient/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml > > modules/org.openbravo.v3.datasets/src-db/database/sourcedata/AD_MODULE.xml > > modules/org.openbravo.v3.datasets/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml > > modules/org.openbravo.v3.framework/src-db/database/sourcedata/AD_MODULE.xml > > modules/org.openbravo.v3.framework/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml > modules/org.openbravo.v3/src-db/database/sourcedata/AD_MODULE.xml > > modules/org.openbravo.v3/src-db/database/sourcedata/AD_MODULE_DEPENDENCY.xml > src-db/database/sourcedata/AD_MODULE.xml > > Asier Lostalé [email protected]_ null > fixed bug 28386: keep selected item when reopening FK drop down > > modules/org.openbravo.client.application/web/org.openbravo.client.application/js/form/formitem/ob-formitem-fk-filter.js > > Asier Lostalé [email protected]_ null > fixed bug 28386: FK filter dropdown hides elements when it's reopened > > When a FK filter drop down was reopened after having selected an element, it > only displayed that element in the list. > > Few things have been fixed: > * When requesting datasource for FK drop down, the same criteria used in > the > grid is used, but removing that drop down criterion. This was not > properly > done for direct FK selection > * == element before the identifier was some times removed > * When reopening a drop down having an element selected, the criteria was > changed > from equals with FK value to iEquals with identifier value > > modules/org.openbravo.client.application/web/org.openbravo.client.application/js/form/formitem/ob-formitem-fk-filter.js > > Alvaro Ferraz [email protected]_ null > Fixes bug 28308 LandedCost Accounting should always be created in the > same order > > In order to help JUnit tests assert landed cost accounting, an orderBy clause > has been added when creating Landed Cost Accounting lines, to be created > always in the same order > src/org/openbravo/erpCommon/ad_forms/DocLineLandedCost_data.xsql > > Alvaro Ferraz [email protected]_ null > Fixes bug 28266 ParentCostAdjustmentLine should always be assigned in the > same order > > In order to help JUnit tests assert Cost Adjustment lines, an orderBy clause > has been added when assigning the field "Parent Cost Adjustment Line" to > follow always the same order > src/org/openbravo/costing/CostAdjustmentProcess.java > > Alvaro Ferraz [email protected]_ null > Related to Issue 28148 Cost Adjustment Lines created ordered by > trxprocessdate > > In order to help JUnit tests assert Cost Adjustment lines, an orderBy clause > has been added when creating cost adjustment lines of type Landed Cost to > follow always the same order > src/org/openbravo/costing/LCMatchingProcess.java > > Alvaro Ferraz [email protected]_ null > Related to bug 28286 LandedCostLineAmt should always be created in the > same order > > The field in the order by clause must appear in the group by clause to > prevent fail in Postgresql 8.4 > src/org/openbravo/costing/LandedCostDistributionByAmount.java > > Alvaro Ferraz [email protected]_ null > Fixes bug 28286 LandedCostLineAmt should always be created in the same > order > > In order to help JUnit tests assert landed cost, an orderBy clause has been > added when creating Landed Cost Receipt Line Amount lines, to be always > created in the same order. > src/org/openbravo/costing/LandedCostDistributionByAmount.java > src/org/openbravo/costing/LandedCostProcess.java > > Alvaro Ferraz [email protected]_ null > Fixes bug 28387 BillofMaterialsAccounting should always be created in the > same order > > In order to help JUnit tests assert Bill of Materials Production accounting, > an orderBy clause has been added when creating Bill of Materials Production > Accounting lines, to be created always in the same order > src/org/openbravo/erpCommon/ad_forms/DocLineProduction_data.xsql > > Alvaro Ferraz [email protected]_ null > [Costing]Related to issue 28333 Data needed in demodata for > CostAdjustment test > referencedata/sampledata/QA_Testing/M_LANDEDCOST.xml > referencedata/sampledata/QA_Testing/M_LC_COST.xml > referencedata/sampledata/QA_Testing/AD_SEQUENCE.xml > > Alvaro Ferraz [email protected]_ null > [Costing]Related to issue 28333 Data needed in demodata for > CostAdjustment test > > Enable M_LandedCost, M_LC_Cost and M_LC_Type tables in sampledata dataset > src-db/database/sourcedata/AD_DATASET_TABLE.xml > > Alvaro Ferraz [email protected]_ null > [Costing] Fixes issue 28333: Data needed in demodata for CostAdjustment > test > referencedata/sampledata/QA_Testing/C_GLITEM_ACCT.xml > referencedata/sampledata/QA_Testing/M_LC_TYPE.xml > referencedata/sampledata/QA_Testing/AD_ORG_WAREHOUSE.xml > referencedata/sampledata/QA_Testing/AD_PREFERENCE.xml > referencedata/sampledata/QA_Testing/AD_PROCESS_REQUEST.xml > referencedata/sampledata/QA_Testing/AD_SEQUENCE.xml > referencedata/sampledata/QA_Testing/C_BPARTNER.xml > referencedata/sampledata/QA_Testing/C_BPARTNER_LOCATION.xml > referencedata/sampledata/QA_Testing/C_BP_CUSTOMER_ACCT.xml > referencedata/sampledata/QA_Testing/C_BP_VENDOR_ACCT.xml > referencedata/sampledata/QA_Testing/C_DOCTYPE.xml > referencedata/sampledata/QA_Testing/C_GLITEM.xml > referencedata/sampledata/QA_Testing/C_LOCATION.xml > referencedata/sampledata/QA_Testing/C_ORDER.xml > referencedata/sampledata/QA_Testing/C_ORDERLINE.xml > referencedata/sampledata/QA_Testing/C_ORDERLINETAX.xml > referencedata/sampledata/QA_Testing/C_ORDERTAX.xml > referencedata/sampledata/QA_Testing/M_LOCATOR.xml > referencedata/sampledata/QA_Testing/M_PRICELIST.xml > referencedata/sampledata/QA_Testing/M_PRICELIST_VERSION.xml > referencedata/sampledata/QA_Testing/M_PRODUCT.xml > referencedata/sampledata/QA_Testing/M_PRODUCTPRICE.xml > referencedata/sampledata/QA_Testing/M_PRODUCT_ACCT.xml > referencedata/sampledata/QA_Testing/M_WAREHOUSE.xml > referencedata/sampledata/QA_Testing/M_WAREHOUSE_ACCT.xml > > Unai Martirena [email protected]_ null > Fixes Issue 28450: Costing Migration Process does not fail any more. > > In the function insertTrxCosts() in CostingMigrationProcess.java while > inserting m_transaction_cost records the column dateacct is filled in the > following way: > * If the transaction is a goods shipment line, with the accounting date of > the Shipment. > * If the transaction is not a goods shipment line, with the movement date of > the transaction. > src/org/openbravo/costing/CostingMigrationProcess.java > > Unai Martirena [email protected]_ null > Fixes Bug 28441:Validate Costing Rule doesn't fail if there prev > transactions. > > The process was failing while trying to create Transaction Cost records in > initializeOldTrx and updateInventoriesCostAndProcessInitInventories > processes. It was not setting any value to accounting date column, which is > mandatory. This column has been populated in the following way: If the > related transaction is a shipment the accounting date of the shipment is > assigned, if not, the movement date of the transaction will be assigned. > src/org/openbravo/costing/CostingRuleProcess.java > > Unai Martirena [email protected]_ null > Fixes bug 28401:Initialized All Trx process not uses movement date. > > Initialize Old Transaction process inside Validate Costing Rule process > should filter by Movement Date of Transactions instead of Transaction Process > Date > src/org/openbravo/costing/CostingRuleProcess.java > > Unai Martirena [email protected]_ null > Related to issue 28289: Improve @FixBackdateFromBeforeStartingDate@ > message > src-db/database/sourcedata/AD_MESSAGE.xml > > Unai Martirena [email protected]_ null > Related to bug 28289:Do @FixBackdateFromBeforeStartingDate@ later in the > process. > > Check the validation at the end of the Costing Rule Validation process when > fixbackdated from and starting date are being initialized. > Also update the error message displayed. > src-db/database/sourcedata/AD_MESSAGE.xml > src/org/openbravo/costing/CostingRuleProcess.java > > Unai Martirena [email protected]_ null > Related to issue 28289: Little code review > src/org/openbravo/costing/CostingRuleProcessActionHandler.java > src/org/openbravo/costing/CostingRuleProcessOnProcessHandler.java > src/org/openbravo/costing/CostingUtils.java > > Unai Martirena [email protected]_ null > Fixes Bug 28289: Manage null start and fix backdated from dates in > Costing Rule. > > Several things have been implemented in this changeset: > * A new Process Definition called 'Validate Costing Rule' has been created > that replaces the old Process with the same name. This has been done to be > able to use the new capabilities that these new kind of processes offer, like > validations before executing the process and the posibility to show a > confirmation popup. The new process action handler calls the old process java > class, so all existing modules that may call or extend the old class they > will continue working. > * The CostingRuleEventHandler has been removed, because it was doing a wrong > validation and the fix backdated from date is managed in the > CostingRuleProcess. > * 2 new functions have been created in CostingUtils > ('getCostingRuleStartingDate' and 'getCostingRuleFixBackdatedFrom') that they > return '01/01/1900' as costing rule Starting Date or Fix Backdated From when > these are null. This has been done because in some places when these dates > are null the application was giving an error. So, every time these dates are > retrieved, these functions will be called. > * A validation has been added before executing the new Action Handler > 'Validate Costing Rule' that shows a popup when transactions without cost > calculated are found in closed periods. It asks for confirmation to proceed > or the option to cancel. > src/org/openbravo/costing/CostingRuleProcessActionHandler.java > src/org/openbravo/costing/CostingRuleProcessOnProcessHandler.java > web/js/validateCostingRuleProcess.js > > modules/org.openbravo.client.application/src/org/openbravo/client/application/ApplicationComponentProvider.java > referencedata/sampledata/F_B_International_Group/AD_PROCESS_ACCESS.xml > > referencedata/sampledata/F_B_International_Group/OBUIAPP_PROCESS_ACCESS.xml > referencedata/sampledata/QA_Testing/AD_PROCESS_ACCESS.xml > referencedata/sampledata/QA_Testing/OBUIAPP_PROCESS_ACCESS.xml > src-db/database/sourcedata/AD_COLUMN.xml > src-db/database/sourcedata/AD_ELEMENT.xml > src-db/database/sourcedata/AD_MESSAGE.xml > src-db/database/sourcedata/AD_MODEL_OBJECT.xml > src-db/database/sourcedata/AD_PROCESS.xml > src-db/database/sourcedata/OBUIAPP_PROCESS.xml > src/org/openbravo/costing/AverageCostAdjustment.java > src/org/openbravo/costing/CostAdjustmentUtils.java > src/org/openbravo/costing/CostingAlgorithmAdjustmentImp.java > src/org/openbravo/costing/CostingRuleProcess.java > src/org/openbravo/costing/CostingServer.java > src/org/openbravo/costing/CostingUtils.java > src/org/openbravo/costing/FixBackdatedTransactionsProcess.java > src/org/openbravo/costing/StandardAlgorithm.java > src/org/openbravo/costing/StandardCostAdjustment.java > src/org/openbravo/event/CostingRuleEventHandler.java > > Unai Martirena [email protected]_ null > Fixes Bug 28289:Add Starting Date and Fix Backdated From allways to > Costing Rule > > Modify CostingRuleEventHandler.java to allways set an Starting Date and Fix > Backdated From to a Costing Rule if it has not been added manually. Take as > Starting Date the Starting Date of the first period that is opened. Set the > same date as Fix Backdated From. > src/org/openbravo/event/CostingRuleEventHandler.java > > Unai Martirena [email protected]_ null > Related to Issue 28301: Fix on updateBDCostingTimeRange function. > > If the movement date of the inventory transaction related to current costing > record is before the movement date of the inventory transaction related to > backdated costing record, then the backdated costing record would be the > current costing record. In other case the current costing record would remain > as current costing record. > src/org/openbravo/costing/AverageCostAdjustment.java > > Unai Martirena [email protected]_ null > Fixes Issue 28301: Cost is properly calculated after two backdated > transactions. > > The problem was in updateBDCostingTimeRange function. While updating the > backdated average costing time, if a previous costing record was found, the > future ending date was assigned to backdated costing record, not to the > current costing, leaving as current costing the backdated costing record, and > this is wrong. > src/org/openbravo/costing/AverageCostAdjustment.java > > Unai Martirena [email protected]_ null > Related to bug 28389: If is no diff in match LCC leave LCC amount as > matchedAmt > src/org/openbravo/costing/LandedCostProcess.java > > Unai Martirena [email protected]_ null > Related to Issue 28389: Fixed Posting of LC Cost with Invoice Line > > While processing a Landed Cost with an Invoice in a Landed Cost Cost it, if > the invoice has an exchange rate different from the system, a new Cost > Adjustment is created with that difference between the rates. But this > difference it was not taking into account while setting the matched amount in > Landed Cost Cost, so the Post process it was not working well. > src/org/openbravo/costing/LandedCostProcess.java > > Miguel A. Alsasua [email protected]_ null > fixed issue 28389: the difference amount is calculated adding the amount > of all lines > > the difference amount between the cost amount and matched amount was wrong > calculated when there was more than one line in landed cost cost tab > src/org/openbravo/erpCommon/ad_forms/DocLCCost.java > > Unai Martirena [email protected]_ null > Fixes issue 28192: Net Unit Price now is properly calculated. > > In order to calculate the Net Unit Price, the adjustments of the transaction > are used, but it was not being used the signMultiplier of the transaction, > and needs to be used. > src/org/openbravo/costing/AverageCostAdjustment.java > > Unai Martirena [email protected]_ null > Fixes Issue 28157: Landed Cost takes into account exchange rate at > invoice level > > If an exchange rate different from the System is added in Purchase Invoice > and this Invoice is matched in a Landed Cost, a new record will be created in > 'Matched Amount' tab under 'Landed Cost Cost' tab of 'Landed Cost' window. > This new record will have the new flag of 'Is Conversion Matching' as true, > and the amount will be the difference obtained from using the Invoice > exchange rate compared to the one of the System. > This will create a new Cost Adjustment of source 'Landed Cost' with the same > amount. > src-db/database/model/tables/M_LC_MATCHED.xml > src-db/database/sourcedata/AD_COLUMN.xml > src-db/database/sourcedata/AD_ELEMENT.xml > src-db/database/sourcedata/AD_FIELD.xml > src/org/openbravo/common/inserters/LCMatchFromInvoiceInserter.java > src/org/openbravo/costing/LCCostMatchFromInvoiceHandler.java > src/org/openbravo/costing/LandedCostProcess.java > > Unai Martirena [email protected]_ null > Related to Issue 28113: Revert a change on issue 28115. > > In this cases the net unit price is the cost of the transaction > src/org/openbravo/costing/AverageCostAdjustment.java > > Alvaro Ferraz [email protected]_ null > Fixes bug 28230 Null Pointer Exception is raised when trying to post a > goods receipt > > When a goods receipt with a product of type Service, which has a cost of type > Standard, is posted, the DocInOut class calls the getStandardCost method from > CostingUtils class with the currency of the current organization. If the > organization has no currency, the client's currency will be used. Otherwise, > a null pointer exception will be raised. > src/org/openbravo/erpCommon/ad_forms/DocInOut.java > src/org/openbravo/erpCommon/ad_forms/DocMatchInv.java > > Unai Martirena [email protected]_ null > Fixes Issue 28234: Check in Costing Rule Validation that the org has > Currency. > > If the organization has no currency defined, the costing process will use the > currency defined in the client. This could be wrong if the currency for the > transactions of this organization should be different that the currency of > the client, so before validating a costing rule the organization of it should > have a currency defined. > src-db/database/sourcedata/AD_MESSAGE.xml > src/org/openbravo/costing/CostingRuleProcess.java > > Unai Martirena [email protected]_ null > Related to Issue 28238: Clear Goods Shipment Lines when changing Goods > Shipment. > > A callout has been implemented in Goods Shipment field. > src/org/openbravo/erpCommon/ad_callouts/SL_LandedCost_Receipt.java > src-db/database/sourcedata/AD_CALLOUT.xml > src-db/database/sourcedata/AD_COLUMN.xml > src-db/database/sourcedata/AD_MODEL_OBJECT.xml > src-db/database/sourcedata/AD_MODEL_OBJECT_MAPPING.xml > > Unai Martirena [email protected]_ null > Fixes Issue 28238: Cost Adjustment of Landed Cost type properly created. > > Receipt tab of Landed Cost has been designed to work in the following way: > * either a Goods Receipt header is selected in 'Goods Receipt' field -> this > option implies that specified landed cost are distributed among all Goods > Receipt lines. > * or a Goods Receipt header is selected in Goods Receipt field and a Goods > Receipt line 'of the very same Goods Receipt' is selected in the field 'Goods > Receipt Line' -> this option implies that specified landed cost are > distribute just for the Goods receipt line selected. > Above behaviour implies that Goods Receipt lines field lists only goods > receipt lines of the goods receipt selected in Goods Receipt field. In order > to do this a where clause has been added in Goods Receipt Lines selector to > only display lines of the selected header, if no header is selected, no lines > would be displayed. > src-db/database/sourcedata/OBUISEL_SELECTOR.xml > > Sandra Huguet [email protected]_ null > Fixed bug 28362 c_invoice_post creates unnecesary contentions > > Avoiding the join with m_pricelist and c_doctype contentions are solved > src-db/database/model/functions/C_INVOICE_POST.xml > > Sandra Huguet [email protected]_ null > Fixed bug 28360 c_order_post creates unnecesary contentions > > Avoiding the join with m_pricelist the m_pricelist contention is solved > > For update sentence is deleted in c_orderline selects because the > c_orderline is bloqued with the main select and is redundant and > causes unnecessary contentions. > src-db/database/model/functions/C_ORDER_POST1.xml > > Augusto Mauch [email protected]_ null > Fixed issue 28242: Load grid even with inconsistent default view info > > Before the previous changeset was applied, it was possible to have a > preference that specified that a certain grid had a default saved view, but > that the referenced default saved view did not actually exists. When this > happened the grid was not loaded until the user pressed the Refresh button. > > To fix this, now the inconsistent default view info is detected and the grid > is loaded once it is detected that the default view does not actually exists. > > modules/org.openbravo.client.application/web/org.openbravo.client.application/js/main/ob-standard-view.js > > modules/org.openbravo.client.application/web/org.openbravo.client.application/js/main/ob-standard-window.js > > Augusto Mauch [email protected]_ null > Related with issue 28242: Delete preference along with window > personalization > > When a grid view is saved and set as default two records are added: > - One to the OBUIAPP_UIPersonalization with the description of the view > - One to the Preference table, using the OBUIAPP_DefaultSavedView property, > whose value is the ID of the record added to the OBUIAPP_UIPersonalization > table > > The problem of this issue was that when the a default saved view was removed > from the OBUIAPP_UIPersonalization table, its corresponding entry from the > Preference table was not removed. This resulted in not making the initial > request to load the grid because it was detected that the view had a default > saved view (using the preference), and not doing it after loading the window > personalization because the view description was removed from > OBUIAPP_UIPersonalization. > > The first step of the issue, included in this changeset, removes the > Preference associated with a default saved view when it is deleted from > OBUIAPP_UIPersonalization. This prevents the data from being inconsistent. > The second and final step will consist in loading the grid even when the data > is inconsistent, to fix the cases where the data is already inconsistent. > > modules/org.openbravo.client.application/src/org/openbravo/client/application/event/WindowPersonalizationEventHandler.java > > Atul Gaware [email protected]_ null > Fixes Issues 27820:Error when posting Payment/Transaction/Reconciliation > referencing a cash vat invoice linked to several orders > > Issue is a regression due to related fix for issue 26571. Cast Vat lines > were posted as many times the no. of orders linked with cash vat invoices. > So now posting is based on the payment details so the relevant cash vat line > associated with it is posted though it is looped as many times as the no. of > orders linked. > src/org/openbravo/erpCommon/ad_forms/DocFINFinAccTransaction.java > src/org/openbravo/erpCommon/ad_forms/DocFINPayment.java > src/org/openbravo/erpCommon/ad_forms/DocFINReconciliation.java > > src/org/openbravo/erpCommon/ad_forms/DocLineCashVATReady_PaymentTransactionReconciliation.java > > > > > Last 20 lines of the console output: > > [...truncated 28104 lines...] > method > org.openbravo.model.financialmgmt.payment.FIN_Reconciliation.setAPRMRecDetailVList(java.util.List<org.openbravo.advpaymentmngt.ReconciliationDetail>): > missing in /srv/ci/workspace/int-full-pgsql/SANDBOX/api-checks/output/java > method > org.openbravo.model.financialmgmt.payment.FIN_Reconciliation.setWidget(java.lang.String): > missing in /srv/ci/workspace/int-full-pgsql/SANDBOX/api-checks/output/java > + failure=1 > + exit 1 > Build step 'Execute shell' marked build as failure > Performing Post build task... > Match found for : : True > Logical operation result is TRUE > Running script : cp > /srv/ci/workspace/int-full-pgsql/SANDBOX/api-checks/output/java.japi.gz . > [int-api] $ /bin/bash -xe /tmp/hudson238653324791005499.sh > + cp /srv/ci/workspace/int-full-pgsql/SANDBOX/api-checks/output/java.japi.gz . > POST BUILD TASK : SUCCESS > END OF POST BUILD TASK : 0 > Archiving artifacts > Checking console output > /srv/ci/jobs/int-api/builds/2014-12-30_10-43-47/log: > [checkAPI] 10573 ERROR - > Email was triggered for: Failure > Sending email for trigger: Failure > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > _______________________________________________ > Openbravo-builds mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/openbravo-builds > ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ Openbravo-builds mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openbravo-builds
