Since we've discussed already about the mount points and the reference
in NoBeanAvailableForInjectionException and PaxWicketInjector are only a
documentation reference (which could be removed) we're left with the
following three dependencies:
import org.apache.wicket.Application;
Application.get().getApplicationKey();
import org.apache.wicket.Page
import org.apache.wicket.PageParameters;
public interface PageFactory<T extends Page> {
Class<T> getPageClass();
T createPage(PageParameters params);
}
The question now: How often will they change (how often will we have to
release a major version of PW no longer backward compatible in this case).
Maybe just a feeling, but my guts are crying at me that if those classes and
their usage changes it would be definitely a good idea to break backward
compatibility and release another major release of PW. In addition I don't
think this will happen too often (had happened by now). WDYT?
Kind regards,
Andreas
On Wed, Jul 27, 2011 at 23:44, Brian Topping <[email protected]> wrote:
> Hi Andreas,
>
> Never worry about me anyway, I'm patient.
>
> Here's what I was looking at in the API folder:
>
> Targets
> String 'org.apache.wicket'
> Found usages (8 usages)
> InjectorHolder.java (1 usage)
> (21: 8) import org.apache.wicket.Application;
> MountPointInfo.java (1 usage)
> (18: 8) import
> org.apache.wicket.request.target.coding.IRequestTargetUrlCodingStrategy;
> NoBeanAvailableForInjectionException.java (1 usage)
> (19: 55) * Since the {@link
> PaxWicketInjector#onInstantiation(org.apache.wicket.Component)} method does
> not have a return value
> PageFactory.java (2 usages)
> (18: 8) import org.apache.wicket.Page;
> (19: 8) import org.apache.wicket.PageParameters;
> PageMounter.java (2 usages)
> (20: 8) import org.apache.wicket.Page;
> (21: 8) import
> org.apache.wicket.request.target.coding.IRequestTargetUrlCodingStrategy;
> PaxWicketInjector.java (1 usage)
> (18: 8) import org.apache.wicket.Component;
>
>
> This is from org.ops4j.pax.wicket.api. Am I on the wrong path?
>
> Cheers, B
>
> On Jul 27, 2011, at 4:17 PM, Andreas Pieber wrote:
>
> Hey Brian,
>
> Sorry for the short answer but I'm more the kind of early bird, so no
> longer in front of my PC.
>
> Just one point here: y do you think that? The plain api in the api package
> does not really depends on wicket. The util and the internal part will be
> splitted into the impls (and the inject components). I have not tried by now
> but I don't see any problems. Afaik without the code in front of me the api
> is only dependent on the page class which is not likely to change and mount
> part will be splitted. Anything i've missed?
>
> Btw, no problem at picking it up! Just thought it would be easier after 0.8
> is finished :-)
>
> I'll write a full answer in about 6 hours after a little bit of sleep :-)
>
> Kind regards, Andreas
> On Jul 27, 2011 9:18 PM, "Brian Topping" <[email protected]> wrote:
> > Hi Andreas,
> >
> > On Jul 27, 2011, at 1:03 AM, Andreas Pieber wrote:
> >
> >> wicket-bundle-parent as osginized wicket (removed from service)
> >> pw-api
> >> pw-14-impl
> >> pw-15-impl
> >> pw-spring
> >> pw-aries
> >> pw-osgi (to come)
> >> pw-geronimo (to come)
> >
> > Ok, unless I'm missing the boat, this won't work. Problem is a bunch of
> the API interfaces depend on Wicket, which of course is going to vary
> between implementations.
> >
> > Since it doesn't make a lot of sense to have separate API projects, I'm
> going to duplicate them across the implementation projects until we have a
> chance to consider it more completely.
> >
> > I just found the IRC channel, will be on there as I can...
> >
> > :B
> _______________________________________________
> general mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/general
>
>
>
> _______________________________________________
> general mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/general
>
>
_______________________________________________
general mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/general
