Skip to main content

Bug or feature: depency on external org.kohsuke (in xxLookAndFeelAddon)?

13 replies [Last post]
kleopatra
Offline
Joined: 2003-06-11
Points: 0

Title says it all, leaning heavily on the bug side, as we don't allow mandatory external dependencies ;-) A build debugging left-over, maybe?

Cheers

Jeanette

 

 

 

 

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kschaefe
Offline
Joined: 2006-06-08
Points: 0

Jeanette,

I wanted to separate the use of this dependency from the general conversation, just to talk about what it does.

The MetaInf annotation allows the compiler to automatically generate a META-INF/services file.  These files are not easily managed by IDEs and the use of the annotation and its processing allows us not to worry about file moves or renames as the services code will just work.

So, in this case, at least, because the META-INF/services/org.jdesktop.swingx.plaf.LookAndFeelAddons file is automatically generated during the (Maven) build, users would not be able to use anything except LookAndFeelAddons.getCrossPlatformAddonClassName without either running Maven or hand-generating the file and placing in the correct location.

Karl

kleopatra
Offline
Joined: 2003-06-11
Points: 0

Karl,

thanks for the explanation :-)

Hmm, .. it seems to unveil the real issue - why does the LookAndFeelAddons need any services magic to simply work? It did before (just checked my 1.6.2 local copy), now doesn't find the windowsLAFAddons (on plain compiling, just as you described) - so what's changed and why?

Edit: even with the metainf-services.jar, a plain manual compile doesn't work (winaddon are not found, just the crossplattform). What I did is to download the jar, add to the project jar and did a clean build (in Eclipse). Any ideas?

Edit2: after manually adding the META-INF/services dir  created by the maven build to the plain eclipse source folder (the equivalent to the plaf module), the win addon is found again. 

My current understanding:

  • the jar is meant to help in manual compiles
  • the jar doesn't help in manual compilation (modulo some error I might have made)
  • so "manual compile" do need to manually add the services file
  • it is at a fixed location (the plaf module)
  • we don't expect that location to change (now that the structure is nice and clean)
  • the maven build can find/use it from there

If all this is the case, then there is no reason for adding the jar, that is no need for the external dependency - problem insofar solved as we can post-pone a general source dependency debate until the next time we  seem to need it. Optimistic me, you'll probably correct me :-)

Cheers

Jeanette

kschaefe
Offline
Joined: 2006-06-08
Points: 0

kleopatra wrote:
why does the LookAndFeelAddons need any services magic to simply work? It did before (just checked my 1.6.2 local copy), now doesn't find the windowsLAFAddons (on plain compiling, just as you described) - so what's changed and why?

Good question. It's two-fold. First, we need to remove the cross-dependencies in the plaf architecture. I would like to see (long run) us split this into per-look-and-feel jars to allow users to slim the downloads. This decoupling of dependencies is necessary for that. Secondly, and more importantly, we cannot easily support third party look and feels without some decoupling mechanism. While no such work has gone forward, by putting the ServiceLoader code in place, we are readying the code base to support external (from core) look and feels. This may also help with adoption for people that want to use the plaf-code as a framework to build and deploy custom components.

kleopatra wrote:
even with the metainf-services.jar, a plain manual compile doesn't work (winaddon are not found, just the crossplattform). What I did is to download the jar, add to the project jar and did a clean build (in Eclipse). Any ideas?

Manual compiles must add the metainf-services.jar in the annotation processor segment of processing. I can look up the command line options, if necessary.

kleopatra wrote:
after manually adding the META-INF/services dir created by the maven build to the plain eclipse source folder (the equivalent to the plaf module), the win addon is found again.

Yes, you can even manually create the file and place it in the correct location.

kleopatra wrote:
My current understanding:

  • the jar is meant to help in manual compiles
    No the jar is meant to help Maven compilation and can with some additonal arguments help command line compilation
  • kleopatra wrote:
    the jar doesn't help in manual compilation (modulo some error I might have made)

    No, see above.
  • kleopatra wrote:
    so "manual compile" do need to manually add the services file

    No, see above.
  • kleopatra wrote:
    it is at a fixed location (the plaf module)

    Only if we never move the files again....I'd rather never have to worry about keeping the files dependencies in order.
  • kleopatra wrote:
    we don't expect that location to change (now that the structure is nice and clean)

    Depends on how we want to support third-party look and feels. (When I say this it is a support framework, allowing others to skin our components as necessary.)
  • kleopatra wrote:
    the maven build can find/use it from there

    No sure what this means.

kleopatra wrote:
If all this is the case, then there is no reason for adding the jar, that is no need for the external dependency - problem insofar solved as we can post-pone a general source dependency debate until the next time we seem to need it. Optimistic me, you'll probably correct me :-)

Overall, I think that it is naive to believe that these files would never change again. Furthermore, I think it is bad design to manually maintain files and keep them in version control when they can be programmitcally maintained. The latter ensures that they are never out of date.

I expect that we should be using a similar architecture for generating the Java-Beans markers in the manifest. I have some rudimentary code for this in swing-mavensupport (but this did not make the 1.6.3 time frame).

I don't think we can side step this. The Maven build currently runs with this and would need to be rewritten. While we could build jars manually, it take much more time to get the jars into Maven central and be useful to a wider audience.

Karl

kleopatra
Offline
Joined: 2003-06-11
Points: 0

Hi Karl,

thanks for the thorough explanation - think I got it now (had it upside down in assuming it was for manual compile).

All good design points, especially to let the tool (as much as I hate it ;-) do the whole work and aiming to do so consistently. I agree that we should do it, even at the price of adding compile time dependencies. Ideally, the decision should be documented somewhere, though (hint, hint :-)

Finally convinced, go ahead :-)

Cheers

Jeanette

kschaefe
Offline
Joined: 2006-06-08
Points: 0

Jeanette,

Where to document?  The wiki is locked in preparation for move to the new wiki structure.  I can add some comments in the main POM file, but that doesn't cover the general decision.

Karl

kleopatra
Offline
Joined: 2003-06-11
Points: 0

good question ... and no good answer, unfortunately.

For this one, POM sounds good, api doc should mention it as well, so that manual compilers can find out the reasons and what to do.

Regarding a general decision, just to clarify: I still think that we should be very careful with adding (source) dependencies in the production part. My take is that the default is "don't", but each addition can be discussed and allowed by agreement on its added value (as in this case) or, trivially, if nobody objects :-)

Cheers

Jeanette

kschaefe
Offline
Joined: 2006-06-08
Points: 0

Comments added to POM file and plaf package-info.

Karl

kschaefe
Offline
Joined: 2006-06-08
Points: 0

It's not an exported, external dependency.  The annotations are source only.  This means that clients are not require to have the library.  Even if they did, they would not be able to find the annotation at runtime to do any reflective work on it.

Karl

kleopatra
Offline
Joined: 2003-06-11
Points: 0

hmmm ... as far as I understand the no-dependencies rule it applies to source (except the parts for testing) as well: all production modules must be compilable without adding external jars

Cheers

Jeanette

 

kschaefe
Offline
Joined: 2006-06-08
Points: 0

So, where are the rules at?  I've just searched the entire wiki and can't find any information on external dependencies.  It would be good to refer to the original source, so we can understand the previous decisions to enlighten this one.

Karl

kschaefe
Offline
Joined: 2006-06-08
Points: 0

Historically, we have allowed dependencies on external projects, most specifically the SwingWorker backport (though I know there were others).  We have improved on that to require zero third-party libraries for compiled code.

Furthermore, I would disagree with that idea that the rule applied to source.  I see no difference between the "testing" code and the "real" code.  I someone downloads SwingX, they are going to need JUnit, Mockito, JHLabs Filters to compile the tests.  Anyone that wants to build the project, should build and execute the tests.  That's the right thing to do.  So, what's one more library for the users to download?  It isn't part of the distribution or required by compiled code.  No difference.

Karl

kleopatra
Offline
Joined: 2003-06-11
Points: 0

good historical point!

One other was the ancestor of GroupLayout, if my memory doesn't fail me. Most probably (after all, it _is_ history and the definer at that time was THE BIG BOSS behind Richard the First :-), the definition of "external" was external-to-swinglabs. No longer depending on those is a side-effect of moving to jdk6. Though an improvement, nothing to write on our success banner.

Arguably, the differentiation between "real" and "test" code is a brittle line, growing weaker during time: at the beginning it was only JUnit (and Mockito?). later came all the stuff for hudson, emma, commons whatever. Could well be that nobody complained because nobody wanted to compile the test packages when patching swingx - guessing wildly, obviously.

As to where to find the rule: in extended forum debates. Personally, I remember fighting - unsuccessfully - for a decent external LayoutManager (which was FormLayout at that time) to use in the higher level containers (like JXErrorPane, LogIn) f.i. - which at the end would have been a source dependency not necessarily leading to a binary dependency. Don't know where to find them now, after 2 lossy forum migrations ..

History being and seeing, I think we are free to decide otherwise - after publicly weighing pros and cons of such a change. Personally, I feel very weary to allow external dependencies on the "real" code, be it source or binary (the latter is not in question?). Open for arguments, of course, particularly from the group of users of the framework (as committers we can be bothered with downloading/managing whatever is needed, we must compile the tests anyway :-)

Cheers

Jeanette

kschaefe
Offline
Joined: 2006-06-08
Points: 0

Forum ate my post, so here's the simple version:

I'd like to avoid external runtime dependencies, but I think we should allow external source dependencies.  In this case, the source dependency is tooling to make the build easier.

Karl