Hi David,
Agreed, externalized would be best. SVN diff produces such poor
patches though when there are directory moves involved that I
hesitate to attempt something like that. If its palatable I could
simply copy them and make a patch that adds the copies then someone
could delete them from the j2ee-builder directory once everyone is
happy with the new layout.
The particulars of how these problems are solved don't really matter
if we move them into a separate module either (which is great IMO)
since we would probably want to have all the options implemented in
several different ear's for integration tests.
Speaking of itests: what is the current status of that work. I recall
that a couple of folks were working on that and I was going to help
but I got side tracked with the dependency problems in the console.
I'm happy to help with it now as the console is working (see other
email about that).
Thanks,
-bd-
On Aug 24, 2006, at 12:29 PM, David Jencks wrote:
On a related note I've been creating a bunch of little m2 projects
to build apps to verify defects and their fixes. Usually you have
to look at the output to see if it passed. I've been attaching
these projects to the issues in question. I think we should
consider putting these in svn somewhere and if we can get the itest
plugin to run them that would be even better.
Not exactly the same situation as you have here but it seems
somewhat related. Anyway you might consider making an m2 project
to build this sample app.
thanks
david jencks
On Aug 23, 2006, at 6:59 PM, Bill Dudney wrote:
Hi All,
The tests in the j2ee-builder do not currently have valid
deployment descriptors. While that's ok for this module because of
the mocked out deployment bits I was hoping to use them in other
tests. I have most of the stuff fixed up but there are a few
things that I don't want to do without feedback.
1) there rar is empty, no jar's no xml in the deployment
descriptors its just a place holder. Thoughts on what to do with
that? cook up a simple rar? delete it? I lean towards making a
simple rar.
2) The web.xml references a bogus bunch of ejb's with refs like
'fake-ejb-ref'. Couple of things we could do with this, make them
point to valid ejb references in the ejb jar files that are part
of this ear or delete them. I would/could add some extra EJB's to
the ejb jar to make sure we covered all the reference types.
3) This is less important but I'd like to change the artifactId's
so they are unique (i.e. test-ear-j2ee-1.{3,4}) so that I can
deploy both of the ear files when its all said and done.
4) I'm not sure exactly how to do this with ear/war/ejb-jar but
I'd like to have this module produce a 'tests' jar (we do this in
cayenne with simple junit tests so we can reuse it across modules)
and then reuse these deployment units in other automated tests.
I'm game to poke at it but figure I might get a few of Jason's
brain cells so I can be a bit lazier :-)
I posted this jira;
https://issues.apache.org/jira/browse/GERONIMO-2352
to track this issue.
Thanks!
-bd-
