Re: SCA JAVA JIRAS
On Sun, Feb 24, 2008 at 3:04 AM, haleh mahbod [EMAIL PROTECTED] wrote: Hi, I am interested to work on some JIRAs for the next SCA release. As I searched the JIRAs, I realized that it is not easy to identify where help is needed! I am sharing this information with you because others like me might be running into the same issue. For example, some JIRAs are very old. Does it make sense to work on those? Some JIRAs contain exchanges of information between 2 or more people and are not assigned to anyone, does that mean they are open for grab? I noticed the following cases where JIRA status can easily be updated to get SCA JIRAs into a state that truly reflects the work that needs to be done. I sign up for going through the JIRAs and help clean up the easy ones if there is agreement on the approach. Great, thanks for helping! - Some of the JIRAs are really old and are not relevant any longer. *Can JIRAs that have been created prior to .90 be closed as not relevant since architecture changed?* I think thats likely often the case but its not guaranteed 100% of the time so we'd have to apply some discretion, for example, TUSCANY-83http://issues.apache.org/jira/browse/TUSCANY-83is really old but i'd still like to get it fixed. - Some of the JIRAs have been created during evaluation of prior releases (RCs). They contain comments such as 'did not make it' to the release. *Can these be targeted for next release so that they get evaluated?* If you mean putting them in Java-SCA-Next thats fine, but i don't think assigning them to a specific release like Java-SCA-1.2 is always the correct thing to do. The way i treat the JIRA release for the upcoming release (like Java-SCA-1.2) is to only put JIRAs in there that I'm actually working on or that I think we really really should try to get done in that release. I think it needs more than just did not make it into an older release. - Some of the JIRAs contain conversations that did not complete. Only the people who were involved in the half finished conversation would know what to do with these JIRAs. I'm not sure thats true, just because someone has commented in a JIRA doesn't mean they know any more than is recorded in the JIRA, if its now waiting for more information to come back from the reporter then anyone should be able to pick it up when that info gets added. It would be useful to get these to a proper JIRA state, that is 'close' or 'open'. What is the best approach for handling these? I can help generate a list and share it on the ML if it is helpful given that there are 170 JIRAs. - Some JIRAs contain a response, for example 'problem does not exist in the latest release', and yet they are in an open state. It might be that it is expected of the originator to close the JIRA. *Should these be closed?* Yes that sounds fine. Meanwhile, I think I have identified some JIRAs that I can work on myself. There are many JIRAs under sample category that need to be validated against the current release to see if they are relevant or not. I'll start with those, but if you already know what the status of these JIRAs should be, it would be good if you could change the status to what it should be before I spend time on them :) Haleh
Trouble with aggregating definitions.xml in distro
Hi, I have been working on modifying the existing bigbank demo to include security (things that have been tried and working in the securie-bigbank demo). All seemed fine, until I tried the modified bigbank demo from a distribution. One of things we do now is aggregating the various definitions.xml in META-INF/services since we now allow various modules and contributions to have their own definitions.xml if needs be. In a distro all of these definitions.xml are aggregated into a single file using the shade transformer. I end up with a definitions.xml that has multiple sca:definitions elements but no root. Also there seems to be multiple 'xml' declarations - ?xml version=1.0 encoding=ASCII?. All these creates trouble for the XMLStreamReader. At the present moment I am thinking of the following : 1) In the Definitions Document Processor prepend and append the xml with dummy elements so that there is a root element 2) Either strip all the duplicate xml declarations when doing step (1) or go an manually delete this in all the definitions.xml in our modules Though most of it has been tried and works, I feel its like some 'trick code' and could give us troubles in maintainability. Does anybody have a better idea to deal with this ? Thanks. - Venkat
Re: SDO Java 1.1-incubating release candidate 1
As for the felix version. Should we make sure both SCA and SDO are using the same versions ? On Sun, Feb 24, 2008 at 9:56 PM, Amita Vadhavkar [EMAIL PROTECTED] wrote: Below are the things pending before I can form RC2, please see if anybody have any inputs. All others comments are acted on. Pending: 1) The src distro includes the impl/.felix folder - is that really required or could it be excluded? 2) The sdo-api pom.xml is using the 0.8.0-SNAPSHOT version of the felix maven-osgi-plugin, could that use a non-snapshot release? 3) Mention of backport util source location in bin/Notice file - confirmation Regards, Amita On Fri, Feb 22, 2008 at 10:18 PM, kelvin goodson [EMAIL PROTECTED] wrote: On 22/02/2008, Amita Vadhavkar [EMAIL PROTECTED] wrote: Thanks for all the review comments - working on those. I am just checking a few things below where I am not clear - NOTICE file -- TO CHECK = where is backport developed Assuming http://backport-jsr166.sourceforge.net/, please confirm I'm 95% sure you are right, but opening up the jar to look for info on origin doesn't prove fruitful. I also downloaded the javadoc from http://repo1.maven.org/maven2/backport-util-concurrent/backport-util-concurrent/3.1/to see if that helped, but no. Potential ISSUE - I'm not sure if the samples should now have the felix librairs and backport libray listed as dependencies in the samples javadoc -?Are the samples using these? or it is because the libs used by the samples use these libs? If this is required, it will go in the same place in index.html where we are listing all the other dependencies, right? I wrote this in the context of a failing runsamples script, but having got it working it's clear that the samples are not dependent on having these new libraries on the classpath. So I don't believe any changes is needed to the javadoc for this. Am still not able to remove the target dir appearing in the sample project of bin distribution. Trying... good luck, I can't help right now, but might get some time later if you haven't already solved it Regards, Amita On Thu, Feb 21, 2008 at 8:44 PM, kelvin goodson [EMAIL PROTECTED] wrote: the problems with the runsamples.bat file are that 1) it is missing the tuscany prefix from the sdo api jar and 2) the woodstox library is at 3.2.0rather than 3.2.1 Also I can see that the runsamples.sh file is at the 1.0-incubatinglevel and has the woodstox version issue. Kelvin. On 21/02/2008, kelvin goodson [EMAIL PROTECTED] wrote: Amita, thanks for this, here are some comments Binary zip file on Windows == MD5 is fine I couldn't find your public pgp signing key -- it needs adding to the KEYS file at http://svn.apache.org/viewvc/incubator/tuscany/KEYS and registering on a key server (you may have done that, I haven't spent a lot of time remembering how to search for it yet) LICENSE is correct for all 3rd party jars in the lib file and jar versions are correct NOTICE file -- TO CHECK = where is backport developed README seems fine Samples javadoc -- Potential ISSUE - I'm not sure if the samples should now have the felix librairs and backport libray listed as dependencies in the samples javadoc ISSUE running runsamples.bat in the samples dir results in ... SDO Sample Programs. Running with BINARY_BASE set to .. If this script fails with ClassDefNotFound errors you probably need to edit the BINARY_BASE variable in the script to point to the location where you unpacked the Tuscany SDO binary distribution Exception in thread main java.lang.NoClassDefFoundError: commonj/sdo/DataObject at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Unknown Source) at org.apache.tuscany.samples.sdo.internal.SampleInfrastructure.class$( SampleInfrastructure.java:58) at org.apache.tuscany.samples.sdo.internal.SampleInfrastructure .clinit(SampleInfrastructure.java:57) I guess the bat and sh scrips need the classpath changing to reflect the updated jar versions C:\Release\sdo- 1.1-inc\RC1\bin\apache-tuscany-sdo-1.1-incubating\tuscany-sdo-1.1-incubating\samples ISSUE - there is an extra target directory in the samples directory of the binary distribution Release notes ... ISSUE -- following is not so Apache Tuscany's SDO Java Release
