[ 
http://jira.codehaus.org/browse/SUREFIRE-696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255415#action_255415
 ] 

Kristian Rosenvold commented on SUREFIRE-696:
---------------------------------------------

Sorry I was wrong about the immutability, my bad. I was just looking at the 
diff and it must have been wishful thinking on my behalf. I would like to make 
it immutable since it IMO generally improves construction logic and forces you 
to create objects in a given order - as required by the problem domain -  it 
usually just drives towards better code. But as you'll see making it immutable 
involves a fair amount of change.

The current situation wrt jdk 1.3 is that the *forked* side of the booter and 
the junit 3.x provider can actually fork down to 1.3. I am no particular fan of 
this feature, but that'd have to be a ML discussion of sorts. We will not be 
getting rid of 1.4 yet and I don't personally see the big difference in 
supporting 1.3.

But the booter module is basically split in 2, the "remote" part, which is 1.3 
and the "plugin" side which is 1.4. I have tried to increase this separation by 
moving the classes that belong only on the "plugin" side out of the booter 
project and into org.apache.maven.plugin.surefire.booterclient.

So the issues you found in PropertiesWrapper and SurefireStarter are real, 
since that's 1.3 code. The others questionable, since we somehow need 1.4 to 
build;) I will look at your patch tonight and fix the constructors too.

I don't like the 1.3 situation since it's really not sustainable; 1.3 
compatibility was broken in from 2.4.2->2.6 and I restored it in 2.7. I have to 
run in virtualbox to even test this stuff, since there is no 1.3 available for 
my platform. But I suppose I've just decided to look at it as a challenge since 
I never have to deal with this in my day job.

> Improve the design of the class Classpath
> -----------------------------------------
>
>                 Key: SUREFIRE-696
>                 URL: http://jira.codehaus.org/browse/SUREFIRE-696
>             Project: Maven Surefire
>          Issue Type: Improvement
>          Components: Maven Surefire Plugin
>    Affects Versions: 2.7.2
>            Reporter: Stefan Birkner
>            Priority: Minor
>         Attachments: SUREFIRE-696.patch, SUREFIRE-Classpath.patch
>
>
> This patch contains some improvements for the class Classpath:
> * Only use a set for storing the elements.
> * append(Classpath) has been changed to Classpath.join(Classpath, Classpath), 
> because the classpath doesn't get appended. Instead a new one is created.
> * Renamed setForkProperties to writeToForkProperties.
> * Renamed setAsSystemProperty to writeToSystemProperty.
> * Moved getClassPathAsString() into writeToSystemProperty and only call 
> writeToSystemProperty from outside.
> * Added readFromForkProperties in order to have serialization and 
> deseralization being part of the same class.
> From my point of view these changes improve the readability of the Surefire 
> code and are another step on the way to clean code.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to