[
https://issues.jboss.org/browse/DROOLS-906?page=com.atlassian.jira.plugin...
]
Geoffrey De Smet edited comment on DROOLS-906 at 9/28/15 7:11 AM:
------------------------------------------------------------------
Some thoughts:
- We delegate this functionality to aether. So if this issue is to be fixed, it should be
fixed upstream.
- As far as I know Maven/Aether, it is illegal to manipulate the maven repository's
metadata to control the version of (k)jars used by projects that the depend on the version
RELEASE. The main reason for this is that the metadata can be refreshed (= deteted and
regenerated) at any time. The metadata is just an index for searches (to reduce network
usage when determining the latest release, etc).
- RELEASE is a calculated property. If 0.1 and 0.2 are released, it should always be
"0.2", as defined by the maven api.
- To control the version of the (k)jars being used by projects in production, specify the
specific kjar version in a configuration file of your end-user app and use kie-ci to load
that specific version. If you need a more centralized approach, then put the configuration
file somewhere centrally
was (Author: ge0ffrey):
Some train of thoughts:
- We delegate this functionality to aether. So if this issue is to be fixed, it should be
fixed upstream.
- As far as I know Maven/Aether, it is illegal to manipulate the maven repository's
metadata to control the version of (k)jars used by projects that the depend on the version
RELEASE. The main reason for this is that the metadata can be refreshed (= deteted and
regenerated) at any time. The metadata is just and index for searches (to reduce network
usage when determining the latest release, etc).
- RELEASE is a calculated property. If 0.1 and 0.2 are released, it should always be
"0.2", as defined by the maven api.
- To control the version of the (k)jars being used by projects in production, specify the
specific kjar version in a configuration file of your end-user app and use kie-ci to load
that specific version. If you need a more centralized approach, then put the configuration
file somewhere centrally
Kiescanner do not find updates in the KieContainer if the current
RELEASE of a maven artifact change selecting an older version
-------------------------------------------------------------------------------------------------------------------------------
Key: DROOLS-906
URL:
https://issues.jboss.org/browse/DROOLS-906
Project: Drools
Issue Type: Bug
Affects Versions: 6.2.0.Final
Environment: Ear containing a startup bean, with the kiescanner loaded at
postconstruct,
deployed in Wildfly 8.2.0
Reporter: Getano Piazzolla
Assignee: Mario Fusco
Priority: Critical
Labels: drools, kie, maven
When using the KieScanner as indicated in the guide, if the kContainer is initalized
using a ReleaseIdImpl that idicate
as version "RELEASE", the KieScanner do not find changes in the repository if
we indicate as RELEASE a previous version of the repository.
IN CODE:
ReleaseIdImpl releaseId = new ReleaseIdImpl("blabla", "blabla",
"RELEASE");
KieServices ks = KieServices.Factory.get();
kContainer = ks.newKieContainer(releaseId);
kieScanner = ks.newKieScanner(kContainer);
kieScanner.start(5000L);
For example if we change the maven-metadata.xml/maven-metadata-local.xml
FROM
<metadata>
<groupId>com.noemalife.dmcs.rules</groupId>
<artifactId>maven-validation-rules</artifactId>
<versioning>
<release>0.2</release>
<versions>
<version>0.1</version>
<version>0.2</version>
</versions>
<lastUpdated></lastUpdated>
</versioning>
</metadata>
TO
<metadata>
<groupId>com.noemalife.dmcs.rules</groupId>
<artifactId>maven-validation-rules</artifactId>
<versioning>
<release>0.1</release>
<versions>
<version>0.1</version>
<version>0.2</version>
</versions>
<lastUpdated></lastUpdated>
</versioning>
</metadata>
The kieScanner do not find changes; I have to restart the AS to be able to load the
correct RELEASE version.
(The kieScanner behaves and updates correctly if I change the release version from 0.1 to
0.2 )
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)