Community
Participate
Working Groups
In 3.2 the Junit 3.8 and 4.0 plugins are shipped as directories. I know that at one point we went through this decision path of understanding why this was desireable but I suspect that the assumptions used at that time are no longer valid. For 3.3. we should review the situation and press for the Junit team to in fact include the needed manifest markup in the jars that they produce. We will then be able to simply include their JARs directly in our builds as we do with SSH and ICU.
A reason why we didn't change to JAR'ed packageing is that we offer a classpath variable JUNIT_HOME that points the the plugin directory and users have 'JUNIT_HOME/junit.jar' in their classpaths. We would definitly like to get rid of this classpath variable but we have to see how we find a non-breaking workaround for that.
feels like the work around should be easy. If they update their classpath then the PDE UI will read their manifest and add the needed information. Seems also that this will be increasingly important now that we have two Junits. What would JUNIT_HOME be set to?
Jeff, Martin is referring in comment 1 to Java projects that have no manifest.mf. So there are many .classpath files out there for these kinds of projects that have a JUNIT_HOME classpath variable appended by a hardcoded junit.jar. In a perfect world where all Java projects would have a manifest.mf and a PDE container, the shape of the junit plugin could have been switched easily and nobody would have been broken.
Thanks for that. What is the story for the two versions of Junit? How do Java project developers use the Junit they want? Two variables? One global setting? I noticed that the jar names are different. Does that play a role here? since Junit only has one JAR, could we not just have two vars, JUNIT3 and JUNIT4 and let users pick. The value of the vars would be the full path to the JAR. Then we can JAR the bundles and set the vars to point at the bundles. Seems like existing Java projects are going to need some sort of migration anyway.
while we're at it, is there something preventing us from shipping org.eclipse.jdt.junit and org.eclipse.jdt.junit.runtime as JARs?
Wassim, does your bug 90723 no longer hold?
right. It no longer holds. we officially dropped support for all things 2.x in the 3.2 cycle.
> What is the story for the two versions of Junit? How do Java project > developers use the Junit they want? Two variables? One global setting? I > noticed that the jar names are different. Does that play a role here? 2 variables would be possible, but as we don't really like variables, for 3.2 a JUnit classpath container has been added that is configured to resolve either to JUnit 3 or JUnit 4. The classpath container is flexible enough to allow the plugin to be JAR'ed or hopefully all other future formats. We could in fact already JAR org.junit4. I'll have a look at that for 3.2. If we now could bring all users of the old classpath variable to the new container then we can also JAR JUnit 3. But I don't see a (non-breaking) solution right now. And the efford put in that must correspond to the benefit of having org.junit JARed. Jeff, is there a big benefit besides consistency? If JARing org.eclipse.jdt.junit and org.eclipse.jdt.junit.runtime is possible then we should do that for 3.3. Don't want to risk anything for 3.2.
Fair enough. I suggest - JAR Junit 4 in 3.2. Junit 4 users would be directed to use the classpath container - encourage Java developers to use the JUnit container in the 3.2 time frame. For exmaple, if you find a reference to the JUNIT_HOME var on the lib path in 3.2, produce a warning on the project telling people that the JUNIT_HOME var on the classpath is deprecated and directing people to use the container. - in 3.3 JAR everything You are right that there are no hard, concrete benefits to JARing but it is a bit more than consistency. At a strategic level we need OSGi/Eclipse bundles to appear to (and in fact) be normal Java JARs that happen to have modularity information. This will have a big impact as people move to modular JAva development and want to consume, for example, JUnit JARs out of a repo somewhere but also be able ot use the modularity metadata contained therein. The way it is now, the JUnit jar on the net would be a bundle JAR that contains a nested code JAR. This cannot be used directly by compilers or other tooling nor can it be run directly by normal Java runtimes. See JSR 277, 232, 291 for more information
> - encourage Java developers to use the JUnit container in the 3.2 time frame. > For exmaple, if you find a reference to the JUNIT_HOME var on the lib path in > 3.2, produce a warning on the project telling people that the JUNIT_HOME var on > the classpath is deprecated and directing people to use the container. That would be nice. Altough I don't see how I can generate the warnings for usages of JUNIT_HOME. We have no builder. Philippe, any idea? Suggestions - jdt.core cheets and just reports JUNIT_HOME as deprecated (hardcoded) - extend 'ClasspathVariableInitializer' with new API 'isDeprecated() : String (reason)'
I filed bug 138599 requesting a new feature to mark a classpath variable as deprecated.
Re: comment 10. I would rather see this problem as a migration issue. So in theory, yes a container/variable could be deprecated; but this is a one time issue; and I'd rather have a migration story (a la code cleanup), where a workspace would be upgraded; rather than 20 different custom quickfixes which require specific markers to be generated (and also requiring corresponding preferences to be inserted... think of customers who do not want such warnings to be rendered ever, like code generators).
I guess it needs both, migration story and incremental update using quick fix or manual change. In the case of JUnit, it seems unlikely to me that the user has a workspace full of projects using the variable. Rather be one or two. So the incremental updating could do the job here.
yes, an "update my project" facility or some such would be cool.
In 3.3 we should have a way to deprecate the classpath variable (bug 138599). JARing JUnit 4 should already be possible but might require legal approval from junit.org regarding the re-packaging. I guess also could JAR org.eclipse.jdt.junit and org.eclipse.jdt.junit.runtime.
Created attachment 56788 [details] patch to jar jdt.junit and jdt.junit.runtime
released patch > 20070111. jdt.junit and jdt.junit.runtime are now jarred. org.junit and org.junit4 are still unjarred for the following reasons: - classpath variable for junit 3 (see comment 1) - first have to consult legal - wait for the Orbit project to take the initiative
not for 3.4
We can look at this again when JUnit 4 is moved to Orbit (bug 186369).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
JUnit 5 is now JARed.
