December 2009 - dna-dev - Jboss List Archives

DNA continuous on JDK1.5 - Build # 860 - Still Unstable!

by jboss-qa-internal＠redhat.com

DNA continuous on JDK1.5 - Build # 860 - Still Unstable: Check console output at http://hudson.qa.jboss.com/hudson/job/DNA%20continuous%20on%20JDK1.5/860/ to view the results.

14 years, 6 months

1
0
0 / 0

DNA continuous on JDK1.5 - Build # 859 - Unstable!

by jboss-qa-internal＠redhat.com

DNA continuous on JDK1.5 - Build # 859 - Unstable: Check console output at http://hudson.qa.jboss.com/hudson/job/DNA%20continuous%20on%20JDK1.5/859/ to view the results.

14 years, 6 months

1
0
0 / 0

Eclipse plug-in in SVN

by Randall Hauch

A few weeks back, Dan committed the Eclipse publishing plug-in into the SVN trunk. It really is a fantastic and nicely-done bit of software. He did almost all of the development on a separate branch, and at the end merged the code into trunk. Since this was our first non-Maven code, I suggested that he commit it into the 'tools' directory, thinking that we'd be able to integrate the Eclipse build into the Maven build system. But after thinking about it for a while, building the Eclipse plugins (including the update site) from within our build system is a pretty complicated affair, both from a mechanism perspective but also from a dependency perspective. The Eclipse plugin requires the released JARs for 'dna-common' and 'dna-web-jcr-rest-client' to be bundled into the plugin update site, but those JARs really have to be built against the tagged release. That means that the Eclipse plugin code would have to be tagged with the rest of the code as part of the normal release, but the Eclipse update site would have to be reproduced afterward. Any problems with the Eclipse plugin or update site, and the whole codebase would have to be re-tagged and re-released. Very messy. My latest idea is that the Eclipse plugins just shouldn't even be in the http://anonsvn.jboss.org/repos/dna/trunk/ at all, and to instead place them in a separate area of SVN, like http://anonsvn.jboss.org/repos/dna/eclipse/trunk (along with the corresponding 'branches' and 'tags' sibling directories). All of the Eclipse plugin code would move into there, where they can remain non-Maven and Eclipse-specific PDE projects. We can then release the Maven-built part of DNA as usual, and then bundle and release the Eclipse plugin code. (At some point in the future, the DNA Eclipse plugin code might even move into the JBoss Tools superproject. So it certainly doesn't hurt to break it out now.) Anybody have thoughts about this? Best regards, Randall

14 years, 6 months

3
3
0 / 0

DNA continuous on JDK1.5 - Build # 857 - Fixed!

by jboss-qa-internal＠redhat.com

DNA continuous on JDK1.5 - Build # 857 - Fixed: Check console output at http://hudson.qa.jboss.com/hudson/job/DNA%20continuous%20on%20JDK1.5/857/ to view the results.

14 years, 6 months

1
0
0 / 0

DNA continuous on JDK1.5 - Build # 856 - Still Failing!

by jboss-qa-internal＠redhat.com

DNA continuous on JDK1.5 - Build # 856 - Still Failing: Check console output at http://hudson.qa.jboss.com/hudson/job/DNA%20continuous%20on%20JDK1.5/856/ to view the results.

14 years, 6 months

1
0
0 / 0

DNA continuous on JDK1.5 - Build # 855 - Failure!

by jboss-qa-internal＠redhat.com

DNA continuous on JDK1.5 - Build # 855 - Failure: Check console output at http://hudson.qa.jboss.com/hudson/job/DNA%20continuous%20on%20JDK1.5/855/ to view the results.

14 years, 6 months

1
0
0 / 0

NetChangeObserver Questions

by Daniel Florian

Here are some questions concerning the NetChangeObserver class which I am modifying whilst implenting the observation feature: 1. How do the CopyBranchRequest, CloneBranchRequest, RenameNodeRequest, and MoveBranchRequest create the node properties (and children)? I was expecting these types to be Iterable<Property> just like CreateNodeRequest so that I could generate the new property events. Don't I also need to add these property added events? 2. The docs for UpdateValuesRequest states that it can be used for a new property. If true, it would need the "isNewProperty()" method that was recently added to SetPropertyRequest and UpdatePropertiesRequest. Are the docs right? 3. There is no way to get the Property object from UpdateValuesRequest. The Property type is needed in the call to NetChangeDetails.changedProperty(Property) and NetChangeDetails.addProperty(Property). 4. I added code to handle CreateWorkspaceRequest, DestroyWorkspaceRequest, and CloneWorkspaceRequest. Right now it just creates a NODE_ADDED event for the root node. Seems like I could remove all the code for these requests as no listeners could possibly exist for these new/deleted workspaces. Agree? If not, the CreateWorkspaceRequest and CloneWorkspaceRequest will need a way to say what properties were added to the root node. Same issue as #1 above.

14 years, 6 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

dna-dev December 2009