Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Mime-Version: 1.0 (Apple Message framework v752.2)
In-Reply-To: <D2F68765-0C30-4C15-A42B-5EC9372C266A@planet57.com>
References: <1B1842CD-CF73-4B16-9ABE-75F5EEECA953@apache.org>
 <9BE0B047-0CFE-416A-87C8-459AEA9E4518@planet57.com>
 <2DFB3B1D-28FC-4CEF-82D7-C029BAFA764D@apache.org>
 <8701D6B6-E6CF-4471-B0B3-6DA0CDF4ED75@planet57.com>
 <0C508275-0618-4764-8330-AF77BC0489C9@apache.org>
 <E7B12BE5-C767-478B-8760-4DB166FA74DE@planet57.com>
 <7E26B950-696F-4701-B999-BC56C3761406@apache.org>
 <D2F68765-0C30-4C15-A42B-5EC9372C266A@planet57.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <3E18F36F-4731-42D6-93F4-5E199FD3AD7A@apache.org>
Content-Transfer-Encoding: 7bit
From: Bill Dudney <bdudney@apache.org>
Subject: Re: j2ee-builder tests?
Date: Tue, 29 Aug 2006 13:07:21 -0600
To: dev@geronimo.apache.org

Hi Jason,

I have a patch ready for this but I wanted to run a couple of things  
by you before submitting it.

1) The dependency plugin version 2.0-SNAPSHOT is all that appears to  
work. I could not find a functional 1.0 version of this plugin. I  
guess the question here is what is the community stance on using  
snapshots of plugins for the build? If this is not OK we need to get  
on the maven lists and try to get a released version of the  
dependency plugin. I found a couple of posts on the maven lists that  
make me hope that a 2.0 release is going to happen soon but I don't  
follow the maven community that closely so I'm not sure.

2) The j2ee-builder tests use a 'naked' ear that has been stripped of  
its geronimo-application.xml file. Easy enough to do with ant and we  
can do it with maven as well I'm sure but I was hoping you'd have  
some ideas about how to do it more simply that what I was thinking.  
Here are my two ideas;
	a) adopt an approach similar to the boilerplate-{j2ee,minimal} in  
the assembly build
	b) use something in the dependency plugin that can strip various  
elements from a jar file
	c) unpack it then repack with the geronimo-application.xml file  
excluded

3) There are a couple of more testing bits in the geronimo-j2ee- 
builder module. I'm not sure what the best way to remove them is.
	a) src/test-plan - has some bad plan files that ensure that failure  
happens when expected. I think these should be moved into src/test/ 
resources and used from there in the tests but wanted to get your take.
	b) src/test-unpacked-ear is another set of deployment descriptors  
and plans used for both positive and negative tests. Again these  
could/should probably be moved into the src/test/resources directory  
(when its created until then it looks like src/test is the destination)

after discussion ends on these questions I'll post the complete patch  
to;

https://issues.apache.org/jira/browse/GERONIMO-2352

Thanks again,

-bd-

On Aug 28, 2006, at 9:56 PM, Jason Dillon wrote:

> That is my preference.
>
> --jason
>
>
> On Aug 28, 2006, at 7:45 PM, Bill Dudney wrote:
>
>> Hi Jason,
>>
>> If we don't care about a trail then its really easy.
>>
>> I can do everything via a patch then and just delete the old stuff  
>> from the j2ee-builder at the end.
>>
>> Thanks,
>>
>> -bd-
>>
>> On Aug 28, 2006, at 5:13 PM, Jason Dillon wrote:
>>
>>> Hi Bill... I don't think that will work... since as soon as I  
>>> move them the build will start failing, as those bits are still  
>>> needed to run the geronimo-j2ee-builder tests.
>>>
>>> I'm not really concerned about the paper trail that we get with  
>>> svn mv for these.  I'd rather just svn add the new tree of  
>>> modules, delete the old bits and apply a patch to hook it up to  
>>> the build.  Or a zip for the new modules and a patch for the  
>>> build changes is fine too.
>>>
>>> --jason
>>>
>>>
>>> On Aug 28, 2006, at 8:45 AM, Bill Dudney wrote:
>>>
>>>> Hi Jason,
>>>>
>>>> Yes I made some progress. Not quite done as I ran into a  
>>>> redeploy bug that I spent a bit of time poking at over the  
>>>> weekend. I think the thing to do is to get the test stuff moved  
>>>> over and then I'll experiment more with the redeploy bug.
>>>>
>>>> From past experience patches generated by svn after an svn mv  
>>>> are not the best. So I was thinking that you should move the  
>>>> stuff around, then I'll submit a patch against the moved  
>>>> content. Does that sound OK or is there a better way?
>>>>
>>>> Once the move is complete I'll generate a patch that can be  
>>>> applied to these bits to make them deploy and get rid of the  
>>>> j2ee-builder pom and ant stuff that uses these. There are two  
>>>> other test deployables (test-plan and test-unpacked-ear) that  
>>>> I'd also like to move but I was thinking it would be better to  
>>>> get this done first then move the other two.
>>>>
>>>> Thanks,
>>>>
>>>> -bd-
>>>>
>>>> Here is the list of commands that will get us to the point of an  
>>>> easy patch. Again I'm totally open to a better way if there is one.
>>>>
>>>> svn mkdir test-deployables
>>>> svn mv modules/j2ee-builder/src/test-ear test-deployables/test- 
>>>> ear-j2ee-1.4
>>>> svn mv modules/j2ee-builder/src/test-ear13 test-deployables/test- 
>>>> ear-j2ee-1.3
>>>>
>>>> svn ci -m 'initial move of test stuff'
>>>>
>>>> cd test-deployables/test-ear-j2ee-1.4 (repeat from here down for  
>>>> the test-ear-j2ee-1.3 as well)
>>>>
>>>> svn mv test-ejb-ear ejb
>>>> svn mv test-rar rar
>>>> svn mv test-war war
>>>> svn mkdir ear/src/main/resources (these have to be done one at a  
>>>> time AFAIK)
>>>> svn mv META-INF ear/src/main/resources
>>>>
>>>> cd ejb
>>>>
>>>> svn mkdir src/main/java
>>>> svn mkdir src/main/resources
>>>>
>>>> svn mv org src/main/java
>>>> svn mv META-INF src/main/resources
>>>>
>>>> cd ../rar
>>>>
>>>> svn mkdir src/main/resources
>>>> svn mv META-INF src/main/resources
>>>>
>>>> cd ../web
>>>>
>>>> svn mkdir src/main/webapp
>>>> svn mv hello.txt src/main/webapp
>>>> svn mv WEB-INF src/main/webapp
>>>>
>>>> svn ci -m "moving the test stuff"
>>>>
>>>>
>>>> On Aug 27, 2006, at 11:51 PM, Jason Dillon wrote:
>>>>
>>>>> Hiya Bill... didya happen to make any progress on this?
>>>>>
>>>>> --jason
>>>>>
>>>>>
>>>>> On Aug 25, 2006, at 1:28 PM, Bill Dudney wrote:
>>>>>
>>>>>> Hi Jason,
>>>>>>
>>>>>> I'd be happy to do this. Do you have a direction yet on the  
>>>>>> movement of modules? This would probably best fit in something  
>>>>>> like
>>>>>>
>>>>>> trunk/test-deployables/${module-name}
>>>>>>
>>>>>> Does that sit well, or would you rather me put it into  
>>>>>> modules? Then you can move it around when you move everything  
>>>>>> else.
>>>>>>
>>>>>> TTFN,
>>>>>>
>>>>>> -bd-
>>>>>>
>>>>>> On Aug 25, 2006, at 1:54 PM, Jason Dillon wrote:
>>>>>>
>>>>>>> I think it would be good to turn those mock test apps into a  
>>>>>>> set of real m2 modules that build the j2ee deployables, then  
>>>>>>> j2ee-deployer can depend on them  and not have to hack up its  
>>>>>>> build to generate them... and then those mock apps could be  
>>>>>>> reused outside of that module too... say to test the cli  
>>>>>>> deployer and more.
>>>>>>>
>>>>>>> You want to take a whack at this?
>>>>>>>
>>>>>>> Should be easy enough... I'd like to use these mock apps  
>>>>>>> instead of converting all of those hacks to use the m2  
>>>>>>> standard layout for j2ee-builder.
>>>>>>>
>>>>>>> --jason
>>>>>>>
>>>>>>>
>>>>>>> On Aug 23, 2006, at 3: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-
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>