granite gas3 build, classpath question

[Kris Hofmans]

Hello,

We've been using the gas3 for a while, it has always printed some exceptions, but we have reached a point where it stopped generating certain entities.

Sometimes we had "stupid" workarounds like commenting out certain annotations like @EntityListeners and then the generation would succeed.

I believe that the exceptions might be caused by the fact that the classpath is not added correctly to the gds plugin. For example

our java build path looks like this:

Yet the gds plugin only contains the references to those projects and the jdk but not the jar files that we've added.

Is there a way to get gas3 use the complete classpath as defined for the java buildpath?

Didn't want to log this in jira immediately since it could be intended to work like this?

Thanks,

Kind regards,

Kris

[wdrai]

That may be a bug, it should follow the classpath definition of the referenced projects.

[Gerrie Kimpen]

The problem is that Variable Classpath Entries (=those entries who extend a path variable) are not added to the generator's classpath. The attached files contain a quick fix for this problem (based on the 2.3.0.GA release). If you want the org.granite.builder_2.3.0.GA-ClasspathFix.jar just mail me.

@ the autors:

[1]

This is a quick fix since it only fixes the generator's classpath. It does not fix the content of the ClasspathsPanel. This means that the effective classpath - the one that is used by the generator - is not reflected the UI (Project properties > GraniteDS > Libraries).

The code that extracts the classpath from the Eclipse project is quite verbose and might not be very future proof. The reason for this is that you seem to go the extra mile to present the classpath in ClasspathsPanel an Eclipse-like manner: making a visual distinction between the various IClasspathEntry kinds. You could make your code far more robust if you just presented the classpath as a flat list here.

[2]

The ProjectsPanel (Project properties > GraniteDS > Projects) should not be needed in most cases since you can detect the referenced projects based on the settings in Java Build Path > Projects. You've already implemented ProjectUtil.isGraniteProject(dependentProject) so you can easily filter out the non-relevant dependent projects.

[3]

Wouldn't it make sense that the generator picks his .class files based on the rules configged for the externalizers in granite-config.xml? "What you externalize is what you generate", or something like that :)

Now you need to specifiy inclusion/exclusion filters in Project properties > GraniteDS > Java Sources, which can be very tedious and difficult to maintain.

grtz

Gerrie

[gerrie]

I just found out (I think :) that you do not need to explicitly define
an externalizer for each Java class that will be sent to the client. I
assume the DefaultExternalizer is used as fallback. If this is true,
then the generator cannot know about *all* classes that will be
externalized. So point [3] makes much less sense.

[Franck Wolff]

Patch applied.

Could you confirm it is working: http://www.graniteds.org/bamboo/browse/GDSEB-GDSEB-206/artifact?

Thanks.

[Gerrie Kimpen]

It works, thank you!

Keep in mind however that my patch was a quick fix and that the effective classpath is not relflected in the UI any more (see my first remark [1] below).

grtz

Gerrie

[Franck Wolff]

I already noticed this issue. I'll see if I have time fix that before the next release.

BTW: I have just commited a fix for GDS-995 (@ExternalizedProperty seen by the GAS3 generator but not by DefaultExternalizer). It's completely untested, potentially dangerous and I would really appreciate if you (and other) can give it a try with the two last builds: distrib (#228) and builder (#211).

Thanks.

[gerrie]

I gave distrib (#228) and builder (#211) a try.

The results:

For the builder (builder #211) :

Unfortunately v2.3.1 of the Eclipse plugin/builder does not seem to be a drop-in replacement for the 2.3.0 version that we currently use (we've patched v2.3.0):

- no as3 code is generated any more

- I'm not able to access the GraniteDS properties page (error instead)

Fortunately issue GDS-995 is not caused by the builder (IMHO). The builder - even v2.3.0 - does a good job. To me it is an externalizer issue.

For the externalizer (distrib #228):

The result of the new DefaultExternalizer#findOrderedFields impl still is not in sync with the generated as3 code (I'm talking builder v2.3.0 here).

The builder generates as3 getters (and read/writeExternal code) as soon as it encounters the label field in the Java class hierarchy (I think this is correct). This is at the abstract level:

abstract class AbstractFoo {

@ExternalizedProperty

public abstract String getLabel();

}

The externalizer's findOrderedFields sees that same label field not until its implementation at the concrete level:

class ConcreteFoo extends AbstractFoo {

public String getLabel() {

return  "conrete";

}

} 

Hence the mismatch. 

So, to conclude, what became better with your fix is that the externalizer now actually calls the getLabel method (before your fix it was left totally uncalled). The moment of the method call is however still not in sync with the generator.

Grtz,

Gerrie

[Franck Wolff]

Bamboo builds were broken (my fault, I had introduced a new reference to a Eclipse 3.5+ method while our build process relies on Eclipse 3.4). All builds seemed to be successful because Bamboo wasn't reporting any failure (this is fixed now).

Try with the last build #223 and tell us if it works and if the builder and the distrib are now consistent.

Thanks.

[Gerrie Kimpen]

The builder #223 works fine now. However the test results have not changed, as expected, since the builder is not the cause: field order of builder and DefaultExternalizer still out of sync. Do they use the same code base already?

Is the problem description clear enough? I'll try to write a failing test.

grtz

gerrie

[gerrie]

I have created a (failing) test for this issue:

Unpack testclasses.zip into the org.granite.test.externalizers package and run the DefaultExternalizerTest.

Grtz,

gerrie

[Franck Wolff]

No, they don't use the same code base and, even if they should, it would be dangerous to make such a big change now. A failing test would be great indeed.

F.

2012/5/22 Gerrie Kimpen <gerrie...@gmail.com>

[Gerrie Kimpen]

FYI: the failing test is already attached ...

[Franck Wolff]

You're right, everything (gas3 / externalizer) was wrong... Could you test with the last 2 builds: distrib #243 and builder #226. I have made some tests this time and, even if there is still something wrong, it shouldn't miserably fail like before :-/

Thanks.

[Franck Wolff]

Gerrie?

We are going to release the new version 2.3.2.GA today and it would be nice to be sure that your issue is now resolved...

Thanks,
F.

[Gerrie Kimpen]

I'm sorry I didn't knew that.

I'll try to test over an hour (busy busy, sprint demo is coming up, it seems that we have some bugs too :)

[Gerrie Kimpen]

It works! 

Tnx Frank

[Franck Wolff]

Great!

Thanks.