On Feb 21, 2012, at 7:40 AM, Romain Manni-Bucau wrote:

> i created a module xbean-xml in maven plugins to be able to commit but it
> should be in xbean i think (the mvn plugin too by the way).
> 
> the example needs openjpa (not jpa ;)) because before using the plugin i
> enhance the entities with the openjpa plugin so then the classes are
> enhanced and reference some openjpa classes so it is needed in this case.

Can you provide more detail on this enhancement?  It sounds like you're mixing 
concerns.

> Concerning the verbosity of xml it is simply a ratio between useful
> characters and useless ones (yes i use vim :p).
> 
> The scan.xml location is configurable. For the moment there is 2 properties
> but it can be (should be) merged in one (today we have base + relative
> path, i liked it because relative is the convention and base is whatever
> you want).

It seems that you are simply restating what you've done instead of justifying 
the weakening of a feature or explaining why the feature of having the scan.xml 
file in a known place is not all that important.

> The snippet David sent in his first mail is till available, i just added
> the notion of "profile" which are in my mind a set of predefined
> [implementations, subclasses, annotations] easier to configure (the one i
> provided is jee6, simply look what it looks like to understand why it is
> not so useless ;)). Maybe it should be done through files at the classpath
> instead of hardcoding it...was a first step ;)

I'm not sure that hardcoding is required.  Per David's earlier email the 
configuration would dictate what would be searched for in the scan.

I thought about profiles as well but then one must publish and maintain those 
profiles.  I hate, hate, hate, finding things in the classpath.  Things 
magically appear and disappear all too often.  :)  What might be a good idea is 
to publish the profile file in Maven.  Then we could use the Maven dependency 
plugin to pull own the file and drop it into the target directory.  Then the 
scan plugin could be configured to read it.

One subtle point to the above use case, it's better to just loosely couple 
things and simply list the exact criteria, and not the profile, that was 
searched for in the scan.xml.


Regards,
Alan

 

Reply via email to