2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

dna-dev November 2009

dna-dev@lists.jboss.org

5 participants
21 discussions

Start a nNew thread

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

16 years, 10 months

3
3
0 / 0

DNA nightly integration on JDK1.5 - Build # 598 - Still Failing!

by jboss-qa-internal＠redhat.com

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

16 years, 10 months

1
0
0 / 0

DNA nightly integration on JDK1.5 - Build # 597 - Failure!

by jboss-qa-internal＠redhat.com

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

16 years, 10 months

1
0
0 / 0

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

by jboss-qa-internal＠redhat.com

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

16 years, 10 months

1
0
0 / 0

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

by jboss-qa-internal＠redhat.com

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

16 years, 10 months

1
0
0 / 0

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

by jboss-qa-internal＠redhat.com

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

16 years, 10 months

1
0
0 / 0

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

by jboss-qa-internal＠redhat.com

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

16 years, 10 months

1
0
0 / 0

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

by jboss-qa-internal＠redhat.com

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

16 years, 10 months

1
0
0 / 0

Generating Events For Child Nodes

by Daniel Florian

The requirements for generating events for children of nodes that have been added/removed/moved/copied seems to be different between JCR 1.0 to JCR 2.0. For JCR 1.0 it seems these events are required. For JCR 2.0 it they are optional. These 2 TCK observation tests are failing because of this: NodeRemovedTest.testMultiNodesRemoved WorkspaceOperationTest.testCopy Here are the spec details: 1. JSR 170 1.0 (JCR 1.0 11 May 2005) a. Section 8.3.7.1 Creating a new Node ... as well for each of the automatically created child nodes or properties (either NODE_ADDED or PROPERTY_ADDED, as the case may be). b. Section 8.3.7.4 Removing a Child Node ... Additionally, an implementation should also generate a NODE_REMOVE or PROPERTY_REMOVE (as appropriate) for each item in the removed subtree. c. Section 8.3.7.6 Copying a Subtree ... Additionally, an implementation should generate appropriate events for each resulting node and property addition in the copied subtree. d Section 8.3.7.7 Moving a Subtree ... Additionally, an implementation should generate a NODE_REMOVE or PROPERTY_REMOVE (as appropriate) for each node and property removed from its source path location and a NODE_ADDED or PROPERTY_ADDED (as appropriate) for each node and property added at its destination path location. e. Section 8.3.7.8 Re-ordering a set of Child Nodes ... Additionally, an implementation should generate appropriate events reflecting the “shifting over” of the node B and any nodes that come after it in the child node ordering. Each such shifted node would also produce a NODE_REMOVED and NODE_ADDED event pair with paths differing at most by a final index. 2. JSR 283 FCS (JCR 2.0 10 Aug 2009)- Section 12.2 Scope of Event Reporting The scope of event reporting is implementation-dependent. An implementation should make a best-effort attempt to report all events, but may exclude events if reporting them would be impractical given implementation or resource limitations. For example, on an import, move or remove of a subgraph containing a large number of items, an implementation may choose to report only events associated with the root node of the affected graph and not those for every subitem in the structure.

16 years, 10 months

2
1
0 / 0

Recent changes and Maven hell

by Randall Hauch

You may have noticed the many build failures yesterday. It looks like I was able to fine-tune several of our dependencies (particular by upgrading RESTEasy) and then work with the QA team to clear out problem areas of the build machine's ~/.m2/repository. Hopefully things should be transparent to everyone, but there may be some cases where you run into trouble. A number of artifacts in the JBoss Maven repository have been marked as "relocated" (see http://maven.apache.org/guides/mini/guide-relocation.html). Now, if you have been building recently, there's a good chance that your local ~/.m2/repository has cached the artifacts (from various repositories) a while back. The good news is that you probably wont' see any issues. The bad news is that you might be building with artifacts that the official builds no longer use, meaning you might see different behavior than the Hudson builds. The "correct" thing would be to move (or rename) your ~/.m2/repository and rebuild everything. Unfortunately, you'll probably then run into the next problem. When you do start with a clean local Maven repository, you'll get a couple of artifacts that are now relocated. Maven 2.0.9 works fine, but the M2Eclipse plugin that I was using (200905xxxx) didn't like those relocations (https://issues.sonatype.org/browse/MNGECLIPSE-1497) and I had to upgrade to the latest stable development release of M2Eclipse (at http://m2eclipse.sonatype.org/update-dev/). So far so good, but it took me a while to figure out. In short, you may run into some Maven problems, but it should be possible to solve them. Holler if you run into any problems. Best regards, Randall

16 years, 10 months

1
0
0 / 0

← Newer
1
2
3
Older →