June 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SASL-60) Delete all forked code from the project

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/SASL-60?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse resolved SASL-60. ---------------------------------- Resolution: Done > Delete all forked code from the project > --------------------------------------- > > Key: SASL-60 > URL: https://issues.jboss.org/browse/SASL-60 > Project: WildFly SASL Provider > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 2.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-207) Transitive dependencies are not in sync with EAP: scannotation and xmlschema-core

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-207?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer resolved DROOLS-207. ------------------------------------------- Resolution: Done > Transitive dependencies are not in sync with EAP: scannotation and xmlschema-core > --------------------------------------------------------------------------------- > > Key: DROOLS-207 > URL: https://issues.jboss.org/browse/DROOLS-207 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Minor > > > EAP 6.1 --> kie-wb.war > > --------------------------------------------------------- > > EAP has scannotation-1.0.2-redhat-2.jar --> kie-wb has 1.0.3 > > EAP has xmlschema-core-2.0.2-redhat-2.jar --> kie-wb has 2.0.3 > In theory this should not be able to happen. > A dependency:tree on kie-wb show this: > {code} > [INFO] org.kie:kie-wb-webapp:war:6.1.0-SNAPSHOT > ... > [INFO] +- org.jbpm:jbpm-designer-backend:jar:6.1.0-SNAPSHOT:compile > ... > [INFO] | +- org.jbpm:jbpm-workitems:jar:6.1.0-SNAPSHOT:compile (version managed from 6.1.0-SNAPSHOT) > ... > [INFO] | | \- org.apache.ws.xmlschema:xmlschema-core:jar:2.0.3:compile > {code} > and also > {code} > [INFO] org.kie:kie-wb-distribution-wars:pom:6.1.0-SNAPSHOT > ... > [INFO] +- org.jboss.resteasy:resteasy-jaxrs:jar:2.3.6.Final:compile > [INFO] | +- org.scannotation:scannotation:jar:1.0.3:compile > {code} > Investigate if any of those artifacts aren't messing with the transitive dependency version by overwriting their version. It's also possible that the bug is on the side of EAP (if they overwrite one of their transitive dependencies with a lower version). -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-482) Inventory of dependencies that do not fulfill our minimal dependency requirements.

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-482?page=com.atlassian.jira.plugin... ] Geoffrey De Smet commented on DROOLS-482: ----------------------------------------- All dependencies declared in kie-parent-with-dependencies (not those in the ip-bom) should be checked if they belong in this list, because we have a couple of suspicious ones there. > Inventory of dependencies that do not fulfill our minimal dependency requirements. > ---------------------------------------------------------------------------------- > > Key: DROOLS-482 > URL: https://issues.jboss.org/browse/DROOLS-482 > Project: Drools > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.Beta3 > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > > We have a set of minimal requirements for our dependencies: > https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/READ... > If you're aware of any dependency that doesn't meet these requirements, please add it in this jira (description or comment). > Violating dependencies: > (none known yet) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-514) Clean up jetty dependencies in kie-parent-with-dependencies pom.xml

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-514?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer reopened DROOLS-514: ------------------------------------------- > Clean up jetty dependencies in kie-parent-with-dependencies pom.xml > ------------------------------------------------------------------- > > Key: DROOLS-514 > URL: https://issues.jboss.org/browse/DROOLS-514 > Project: Drools > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.Beta4 > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Attachments: jetty-depTree.txt > > > 1) Make an inventory (using "mvn-all dependency:tree) of all modules that use jetty dependency and clearly indicate per module: > - Jetty groupId and Jetty version > - Scope: test or production > - Build classpath: normal dependency or plugin dependency (latter makes scope n/a) > 2) In theory, we should have no normal dependency in a non-test scope to Jetty, as our stuff is deployed on JBoss EAP, Tomcat, Jetty and WildFly alike. Is this true? > GWT does use Jetty, but only during compilation (= plugin classpath, not the dependencies classpath). gwt-dev is a fat jar that includes jetty even... but gwt-dev shouldn' be in the dependencies either (but it is and it needs to be removed!). > 3) Based on this inventory, discuss with ge0ffrey and mantis plan of attack. > Goal: Get rid of the jetty mess in kie-parent-with-dependencies. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-297) The release procedure should validate there are no snapshot dependencies with the enforcer plugin

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-297?page=com.atlassian.jira.plugin... ] Geoffrey De Smet commented on DROOLS-297: ----------------------------------------- [~mbiarnes] On the ip-bom list, Keith and Gary we're wondering how to do this. How did you fix this for us? We 'll want to extract that to the ip-bom, so the other projects benefit from it too. > The release procedure should validate there are no snapshot dependencies with the enforcer plugin > ------------------------------------------------------------------------------------------------- > > Key: DROOLS-297 > URL: https://issues.jboss.org/browse/DROOLS-297 > Project: Drools > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > > Apparently, we've been releasing jars which have snapshot dependencies (non-timestamped). For example drools-wb-jcr2vfs-migration-core 6.0.0.CR4 depends on 5.5.1-SNAPSHOT. Why Nexus's validation no longer prevents this is beyond me. > Anyway, we need to prevent this. Luckily the enforcer plugin has a rule to validate this: > http://maven.apache.org/enforcer/enforcer-rules/requireReleaseVersion.html > During normal development this rule shouldn't be active, as jbpm depends on a drools snapshot etc. > But during a release procedure, it must be executed once. For example, after changing the version and before deploying them. Or as part of the actual deploy build - whatever works best. > One way would be to put it in the release profile "jboss-release", similar to what the jboss-parent pom does (which we extend): > https://github.com/jboss/jboss-parent-pom/blob/master/pom.xml#L700 > But I strongly dislike the use of profiles... -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-482) Inventory of dependencies that do not fulfill our minimal dependency requirements.

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-482?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer reopened DROOLS-482: ------------------------------------------- > Inventory of dependencies that do not fulfill our minimal dependency requirements. > ---------------------------------------------------------------------------------- > > Key: DROOLS-482 > URL: https://issues.jboss.org/browse/DROOLS-482 > Project: Drools > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.Beta3 > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > > We have a set of minimal requirements for our dependencies: > https://github.com/droolsjbpm/droolsjbpm-build-bootstrap/blob/master/READ... > If you're aware of any dependency that doesn't meet these requirements, please add it in this jira (description or comment). > Violating dependencies: > (none known yet) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-204) No poms such use <version> except for the droolsjbpm-parent pom

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-204?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer closed DROOLS-204. ----------------------------------------- > No poms such use <version> except for the droolsjbpm-parent pom > --------------------------------------------------------------- > > Key: DROOLS-204 > URL: https://issues.jboss.org/browse/DROOLS-204 > Project: Drools > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > Priority: Critical > Fix For: 6.0.0.CR2 > > Attachments: problem_list.txt > > > Open all projects (from the repository-list.txt) in IntelliJ (or Eclipse). Do a find in path (ctrl-shift-r) for "<version>" in all directories in files named "pom.xml". > Export that result to txt (intellij has a button on the left for that) and paste that result as a comment on this issue. > Only the droolsjbpm-parent pom file should show up in that result (in theory). > For <version> each of those in that list: > 1) If the droolsjbpm-parent already declares the same dependency (=> exact same groupId, artifactId (and optionally type, classifier)) with the same version, just remove the <version> line. > If all cases of 1) are fixed and committed: > 2) If the droolsjbpm-parent already declares the same dependency with a lower verion, remove the <version> line and notify the pom owner. > 3) If the droolsjbpm-parent already declares the same dependency with a higher verion, add it to a the "problem list". > 4) If the droolsjbpm-parent doesn't declare the dependency yet and EAP doesn't have it either (or it's the same version), add it in the droolsjbpm-parent pom and remove <version> line from the original pom. > 5) If the droolsjbpm-parent doesn't declare the dependency yet and EAP has it in another version, add it to the "problem list". > Copy the "problem list" as a comment to this issue too. > Reqs: need to be done on master and 6.0.x (=> use git cherry-pick -x ...) > Special cases that warrant exceptions: > - The <scope>system</scope> artifact "downloaded-jdbc-driver-jar", which is a special hack of mriet. Leave it alone -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-297) The release procedure should validate there are no snapshot dependencies with the enforcer plugin

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-297?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer closed DROOLS-297. ----------------------------------------- > The release procedure should validate there are no snapshot dependencies with the enforcer plugin > ------------------------------------------------------------------------------------------------- > > Key: DROOLS-297 > URL: https://issues.jboss.org/browse/DROOLS-297 > Project: Drools > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > > Apparently, we've been releasing jars which have snapshot dependencies (non-timestamped). For example drools-wb-jcr2vfs-migration-core 6.0.0.CR4 depends on 5.5.1-SNAPSHOT. Why Nexus's validation no longer prevents this is beyond me. > Anyway, we need to prevent this. Luckily the enforcer plugin has a rule to validate this: > http://maven.apache.org/enforcer/enforcer-rules/requireReleaseVersion.html > During normal development this rule shouldn't be active, as jbpm depends on a drools snapshot etc. > But during a release procedure, it must be executed once. For example, after changing the version and before deploying them. Or as part of the actual deploy build - whatever works best. > One way would be to put it in the release profile "jboss-release", similar to what the jboss-parent pom does (which we extend): > https://github.com/jboss/jboss-parent-pom/blob/master/pom.xml#L700 > But I strongly dislike the use of profiles... -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-297) The release procedure should validate there are no snapshot dependencies with the enforcer plugin

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-297?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer resolved DROOLS-297. ------------------------------------------- Resolution: Done > The release procedure should validate there are no snapshot dependencies with the enforcer plugin > ------------------------------------------------------------------------------------------------- > > Key: DROOLS-297 > URL: https://issues.jboss.org/browse/DROOLS-297 > Project: Drools > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > > Apparently, we've been releasing jars which have snapshot dependencies (non-timestamped). For example drools-wb-jcr2vfs-migration-core 6.0.0.CR4 depends on 5.5.1-SNAPSHOT. Why Nexus's validation no longer prevents this is beyond me. > Anyway, we need to prevent this. Luckily the enforcer plugin has a rule to validate this: > http://maven.apache.org/enforcer/enforcer-rules/requireReleaseVersion.html > During normal development this rule shouldn't be active, as jbpm depends on a drools snapshot etc. > But during a release procedure, it must be executed once. For example, after changing the version and before deploying them. Or as part of the actual deploy build - whatever works best. > One way would be to put it in the release profile "jboss-release", similar to what the jboss-parent pom does (which we extend): > https://github.com/jboss/jboss-parent-pom/blob/master/pom.xml#L700 > But I strongly dislike the use of profiles... -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-377) Upgrade from 1.3.1 to the latest versions-maven-plugin (2.1) to fix upgrade-versions script.

by Michael Biarnes Kiefer (JIRA)

[ https://issues.jboss.org/browse/DROOLS-377?page=com.atlassian.jira.plugin... ] Michael Biarnes Kiefer closed DROOLS-377. ----------------------------------------- > Upgrade from 1.3.1 to the latest versions-maven-plugin (2.1) to fix upgrade-versions script. > -------------------------------------------------------------------------------------------- > > Key: DROOLS-377 > URL: https://issues.jboss.org/browse/DROOLS-377 > Project: Drools > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Geoffrey De Smet > Assignee: Michael Biarnes Kiefer > > In kie-parent-metadata, look for the versions.maven-plugin and use the lastest version, which can be found here: > http://mojo.codehaus.org/versions-maven-plugin/ > I believe this will fix (some of) the problems with the upgrade all versions script: > https://jira.codehaus.org/browse/MVERSIONS-185 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

12 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2014