JSPWiki
  1. JSPWiki
  2. JSPWIKI-38

Rename packages to "org.apache.jspwiki"

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 3.0
    • Component/s: None
    • Labels:
      None

      Issue Links

        Activity

        Hide
        Harry Metske added a comment -

        Will close in a few days......

        Show
        Harry Metske added a comment - Will close in a few days......
        Hide
        Janne Jalkanen added a comment -

        +1

        Show
        Janne Jalkanen added a comment - +1
        Hide
        Harry Metske added a comment -

        I think the move went rather smoothly, can we close this one ?

        Show
        Harry Metske added a comment - I think the move went rather smoothly, can we close this one ?
        Hide
        Janne Jalkanen added a comment -

        Done in 3.0.0-svn-60. Leaving open until we're convinced the move went smoothly.

        Show
        Janne Jalkanen added a comment - Done in 3.0.0-svn-60. Leaving open until we're convinced the move went smoothly.
        Hide
        Janne Jalkanen added a comment -

        @ajaquith: yes, that is a separate issue (which unfortunately flooded this discussion).

        Show
        Janne Jalkanen added a comment - @ajaquith: yes, that is a separate issue (which unfortunately flooded this discussion).
        Hide
        Florian Holeczek added a comment -

        +1

        Show
        Florian Holeczek added a comment - +1
        Hide
        Andrew Jaquith added a comment -

        +1, assuming you meant a straight rename from com.ecyrd.jspwiki --> org.apache.wiki. My concerns about the .api package still apply, but that's something we can resolve later.

        Show
        Andrew Jaquith added a comment - +1, assuming you meant a straight rename from com.ecyrd.jspwiki --> org.apache.wiki. My concerns about the .api package still apply, but that's something we can resolve later.
        Hide
        Harry Metske added a comment -

        +1

        Show
        Harry Metske added a comment - +1
        Hide
        Janne Jalkanen added a comment -

        So shall we change this to "rename packages to org.apache.wiki" considering JSPWIKI-464?

        Show
        Janne Jalkanen added a comment - So shall we change this to "rename packages to org.apache.wiki" considering JSPWIKI-464 ?
        Hide
        Harry Metske added a comment -

        Just for the record, a separate issue for this JSP compilation problem has been filed: JSPWIKI-465

        Show
        Harry Metske added a comment - Just for the record, a separate issue for this JSP compilation problem has been filed: JSPWIKI-465
        Hide
        Andrew Jaquith added a comment -

        The package name org.apache.jspwiki seems to block JSP compilation by Tomcat's Jasper JSP compiler. See Harry's comments at the bug entry JSPWIKI-464.

        Show
        Andrew Jaquith added a comment - The package name org.apache.jspwiki seems to block JSP compilation by Tomcat's Jasper JSP compiler. See Harry's comments at the bug entry JSPWIKI-464 .
        Hide
        Andrew Jaquith added a comment -

        Janne – sorry, I did not mean to suggest you were somehow against interface extraction. We do agree on this. Obviously, this particular discussion has raged for a while, and occasionally precision eludes me.

        You have recap'ped my counter-proposal accurately. I'd like to keep the interfaces in the same packages (after we rename them to org.apache.jspwiki), and not put them in a separate org.apache.jspwiki.api package, or in a separate package tree such as org.apache.jspwiki.api, OR org.apache.jspwiki-api.

        Not to put too fine a point on it, the burden on me is NOT to show that your idea is a bad one. Because what you've suggested is a significant change, the burden is on you to show why a separate .api package (or package tree) is warranted. I understand your reasoning but disagree on the conclusion.

        Consequently I will send out a message to the dev list requesting three votes:

        • Immediate renaming of all packages from com.ecyrd.jspwiki to org.apache.jspwiki, so that we can move to release an early alpha Apache build.
        • Refactoring concrete classes (e.g., WikiEngine) into interfaces whenever possible, and supplementing them with factory interfaces if warranted (e.g., interface WikiEngineFactory).
        • Creation of the .api package/package tree, and creation of various types in this package (e.g., WikiEngine, WikiPage)

        I will vote +1 for the first two items, and -1 (veto) on the third with the recommendation that we use existing (after-rename, org.apache.jspwiki) packages. The third vote is essentially a retroactive vote.

        Let's count 'em the votes. Smoke 'em if you got 'em.

        Show
        Andrew Jaquith added a comment - Janne – sorry, I did not mean to suggest you were somehow against interface extraction. We do agree on this. Obviously, this particular discussion has raged for a while, and occasionally precision eludes me. You have recap'ped my counter-proposal accurately. I'd like to keep the interfaces in the same packages (after we rename them to org.apache.jspwiki), and not put them in a separate org.apache.jspwiki.api package, or in a separate package tree such as org.apache.jspwiki.api, OR org.apache.jspwiki-api. Not to put too fine a point on it, the burden on me is NOT to show that your idea is a bad one. Because what you've suggested is a significant change, the burden is on you to show why a separate .api package (or package tree) is warranted. I understand your reasoning but disagree on the conclusion. Consequently I will send out a message to the dev list requesting three votes: Immediate renaming of all packages from com.ecyrd.jspwiki to org.apache.jspwiki, so that we can move to release an early alpha Apache build. Refactoring concrete classes (e.g., WikiEngine) into interfaces whenever possible, and supplementing them with factory interfaces if warranted (e.g., interface WikiEngineFactory). Creation of the .api package/package tree, and creation of various types in this package (e.g., WikiEngine, WikiPage) I will vote +1 for the first two items, and -1 (veto) on the third with the recommendation that we use existing (after-rename, org.apache.jspwiki) packages. The third vote is essentially a retroactive vote. Let's count 'em the votes. Smoke 'em if you got 'em.
        Hide
        Janne Jalkanen added a comment -

        @Murray: everything is an API, both classes and interfaces, if it's public. However, the question is really about stable and unstable APIs. The .api package comes with a promise (and hopefully, a test suite) to make sure that if you code against them only, your plugins will work in the future. And, if you do code against anything unstable, you know that it's likely to break from major version to major version.

        Currently, this is not the case. We have even broken interfaces (like the PageFilter one) between minor versions, which means that it's difficult for developers to keep up.

        The JCR branch has nothing to do with this, really.

        The API package does not mean that we lose any sense of the API hierarchy. We can easily have
        org.apache.jspwiki.api.acl
        org.apache.jspwiki.api.plugin
        org.apache.jspwiki.api.filter

        If we choose to have so.

        Having the interface in the same package as the concrete implementation has no advantage with respect to protected members, since interfaces cannot have members at all...

        Show
        Janne Jalkanen added a comment - @Murray: everything is an API, both classes and interfaces, if it's public. However, the question is really about stable and unstable APIs. The .api package comes with a promise (and hopefully, a test suite) to make sure that if you code against them only, your plugins will work in the future. And, if you do code against anything unstable, you know that it's likely to break from major version to major version. Currently, this is not the case. We have even broken interfaces (like the PageFilter one) between minor versions, which means that it's difficult for developers to keep up. The JCR branch has nothing to do with this, really. The API package does not mean that we lose any sense of the API hierarchy. We can easily have org.apache.jspwiki.api.acl org.apache.jspwiki.api.plugin org.apache.jspwiki.api.filter If we choose to have so. Having the interface in the same package as the concrete implementation has no advantage with respect to protected members, since interfaces cannot have members at all...
        Hide
        Janne Jalkanen added a comment -

        Andrew, if you read my proposal carefully, you will notice that interface extraction is the one thing we agree on. So this is not a "interface extraction vs shunting developers off to a different package" -situation, and please don't try to represent it as such.

        To recap: my proposal is to put the interfaces in a separate package (because of all the several reasons I have provided above), and your proposal is to keep them with the regular classes (because it's a non-starter for you).

        I would like to hear a bit more fact-based argumentation for your point of view. I don't think typing four extra letters (".api") is not a problem for developers, especially since most IDEs are able to fill it in automatically. So all that remains is your aesthetical objection (which, as Murray points out, makes it all rather muddy).

        There are three additional objections at coding against interfaces:

        • Exceptions are not interfaces, so therefore you cannot code purely against an interface.
        • We probably wish to retain the option of having unstable interfaces before they are graduated into a "stable" interface, which in my proposal is marked by transferring them from the regular class hierarchy to the .api -class hierarchy. Similarly, we lose the ability to make unstable "subinterfaces" by inheriting on a stable interface. For example, certain SPI code could easily be like this for a while - first releasing it "internally" in 3.1 so that developers can take a whack at it, then stabilizing it in 3.2.
        • It is impossible to tell, just by looking at the source code itself, whether you are using an interface or a class. Therefore, the developer lacks any visual cues as to whether he is relying on unstable or stable APIs, and needs to rely on documentation.
        Show
        Janne Jalkanen added a comment - Andrew, if you read my proposal carefully, you will notice that interface extraction is the one thing we agree on. So this is not a "interface extraction vs shunting developers off to a different package" -situation, and please don't try to represent it as such. To recap: my proposal is to put the interfaces in a separate package (because of all the several reasons I have provided above), and your proposal is to keep them with the regular classes (because it's a non-starter for you). I would like to hear a bit more fact-based argumentation for your point of view. I don't think typing four extra letters (".api") is not a problem for developers, especially since most IDEs are able to fill it in automatically. So all that remains is your aesthetical objection (which, as Murray points out, makes it all rather muddy). There are three additional objections at coding against interfaces: Exceptions are not interfaces, so therefore you cannot code purely against an interface. We probably wish to retain the option of having unstable interfaces before they are graduated into a "stable" interface, which in my proposal is marked by transferring them from the regular class hierarchy to the .api -class hierarchy. Similarly, we lose the ability to make unstable "subinterfaces" by inheriting on a stable interface. For example, certain SPI code could easily be like this for a while - first releasing it "internally" in 3.1 so that developers can take a whack at it, then stabilizing it in 3.2. It is impossible to tell, just by looking at the source code itself, whether you are using an interface or a class. Therefore, the developer lacks any visual cues as to whether he is relying on unstable or stable APIs, and needs to rely on documentation.
        Hide
        Murray Altheim added a comment -

        Hi Andrew,

        I do admit to some confusion in this discussion, with my apologies for any part I've played in that confusion.

        Yes, this was what I'd mentioned in my message of 28/Dec/08 01:52 AM. I have several instances of an interface, a default implementation, and a factory all in the same package. I don't have an aesthetic issue with that, and it does provide the advantage of being able to use protected methods and member variables across the classes. It's also easy for the developer to locate all of the components since they're in one place.

        I can likewise understand Janne's desire to have all of the APIs in one place too, as it's a clear encapsulation of the set of guarantees being promised. If there's only to be that set of APIs I think Janne's suggestion is a good one, but if there are other APIs littered throughout the package hierarchy (and I suspect there are based on the current code) and those APIs aren't guaranteed as stable as those in the api package, well, that's rather muddy.

        I do think that (based on my experience in the JDK, particularly with JAXP) that there are advantages to both. But I wouldn't say I'm a fence-sitter on this, since the only way I think a separate api package is a good idea is if all the APIs of the entire application live there since that's what's suggested by its presence. If there are interfaces elsewhere I guess a developer would assume those aren't guaranteed as stable, which is weird. Also, in the api package we lose any sense of the API hierarchy and we end up mixing all sorts of things that aren't really related except by being APIs.

        I do like the simplicity (for developers) for those classes we expect to have an interface, a factory and a default implementation, that they live in one place. I'm trying to think how this isn't simply a matter of taste or aesthetics.

        After New Years as Janne suggested I'll download the JCR branch and take a look since I'm only speculating. I'm kinda busy right now with a couple other things, playing catch-up. (What are we doing not enjoying the holidays, anyway?)

        Show
        Murray Altheim added a comment - Hi Andrew, I do admit to some confusion in this discussion, with my apologies for any part I've played in that confusion. Yes, this was what I'd mentioned in my message of 28/Dec/08 01:52 AM. I have several instances of an interface, a default implementation, and a factory all in the same package. I don't have an aesthetic issue with that, and it does provide the advantage of being able to use protected methods and member variables across the classes. It's also easy for the developer to locate all of the components since they're in one place. I can likewise understand Janne's desire to have all of the APIs in one place too, as it's a clear encapsulation of the set of guarantees being promised. If there's only to be that set of APIs I think Janne's suggestion is a good one, but if there are other APIs littered throughout the package hierarchy (and I suspect there are based on the current code) and those APIs aren't guaranteed as stable as those in the api package, well, that's rather muddy. I do think that (based on my experience in the JDK, particularly with JAXP) that there are advantages to both. But I wouldn't say I'm a fence-sitter on this, since the only way I think a separate api package is a good idea is if all the APIs of the entire application live there since that's what's suggested by its presence. If there are interfaces elsewhere I guess a developer would assume those aren't guaranteed as stable, which is weird. Also, in the api package we lose any sense of the API hierarchy and we end up mixing all sorts of things that aren't really related except by being APIs. I do like the simplicity (for developers) for those classes we expect to have an interface, a factory and a default implementation, that they live in one place. I'm trying to think how this isn't simply a matter of taste or aesthetics. After New Years as Janne suggested I'll download the JCR branch and take a look since I'm only speculating. I'm kinda busy right now with a couple other things, playing catch-up. (What are we doing not enjoying the holidays, anyway?)
        Hide
        Andrew Jaquith added a comment -

        Murray – my counter-proposal was that we eliminate the .api package and focus on refactoring concrete classes into interfaces instead. I.e., WikiEngine becomes an interface in the top-level package, and we provide a concrete class called DefaultWikiEngine (for example) that provides the implementation. This could be combined with a factory class that produces WikiEngines.

        This has already been done, partially, with WikiContext (even though the interface ended up in the .api package, which I'd prefer us to avoid).

        In other words: focus on refactoring by extracting interfaces, not shunting developers off to another package. If we provide good interfaces, developers will use them in preference to the concrete classes anyway.

        Show
        Andrew Jaquith added a comment - Murray – my counter-proposal was that we eliminate the .api package and focus on refactoring concrete classes into interfaces instead. I.e., WikiEngine becomes an interface in the top-level package, and we provide a concrete class called DefaultWikiEngine (for example) that provides the implementation. This could be combined with a factory class that produces WikiEngines. This has already been done, partially, with WikiContext (even though the interface ended up in the .api package, which I'd prefer us to avoid). In other words: focus on refactoring by extracting interfaces, not shunting developers off to another package. If we provide good interfaces, developers will use them in preference to the concrete classes anyway.
        Hide
        Janne Jalkanen added a comment -

        Murray, that is exactly what I am proposing - having a separate org.apache.jspwiki.api -package, and placing a number of existing manager classes into it as interfaces. Or to be precise, a mostly equivalent set of APIs; JCR requires some modifications which would make it complicated to support the existing set of APIs - mainly because we need to carry state information in a WikiContext, which the old API signatures do not mostly support. I would also like us to start using WikiNames wherever useful.

        The idea behind this is largely the same as with our existing package structure - there is nothing technical in preventing everything to be in the org.apache.jspwiki -namespace (with no subpackages), but both aesthetics and experience tell us that it just makes sense to add subpackages to make class management easier.

        In the same vein, isolating the API interfaces into a separate package makes it a lot easier to manage than having everything dispersed around - e.g. if we want to create a jspwiki-api.jar, we only need to jar up the contents of a particular subdirectory. If the developer wants to know whether he is using any possibly unstable components, all he needs to do is to glance at the set of import statements on the top - if he's using other classes than org.apache.jspwiki.api.*, he knows that the classes are potentially unstable. In addition, it makes the committer's life easier, since there is an agreement by convention that the APIs inside *.api are not to be touched without common agreement, whereas anything outside of this package can be treated with more liberties. We have so many people contributing in the code that API incompatibilities can creep in without anyone noticing.

        (There is no PageManager at all; there is a ContentManager, which will have a very similar API, but it will manage both pages and attachments. Check out the JCR branch. I am not very hot into writing bridging classes, simply because it is a lot of work which will need to be supported for a long time, and I am running out of time already. If you want to write a compatibility suite, go ahead.)

        Show
        Janne Jalkanen added a comment - Murray, that is exactly what I am proposing - having a separate org.apache.jspwiki.api -package, and placing a number of existing manager classes into it as interfaces. Or to be precise, a mostly equivalent set of APIs; JCR requires some modifications which would make it complicated to support the existing set of APIs - mainly because we need to carry state information in a WikiContext, which the old API signatures do not mostly support. I would also like us to start using WikiNames wherever useful. The idea behind this is largely the same as with our existing package structure - there is nothing technical in preventing everything to be in the org.apache.jspwiki -namespace (with no subpackages), but both aesthetics and experience tell us that it just makes sense to add subpackages to make class management easier. In the same vein, isolating the API interfaces into a separate package makes it a lot easier to manage than having everything dispersed around - e.g. if we want to create a jspwiki-api.jar, we only need to jar up the contents of a particular subdirectory. If the developer wants to know whether he is using any possibly unstable components, all he needs to do is to glance at the set of import statements on the top - if he's using other classes than org.apache.jspwiki.api.*, he knows that the classes are potentially unstable. In addition, it makes the committer's life easier, since there is an agreement by convention that the APIs inside *.api are not to be touched without common agreement, whereas anything outside of this package can be treated with more liberties. We have so many people contributing in the code that API incompatibilities can creep in without anyone noticing. (There is no PageManager at all; there is a ContentManager, which will have a very similar API, but it will manage both pages and attachments. Check out the JCR branch. I am not very hot into writing bridging classes, simply because it is a lot of work which will need to be supported for a long time, and I am running out of time already. If you want to write a compatibility suite, go ahead.)
        Hide
        Murray Altheim added a comment -

        Janne,

        Yes, I have realized I would have to rewrite all of the existing plugins for 3.0. That represents about 45 plugins (of the publicly available ones; there are more private ones) and more than 150 classes, many of which will be affected. I assume that support for a lot of these in 3.0 will disappear, as I can't realistically rewrite that many plugins. Yes, I might be able to solicit some help. The Assertion Framework is about 20 plugin classes and a lot of tie-ins to the WikiEngine, PageManager, events code, etc. The TagManager would likewise need wholesale revision. I'm hoping all of my higher-priority classes can be migrated, otherwise I'll be forced to stay with 2.x. I really don't want to be the Fletcher Christian of JSPWiki, believe me. We all know what it was like on Pitcairn Island for the survivors.

        While we've not had interfaces, I've treated any of the *Manager classes as relatively stable entities, and in the past been able to maintain currency with the trunk through a constant migration. As I wrote, this was a relatively stable migration, and yes, it would have been mitigated had there been APIs.

        I have assumed that going to JCR meant a wholesale upending of any previous managers, but I have also assumed (perhaps wrongly) that the basic functionality of the manager classes would be relatively easy to recreate via some bridging manager classes. Are you saying there'd be no PageManager at all in 3.0? If there is, or there's something akin to it, it should be relatively easy to replicate the functionality via a bridging PageManager class that I can use. As for using factory classes rather than constructors, hey, I'm all for that. I don't mind rewriting stuff when it truly is a simplification but doesn't alter the fundamental structure and functionality.

        As you say, JSPWiki has been a set of classes on which you can. And I have hacked a great deal and now I must pay.

        As for not permitting APIs within the regular class hierarchy, why is that a non-starter? Aesthetics? I've resisted making arguments based on aesthetics during this discussion. I may not be the world's cleanest coder, but of the ~200K lines of code in Ceryle l've got interfaces and implementations in the same hierarchy, and I've got them in separate hierarchies. With versioning the interfaces over time (over seven years) I'm not sure that either has made a substantial difference. I've had to make changes in the interface based on changing project needs. Where the API was located would have made little difference. Interfaces vary in stability too.

        But yes, I understand the difference and I don't think I disagree with you in the basics. A guarantee would be nice, but it would be only a relative guarantee and (to my mind) shouldn't come at the expense of significantly complicated code or package structure. Factories are by nature a bit more complicated, but god have I seen a variety of different approaches to that, some extravagantly complicated, others almost as simple as using a constructor.

        What about the idea of creating a single package org.apache.jspwiki.api.*, and placing within that the WikiEngine and all of the existing manager classes as interfaces (bridges to previous managers)? How different is that from what you're proposing? Why do the APIs need to be in some other hierarchy? [I don't have a problem with Foo and FooImpl being in the same package hierarchy or even the same package if Foo is labeled as a stable interface with a version number, where FooImpl is the default implementation.]

        You keep writing things that I agree with, then you write something that seemingly contradicts that agreement. Perhaps I'm just misunderstanding you. Yes, we're just having a conversation towards finding a good solution to this. Thanks for your continued patience.

        Show
        Murray Altheim added a comment - Janne, Yes, I have realized I would have to rewrite all of the existing plugins for 3.0. That represents about 45 plugins (of the publicly available ones; there are more private ones) and more than 150 classes, many of which will be affected. I assume that support for a lot of these in 3.0 will disappear, as I can't realistically rewrite that many plugins. Yes, I might be able to solicit some help. The Assertion Framework is about 20 plugin classes and a lot of tie-ins to the WikiEngine, PageManager, events code, etc. The TagManager would likewise need wholesale revision. I'm hoping all of my higher-priority classes can be migrated, otherwise I'll be forced to stay with 2.x. I really don't want to be the Fletcher Christian of JSPWiki, believe me. We all know what it was like on Pitcairn Island for the survivors. While we've not had interfaces, I've treated any of the *Manager classes as relatively stable entities, and in the past been able to maintain currency with the trunk through a constant migration. As I wrote, this was a relatively stable migration, and yes, it would have been mitigated had there been APIs. I have assumed that going to JCR meant a wholesale upending of any previous managers, but I have also assumed (perhaps wrongly) that the basic functionality of the manager classes would be relatively easy to recreate via some bridging manager classes. Are you saying there'd be no PageManager at all in 3.0? If there is, or there's something akin to it, it should be relatively easy to replicate the functionality via a bridging PageManager class that I can use. As for using factory classes rather than constructors, hey, I'm all for that. I don't mind rewriting stuff when it truly is a simplification but doesn't alter the fundamental structure and functionality. As you say, JSPWiki has been a set of classes on which you can. And I have hacked a great deal and now I must pay. As for not permitting APIs within the regular class hierarchy, why is that a non-starter? Aesthetics? I've resisted making arguments based on aesthetics during this discussion. I may not be the world's cleanest coder, but of the ~200K lines of code in Ceryle l've got interfaces and implementations in the same hierarchy, and I've got them in separate hierarchies. With versioning the interfaces over time (over seven years) I'm not sure that either has made a substantial difference. I've had to make changes in the interface based on changing project needs. Where the API was located would have made little difference. Interfaces vary in stability too. But yes, I understand the difference and I don't think I disagree with you in the basics. A guarantee would be nice, but it would be only a relative guarantee and (to my mind) shouldn't come at the expense of significantly complicated code or package structure. Factories are by nature a bit more complicated, but god have I seen a variety of different approaches to that, some extravagantly complicated, others almost as simple as using a constructor. What about the idea of creating a single package org.apache.jspwiki.api.* , and placing within that the WikiEngine and all of the existing manager classes as interfaces (bridges to previous managers)? How different is that from what you're proposing? Why do the APIs need to be in some other hierarchy? [I don't have a problem with Foo and FooImpl being in the same package hierarchy or even the same package if Foo is labeled as a stable interface with a version number, where FooImpl is the default implementation.] You keep writing things that I agree with, then you write something that seemingly contradicts that agreement. Perhaps I'm just misunderstanding you. Yes, we're just having a conversation towards finding a good solution to this. Thanks for your continued patience.
        Hide
        Janne Jalkanen added a comment -

        Murray,

        perhaps you don't realize this but you will have to rewrite all your plugins for 3.0 anyway, regardless of this discussion. The move to JCR means that most of the WikiEngine/PageManager/AttachmentManager/ReferenceManager APIs will be gone, period.

        My aim with the API package was to create a set of interfaces which could be used to create a set of functionality to prevent from this from occurring in the future. Something with sane design, preferably, as opposed to the ad-hoc design of WikiEngine.

        But hey, obviously people don't want APIs or any promises of stability. So be it then. It'll just be harder on everyone in the long run.

        Try to understand - if it is within the regular package hierarchy, I do not wish to make any promises about it being stable, just like with any of our current APIs, none of which are declared stable. We do not currently have an API, we have just a set of classes on which you can hack. And declaring some APIs stable within the regular class hierarchy is simply a non-starter for me.

        Show
        Janne Jalkanen added a comment - Murray, perhaps you don't realize this but you will have to rewrite all your plugins for 3.0 anyway, regardless of this discussion. The move to JCR means that most of the WikiEngine/PageManager/AttachmentManager/ReferenceManager APIs will be gone, period. My aim with the API package was to create a set of interfaces which could be used to create a set of functionality to prevent from this from occurring in the future. Something with sane design, preferably, as opposed to the ad-hoc design of WikiEngine. But hey, obviously people don't want APIs or any promises of stability. So be it then. It'll just be harder on everyone in the long run. Try to understand - if it is within the regular package hierarchy, I do not wish to make any promises about it being stable, just like with any of our current APIs, none of which are declared stable. We do not currently have an API, we have just a set of classes on which you can hack. And declaring some APIs stable within the regular class hierarchy is simply a non-starter for me.
        Hide
        Murray Altheim added a comment -

        Since there seems to be some perception that my comments are overly critical I'll preface this with the note that my entire motivation for writing this is in hope that I'll be able to continue to use JSPWiki 3.0 following the migration. There are a number of factors that effect that, the biggest being time available. [Apologies for the length.]

        As Andrew has alluded, I'm not one who appreciates complexity for complexity' sake. I doubt Janne is either and I'm assuming his motivations for this are as he has stated. Reading over his comments above (27/Dec/08 03:26 AM) I think I agree with most of them, particularly that our priority is to produce the WikiEngine. I certainly don't require an API to that, which would only limit my abilities. [And *please* don't create private packages or begin using dashes in package names. Ugh.]

        In the case of the JAXP API I can see the rationale for separating the API from the implementations, since the latter are derived from a number of disparate code bases. But in this case we are developing a wiki, which traditionally has been one of the simplest software applications, and we're developing an implementation that is: (a) likely to be the main if only implementation; (b) has no prior API commitments; and (c) is going to break all previous implementations, given it is going to (by design) recommend and/or require that all previous extensions (frameworks, plugins, etc.) use the new implementation since that implementation is guaranteed to change (with at least a package name change). This latter point might seem to suggest the need for an API, but that would also be satisfied by a relatively stable implementation (which has been the status quo). A package name change would maintain that stability more than changes to the fundamental architecture.

        I must confess that I don't know why we really need a separate API package. For the past few years I've been able to follow the changes to the implementation as it has gradually gone from version to version. Would such an API be any more stable? Really? I'm probably a good test case on how much access to the innards of the engine will be available via the API. While Janne is rightfully critical of my armchair statements, not having attempted to migrate my Assertion Framework to 3.0, at this point I'd be a fool to do so even if I had the time. It's a bit of a chicken and an egg problem, as I'd much prefer to wait until the 3.0 code has stabilised before doing that, yet I'd be the first to note any deficiencies for extension classes as I hit those limitations, so any API 1.0 would likely need to become an API 1.1 as I found places in the API that needed opening.

        While I'd really hate to lock the project into the 2.x code, I'm going to have a tough time convincing management of what is (to an outside observer) going to look like architectural changes with few if any user benefits. I.e., I'd be spending a large amount of time coding to remain with the 3.0 code base with little obvious benefit in the outward application. I'd have to rewrite all of the custom plugins (which includes all the CeryleWikiPlugins plus others not publicly available), the Assertion Framework, and (on the side, unrelated to paid work) all of the integration code used to make JSPWiki work embedded in Ceryle (if that will even be still possible, which remains to be seen since they're fairly tightly integrated). I don't know how much work that'd be but it hardly sounds trivial.

        Merely changing the package names is by comparison almost a trivial exercise (accomplished e.g., via a sed script). While not wanting to sound sour about 3.0 you might begin to see that my perspective on this is based on looking ahead at what sounds like a great deal of work (with little in-house support for it), which is why I'm a bit worried. I am enthusiastic as I've said before about Priha since I can likely justify that to my boss and perhaps even use that in other places. But wholesale architectural changes for what is an wiki project seem to me to be overkill, at least for 3.0.

        If put to a vote I'd agree with Andrew's recommendation that we simply rename the packages for now. If there's a need for an API for the rendering engine, we make a simple API for that within the package hierarchy. I don't see the need for a separate package for that API. If an API really simplifies things for me, well, then great; I just don't yet see that.

        In a nutshell, this is again simply a call for simplicity where possible.

        Murray

        PS. While this may seem tangential to any arguments here, my time on this is until sometime in the coming year very limited, as like many here I've got a busy project schedule. I've basically got to apply to my boss if I'm going to spend a substantial amount of time doing the migration, which means I need to convince him of the need. The Assertion Framework was "unfunded" by a rather useless director who just resigned, so following his happy disappearance I've got to re-apply in the new year to get the project re-funded, and the amount of time required will have a lot to do with the decision, given the organisation has a lot of pressing needs that I'm qualified to satisfy. I don't want to fork the code, or be forced into using a fork, but I can say that looking at our organisation for the next three years we're going to be under a very restrained budget. We're also moving out of the current building during a renovation with all that entails for a . I simply won't have the time to do large changes. I know that none of this is anyone else's concern but I doubt I'm the only one in a similar situation. Maybe I am and I'm therefore ignorable. I don't know.

        Show
        Murray Altheim added a comment - Since there seems to be some perception that my comments are overly critical I'll preface this with the note that my entire motivation for writing this is in hope that I'll be able to continue to use JSPWiki 3.0 following the migration. There are a number of factors that effect that, the biggest being time available. [Apologies for the length.] As Andrew has alluded, I'm not one who appreciates complexity for complexity' sake. I doubt Janne is either and I'm assuming his motivations for this are as he has stated. Reading over his comments above (27/Dec/08 03:26 AM) I think I agree with most of them, particularly that our priority is to produce the WikiEngine. I certainly don't require an API to that, which would only limit my abilities. [And *please* don't create private packages or begin using dashes in package names. Ugh.] In the case of the JAXP API I can see the rationale for separating the API from the implementations, since the latter are derived from a number of disparate code bases. But in this case we are developing a wiki , which traditionally has been one of the simplest software applications, and we're developing an implementation that is: (a) likely to be the main if only implementation; (b) has no prior API commitments; and (c) is going to break all previous implementations, given it is going to (by design) recommend and/or require that all previous extensions (frameworks, plugins, etc.) use the new implementation since that implementation is guaranteed to change (with at least a package name change). This latter point might seem to suggest the need for an API, but that would also be satisfied by a relatively stable implementation (which has been the status quo). A package name change would maintain that stability more than changes to the fundamental architecture. I must confess that I don't know why we really need a separate API package. For the past few years I've been able to follow the changes to the implementation as it has gradually gone from version to version. Would such an API be any more stable? Really? I'm probably a good test case on how much access to the innards of the engine will be available via the API. While Janne is rightfully critical of my armchair statements, not having attempted to migrate my Assertion Framework to 3.0, at this point I'd be a fool to do so even if I had the time. It's a bit of a chicken and an egg problem, as I'd much prefer to wait until the 3.0 code has stabilised before doing that, yet I'd be the first to note any deficiencies for extension classes as I hit those limitations, so any API 1.0 would likely need to become an API 1.1 as I found places in the API that needed opening. While I'd really hate to lock the project into the 2.x code, I'm going to have a tough time convincing management of what is (to an outside observer) going to look like architectural changes with few if any user benefits. I.e., I'd be spending a large amount of time coding to remain with the 3.0 code base with little obvious benefit in the outward application. I'd have to rewrite all of the custom plugins (which includes all the CeryleWikiPlugins plus others not publicly available), the Assertion Framework, and (on the side, unrelated to paid work) all of the integration code used to make JSPWiki work embedded in Ceryle (if that will even be still possible, which remains to be seen since they're fairly tightly integrated). I don't know how much work that'd be but it hardly sounds trivial. Merely changing the package names is by comparison almost a trivial exercise (accomplished e.g., via a sed script). While not wanting to sound sour about 3.0 you might begin to see that my perspective on this is based on looking ahead at what sounds like a great deal of work (with little in-house support for it), which is why I'm a bit worried. I am enthusiastic as I've said before about Priha since I can likely justify that to my boss and perhaps even use that in other places. But wholesale architectural changes for what is an wiki project seem to me to be overkill, at least for 3.0. If put to a vote I'd agree with Andrew's recommendation that we simply rename the packages for now. If there's a need for an API for the rendering engine, we make a simple API for that within the package hierarchy. I don't see the need for a separate package for that API. If an API really simplifies things for me, well, then great; I just don't yet see that. In a nutshell, this is again simply a call for simplicity where possible. Murray PS. While this may seem tangential to any arguments here, my time on this is until sometime in the coming year very limited, as like many here I've got a busy project schedule. I've basically got to apply to my boss if I'm going to spend a substantial amount of time doing the migration, which means I need to convince him of the need. The Assertion Framework was "unfunded" by a rather useless director who just resigned, so following his happy disappearance I've got to re-apply in the new year to get the project re-funded, and the amount of time required will have a lot to do with the decision, given the organisation has a lot of pressing needs that I'm qualified to satisfy. I don't want to fork the code, or be forced into using a fork, but I can say that looking at our organisation for the next three years we're going to be under a very restrained budget. We're also moving out of the current building during a renovation with all that entails for a . I simply won't have the time to do large changes. I know that none of this is anyone else's concern but I doubt I'm the only one in a similar situation. Maybe I am and I'm therefore ignorable. I don't know.
        Hide
        Janne Jalkanen added a comment -

        There have been several calls (over many years) to separate the rendering engine from the core, and unless we isolate the implementation and the API, it's simply not possible.

        Show
        Janne Jalkanen added a comment - There have been several calls (over many years) to separate the rendering engine from the core, and unless we isolate the implementation and the API, it's simply not possible.
        Hide
        Andrew Jaquith added a comment -

        Janne –

        I thought the general goal of any API design would be to treat the API as a first-class citizen, and not the implementation. That is why I proposed org.apache.jspwiki as the one where the API would live.

        It seems fairly clear that you and I are not going to agree. I confess I do not understand who the API package is aimed at, why they need it, and how it makes things less confusing for them rather than more. There has been no spontaneous developer uprising calling for a separate API package, and the one developer (other than me) who has weighed in on it – Murray – doesn't seem to like it.

        Because we do not agree, it seems that the status quo should hold. In other words: continued good class and interface design, appropriate refactorings for 3.0, and continued conversion of concrete classes to interfaces + factories. (Example: what we've done with WikiContext). More of the same, but better.

        That said, we do have to rename the package structure to org.apache.jspwiki.

        Therefore, I recommend we simply make a straight 1:1 rename from com.ecyrd.jspqiki to org.apache.jspwiki, and kill the API package. Let's vote on it.

        Show
        Andrew Jaquith added a comment - Janne – I thought the general goal of any API design would be to treat the API as a first-class citizen, and not the implementation. That is why I proposed org.apache.jspwiki as the one where the API would live. It seems fairly clear that you and I are not going to agree. I confess I do not understand who the API package is aimed at, why they need it, and how it makes things less confusing for them rather than more. There has been no spontaneous developer uprising calling for a separate API package, and the one developer (other than me) who has weighed in on it – Murray – doesn't seem to like it. Because we do not agree, it seems that the status quo should hold. In other words: continued good class and interface design, appropriate refactorings for 3.0, and continued conversion of concrete classes to interfaces + factories. (Example: what we've done with WikiContext). More of the same, but better. That said, we do have to rename the package structure to org.apache.jspwiki. Therefore, I recommend we simply make a straight 1:1 rename from com.ecyrd.jspqiki to org.apache.jspwiki, and kill the API package. Let's vote on it.
        Hide
        Janne Jalkanen added a comment -

        Or - as a funny thought - the API package could be managed outside Apache (e.g. under the org.jspwiki-hierarchy). This is not unprecedented; Apache has on several occasions provided reference implementations to JCP packages, where the API classes are not maintained by Apache (though quite often it is the exact same people).

        Show
        Janne Jalkanen added a comment - Or - as a funny thought - the API package could be managed outside Apache (e.g. under the org.jspwiki-hierarchy). This is not unprecedented; Apache has on several occasions provided reference implementations to JCP packages, where the API classes are not maintained by Apache (though quite often it is the exact same people).
        Hide
        Janne Jalkanen added a comment -

        The Ruby on Rails folks have taught an important lesson: convention over configuration. I think this is very powerful, and Stripes uses the same paradigm as well by defaulting to certain package naming conventions for its ActionBeans: in fact, they force you to have an extra level of depth in your package naming by assuming your ActionBeans lie in the ".stripes." or ".action." packages. In the same vein, I think the separation of the API classes into a separate hierarchy of their own does make sense by encoding the fact that they are API classes directly into the package names themselves. Much like the "plugin" in the package name means that these are plugins.

        Now, I am not entirely certain whether moving practically all of our classes (save a few odd stranglers, perhaps ten or so for 3.0) into a .private -namespace makes sense either. It is certainly not the simple solution that Andrew alluded to above, and will probably confuse developers. Think about the two different messages: "You may use anything in the api-package, and that will be stable." vs "You may use anything under org.apache.jspwiki.* EXCEPT for the packages under private, and all those will be stable (except those aforementioned packages)" There's a subtle difference, and I would much rather go for the first one than the second one. Easier to communicate, easier to code, easier to understand and easier to build scripts for. And, while creation of an "impl" -package might keep third party developers happier, it will annoy our current core developer base by introducing an extra layer. After all, we have to deal with those 350+ classes all the time.

        However, we could make a cosmetic change by creating a JSPWiki API subproject, call it "jspwiki-api". It's really all about switching a period to a dash, but it does not create any further nesting levels (though since most developers these days do use IDEs, I don't think any extra levels are really a problem). So, we would have "org.apache.jspwiki" with the implementation, and "org.apache.jspwiki-api" for the API.

        Other possibility is to treat these in reverse, but I don't really like the "impl" or "private" names. There would need to be a better naming convention.

        I guess my main objection is that since the aim of this project is to produce the wikiengine itself, not the API, I really don't like the idea that we give the API the first-class citizen treatment and force the actual implementation to some second-tier packages. The org.apache.jspwiki -package should really be about the JSPWiki engine, not an abstract API class set. If we had set out to do to create an API definition, then yes, then obviously we would do things differently, but I don't think API creation has ever been more than just an issue on this tracker.

        If we wish to have a top-level package for the API, then perhaps a subproject with own dedicated package name might make most sense.

        Show
        Janne Jalkanen added a comment - The Ruby on Rails folks have taught an important lesson: convention over configuration. I think this is very powerful, and Stripes uses the same paradigm as well by defaulting to certain package naming conventions for its ActionBeans: in fact, they force you to have an extra level of depth in your package naming by assuming your ActionBeans lie in the ".stripes." or ".action." packages. In the same vein, I think the separation of the API classes into a separate hierarchy of their own does make sense by encoding the fact that they are API classes directly into the package names themselves. Much like the "plugin" in the package name means that these are plugins. Now, I am not entirely certain whether moving practically all of our classes (save a few odd stranglers, perhaps ten or so for 3.0) into a .private -namespace makes sense either. It is certainly not the simple solution that Andrew alluded to above, and will probably confuse developers. Think about the two different messages: "You may use anything in the api-package, and that will be stable." vs "You may use anything under org.apache.jspwiki.* EXCEPT for the packages under private, and all those will be stable (except those aforementioned packages)" There's a subtle difference, and I would much rather go for the first one than the second one. Easier to communicate, easier to code, easier to understand and easier to build scripts for. And, while creation of an "impl" -package might keep third party developers happier, it will annoy our current core developer base by introducing an extra layer. After all, we have to deal with those 350+ classes all the time. However, we could make a cosmetic change by creating a JSPWiki API subproject, call it "jspwiki-api". It's really all about switching a period to a dash, but it does not create any further nesting levels (though since most developers these days do use IDEs, I don't think any extra levels are really a problem). So, we would have "org.apache.jspwiki" with the implementation, and "org.apache.jspwiki-api" for the API. Other possibility is to treat these in reverse, but I don't really like the "impl" or "private" names. There would need to be a better naming convention. I guess my main objection is that since the aim of this project is to produce the wikiengine itself, not the API, I really don't like the idea that we give the API the first-class citizen treatment and force the actual implementation to some second-tier packages. The org.apache.jspwiki -package should really be about the JSPWiki engine , not an abstract API class set. If we had set out to do to create an API definition, then yes, then obviously we would do things differently, but I don't think API creation has ever been more than just an issue on this tracker. If we wish to have a top-level package for the API, then perhaps a subproject with own dedicated package name might make most sense.
        Hide
        Andrew Jaquith added a comment -

        Craig: yes, you've summarized my proposal correctly.

        We might wait until JSPWiki 6 to file the JSR, though.

        Show
        Andrew Jaquith added a comment - Craig: yes, you've summarized my proposal correctly. We might wait until JSPWiki 6 to file the JSR, though.
        Hide
        Craig L Russell added a comment -

        > However, what I do not want is to have the package that the general public uses to be four levels deep. Having developers needing to use org.apache.jspwiki.api just sounds wrong to me. This is my non-starter.

        Just so I'm clear what I'm hearing: you could have the public api be org.apache.jspwiki with sub-packages as deep as you like; and the implementation org.apache.jspwiki.impl or org.apache.jspwiki.private similarly with sub-packages to separate different parts of the project. In two separate jar files.

        Of course, you could always file a JSR and get the javax.wiki name space. <ducks now>

        Show
        Craig L Russell added a comment - > However, what I do not want is to have the package that the general public uses to be four levels deep. Having developers needing to use org.apache.jspwiki.api just sounds wrong to me. This is my non-starter. Just so I'm clear what I'm hearing: you could have the public api be org.apache.jspwiki with sub-packages as deep as you like; and the implementation org.apache.jspwiki.impl or org.apache.jspwiki.private similarly with sub-packages to separate different parts of the project. In two separate jar files. Of course, you could always file a JSR and get the javax.wiki name space. <ducks now>
        Hide
        Andrew Jaquith added a comment -

        Craig: good to know what our constraints are with respect to naming. Sounds like you agree 2 jars is the right solution: 1 for the API and one for the private implementation.

        If both public APIs and "private" implementation code must be under the org.apache namespace, then I am not sure that it makes a lot of sense to have both a .jspwiki package and a .wiki package (for example).

        However, what I do not want is to have the package that the general public uses to be four levels deep. Having developers needing to use org.apache.jspwiki.api just sounds wrong to me. This is my non-starter.

        If anything, I'd prefer to invert things, so that the public API namespace is org.apache.jspwiki, and the private namespace is off of that: org.apache.jspwiki.private. We could put 'em in different source folders too, so that IDE developers (basically, just about everyone) have clearly delineated working areas.

        Perfect? No. But if all top-level options other than org.apache are closed off to us, then this may be the best we can do, while still accomplishing the desired separation between public APIs and private implementations.

        Janne, what do you think?

        Show
        Andrew Jaquith added a comment - Craig: good to know what our constraints are with respect to naming. Sounds like you agree 2 jars is the right solution: 1 for the API and one for the private implementation. If both public APIs and "private" implementation code must be under the org.apache namespace, then I am not sure that it makes a lot of sense to have both a .jspwiki package and a .wiki package (for example). However, what I do not want is to have the package that the general public uses to be four levels deep. Having developers needing to use org.apache.jspwiki.api just sounds wrong to me. This is my non-starter. If anything, I'd prefer to invert things, so that the public API namespace is org.apache.jspwiki, and the private namespace is off of that: org.apache.jspwiki.private. We could put 'em in different source folders too, so that IDE developers (basically, just about everyone) have clearly delineated working areas. Perfect? No. But if all top-level options other than org.apache are closed off to us, then this may be the best we can do, while still accomplishing the desired separation between public APIs and private implementations. Janne, what do you think?
        Hide
        Craig L Russell added a comment -

        To keep the api separate from the impl, you might consider defining two projects: the API and the impl project. Each would build its own jar file but from a programming perspective, you would only ever import the api packages and use the API jar.

        Just thinking out loud.

        Show
        Craig L Russell added a comment - To keep the api separate from the impl, you might consider defining two projects: the API and the impl project. Each would build its own jar file but from a programming perspective, you would only ever import the api packages and use the API jar. Just thinking out loud.
        Hide
        Craig L Russell added a comment -

        > What I am looking for here is that I strongly believe that API classes should be isolated in their own package hierarchy in order to provide a clear visual and logical separation of the implementation classes. It does not have to be called "org.apache.jspwiki.api" - it could also be called "org.jspwiki" or "org.apache.wiki" - whatever.

        If you're in Apache, you're in the apache name space: org.apache.jspwiki or org.apache.whateverWeChangeTheNameToNext.

        As far as I know, we're not talking about multiple independent implementations of a standard or common API. So having an org.apache.wiki interface doesn't sound right.

        But let's not continue on the thread of discussing keeping the com.ecyrd.jspwiki name space in Apache. That is a non-starter.

        Show
        Craig L Russell added a comment - > What I am looking for here is that I strongly believe that API classes should be isolated in their own package hierarchy in order to provide a clear visual and logical separation of the implementation classes. It does not have to be called "org.apache.jspwiki.api" - it could also be called "org.jspwiki" or "org.apache.wiki" - whatever. If you're in Apache, you're in the apache name space: org.apache.jspwiki or org.apache.whateverWeChangeTheNameToNext. As far as I know, we're not talking about multiple independent implementations of a standard or common API. So having an org.apache.wiki interface doesn't sound right. But let's not continue on the thread of discussing keeping the com.ecyrd.jspwiki name space in Apache. That is a non-starter.
        Hide
        Andrew Jaquith added a comment -

        I should have mentioned: in terms of emphasis, the public API will be more weighted towards interfaces, while the private implementations will be more weighted towards concrete classes.

        In general, the (mostly) interfaces in the org.apache.jspwiki API namespace should require fewer methods than the corresponding classes that we have today in com.ecyrd.jspwiki. We should strive for "clawing back" the interface to its minimal essence.

        For example, if you look at my WikiContext interface for 3.0, you'll see that it loses about a half-dozen methods compared to the 2.8-era WikiContext class. It has no hasAccess() method, and the horrible Command methods are gone.

        So, as we extract interfaces and pull things over to the public API namespace, we should be mindful of implementation-level methods that have crept in to suit the needs of one or two callers. Any method that just a small handful of callers should probably be regarded as an implementation method, and omitted from the public API.

        Show
        Andrew Jaquith added a comment - I should have mentioned: in terms of emphasis, the public API will be more weighted towards interfaces, while the private implementations will be more weighted towards concrete classes. In general, the (mostly) interfaces in the org.apache.jspwiki API namespace should require fewer methods than the corresponding classes that we have today in com.ecyrd.jspwiki. We should strive for "clawing back" the interface to its minimal essence. For example, if you look at my WikiContext interface for 3.0, you'll see that it loses about a half-dozen methods compared to the 2.8-era WikiContext class . It has no hasAccess() method, and the horrible Command methods are gone. So, as we extract interfaces and pull things over to the public API namespace, we should be mindful of implementation-level methods that have crept in to suit the needs of one or two callers. Any method that just a small handful of callers should probably be regarded as an implementation method, and omitted from the public API.
        Hide
        Andrew Jaquith added a comment -

        Janne,

        Your previous comment was very helpful. It illuminated several important points, which I either failed to understand, or you failed to communicate. That's why we have these discussions, right? To make our points clear, so that we may find common ground.

        In particular, I failed to appreciate your intent to keep an entire package tree under the .api package. My impression was that there would not be a hierarchy there, and that everything that developers needed to rely on would go into one flat namespace. That seemed messy. Ok. It's good that that's not what you meant.

        Now, I could fence with you a bit more about the fact that J2SE and J2EE are, in fact, NOT specifications and are actually APIs, but would distract from where we need to go, which is to figure out what we need to do.

        So, let's see if we can agree on the following principles:
        1. Specifying a public API – in an Apache package namespace – is a good and worthy goal
        2. Implementing the API – in a separate, "private" package namespace is desirable
        3. The namespaces should be distinct enough that developers should be able to tell what APIs are "public" and which ones are "private"
        4. It follows that the public interface and private implementations should not be in the same package hierarchy (your logic was persuasive...)
        5. The public interface and private implementations may be in the same source folder (though I'd like to see them separated...)

        With me so far? Ok, good. Here's what I propose:

        • Private implementations live on in the "com.ecyrd.jspwiki" package namespace
        • Public APIs move to the "org.apache.jspwiki" package namespace
        • We do not create a "org.apache.jspwiki.api" package – just snip the .api subpackage and move everything up a level
        • Create parallel packages under "org.apache.jspwiki.api" as needed. For example: .auth

        In essence, this creates two trees, one that is org.apache.jspwiki and the other, which is com.ecyrd.jspwiki (what we have now). The two would have parallel subpackage structures. Personally, I don't think we need to keep these in separate source folders, although we might want to package them into separate jars (jspwiki-api.jar + jspwiki-impl.jar?) at build-time.

        I think this is a nice solution. It has the benefit of being simple. The trick, of course, will be figuring out what types need to migrate from one tree to the other. Judicious use of the Extact Interface... refactoring tool will become an important skill.

        Reasonable?

        Show
        Andrew Jaquith added a comment - Janne, Your previous comment was very helpful. It illuminated several important points, which I either failed to understand, or you failed to communicate. That's why we have these discussions, right? To make our points clear, so that we may find common ground. In particular, I failed to appreciate your intent to keep an entire package tree under the .api package. My impression was that there would not be a hierarchy there, and that everything that developers needed to rely on would go into one flat namespace. That seemed messy. Ok. It's good that that's not what you meant. Now, I could fence with you a bit more about the fact that J2SE and J2EE are, in fact, NOT specifications and are actually APIs, but would distract from where we need to go, which is to figure out what we need to do. So, let's see if we can agree on the following principles: 1. Specifying a public API – in an Apache package namespace – is a good and worthy goal 2. Implementing the API – in a separate, "private" package namespace is desirable 3. The namespaces should be distinct enough that developers should be able to tell what APIs are "public" and which ones are "private" 4. It follows that the public interface and private implementations should not be in the same package hierarchy (your logic was persuasive...) 5. The public interface and private implementations may be in the same source folder (though I'd like to see them separated...) With me so far? Ok, good. Here's what I propose: Private implementations live on in the "com.ecyrd.jspwiki" package namespace Public APIs move to the "org.apache.jspwiki" package namespace We do not create a "org.apache.jspwiki.api" package – just snip the .api subpackage and move everything up a level Create parallel packages under "org.apache.jspwiki.api" as needed. For example: .auth In essence, this creates two trees, one that is org.apache.jspwiki and the other, which is com.ecyrd.jspwiki (what we have now). The two would have parallel subpackage structures. Personally, I don't think we need to keep these in separate source folders, although we might want to package them into separate jars (jspwiki-api.jar + jspwiki-impl.jar?) at build-time. I think this is a nice solution. It has the benefit of being simple. The trick, of course, will be figuring out what types need to migrate from one tree to the other. Judicious use of the Extact Interface... refactoring tool will become an important skill. Reasonable?
        Hide
        Murray Altheim added a comment -

        Janne,

        I have previously commented on this project in ways I thought were productive, and
        your reaction has at times been very negative. I'm sorry you thought my message
        was a rant, as it certainly wasn't intended as such. I wasn't trying to suggest that
        you or anyone else in the project has bad judgment, has made bad decisions, etc.
        Far from it. I have a great deal of respect for the people involved, and the quality of
        the work is always very high. I have not assumed the worst, and I tried to make
        that clear in my message: I stated that I was basing my understanding on what I
        have read of the messages passing through jspwiki-dev, as I do read each one.

        As for forking, the substantial amount of code that I've written that extends the
        functionality was not written as a fork, as it relies entirely on the existing APIs and
        existing base classes (e.g., WikiContext). I have not contributed that code because
        I currently do not have that legal option. I continue to explore the possibility of
        releasing it with management but that timeline and priority is not up to me. We
        just had a contract change and the question is again in the air (though I have at
        least verbal assurances from my manager on releasing IP, for what that's worth).

        I was reacting to what looks to be some very substantive changes in 3.0, both with
        the APIs (things that were classes are turning into APIs and vice-versa) as well as
        backend changes that will take me a lot of time to deal with since they also break
        the existing provider API (from what I can see). As you know I'm quite interested in
        using priha but even that will take a lot of time to deal with since I'll likely be
        integrating it with other systems.

        Both this message and previous ones were simply pleas for simplicity: when
        and where there is an option for a simpler design I am simply asking that the
        simpler approach be taken. When there is an option to completely break previous
        APIs that those decisions be taken with the knowledge that this will have a very
        substantial impact on existing users, some a lot more than others. I happen to
        be a somewhat special case because I have done a lot of extension work, but
        all that work is based on APIs or base classes that look to change or disappear.
        If that's not a cause for concern amongst this project team I'm not sure what
        might be. I'm probably not the only person to have used JSPWiki as part of an
        enterprise system. Anyone else that has may find migrating to 3.0 difficult.

        But please don't consider this a rant. I am not angry. I am not trying to spread
        fear, merely have a conversation. I hope to be able to fully test out the code
        against the work I've done previously, but as a lot of people my time available
        to do this is short. I'm hoping to have more in the new year. We've had a rather
        surreal last six months.

        And as to message length, I'm a very fast typist.

        Murray

        Show
        Murray Altheim added a comment - Janne, I have previously commented on this project in ways I thought were productive, and your reaction has at times been very negative. I'm sorry you thought my message was a rant, as it certainly wasn't intended as such. I wasn't trying to suggest that you or anyone else in the project has bad judgment, has made bad decisions, etc. Far from it. I have a great deal of respect for the people involved, and the quality of the work is always very high. I have not assumed the worst, and I tried to make that clear in my message: I stated that I was basing my understanding on what I have read of the messages passing through jspwiki-dev, as I do read each one. As for forking, the substantial amount of code that I've written that extends the functionality was not written as a fork, as it relies entirely on the existing APIs and existing base classes (e.g., WikiContext). I have not contributed that code because I currently do not have that legal option . I continue to explore the possibility of releasing it with management but that timeline and priority is not up to me. We just had a contract change and the question is again in the air (though I have at least verbal assurances from my manager on releasing IP, for what that's worth). I was reacting to what looks to be some very substantive changes in 3.0, both with the APIs (things that were classes are turning into APIs and vice-versa) as well as backend changes that will take me a lot of time to deal with since they also break the existing provider API (from what I can see). As you know I'm quite interested in using priha but even that will take a lot of time to deal with since I'll likely be integrating it with other systems. Both this message and previous ones were simply pleas for simplicity: when and where there is an option for a simpler design I am simply asking that the simpler approach be taken. When there is an option to completely break previous APIs that those decisions be taken with the knowledge that this will have a very substantial impact on existing users, some a lot more than others. I happen to be a somewhat special case because I have done a lot of extension work, but all that work is based on APIs or base classes that look to change or disappear. If that's not a cause for concern amongst this project team I'm not sure what might be. I'm probably not the only person to have used JSPWiki as part of an enterprise system. Anyone else that has may find migrating to 3.0 difficult. But please don't consider this a rant. I am not angry. I am not trying to spread fear, merely have a conversation. I hope to be able to fully test out the code against the work I've done previously, but as a lot of people my time available to do this is short. I'm hoping to have more in the new year. We've had a rather surreal last six months. And as to message length, I'm a very fast typist. Murray
        Hide
        Janne Jalkanen added a comment -

        Andrew,

        using J2SE and/or J2EE as examples is not valid, since they are specs and they are implemented by applications in a completely different hierarchy. For example, Tomcat implements the J2EE API using its own org.apache.catalina -hierarchy, and Sun implements J2SE in com.sun.* -hierarchy. Same goes with e.g. JCR, which is specified in the "javax.jcr." -hierarchy, but the actual implementation could be in "org.apache.jackrabbit." This provides a clear, visual separation for people when they are using the "official" API classes, and when they are using the implementation-specific classes. Remember, anything under "java.*" is official and won't change.

        We can sub-package the org.apache.jspwiki.api -package as needed, e.g. org.apache.jspwiki.api.acl to put the ACL stuff in it. It would essentially be a "root" package, not a generic grab-bag of things. We can design it to be a smart hierarchy with things grouped together logically and still keep it independent of any refactorings we do with the implementation classes. This would not be true if they were all under the same hierarchy.

        However, if we keep both the implementations and interfaces in the same package, logically and visually these are going to be equivalent for the developer. And, if we put all the implementations under .impl, then we have to put all of our 350+ classes under a hierarchy structure which starts with impl, essentially adding a layer of pain to us JSPWiki dev team, just so that we can keep a handful of classes in the main hierarchy.

        With the interfaces in a separate package, it is clear to the developer immediately when he sees the import-statements on the top of the file whether he is depending on internal classes.

        What I am looking for here is that I strongly believe that API classes should be isolated in their own package hierarchy in order to provide a clear visual and logical separation of the implementation classes. It does not have to be called "org.apache.jspwiki.api" - it could also be called "org.jspwiki" or "org.apache.wiki" - whatever.

        Show
        Janne Jalkanen added a comment - Andrew, using J2SE and/or J2EE as examples is not valid, since they are specs and they are implemented by applications in a completely different hierarchy. For example, Tomcat implements the J2EE API using its own org.apache.catalina -hierarchy, and Sun implements J2SE in com.sun.* -hierarchy. Same goes with e.g. JCR, which is specified in the "javax.jcr. " -hierarchy, but the actual implementation could be in "org.apache.jackrabbit. " This provides a clear, visual separation for people when they are using the "official" API classes, and when they are using the implementation-specific classes. Remember, anything under "java.*" is official and won't change. We can sub-package the org.apache.jspwiki.api -package as needed, e.g. org.apache.jspwiki.api.acl to put the ACL stuff in it. It would essentially be a "root" package, not a generic grab-bag of things. We can design it to be a smart hierarchy with things grouped together logically and still keep it independent of any refactorings we do with the implementation classes. This would not be true if they were all under the same hierarchy. However, if we keep both the implementations and interfaces in the same package, logically and visually these are going to be equivalent for the developer. And, if we put all the implementations under .impl, then we have to put all of our 350+ classes under a hierarchy structure which starts with impl, essentially adding a layer of pain to us JSPWiki dev team, just so that we can keep a handful of classes in the main hierarchy. With the interfaces in a separate package, it is clear to the developer immediately when he sees the import-statements on the top of the file whether he is depending on internal classes. What I am looking for here is that I strongly believe that API classes should be isolated in their own package hierarchy in order to provide a clear visual and logical separation of the implementation classes. It does not have to be called "org.apache.jspwiki.api" - it could also be called "org.jspwiki" or "org.apache.wiki" - whatever.
        Hide
        Janne Jalkanen added a comment -

        Murray - you are right. You shouldn't comment until you've actually checked out what has been done.

        We would rather deal with facts rather than suppositions, fears and assumptions. Whether MySQL is more difficult to install DSpace or vice versa is completely and utterly irrelevant with respect to JSPWiki.

        You're just assuming that we're going to make things difficult for you. This is wrong. As you well know, making things simple is very complicated and difficult and time-consuming, and that is the discussion you are seeing.

        Murray, you are a committer to this project. You know very well the price of forking - you cannot assume that we'll keep everything the same to please you. If you had lots of invasive code you wanted to share, you should've discussed it with everyone else, and then started to commit it - because that is what committers do.

        Please stop assuming the worst and just start helping us, mmkay? We are all under time pressure, but if you can find the time to write long rants, you have the time to check out the code.

        Show
        Janne Jalkanen added a comment - Murray - you are right. You shouldn't comment until you've actually checked out what has been done. We would rather deal with facts rather than suppositions, fears and assumptions. Whether MySQL is more difficult to install DSpace or vice versa is completely and utterly irrelevant with respect to JSPWiki. You're just assuming that we're going to make things difficult for you. This is wrong. As you well know, making things simple is very complicated and difficult and time-consuming, and that is the discussion you are seeing. Murray, you are a committer to this project. You know very well the price of forking - you cannot assume that we'll keep everything the same to please you. If you had lots of invasive code you wanted to share, you should've discussed it with everyone else, and then started to commit it - because that is what committers do . Please stop assuming the worst and just start helping us, mmkay? We are all under time pressure, but if you can find the time to write long rants, you have the time to check out the code.
        Hide
        Murray Altheim added a comment -

        Janne,

        I'm not going to be able to comment conclusively until I have a chance to actually download and
        try out the 3.0 code, but from what I can see I have a sneaking suspicion that a large number of
        plugins I've developed and perhaps the entire edifice of the Assertion Framework will become
        impossible to migrate forward. There seem to be so many radical changes to the design, to the
        API approach, and while all this is in mind of being improvements, the complexity of JSPWiki 3.0
        compared to previous versions for the developer is going to be either a real turn-on for some
        (who have enormous amounts of time to invest and love tinkering) and a complete turn-off for
        others. I'm frankly going to have to find a huge amount of time to simply digest what has
        happened, and as you may guess that's been short lately.

        I know you think my comments in this regard are just sour grapes, but I'm hoping (and I say
        this sincerely) that 3.0 hasn't become impossible for me to use, both in terms of breaking
        compatibility with previous extensions I've developed, in terms of the potential impossibility
        of implementing things that used to be simple (JSPs are simple), and in terms of the learning
        curve of technologies now required to develop for JSPWiki. I'm not talking here about renaming
        classes.

        Of course, there are separate issues for those migrating from previous versions and those
        coming new to 3.0. There's the changes in installation requirements for deployers. I really
        love the fact that JSPWiki is a really simple install, and I know that's been an enormous
        selling point for the project. By contrast, installing DSpace is a pain for a lot of people because
        it requires knowledge and installation of PostgresQL or MySQL. Not a big deal for some but
        an impenetrable wall for others. A lot of people are driven away by complexity.

        Now, I also know that we've already committed to this course. It just seems that the project is
        heading down the road of becoming so complex that it loses the appeal of being capable of
        being hacked by anyone who doesn't understand some rather complex technologies. What I'm
        saying is that I fear you may have lost me with 3.0. That may be my own failing, but you might
        consider that there are others like me. Where the project can remain simple (and I know some
        of the changes you're considering are simplifications, by adding someone else's complexity)
        I'm all for it.

        Thanks for listening.

        Murray

        Show
        Murray Altheim added a comment - Janne, I'm not going to be able to comment conclusively until I have a chance to actually download and try out the 3.0 code, but from what I can see I have a sneaking suspicion that a large number of plugins I've developed and perhaps the entire edifice of the Assertion Framework will become impossible to migrate forward. There seem to be so many radical changes to the design, to the API approach, and while all this is in mind of being improvements, the complexity of JSPWiki 3.0 compared to previous versions for the developer is going to be either a real turn-on for some (who have enormous amounts of time to invest and love tinkering) and a complete turn-off for others. I'm frankly going to have to find a huge amount of time to simply digest what has happened, and as you may guess that's been short lately. I know you think my comments in this regard are just sour grapes, but I'm hoping (and I say this sincerely) that 3.0 hasn't become impossible for me to use, both in terms of breaking compatibility with previous extensions I've developed, in terms of the potential impossibility of implementing things that used to be simple (JSPs are simple), and in terms of the learning curve of technologies now required to develop for JSPWiki. I'm not talking here about renaming classes. Of course, there are separate issues for those migrating from previous versions and those coming new to 3.0. There's the changes in installation requirements for deployers. I really love the fact that JSPWiki is a really simple install, and I know that's been an enormous selling point for the project. By contrast, installing DSpace is a pain for a lot of people because it requires knowledge and installation of PostgresQL or MySQL. Not a big deal for some but an impenetrable wall for others. A lot of people are driven away by complexity. Now, I also know that we've already committed to this course. It just seems that the project is heading down the road of becoming so complex that it loses the appeal of being capable of being hacked by anyone who doesn't understand some rather complex technologies. What I'm saying is that I fear you may have lost me with 3.0. That may be my own failing, but you might consider that there are others like me. Where the project can remain simple (and I know some of the changes you're considering are simplifications, by adding someone else's complexity) I'm all for it. Thanks for listening. Murray
        Hide
        Andrew Jaquith added a comment -

        Janne – let's start with the things we agree on.

        I agree that there are a few classes in the top-level (ecyrd) package that need to be moved to sub-packages. Moving, for example, TextUtil to the .util package was a good thing. There will be others. So, let's agree that is a good thing. But it's not really the core issue here.

        I also agree that renaming is fairly trivial. My point was that we strive for simplicity where we can get it. A straight rename from com.ecyrd.jspwiki to org.apache.jspwiki would be a good goal, even though in practice any third party will need to do some work. I'd just prefer to make it easier.

        As for creating a separate source folder for the API classes, it sounds like this is something we are both indifferent about, but are open to.

        Now, to the core issue. I am not sure how you can argue that today's top-level package is a mess, with too much stuff in it – and then suggest what we really need is a single "stable" .api package with – guess what? – lots of stuff in it. Other stuff, to be sure, but still things that are only related in the sense that we declare them to be stable. How do you manage what goes into the top-level package, and where do you stop? Does FilterException belong there? No, it probably belongs in the .filter package. As for additions, let's say we decide UserDatabase needs to be a "stable" API. Do you move that to the .api package? What about the RSS generators? The WikiActionBean interface? After a while that .api package will get pretty crowded too. See what I mean? You're just replacing one bag of unrelated stuff with another.

        By contrast, the "package hierarchy-plus-interface" paradigm, supplemented by additional .impl subpackages, is a well-understood convention. The package hierarchy itself gives developers contextual information.

        I do not understand how "saying interfaces are stable" could be a bad thing. They are supposed to be stable. This is what Bloch has been saying for years: http://lcsd05.cs.tamu.edu/slides/keynote.pdf

        I gave you two specific examples of projects that used this convention: slf4j and the J2EE packages. Let me give you 2 more: the J2SE itself (e.g., Collections API), and Stripes.

        Can you give me one example of a Java project that uses the approach you suggest?

        Show
        Andrew Jaquith added a comment - Janne – let's start with the things we agree on. I agree that there are a few classes in the top-level (ecyrd) package that need to be moved to sub-packages. Moving, for example, TextUtil to the .util package was a good thing. There will be others. So, let's agree that is a good thing. But it's not really the core issue here. I also agree that renaming is fairly trivial. My point was that we strive for simplicity where we can get it. A straight rename from com.ecyrd.jspwiki to org.apache.jspwiki would be a good goal, even though in practice any third party will need to do some work. I'd just prefer to make it easier. As for creating a separate source folder for the API classes, it sounds like this is something we are both indifferent about, but are open to. Now, to the core issue. I am not sure how you can argue that today's top-level package is a mess, with too much stuff in it – and then suggest what we really need is a single "stable" .api package with – guess what? – lots of stuff in it. Other stuff, to be sure, but still things that are only related in the sense that we declare them to be stable. How do you manage what goes into the top-level package, and where do you stop? Does FilterException belong there? No, it probably belongs in the .filter package. As for additions, let's say we decide UserDatabase needs to be a "stable" API. Do you move that to the .api package? What about the RSS generators? The WikiActionBean interface? After a while that .api package will get pretty crowded too. See what I mean? You're just replacing one bag of unrelated stuff with another. By contrast, the "package hierarchy-plus-interface" paradigm, supplemented by additional .impl subpackages, is a well-understood convention. The package hierarchy itself gives developers contextual information. I do not understand how "saying interfaces are stable" could be a bad thing. They are supposed to be stable. This is what Bloch has been saying for years: http://lcsd05.cs.tamu.edu/slides/keynote.pdf I gave you two specific examples of projects that used this convention: slf4j and the J2EE packages. Let me give you 2 more: the J2SE itself (e.g., Collections API), and Stripes. Can you give me one example of a Java project that uses the approach you suggest?
        Hide
        Janne Jalkanen added a comment -

        I disagree. I personally hate the ".spi" -paradigm, since it results in a situation where pretty much everything is a mess and could or could not be stable. It also makes it very, very complicated to figure out the API. And you never quite know exactly which APIs you are supposed to trust on, since we've got also a bunch of interfaces which might or might not be stable. We do need interfaces for our own abstractions without revealing them to the developer too, and if we say that interfaces are stable, then well, then we'll end up doing a lot of casting.

        Putting everything in a single package which we agree to be stable makes it clear for everyone what we can and cannot do with it. It is not necessarily clear to the developer which JAR file his class comes from, so he might be surprised to find out that half of the interfaces he is coding on just are not reliable. We can, of course, put them in a separate source directory as well to ease management, but I would still keep them in the dedicated package. In addition, the dedicated package allows separate version numbering tracking for API and the core code.

        I also dislike the fact that we've got stuff in the "root" directory (which quite a few people have also pointed out on the mailing lists) - it's really just a collection of miscallaneous classes about which we don't know where to put them. I would greatly prefer if they were moved into a ".core" package to signify what they really mean. This is quite commonly done in large projects.

        It is most definitely not an abstraction; they're the same interface classes, but in a different package. Abstraction implies layering, which is not true.

        There is nothing very complicated in renaming the packages, so making it easier is not a very strong argument.

        Show
        Janne Jalkanen added a comment - I disagree. I personally hate the ".spi" -paradigm, since it results in a situation where pretty much everything is a mess and could or could not be stable. It also makes it very, very complicated to figure out the API. And you never quite know exactly which APIs you are supposed to trust on, since we've got also a bunch of interfaces which might or might not be stable. We do need interfaces for our own abstractions without revealing them to the developer too, and if we say that interfaces are stable, then well, then we'll end up doing a lot of casting. Putting everything in a single package which we agree to be stable makes it clear for everyone what we can and cannot do with it. It is not necessarily clear to the developer which JAR file his class comes from, so he might be surprised to find out that half of the interfaces he is coding on just are not reliable. We can, of course, put them in a separate source directory as well to ease management, but I would still keep them in the dedicated package. In addition, the dedicated package allows separate version numbering tracking for API and the core code. I also dislike the fact that we've got stuff in the "root" directory (which quite a few people have also pointed out on the mailing lists) - it's really just a collection of miscallaneous classes about which we don't know where to put them. I would greatly prefer if they were moved into a ".core" package to signify what they really mean. This is quite commonly done in large projects. It is most definitely not an abstraction; they're the same interface classes, but in a different package. Abstraction implies layering, which is not true. There is nothing very complicated in renaming the packages, so making it easier is not a very strong argument.
        Hide
        Andrew Jaquith added a comment -

        Some comments on the .api package:

        • I do NOT like the idea of creating a separate org.apache.jspwiki.api package. That seems like one abstraction too far. It is awkward and unnnatural, and it just looks funny. You do not see this in slf4j or the J2EE servlet packages. What you see (in those examples) are interfaces everywhere, and sub-packages called .spi, or .impl or similar that contain the actual implementations.
        • I DO like the idea of "coding to the interface" – making sure we create well-defined interfaces that substitute for what are, today, concrete classes.

        So, I think we make should change our approach slightly.

        First, the current interface classes in the proposed org.apache.jspwiki.api package should be moved to org.apache.jspwiki. We should start replacing concrete implementations in the code with the interfaces immediately. Janne has already done this with WikiPage; the next one should be WIkiContext (the one in the top-level com.ecyrd.jspwiki package is the correct one to use.

        Second, the contract we should follow, at least in the top-level org.ecyrd.jspwiki package, should be this: any interfaces are guaranteed to be the "permanent" API. Concrete implementations (example: JCRWikiPage) will be in .spi or .impl subpackages.

        Third, we should consider creating a separate source folder (proposed name: api) that creates a separate jspwiki-api.jar. Concrete implementations go in the regular jspwiki.jar. I would be happy to make the modifications to the Ant script and Eclipse workspace files to do this.

        The advantage of this approach is that it would make moving to the apache namespace fairly easy: just change com.ecyrd.jspwiki to org.apache.jspwiki, in most cases. There would need to be some cases where callers might need to use a factory class instead of constructors, but those should be fairly easy to figure out.

        Show
        Andrew Jaquith added a comment - Some comments on the .api package: I do NOT like the idea of creating a separate org.apache.jspwiki.api package. That seems like one abstraction too far. It is awkward and unnnatural, and it just looks funny. You do not see this in slf4j or the J2EE servlet packages. What you see (in those examples) are interfaces everywhere, and sub-packages called .spi, or .impl or similar that contain the actual implementations. I DO like the idea of "coding to the interface" – making sure we create well-defined interfaces that substitute for what are, today, concrete classes. So, I think we make should change our approach slightly. First, the current interface classes in the proposed org.apache.jspwiki.api package should be moved to org.apache.jspwiki. We should start replacing concrete implementations in the code with the interfaces immediately. Janne has already done this with WikiPage; the next one should be WIkiContext (the one in the top-level com.ecyrd.jspwiki package is the correct one to use. Second, the contract we should follow, at least in the top-level org.ecyrd.jspwiki package, should be this: any interfaces are guaranteed to be the "permanent" API. Concrete implementations (example: JCRWikiPage) will be in .spi or .impl subpackages. Third, we should consider creating a separate source folder (proposed name: api) that creates a separate jspwiki-api.jar. Concrete implementations go in the regular jspwiki.jar. I would be happy to make the modifications to the Ant script and Eclipse workspace files to do this. The advantage of this approach is that it would make moving to the apache namespace fairly easy: just change com.ecyrd.jspwiki to org.apache.jspwiki, in most cases. There would need to be some cases where callers might need to use a factory class instead of constructors, but those should be fairly easy to figure out.
        Hide
        Janne Jalkanen added a comment -

        I think we should wait for a while until we're fairly certain that we don't have to merge a lot of stuff from 2.8 branch anymore. And after Andrew has merged in the Stripes branch (because I'm sure he would hate having to merge all those changes back and forth).

        Show
        Janne Jalkanen added a comment - I think we should wait for a while until we're fairly certain that we don't have to merge a lot of stuff from 2.8 branch anymore. And after Andrew has merged in the Stripes branch (because I'm sure he would hate having to merge all those changes back and forth).
        Hide
        Harry Metske added a comment -

        When would be an appropriate moment to do this ?
        What approach ?
        I guess it requires some coordination before committing ?

        Show
        Harry Metske added a comment - When would be an appropriate moment to do this ? What approach ? I guess it requires some coordination before committing ?
        Hide
        Janne Jalkanen added a comment -

        Yes, it will break all of the existing plugins. Which is why we want to do this in a relatively controlled fashion during a major upgrade.

        Show
        Janne Jalkanen added a comment - Yes, it will break all of the existing plugins. Which is why we want to do this in a relatively controlled fashion during a major upgrade.
        Hide
        Nascif Abousalh-Neto added a comment -

        This has the potential to break all existing the plugins.

        Show
        Nascif Abousalh-Neto added a comment - This has the potential to break all existing the plugins.
        Hide
        Janne Jalkanen added a comment -

        Updated dependency.

        I am not at all sure about moving revision histories, as those contain code under LGPL. Can we do that?

        Show
        Janne Jalkanen added a comment - Updated dependency. I am not at all sure about moving revision histories, as those contain code under LGPL. Can we do that?
        Hide
        Neil Miller added a comment -

        Recommend this be made dependent on JSPWIKI-36 (Transfer JSPWiki 2.6 source to Apache SVN). At least, that is, if you're going to be transferring revision histories over into SVN, which I would also recommend doing.

        Show
        Neil Miller added a comment - Recommend this be made dependent on JSPWIKI-36 (Transfer JSPWiki 2.6 source to Apache SVN). At least, that is, if you're going to be transferring revision histories over into SVN, which I would also recommend doing.

          People

          • Assignee:
            Janne Jalkanen
            Reporter:
            Janne Jalkanen
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development