JFlex

Hi Steve,

> I've been trying to track down why the testsuite "java" test case fails 
> for me under the java5 branch.
> 
> I have not been able to get the testsuite working under the 1.4.3 tag, 
> so instead I manually generated, compiled, and ran the scanner against 
> the input files in the "java" test case using the JFlex 1.4.3 jar, and I 
> found that for one of the three input files (java-1.input), 1.4.3 also 
> does not produce the expected result (java-1.output). 

That is strange. The test case works for me for 1.4.3 (on MacOS and Linux). 
Can you send the difference? It could be that there is something platform 
dependent going on.


> In fact, the 
> scanners generated by 1.4.3 and 1.5.0-SNAPSHOT produce exactly the same 
> output for java-1.input; and the source for the scanner generated by 
> both versions is the same, with the exception that switch case 
> statements are not in the same order (I sorted the case statements for 
> both and compared the results - they are identical).

yes, the order of the switch statements is platform and Java-version 
dependent. That is no problem, I've seen this before in other test cases as 
well. As long as their contents are all the same, the generated code should be 
robust against the reordering.

Cheers,
Gerwin

Hi Gerwin,

Gerwin Klein wrote:
> Hi Steve,
> 
>> I've been trying to track down why the testsuite "java" test case fails 
>> for me under the java5 branch.
>>
>> I have not been able to get the testsuite working under the 1.4.3 tag, 
>> so instead I manually generated, compiled, and ran the scanner against 
>> the input files in the "java" test case using the JFlex 1.4.3 jar, and I 
>> found that for one of the three input files (java-1.input), 1.4.3 also 
>> does not produce the expected result (java-1.output). 
> 
> That is strange. The test case works for me for 1.4.3 (on MacOS and Linux). 
> Can you send the difference? It could be that there is something platform 
> dependent going on.

I've attached the (gzip'd) output using the "java" scanner running under 
Windows Vista 64-bit, with java-1.input as the input.

The scanner that produced the attached file was generated using Sun's 
1.4.2_17 JVM.  I compiled and ran the scanner under the same version's 
compiler & JVM.

I tested all permutations of the variables below (under Windows Vista 
64-bit), and all produced the same output:

  - Bash shell under Cygwin vs. Windows cmd.exe
  - Sun 1.4.2_17 (32-bit) JDK vs. Sun's 1.5.0_15 (64-bit) JDK
  - JFlex 1.4.3 vs. JFlex 1.5.0-SNAPSHOT

BTW, to perform the diff, I used both the --strip-trailing-cr and --text 
options to diff, since the output under Windows contains carriage 
returns, and the output from java-1.input makes "diff" think that it's 
binary.

Steve

Hi Gerwin,

Have you had a chance to look at the output I sent?

I also tested on Linux (Sun JDK 1.5.0_15), and got the same failure 
result for the java testcase's java-1.input, using both JFlex 1.4.3 and 
1.5.0-SNAPSHOT.

Here's what I have done to manually run the test:

PROMPT$ java -cp ~/.m2/repository/de/jflex/jflex/1.4.3/jflex-1.4.3.jar 
java.jflex
PROMPT$ javac Java.java
PROMPT$ java -cp . Java java-1.input > new-java-1.output
PROMPT$ diff java-1.output new-java-1.output

Is that the correct process?

If so, I'm confused about what's happening - seems like you should be 
getting the same results as me.

Steve

Steve Rowe wrote:
> Hi Gerwin,
> 
> Gerwin Klein wrote:
>> Hi Steve,
>>
>>> I've been trying to track down why the testsuite "java" test case 
>>> fails for me under the java5 branch.
>>>
>>> I have not been able to get the testsuite working under the 1.4.3 
>>> tag, so instead I manually generated, compiled, and ran the scanner 
>>> against the input files in the "java" test case using the JFlex 1.4.3 
>>> jar, and I found that for one of the three input files 
>>> (java-1.input), 1.4.3 also does not produce the expected result 
>>> (java-1.output). 
>>
>> That is strange. The test case works for me for 1.4.3 (on MacOS and 
>> Linux). Can you send the difference? It could be that there is 
>> something platform dependent going on.
> 
> I've attached the (gzip'd) output using the "java" scanner running under 
> Windows Vista 64-bit, with java-1.input as the input.
> 
> The scanner that produced the attached file was generated using Sun's 
> 1.4.2_17 JVM.  I compiled and ran the scanner under the same version's 
> compiler & JVM.
> 
> I tested all permutations of the variables below (under Windows Vista 
> 64-bit), and all produced the same output:
> 
>  - Bash shell under Cygwin vs. Windows cmd.exe
>  - Sun 1.4.2_17 (32-bit) JDK vs. Sun's 1.5.0_15 (64-bit) JDK
>  - JFlex 1.4.3 vs. JFlex 1.5.0-SNAPSHOT
> 
> BTW, to perform the diff, I used both the --strip-trailing-cr and --text 
> options to diff, since the output under Windows contains carriage 
> returns, and the output from java-1.input makes "diff" think that it's 
> binary.
> 
> Steve

Steve Rowe wrote:
> Here's what I have done to manually run the test:
> 
> PROMPT$ java -cp ~/.m2/repository/de/jflex/jflex/1.4.3/jflex-1.4.3.jar java.jflex

That's not quite right, of course - I actually invoked JFlex:

PROMPT$ java -cp ~/.m2/repository/de/jflex/jflex/1.4.3/jflex-1.4.3.jar 
JFlex.Main java.jflex

Steve

Hi Steve,

 > Have you had a chance to look at the output I sent?

sorry, totally swamped at the moment, haven't had a chance yet.


> I also tested on Linux (Sun JDK 1.5.0_15), and got the same failure 
> result for the java testcase's java-1.input, using both JFlex 1.4.3 and 
> 1.5.0-SNAPSHOT.
> 
> Here's what I have done to manually run the test:
> 
> PROMPT$ java -cp ~/.m2/repository/de/jflex/jflex/1.4.3/jflex-1.4.3.jar 
> java.jflex
> PROMPT$ javac Java.java
> PROMPT$ java -cp . Java java-1.input > new-java-1.output
> PROMPT$ diff java-1.output new-java-1.output
> 
> Is that the correct process?

yes, that is correct.


> If so, I'm confused about what's happening - seems like you should be 
> getting the same results as me.

and I am getting a failure now, too! I'm not sure what's going on, I could 
swear all tests ran cleanly before I released. It's also breaking in the same 
way on version 1.4.2 already and I've run the tests tens or hundreds of times
during development, not seeing that error.

I'll have to look into it in more detail, but it doesn't seem to be a fault of 
the java-5 branch at all.

Cheers,
Gerwin

Got it. Fairly embarrassing: my working copy for the test case in Eclipse was 
not clean (this is the one that passed, I ran the test from the previous email 
on a different working copy). I had fixed the test a long time ago already 
(before 1.4.3), but never committed and with (hopefully) temporary blindness 
didn't see the obvious staring me in the face.

I have committed the necessary changes to trunk now.

Sorry for this, guys.

Gerwin

Hi Gerwin,

I think some of the differences I'm seeing in the test suite Java 
testcase have to do with the default file encoding.

Here's the output from "java -cp jflex-1.4.3.jar JFlex.Main --info" for me:

Java version:  1.4.2_17
Runtime name:  Java(TM) 2 Runtime Environment, Standard Edition
Vendor:        Sun Microsystems Inc.
VM version:    1.4.2_17-b06
VM vendor:     Sun Microsystems Inc.
VM name:       Java HotSpot(TM) Client VM
VM info:       mixed mode
OS name:       Windows Vista
OS arch:       x86
OS version:    6.0
Encoding:      Cp1252
JFlex version: 1.4.3

What's the default file encoding for you?  I can attempt to use that via 
-Dfile.encoding when I run the Java test case to see if that reduces the 
differences (I suspect it will).

Thanks,
Steve

Steve Rowe wrote:
> Hi Gerwin,
> 
> Have you had a chance to look at the output I sent?
> 
> I also tested on Linux (Sun JDK 1.5.0_15), and got the same failure 
> result for the java testcase's java-1.input, using both JFlex 1.4.3 and 
> 1.5.0-SNAPSHOT.
> 
> Here's what I have done to manually run the test:
> 
> PROMPT$ java -cp ~/.m2/repository/de/jflex/jflex/1.4.3/jflex-1.4.3.jar 
> java.jflex
> PROMPT$ javac Java.java
> PROMPT$ java -cp . Java java-1.input > new-java-1.output
> PROMPT$ diff java-1.output new-java-1.output
> 
> Is that the correct process?
> 
> If so, I'm confused about what's happening - seems like you should be 
> getting the same results as me.
> 
> Steve
> 
> Steve Rowe wrote:
>> Hi Gerwin,
>>
>> Gerwin Klein wrote:
>>> Hi Steve,
>>>
>>>> I've been trying to track down why the testsuite "java" test case 
>>>> fails for me under the java5 branch.
>>>>
>>>> I have not been able to get the testsuite working under the 1.4.3 
>>>> tag, so instead I manually generated, compiled, and ran the scanner 
>>>> against the input files in the "java" test case using the JFlex 1.4.3 
>>>> jar, and I found that for one of the three input files 
>>>> (java-1.input), 1.4.3 also does not produce the expected result 
>>>> (java-1.output). 
>>> That is strange. The test case works for me for 1.4.3 (on MacOS and 
>>> Linux). Can you send the difference? It could be that there is 
>>> something platform dependent going on.
>> I've attached the (gzip'd) output using the "java" scanner running under 
>> Windows Vista 64-bit, with java-1.input as the input.
>>
>> The scanner that produced the attached file was generated using Sun's 
>> 1.4.2_17 JVM.  I compiled and ran the scanner under the same version's 
>> compiler & JVM.
>>
>> I tested all permutations of the variables below (under Windows Vista 
>> 64-bit), and all produced the same output:
>>
>>  - Bash shell under Cygwin vs. Windows cmd.exe
>>  - Sun 1.4.2_17 (32-bit) JDK vs. Sun's 1.5.0_15 (64-bit) JDK
>>  - JFlex 1.4.3 vs. JFlex 1.5.0-SNAPSHOT
>>
>> BTW, to perform the diff, I used both the --strip-trailing-cr and --text 
>> options to diff, since the output under Windows contains carriage 
>> returns, and the output from java-1.input makes "diff" think that it's 
>> binary.
>>
>> Steve
> 
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Jflex-devel mailing list
> Jflex-devel@...
> https://lists.sourceforge.net/lists/listinfo/jflex-devel
> 
>

Hi Steve,

good question. My default encoding used to be iso-latin-1 (= iso-8859-1). It is 
possible that it has switched to MacRoman with my last checkins.

So you are still seeing differences in the trunk version that I (thought I) 
fixed with my last checkin?

In a new version of this test suite, we should take care to make it more 
platform independent. That includes annotating which character encoding inputs 
are. The current version was never meant to be released, it was just my personal 
set of test runs. Sorry for all the problems this is causing.

Cheers,
Gerwin


Steve Rowe wrote:
> Hi Gerwin,
> 
> I think some of the differences I'm seeing in the test suite Java 
> testcase have to do with the default file encoding.
> 
> Here's the output from "java -cp jflex-1.4.3.jar JFlex.Main --info" for me:
> 
> Java version:  1.4.2_17
> Runtime name:  Java(TM) 2 Runtime Environment, Standard Edition
> Vendor:        Sun Microsystems Inc.
> VM version:    1.4.2_17-b06
> VM vendor:     Sun Microsystems Inc.
> VM name:       Java HotSpot(TM) Client VM
> VM info:       mixed mode
> OS name:       Windows Vista
> OS arch:       x86
> OS version:    6.0
> Encoding:      Cp1252
> JFlex version: 1.4.3
> 
> What's the default file encoding for you?  I can attempt to use that via 
> -Dfile.encoding when I run the Java test case to see if that reduces the 
> differences (I suspect it will).
> 
> Thanks,
> Steve
> 
> Steve Rowe wrote:
>> Hi Gerwin,
>>
>> Have you had a chance to look at the output I sent?
>>
>> I also tested on Linux (Sun JDK 1.5.0_15), and got the same failure 
>> result for the java testcase's java-1.input, using both JFlex 1.4.3 and 
>> 1.5.0-SNAPSHOT.
>>
>> Here's what I have done to manually run the test:
>>
>> PROMPT$ java -cp ~/.m2/repository/de/jflex/jflex/1.4.3/jflex-1.4.3.jar 
>> java.jflex
>> PROMPT$ javac Java.java
>> PROMPT$ java -cp . Java java-1.input > new-java-1.output
>> PROMPT$ diff java-1.output new-java-1.output
>>
>> Is that the correct process?
>>
>> If so, I'm confused about what's happening - seems like you should be 
>> getting the same results as me.
>>
>> Steve
>>
>> Steve Rowe wrote:
>>> Hi Gerwin,
>>>
>>> Gerwin Klein wrote:
>>>> Hi Steve,
>>>>
>>>>> I've been trying to track down why the testsuite "java" test case 
>>>>> fails for me under the java5 branch.
>>>>>
>>>>> I have not been able to get the testsuite working under the 1.4.3 
>>>>> tag, so instead I manually generated, compiled, and ran the scanner 
>>>>> against the input files in the "java" test case using the JFlex 1.4.3 
>>>>> jar, and I found that for one of the three input files 
>>>>> (java-1.input), 1.4.3 also does not produce the expected result 
>>>>> (java-1.output). 
>>>> That is strange. The test case works for me for 1.4.3 (on MacOS and 
>>>> Linux). Can you send the difference? It could be that there is 
>>>> something platform dependent going on.
>>> I've attached the (gzip'd) output using the "java" scanner running under 
>>> Windows Vista 64-bit, with java-1.input as the input.
>>>
>>> The scanner that produced the attached file was generated using Sun's 
>>> 1.4.2_17 JVM.  I compiled and ran the scanner under the same version's 
>>> compiler & JVM.
>>>
>>> I tested all permutations of the variables below (under Windows Vista 
>>> 64-bit), and all produced the same output:
>>>
>>>  - Bash shell under Cygwin vs. Windows cmd.exe
>>>  - Sun 1.4.2_17 (32-bit) JDK vs. Sun's 1.5.0_15 (64-bit) JDK
>>>  - JFlex 1.4.3 vs. JFlex 1.5.0-SNAPSHOT
>>>
>>> BTW, to perform the diff, I used both the --strip-trailing-cr and --text 
>>> options to diff, since the output under Windows contains carriage 
>>> returns, and the output from java-1.input makes "diff" think that it's 
>>> binary.
>>>
>>> Steve
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a $600 discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Jflex-devel mailing list
>> Jflex-devel@...
>> https://lists.sourceforge.net/lists/listinfo/jflex-devel
>>
>>
> 
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Jflex-devel mailing list
> Jflex-devel@...
> https://lists.sourceforge.net/lists/listinfo/jflex-devel

Gerwin Klein wrote:
> So you are still seeing differences in the trunk version that I (thought I) 
> fixed with my last checkin?

Weird - I didn't realize that you'd made any checkins to the testsuite, 
but just now after updating, and checking the svn log, I can see:

   ---------------------------------------------------------------------
   r450 | lsf37 | 2009-02-16 06:50:22 -0500 (Mon, 16 Feb 2009) | 3 lines

   port fix for most-negative int literal from 1.4.3 examples
   adjust test output

For some reason, I never received the commit notification for this 
revision (450), but I got the emails for both the one before and the one 
after (449 and 451).  If you separately emailed to the dev list about 
this commit, I never saw that either.

 > My default encoding used to be iso-latin-1 (= iso-8859-1). It is
 > possible that it has switched to MacRoman with my last checkins.

Now that I have your trunk fix, and if I add -Dfile.encoding=MacRoman to 
the command line when I run the generated Java scanner over 
java-1.input, I no longer see any differences with the expected 
java-1.output.  Whew!

> In a new version of this test suite, we should take care to make it more 
> platform independent. That includes annotating which character encoding inputs 
> are. The current version was never meant to be released, it was just my personal 
> set of test runs. Sorry for all the problems this is causing.

No problem :).  Good idea about the char encoding annotation.

Steve

> Steve Rowe wrote:
>> Hi Gerwin,
>>
>> I think some of the differences I'm seeing in the test suite Java 
>> testcase have to do with the default file encoding.
>>
>> Here's the output from "java -cp jflex-1.4.3.jar JFlex.Main --info" for me:
>>
>> Java version:  1.4.2_17
>> Runtime name:  Java(TM) 2 Runtime Environment, Standard Edition
>> Vendor:        Sun Microsystems Inc.
>> VM version:    1.4.2_17-b06
>> VM vendor:     Sun Microsystems Inc.
>> VM name:       Java HotSpot(TM) Client VM
>> VM info:       mixed mode
>> OS name:       Windows Vista
>> OS arch:       x86
>> OS version:    6.0
>> Encoding:      Cp1252
>> JFlex version: 1.4.3
>>
>> What's the default file encoding for you?  I can attempt to use that via 
>> -Dfile.encoding when I run the Java test case to see if that reduces the 
>> differences (I suspect it will).
>>
>> Thanks,
>> Steve
>>
>> Steve Rowe wrote:
>>> Hi Gerwin,
>>>
>>> Have you had a chance to look at the output I sent?
>>>
>>> I also tested on Linux (Sun JDK 1.5.0_15), and got the same failure 
>>> result for the java testcase's java-1.input, using both JFlex 1.4.3 and 
>>> 1.5.0-SNAPSHOT.
>>>
>>> Here's what I have done to manually run the test:
>>>
>>> PROMPT$ java -cp ~/.m2/repository/de/jflex/jflex/1.4.3/jflex-1.4.3.jar 
>>> java.jflex
>>> PROMPT$ javac Java.java
>>> PROMPT$ java -cp . Java java-1.input > new-java-1.output
>>> PROMPT$ diff java-1.output new-java-1.output
>>>
>>> Is that the correct process?
>>>
>>> If so, I'm confused about what's happening - seems like you should be 
>>> getting the same results as me.
>>>
>>> Steve
>>>
>>> Steve Rowe wrote:
>>>> Hi Gerwin,
>>>>
>>>> Gerwin Klein wrote:
>>>>> Hi Steve,
>>>>>
>>>>>> I've been trying to track down why the testsuite "java" test case 
>>>>>> fails for me under the java5 branch.
>>>>>>
>>>>>> I have not been able to get the testsuite working under the 1.4.3 
>>>>>> tag, so instead I manually generated, compiled, and ran the scanner 
>>>>>> against the input files in the "java" test case using the JFlex 1.4.3 
>>>>>> jar, and I found that for one of the three input files 
>>>>>> (java-1.input), 1.4.3 also does not produce the expected result 
>>>>>> (java-1.output). 
>>>>> That is strange. The test case works for me for 1.4.3 (on MacOS and 
>>>>> Linux). Can you send the difference? It could be that there is 
>>>>> something platform dependent going on.
>>>> I've attached the (gzip'd) output using the "java" scanner running under 
>>>> Windows Vista 64-bit, with java-1.input as the input.
>>>>
>>>> The scanner that produced the attached file was generated using Sun's 
>>>> 1.4.2_17 JVM.  I compiled and ran the scanner under the same version's 
>>>> compiler & JVM.
>>>>
>>>> I tested all permutations of the variables below (under Windows Vista 
>>>> 64-bit), and all produced the same output:
>>>>
>>>>  - Bash shell under Cygwin vs. Windows cmd.exe
>>>>  - Sun 1.4.2_17 (32-bit) JDK vs. Sun's 1.5.0_15 (64-bit) JDK
>>>>  - JFlex 1.4.3 vs. JFlex 1.5.0-SNAPSHOT
>>>>
>>>> BTW, to perform the diff, I used both the --strip-trailing-cr and --text 
>>>> options to diff, since the output under Windows contains carriage 
>>>> returns, and the output from java-1.input makes "diff" think that it's 
>>>> binary.
>>>>
>>>> Steve
>>> ------------------------------------------------------------------------------
>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>> -Strategies to boost innovation and cut costs with open source participation
>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>> http://p.sf.net/sfu/XcvMzF8H
>>> _______________________________________________
>>> Jflex-devel mailing list
>>> Jflex-devel@...
>>> https://lists.sourceforge.net/lists/listinfo/jflex-devel
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a $600 discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Jflex-devel mailing list
>> Jflex-devel@...
>> https://lists.sourceforge.net/lists/listinfo/jflex-devel
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Jflex-devel mailing list
> Jflex-devel@...
> https://lists.sourceforge.net/lists/listinfo/jflex-devel
> 
>

Hi Steve,

Steve Rowe wrote:
> Weird - I didn't realize that you'd made any checkins to the testsuite, 
> but just now after updating, and checking the svn log, I can see:
> 
>    ---------------------------------------------------------------------
>    r450 | lsf37 | 2009-02-16 06:50:22 -0500 (Mon, 16 Feb 2009) | 3 lines
> 
>    port fix for most-negative int literal from 1.4.3 examples
>    adjust test output

Yes, that's the one.


> For some reason, I never received the commit notification for this 
> revision (450), but I got the emails for both the one before and the one 
> after (449 and 451).  If you separately emailed to the dev list about 
> this commit, I never saw that either.

I did (see attached). I had some weirdness with the mailing list around that 
point as well. Some of the messages were tagged as spam, even commit messages.

Seems to be ok now again.


>  > My default encoding used to be iso-latin-1 (= iso-8859-1). It is
>  > possible that it has switched to MacRoman with my last checkins.
> 
> Now that I have your trunk fix, and if I add -Dfile.encoding=MacRoman to 
> the command line when I run the generated Java scanner over 
> java-1.input, I no longer see any differences with the expected 
> java-1.output.  Whew!

Very good, glad that is cleared up now.

Cheers,
Gerwin

Steve Rowe wrote:
> Gerwin Klein wrote:
>> Régis Décamps wrote:
>>> I think it is more consistent to stay Java 1.4 in JFlex 1.4.x indeed
>> Fine from my side.
> 
> BTW, maven-jflex-plugin on trunk will not build with Java 1.4 SDK - both 
> the source and the target versions are configured as 1.5 in the POM. 
> When I switch them to 1.4, it builds properly.

True, it's set to 1.5 in both. Is 1.4 critical for anyone or should we just 
leave it on 1.5?


>>> In trunk I've upgraded maven-jflex-plugin-0.3 to JFlex 1.4.2
>>> I have also commited modifications due to sourceforge changes (scp 
>>> access, logo, etc)
>>> I think maven-jflex-plugin can be released as 1.4.2
>>>
>>> Gerwin, here are te steps to release:
>>> 1. Remove SNAPSHOT in POM version
>>> 2. Execute
>>>
>>> mvn -Prelease install deploy site
>>>
>>> 3. and tag in subversion
>> I've done this now for 1.4.2 and 1.4.3.
> 
> Perhaps I've misunderstood, but shouldn't one of the results of the 
> release be that the Maven repository is populated?  I don't see 1.4.3 
> versions of either the maven-jflex-plugin or JFlex itself under 
> <http://jflex.sourceforge.net/repo>.

Hm, you're right. The repository is supposed to be jflex.sf.net/m2repo/, but 
only the maven-jflex-plugin files show up under version 1.4.3.

Not sure what's gone wrong. I'll try again. Regis, do you have any tips on this?


>> I've also just released the current trunk state as JFlex 1.4.3.
>>
>> Could you check if everything works for you as it should?
> 
> I can build, and the unit tests pass, but my attempts to get the 
> Make-based testsuite running didn't work out.

These probably only work for me out of the box. They require some additional 
setup.


> I changed the maven-jflex-plugin dependency for the jflex module on the 
> java5 branch to 1.4.3, and after I manually installed JFlex 1.4.3 into 
> my local Maven repository, and installed the 1.4.3 maven-jflex-plugin, 
> the java5 branch jflex builds with no bootstrapping tricks required -- 
> as I had hoped, JFlex and maven-jflex-plugin v1.4.3 have fixed the java5 
> branch build problem.

Ok, good that this works. If we get the plugin sorted out during the week we 
can finally switch java-5 to the trunk and the current trunk into a branch.

I'd do the license change after we switched, so we don't get too many large 
text conflicts with merging in the few changes I made just before the release.

Steven, can you take a look at merging these changes into java-5 or do you 
want me to do the merge? Up to which revision did your last merge go?

Cheers,
Gerwin

Gerwin Klein wrote:
> [....] If we get the plugin sorted out during the week we 
> can finally switch java-5 to the trunk and the current trunk into a branch.
> 
> I'd do the license change after we switched, so we don't get too many large 
> text conflicts with merging in the few changes I made just before the release.
> 
> Steven, can you take a look at merging these changes into java-5 or do you 
> want me to do the merge? Up to which revision did your last merge go?

Yes, I will merge the latest trunk changes into the java5 branch.  (My 
last trunk->java5 branch merge from revision 413.)

Steve

>> Steven, can you take a look at merging these changes into java-5 or do you 
>> want me to do the merge? Up to which revision did your last merge go?
> 
> Yes, I will merge the latest trunk changes into the java5 branch.  (My 
> last trunk->java5 branch merge from revision 413.)

Ok.

I think I've tracked down what I did wrong with the maven plugin (working on it).

Cheers,
Gerwin

Steve Rowe wrote:
> I don't see 1.4.3 
> versions of either the maven-jflex-plugin or JFlex itself under 
> <http://jflex.sourceforge.net/repo>.

They should now all appear under [http://jflex.sourceforge.net/m2repo]

Cheers,
Gerwin

Gerwin Klein wrote:
> Steve Rowe wrote:
>> I don't see 1.4.3 
>> versions of either the maven-jflex-plugin or JFlex itself under 
>> <http://jflex.sourceforge.net/repo>.
> 
> They should now all appear under [http://jflex.sourceforge.net/m2repo]

Cool, I can see them there.

However, only maven-jflex-plugin has shown up under 
<http://repo1.maven.org/maven2/de/jflex/> - JFlex 1.4.3 is not there. 
Maybe the synchonization only happens once a day, and you hadn't 
completed the upload of JFlex 1.4.3 to jflex.sf.net/m2repo at that point?

Régis, do you know what's happening here?

Steve

On Sun, Feb 1, 2009 at 19:29, Steve Rowe <sarowe@...> wrote:

> Gerwin Klein wrote:
> > Steve Rowe wrote:
> >> I don't see 1.4.3 versions of either the maven-jflex-plugin or JFlex
> itself under
> >> <http://jflex.sourceforge.net/repo>.
> >
> > They should now all appear under [http://jflex.sourceforge.net/m2repo]
>

Yes indeed. The "repo" repository was inaccessible when I was setting up the
synchronization (due to changes in sf.net http configuration) Also I changed
the group of the plugin from de.jflex.maven.plugin to de.jflex as suggested
by a maven team member. That's why I've rebuild a clean new repo under
"m2repo" (more details in an older thread in this list).

Now the old repo could easily be used for snapshots.



> Cool, I can see them there.
>
> However, only maven-jflex-plugin has shown up under
> <http://repo1.maven.org/maven2/de/jflex/> - JFlex 1.4.3 is not there.
> Maybe the synchonization only happens once a day, and you hadn't
> completed the upload of JFlex 1.4.3 to jflex.sf.net/m2repo at that point?


Because JFlex is not mavenized in the 1.4.x branch, its deployment process
is more complicated. I tried to document it
<https://jflex.svn.sourceforge.net/svnroot/jflex/trunk/HOWTO_release.txt>and
it actually seems you managed to deploy it as well. Now, from the
timestamps, it appears the core was uploaded on m2repo after the
synchronization, which happens (iirc) once a day indeed.


> Régis, do you know what's happening here?
>
> I think you made the correct assumptions.

-- 
Régis Décamps

http://regis.decamps.info/
Samuel Goldwyn  - "I had a monumental idea this morning, but I didn't like
it."

> Yes indeed. The "repo" repository was inaccessible when I was setting up 
> the synchronization (due to changes in sf.net <http://sf.net> http 
> configuration) Also I changed the group of the plugin from 
> de.jflex.maven.plugin to de.jflex as suggested by a maven team member. 
> That's why I've rebuild a clean new repo under "m2repo" (more details in 
> an older thread in this list).
>
> Now the old repo could easily be used for snapshots.

We can do that or we could remove it to avoid confusion in the future. I'm fine 
either way.


> Because JFlex is not mavenized in the 1.4.x branch, its deployment 
> process is more complicated. I tried to document it 
> <https://jflex.svn.sourceforge.net/svnroot/jflex/trunk/HOWTO_release.txt>and 
> it actually seems you managed to deploy it as well.

Yes, took me some time to find the document again, but after I did everything 
worked as described. Thanks for putting that together!


> Now, from the 
> timestamps, it appears the core was uploaded on m2repo after the 
> synchronization, which happens (iirc) once a day indeed.

Ok, everything should be fine then.

Cheers,
Gerwin

Steve Rowe wrote:
> Gerwin Klein wrote:
>> [....] If we get the plugin sorted out during the week we 
>> can finally switch java-5 to the trunk and the current trunk into a branch.
>>
>> I'd do the license change after we switched, so we don't get too many large 
>> text conflicts with merging in the few changes I made just before the release.
>>
>> Steven, can you take a look at merging these changes into java-5 or do you 
>> want me to do the merge? Up to which revision did your last merge go?
> 
> Yes, I will merge the latest trunk changes into the java5 branch.  (My 
> last trunk->java5 branch merge from revision 413.)

This is now done.

Steve

On Mon, Feb 2, 2009 at 00:43, Steve Rowe <sarowe@...> wrote:
> Steve Rowe wrote:
>> Gerwin Klein wrote:
>>> [....] If we get the plugin sorted out during the week we
>>> can finally switch java-5 to the trunk and the current trunk into a branch.
>>>
>>> I'd do the license change after we switched, so we don't get too many large
>>> text conflicts with merging in the few changes I made just before the release.
>>>
>>> Steven, can you take a look at merging these changes into java-5 or do you
>>> want me to do the merge? Up to which revision did your last merge go?
>>
>> Yes, I will merge the latest trunk changes into the java5 branch.  (My
>> last trunk->java5 branch merge from revision 413.)
>
> This is now done.
>

Great ! Excellent job!

-- 
Régis Décamps

http://regis.decamps.info/
George Carlin  - "May the forces of evil become confused on the way to
your house."

On Sun, Feb 1, 2009 at 06:19, Steve Rowe <sarowe@...> wrote:
> Gerwin Klein wrote:
>
> BTW, maven-jflex-plugin on trunk will not build with Java 1.4 SDK - both
> the source and the target versions are configured as 1.5 in the POM.
> When I switch them to 1.4, it builds properly.
>

This was wrong indeed. I backported the code to Java 1.4 and forget to
set the correct level in the POM. Arg! I think I'm going to tag and
deploy in central a 1.4.2-r1 and a 1.4.3-r1 release where the POM is
correct.

-- 
Régis Décamps

http://regis.decamps.info/
Fred Allen  - "California is a fine place to live - if you happen to
be an orange."