[Java/XML/DTD] DTD relatief t.o.v. document laden

[JKVA]

Ik heb met Eclipse een EJB 3.0 project gemaakt waarin ik DBUnit gebruik om de database te vullen met testdata.

Voor DBUnit gebruik ik een XML bestand om de data in te zetten.

Dit is mijn structuur:

code:

- project
  - src
    - test
      - resources
        - testData.xml
        - schema.dtd
      - java
    - main
      - resources
      - java

Deze structuur heb ik nodig, aangezien ik straks de boel in Maven2 wil kieperen. Vandaar deze conventie.

Mijn probleem: Ik wil zowel vanuit Eclipse als Maven2 mijn JUnit tests draaien en daar begint het spek te stinken. Als ik namelijk vanuit Eclipse de JUnit test draai, wordt de DTD relatief aan de project root opgezocht, i.p.v. relatief aan het XML bestand.

Dit werkt niet:

XML:

<!DOCTYPE dataset SYSTEM "schema.dtd">

Dit werkt wel:

XML:

<!DOCTYPE dataset SYSTEM "src/test/resources/schema.dtd">

De URL met of zonder ./ prefixen maakt geen verschil.

Waarom zit ik zo te zeuren? Nou, omdat ik straks ook de tests in Maven2 wil draaien en daar bestaat @runtime de directory "src/test/resources/" niet meer en staat schema.dtd WEL in de root en moet daar gezocht worden.

[Jeldert]

Is dit het enige bestand dat niet werkt? Dan zou je eenvoudig een snelkoppeling kunnen maken.

[JKVA]

Jeldert schreef op maandag 09 juli 2007 @ 21:24:
Is dit het enige bestand dat niet werkt? Dan zou je eenvoudig een snelkoppeling kunnen maken.

Het is nu maar 1 bestand, maar ik kan me voorstellen dat ik straks per test een ander bestand wil, dus in principe zou het voor meerdere bestanden moeten werken.

[JKVA]

Hmm, heb nu iets werkends, maar dat is geen goeie oplossing. Ik heb voorlopig DTD validaties uitgezet in mijn parser. Nu wordt alleen in Eclipse gevalideerd. Werkbaar, maar geen goeie oplossing.

[Verwijderd]

Een andere workaround is om je schema op een (interne) webserver te zetten en dus via een url aan te roepen. Ik heb zelf nog niet echt een oplossing gevonden. Maar ik heb dan ook nog niet echt gezocht omdat ik het de moeite niet waard vond.

offtopic:
Eclipse is (zoals gewoonlijk) simpelweg te beperkt voor een product als maven. Zo krijg je ook gratis en voor niets je testclasses op je buildpath bij het uitvoeren van je code. De hippe scoping wordt gewoon platgeslagen tot 1 grote vergaarbak. Een fatsoenlijke IDE zoals IntelliJ Idea doet het natuurlijk wel allemaal goed.

[JKVA]

Verwijderd schreef op dinsdag 10 juli 2007 @ 09:20:
Een andere workaround is om je schema op een (interne) webserver te zetten en dus via een url aan te roepen. Ik heb zelf nog niet echt een oplossing gevonden. Maar ik heb dan ook nog niet echt gezocht omdat ik het de moeite niet waard vond.

offtopic:
Eclipse is (zoals gewoonlijk) simpelweg te beperkt voor een product als maven. Zo krijg je ook gratis en voor niets je testclasses op je buildpath bij het uitvoeren van je code. De hippe scoping wordt gewoon platgeslagen tot 1 grote vergaarbak. Een fatsoenlijke IDE zoals IntelliJ Idea doet het natuurlijk wel allemaal goed.

Tja, IDEA is wel cool, maar ik heb het MT nog niet kunnen overtuigen van het kwaliteitsverschil dat ze krijgen voor een prijs van 500 dollar per licentie t.o.v. 30 dollar voor MyEclipse.

[Verwijderd]

JKVA schreef op dinsdag 10 juli 2007 @ 12:24:
Tja, IDEA is wel cool, maar ik heb het MT nog niet kunnen overtuigen van het kwaliteitsverschil dat ze krijgen voor een prijs van 500 dollar per licentie t.o.v. 30 dollar voor MyEclipse.

Zelfde 'probleem' hier, dus het is een beetje de running-gag om er op te vitten. Ik vergelijk Eclipse altijd met een zwitserszakmes:
- Ja er zit een schaar in, maar het is geen echte schaar.
- Ja er zit een mes in, maar het is geen echt mes
- ...

[misfire]

Hoe roep je DBUnit aan? Hij moet de XML parsen met het goede base URI, namelijk "src/test/resources". Nu lijkt dat niet te gebeuren. Waarschijnlijk wil je de input als een classpath resource inlezen vanuit de test. Dan zou je deze constructor moeten gebruiken. Als je van een file wilt lezen, dan is het handig om de constructor met File te gebruiken.

Dit soort dingen gaat IDEA trouwens ook niet voor je rechtbreien, dit heeft puur te maken met het feit dat je files op verschillende plekken staan in de maven build vs het ontwikkelproject....

[Verwijderd]

misfire schreef op dinsdag 10 juli 2007 @ 13:21:
Dit soort dingen gaat IDEA trouwens ook niet voor je rechtbreien

Appart dat het dan bij mij thuis met Idea wel werkt.

[JKVA]

Ehm, ik zal eens wat code laten zien:
Base testklasse:

Java:

public abstract class BaseTestCase extends DBTestCase {
    @Override
    protected IDataSet getDataSet() throws Exception {
        return new FlatXmlDataSet(this.getClass().getResourceAsStream("/simpleDataSet.xml"), false);
    }
}

Ik kies dus de constructor die een stream pakt en gebruik false bij "dtdMetadata", maar dat is (hopelijk) tijdelijk. Ik wil straks namelijk dat mijn XML door de DTD gevalideerd wordt en niet van mijn IDE afhankelijk zijn.

Tevens gebruik ik Class.getResourceAsStream(), omdat ik dan resources van het classpath kan lezen zonder last te hebben van de naamgeving van source folders.

Het vreemde (lees: vervelende) is alleen dat mijn XML parser (Xerces) de project root als root beschouwt bij het zoeken naar een DTD, i.p.v. de locatie van het XML bestand zelf.

Als ik namelijk in een XML file dit zet

XML:

<!DOCTYPE dataset SYSTEM "schema.dtd">

verwacht ik dat de parser gaat zoeken naar een DTD in dezelfde directory als het XML bestand, maar dat lijkt niet te gebeuren...

[misfire]

DBUnit/Xerces weet niet waar het bestand staat, omdat je een kale inputstream aanlevert. De file referentie zal dus niet aan Xerces worden gevoerd. Als je DBUnit aanroept met een File in de constructor, of de constructor gebruikt die ik gelinkt heb, dan zou het moeten werken.

Ik zou het een sterk verhaal vinden als IDEA dit wel voor je corrigeert, dan zou hij bij iedere testrun bestanden moeten kopiëren op de manier zoals Maven dat ook doet. Zoiets kun je ook in Eclipse 3.3 met de Maven 2 Eclipse plug-in. Uiteindelijk is het in dit geval puur toeval dat het in Maven wel werkt, en geen correct gedrag.

[JKVA]

Ehm, de link in je vorige post, bevat een niet compleet anchor. Welke constructor bedoel je nu?

[JKVA]

Laat maar, ik heb hem werkend. De constructor met een File werkt. Dan wordt de DTD relatief t.o.v. het bestand opgezocht.

Hij is nu zo geworden:

Java:

    @Override
    protected IDataSet getDataSet() throws Exception {
        URL path = this.getClass().getResource(FILE);
        if (path == null) {
            throw new IOException("File: '"+ FILE +"' does not exist!");
        }
        URI uri = path.toURI();
        File xmlFile = new File(uri);
        return new FlatXmlDataSet(xmlFile);
    }

[Verwijderd]

misfire schreef op dinsdag 10 juli 2007 @ 13:51:
Ik zou het een sterk verhaal vinden als IDEA dit wel voor je corrigeert

Dat lijkt mij ook sterk dat idea het corrigeert. Ik ben iig niet tegen dergelijke problemen aangelopen met idea en wel(/aan de lopende band) met eclipse.

[JKVA]

Verwijderd schreef op dinsdag 10 juli 2007 @ 14:33:
[...]
Dat lijkt mij ook sterk dat idea het corrigeert. Ik ben iig niet tegen dergelijke problemen aangelopen met idea en wel(/aan de lopende band) met eclipse.

Stomme vraag, maar gebruik je IDEA ook voor hetzelfde soort werk? Eclipse gebruik ik voornamelijk voor 'echt' werk, waar dus ook irritante real life dingen optreden.

Andere tooling zoals IDEA en NetBeans gebruik ik voornamelijk om een beetje mee te frobelen en dat gaat altijd wel goed...

[Verwijderd]

JKVA schreef op dinsdag 10 juli 2007 @ 15:55:
Stomme vraag, maar gebruik je IDEA ook voor hetzelfde soort werk? Eclipse gebruik ik voornamelijk voor 'echt' werk, waar dus ook irritante real life dingen optreden.

Nouja, hoe echt is echt. Voor mijn hobby projectjes ben ik veel minder pragmatisch dan wanneer ik 'echt' werk. Ik fantaseer dat mijn hobby projectjes enorme bank-systemen zijn. Alles moet dus perfect zijn. Ik ga dus wat dat betreft met mijn idea hobby-projectjes op sommige vlakken verder dan mijn eclipse werk-projecten. Voor beide geldt dat er irritante real life dingen optreden, het zijn alleen andere dingen.

[misfire]

JKVA schreef op dinsdag 10 juli 2007 @ 14:01:
Ehm, de link in je vorige post, bevat een niet compleet anchor. Welke constructor bedoel je nu?

Ik bedoelde die ene met 2 inputstreams in de constructor (probleem met spaties in constructor), maar wat je nu hebt zal ook prima werken.

@Mark: Ik ben toch benieuwd geworden naar je opmerkingen over de support in IDEA voor Maven. Aangezien IDEA geen out of the box support levert voor Maven (alleen in de versie 7 milestone) neem ik aan dat je een plug-in gebruikt. Welke plug-in(s) gebruik je?

[Verwijderd]

misfire schreef op dinsdag 10 juli 2007 @ 17:16:
@Mark: Ik ben toch benieuwd geworden naar je opmerkingen over de support in IDEA voor Maven. Aangezien IDEA geen out of the box support levert voor Maven (alleen in de versie 7 milestone) neem ik aan dat je een plug-in gebruikt. Welke plug-in(s) gebruik je?

Het is andersom; maven heeft idea support

[misfire]

Voor Eclipse schijnt Maven ook support te hebben. Ik werk ook veel met Eclipse en Maven 2 en ik heb eigenlijk vrijwel nooit problemen met die combinatie (wel met Maven 2). Het enige waar je op moet letten is dat de eclipse compiler output dir anders is als die van maven, anders heb je snel ruzie met als je de tools door elkaar gebruikt.

[Verwijderd]

misfire schreef op dinsdag 10 juli 2007 @ 17:47:
Voor Eclipse schijnt Maven ook support te hebben. Ik werk ook veel met Eclipse en Maven 2 en ik heb eigenlijk vrijwel nooit problemen met die combinatie (wel met Maven 2). Het enige waar je op moet letten is dat de eclipse compiler output dir anders is als die van maven, anders heb je snel ruzie met als je de tools door elkaar gebruikt.

Nou iets wat eclipse simpelweg niet kan is onderscheidt maken tussen test en normale classes. Dat onderscheidt is bij maven aanwezig en is ook bij idea aanwezig. Eclipse doet tevens helemaal niets met filesystem changes, dus een build buiten eclipse om wordt niet opgemerkt (bijv nieuwe artifacts).

Volgens mij doe je trouwens iets niet helemaal goed als je output dir afwijkt in eclipse, want die is bij mij gewoon hetzelfde (de 'target' directory dus). Dat is dan net weer iets wat wel goed werkt

[ Voor 11% gewijzigd door Verwijderd op 10-07-2007 18:45 ]

[JKVA]

mvn eclipse:eclipse roeleert

Die Eclipse plugin voor Maven2 vind ik eerlijk gezegd nogal crap. Een collega van mij heeft een alternatieve geschreven dat tig keer beter werkt.

Hmm, zal binnenkort eens vragen of hij het open source mag maken van de grote bazen...

[JKVA]

Verwijderd schreef op dinsdag 10 juli 2007 @ 18:41:
[...]
Nou iets wat eclipse simpelweg niet kan is onderscheidt maken tussen test en normale classes. Dat onderscheidt is bij maven aanwezig en is ook bij idea aanwezig. Eclipse doet tevens helemaal niets met filesystem changes, dus een build buiten eclipse om wordt niet opgemerkt (bijv nieuwe artifacts).

Volgens mij doe je trouwens iets niet helemaal goed als je output dir afwijkt in eclipse, want die is bij mij gewoon hetzelfde (de 'target' directory dus). Dat is dan net weer iets wat wel goed werkt

Output dir zet ik ook altijd hetzelfde, zeker bij webapplicaties, want dan kan ik met maven hot deployen.

[JaWi]

Verwijderd schreef op dinsdag 10 juli 2007 @ 18:41:
[...]
Nou iets wat eclipse simpelweg niet kan is onderscheidt maken tussen test en normale classes. Dat onderscheidt is bij maven aanwezig en is ook bij idea aanwezig. Eclipse doet tevens helemaal niets met filesystem changes, dus een build buiten eclipse om wordt niet opgemerkt (bijv nieuwe artifacts).

FWIW: Preferences -> General -> Workspace -> Refresh automatically aanvinken; staat standaard uit (misschien onterecht) omdat Eclipse ervan uitgaat dat je alles binnen Eclipse doet en niets daarbuiten.

Daarnaast weet Eclipse prima het verschil tussen testen en normale classes; maar dat doet hij alleen als hij een dependency naar JUnit in z'n buildpath vindt. Daarna kun je op elke willekeurige directory zelfs "Run as JUnit Test" doen, waarna alle JUnit testen in deze directory gedraaid worden...

[Verwijderd]

JaWi schreef op dinsdag 10 juli 2007 @ 19:41:
FWIW: Preferences -> General -> Workspace -> Refresh automatically aanvinken; staat standaard uit (misschien onterecht) omdat Eclipse ervan uitgaat dat je alles binnen Eclipse doet en niets daarbuiten.

Met als gevolg dat Eclipse als een malle staat te refreshen maar nog steeds nieuwe maven artifacts mist.

JaWi schreef op dinsdag 10 juli 2007 @ 19:41:
Daarnaast weet Eclipse prima het verschil tussen testen en normale classes;

Ik heb het niet over unit tests draaien, ik heb het over verschil maken in buildpaden. Maven maakt een duidelijk onderscheid tussen test classes en libraries en source classes en libraries. Voor Eclipse is dit gewoon een grote verzamelbak van code, voor maven en je uiteindelijke project niet. De workaround is een appart project maken voor je test classes. Maarja dat wil je niet.

Maar goed, ik ben weer eens een beetje teveel mijn (terechte) afkeer tegen elcipse aan het uitspreken. Dus even in heilige-boontjes modus: gebruik je gewoon wat je prettig vind werken.

[JKVA]

Ofwel: gebruik IDEA, als je het kunt betalen of aan open source werkt. :-)

[Verwijderd]

Het verschil in output dir is er standaard niet maar configureer ik zelf. Dit is om te voorkomen dat je ruzie krijgt tussen de incrementele compiler van Eclipse en de Maven compiler. Standaard gaat dit best goed, behalve als je veel code gaat stuk maken en dan met Maven en Eclipse door elkaar gaat bouwen (omdat Eclipse code met compile fouten anders compileert dan Javac). Een alternatief is de Java compiler setting "rebuild classfiles modified by others", maar ik vind het schoner en makkelijker om de twee compilers uit elkaar te houden.

Met Eclipse kun je inderdaad geen onderscheid maken qua libraries binnen je project. Ik zie hier niet echt een probleem, het code completion lijstje zou langer kunnen worden maar in de praktijk hindert me dat niet. De uiteindelijke scheiding moet uiteindelijk toch in de build afgedwongen worden.

Ik heb niets tegen IDEA, en het is op sommige onderdelen zeker beter, maar Eclipse is ook geen slechte tool. Wat me opvalt is dat veel problemen op Eclipse geschoven worden die helemaal niks met Eclipse te maken hebben (zoals dit probleem). Het is altijd makkelijk om een tool de schuld te geven, en het gras is altijd groener bij de buren. Maar als je weet dat je toch niet met IDEA mag werken van je baas dan lijkt het mij nuttiger om je te focussen op wat Eclipse wél kan (en dat is meestal toch meer dan je denkt).

Ik ben trouwens heel benieuwd naar jullie alternatief voor M2Eclipse, ik hoop dat het open source mag worden.

[JKVA]

Verwijderd schreef op woensdag 11 juli 2007 @ 14:18:
Het verschil in output dir is er standaard niet maar configureer ik zelf. Dit is om te voorkomen dat je ruzie krijgt tussen de incrementele compiler van Eclipse en de Maven compiler. Standaard gaat dit best goed, behalve als je veel code gaat stuk maken en dan met Maven en Eclipse door elkaar gaat bouwen (omdat Eclipse code met compile fouten anders compileert dan Javac). Een alternatief is de Java compiler setting "rebuild classfiles modified by others", maar ik vind het schoner en makkelijker om de twee compilers uit elkaar te houden.

Met Eclipse kun je inderdaad geen onderscheid maken qua libraries binnen je project. Ik zie hier niet echt een probleem, het code completion lijstje zou langer kunnen worden maar in de praktijk hindert me dat niet. De uiteindelijke scheiding moet uiteindelijk toch in de build afgedwongen worden.

Ik heb niets tegen IDEA, en het is op sommige onderdelen zeker beter, maar Eclipse is ook geen slechte tool. Wat me opvalt is dat veel problemen op Eclipse geschoven worden die helemaal niks met Eclipse te maken hebben (zoals dit probleem). Het is altijd makkelijk om een tool de schuld te geven, en het gras is altijd groener bij de buren. Maar als je weet dat je toch niet met IDEA mag werken van je baas dan lijkt het mij nuttiger om je te focussen op wat Eclipse wél kan (en dat is meestal toch meer dan je denkt).

Ik ben trouwens heel benieuwd naar jullie alternatief voor M2Eclipse, ik hoop dat het open source mag worden.

Ja, dat is het zelfs al. Deze week post ik hier de URL. Die collega moet nog wat aanpassen qua licentieheaders en dat geneuzel.

[Verwijderd]

Verwijderd schreef op woensdag 11 juli 2007 @ 14:18:
Het is altijd makkelijk om een tool de schuld te geven, en het gras is altijd groener bij de buren. Maar als je weet dat je toch niet met IDEA mag werken van je baas dan lijkt het mij nuttiger om je te focussen op wat Eclipse wél kan (en dat is meestal toch meer minder dan je denkt).

Begrijp me inderdaad niet verkeerd, doorgaans focus is echt wel op wat eclipse wel kan. Op het moment ontwikkel ik sneller in Eclipse dan in Idea, gewoon omdat ik het meer gebruik en dus beter op de hoogte ben van de key-bindings en quircks. Maar zo nu en dan moet de frustratie, dat we in Java land met zijn allen een amateur platform hebben omarmd, er even uit.

offtopic:
Langere code-completion lijstjes hinderen in de praktijk wel degelijk als het project wat omvangrijker wordt!

[ Voor 6% gewijzigd door Verwijderd op 11-07-2007 15:03 ]

[Verwijderd]

JKVA schreef op woensdag 11 juli 2007 @ 14:34:
[...]
Ja, dat is het zelfs al. Deze week post ik hier de URL. Die collega moet nog wat aanpassen qua licentieheaders en dat geneuzel.

Cool, ik ben heel benieuwd.