Add JUnit4 support

[GoogleCodeExporter]

The code has already been added (there's a new junit4.TearDownTestCase
class that mirrors junit3.TearDownTestCase).

What's left is to change the pom. Here's what I want: it needs to generate
5 jars:

a. tl4j-junit3-only.jar: just the "junit3" package
b. tl4j-junit4-only.jar: just the "junit4" package
c. tl4j-junit3-common.jar: all package except junit3 and junit4
d. tl4j-junit3.jar: contains a+c
e. tl4j-junit4.jar: contains b+c

The last two packages is what I will feature, as most people will simply
choose junit3 or junit4. For reasons I won't go into, I also need the other
packages above generated somehow...

Original issue reported on code.google.com by zorze...@gmail.com on 17 Jun 2009 at 4:52

[GoogleCodeExporter]

I think that I got a solution. I'm attaching a sample pom.xml which is doing 
this by 
specifying the name of the profile. Here are some examples that may help you 
how to 
use them:
mvn clean package -P junit3-only

Would generate the output file: target\tl4j-junit3-only.jar

and etc. The available profiles currently are: junit3-only, junit4-only, junit3-
common,junit3,junit4

Hope this will help. If you have some thoughts or comments about the solution, 
please 
let me know about them. 

Original comment by MGe...@gmail.com on 17 Jun 2009 at 6:40

Attachments:

• pom.xml

[GoogleCodeExporter]

Here is an updated version of the pom which has few lines less then the 
previous pom. 

I know that the switching between profiles is not so good, but as I know in 
maven 2 
it's the only solution. Here is a quote from the plugin documentation: 

-- Quote Starts Here --
If you are looking to produce JARs that are different (ie, they have their own 
dependencies and metadata), Maven doesn't support this. This usually is only 
needed 
when sharing a source directory for intrinsically different things, so the use 
case 
above applies instead.
If you are producing a JAR that is a derivative of the original (eg, just a 
subset of 
classes, or the same JAR with debugging enabled), the Maven supports this 
completely 
using profiles. See Introduction to Profiles for more information.

-- Quote Ends Here --

Original comment by MGe...@gmail.com on 17 Jun 2009 at 7:04

Attachments:

• pom.xml

[GoogleCodeExporter]

I've got questions:

1. The way I understand is that now I would do something like:

$ mvn install -P junit3,junit4,junit3-only,junit4-only,junit3-common

But I get only 2 jars generated:

./target/tl4j.jar
./target/tl4j-junit4.jar

It seems the names in the pom are declared to overwrite each other, but I can't 
quite
figure out the best change, and why "junit4" has its own different name.

2. "mvn install" (no "-P") now does its own thing that has no use. Is it 
possible to
have "mvn install" trigger the command at "1"? Or, at least, simply print out a
message instructing "run it with -P ..."

3. It seems the generated jars have no version number. 

4. Not really related to this, but what's the canonical set of commands I would 
run
for a complete release build? I need to create a HOW_TO_RELEASE document, and 
at this
point I already forgot. The steps are: create svn branch, change version in 
pom.xml,
clean, compile/run tests, package sources, package zip, deploy to maven repo,
manually deploy to googlecode.

BTW, I just realized I forgot to delete build.xml and build.properties. I'll do 
that
soon.

Original comment by zorze...@gmail.com on 17 Jun 2009 at 7:39

[GoogleCodeExporter]

About 1) 
  For badness I think that maven allows only one profile to be executed at time. For 
example mvn install -P junit3
"It seems the names in the pom are declared to overwrite each other, but I 
can't 
quite figure out the best change, and why "junit4" has its own different name." 

I can't figure out what you mean. Please elaborate. 

About 2)
 We could set some of the profiles as a default profile which will be used by default 
without the "-P" switch. 

About 3)
 I'm on a way of doing this. Please wait for the next version of the pom file. It's 
on my todo list right now.

About 4)
 To make this as simple as possible, we have to configure the release plugin of maven 
( http://maven.apache.org/plugins/maven-release-plugin/ ). As I remember with 
this 
plugin you have to execute one or maybe two goals ( one to test whether the new 
release could be created and one to create it ). The plugin is responsible for 
the 
creation of a new branch, copying the trunk into that branch, modifies the pom 
version number and commits the changes into the trunk and etc.

If you would like this future, I could add this plugin to the pom.xml and to 
create 
some kind of HOW_TO_RELEASE.txt which describes with few words the basic usage 
of the  
release plugin and the other stuff if it's necessary. 

Original comment by MGe...@gmail.com on 19 Jun 2009 at 7:05

[GoogleCodeExporter]

1) Hmm, this page seems to imply I can issue comma-separated profiles:

http://maven.apache.org/guides/introduction/introduction-to-profiles.html

But, as you say, this does not seem to be working (that was my confusion -- I 
thought
profiles were overwriting each other's jars). That kind of sucks, but it's not 
the
end of the world.

4) If you want to do the release plugin thing, I'd be grateful. Otherwise, a
HOW_TO_RELEASE.txt is a great start...

Thanks,

Z

Original comment by zorze...@gmail.com on 19 Jun 2009 at 8:12

[GoogleCodeExporter]

I've commited a new pom (modified from Miroslav's latest) together with a set of
instructions on how to release (run doc/howtorelease.sh). The most notable 
change is
that junit-common is really not junit-specific, so I renamed the pom profile to
"agnostic".

A few issues/quirks remain, and I'll just list them here from most to least 
annoying:

* releasing is a multi-step pain in the neck. Anything that can be done to
automate/simplify is welcome

* the HOW_TO_RELEASE.txt doc still lacks the "mvn deploy" instructions

* there's a single source jar that gets generated, which has jars for all bin 
jars.

* the same tests get run multiple times while "install"ing

* "mvn install" should simply print out a message telling the person to run
doc/howtorelease, rather than do whatever it is doing right now

I'm going to be testing the instructions right now.

Original comment by zorze...@gmail.com on 30 Jun 2009 at 8:04