Makes sense, guys--back to the peanut gallery for me. :) Matt
On Mon, Mar 26, 2012 at 4:36 PM, Mark Struberg <[email protected]> wrote: > 'Core' means that this are all things which will not only run in Java EE but > also in Java SE. This includes end-user functionality as well as Extension > programmer tools. We just need to put them into different packages. Core just > means that we don't force any additional dependencies on our users. > > The reason I don't like to split those things out into own jars is that it > soon gets really complicated to get the modularity right without restricting > ourselfs too much. > > > LieGrue, > strub > > > ----- Original Message ----- >> From: Jason Porter <[email protected]> >> To: [email protected]; [email protected] >> Cc: >> Sent: Monday, March 26, 2012 11:07 PM >> Subject: Re: [jira] [Created] (DELTASPIKE-129) re-visit visibility of >> AnnotationBuilder, ImmutableInjectionPoint, InjectableMethod and >> ParameterValueRedefiner >> >> It could, I sort of envisioned that's what Core was for. >> >> On Mon, Mar 26, 2012 at 15:01, Matt Benson <[email protected]> wrote: >> >>> Could it be that certain classes belong in some DS artifact that is >>> meant to serve as a toolbox for extension authors, then? >>> >>> Matt >>> >>> On Sun, Mar 25, 2012 at 1:40 PM, Jason Porter >> <[email protected]> >>> wrote: >>> > For now, the wiki is as good as anywhere else. >>> > >>> > Sent from my iPhone >>> > >>> > On Mar 25, 2012, at 12:03, Pete Muir <[email protected]> wrote: >>> > >>> >> Ok, I see that they are not used. So, what is the objection to >> these >>> classes? No clear use case? If so, where do I document the use cases? >>> >> >>> >> IMO they are all useful things for extension authors. >>> >> >>> >> On 25 Mar 2012, at 18:15, Pete Muir wrote: >>> >> >>> >>> Maybe this is just a cultural mismatch. Do Apache projects >> expect >>> people to rely on the "API" packages and Implementation packages >> when >>> writing code? >>> >>> >>> >>> Anyway, this goes back to my original question. How do you >> reduce the >>> visibility of these classes without affecting the API. Other classes expose >>> them via methods, so it's not as simple as "just reduce the >> visibility"... >>> >>> >>> >>> On 25 Mar 2012, at 18:12, Gerhard Petracek wrote: >>> >>> >>> >>>> imo they shouldn't be part of the api and i'm not >> sure if they fit in >>> the >>> >>>> spi package, because you don't need them to customize >> deltaspike. >>> >>>> they are just helpers which are even quite special for >> extensions >>> authors. >>> >>>> >>> >>>> regards, >>> >>>> gerhard >>> >>>> >>> >>>> >>> >>>> >>> >>>> 2012/3/25 Pete Muir <[email protected]> >>> >>>> >>> >>>>> Yes, this is definitely all squarely aimed at >> extension authors and >>> not >>> >>>>> end user apps IMO. >>> >>>>> >>> >>>>> On 25 Mar 2012, at 18:03, Mark Struberg wrote: >>> >>>>> >>> >>>>>> Is this useful for Extension implementers? If so >> we might think >>> about >>> >>>>> putting them into spi packages? >>> >>>>>> >>> >>>>>> LieGrue, >>> >>>>>> strub >>> >>>>>> >>> >>>>>> >>> >>>>>> >>> >>>>>> ----- Original Message ----- >>> >>>>>>> From: Pete Muir <[email protected]> >>> >>>>>>> To: [email protected] >>> >>>>>>> Cc: >>> >>>>>>> Sent: Sunday, March 25, 2012 6:36 PM >>> >>>>>>> Subject: Re: [jira] [Created] (DELTASPIKE-129) >> re-visit visibility >>> of >>> >>>>> AnnotationBuilder, ImmutableInjectionPoint, >> InjectableMethod and >>> >>>>> ParameterValueRedefiner >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> On 25 Mar 2012, at 17:30, Gerhard Petracek >> wrote: >>> >>>>>>> >>> >>>>>>>> hi pete, >>> >>>>>>>> >>> >>>>>>>> that would be possible e.g. with >> AnnotationBuilder. however, it >>> isn't >>> >>>>>>>> possible with all of them. >>> >>>>>>> >>> >>>>>>> Why? >>> >>>>>>> >>> >>>>>>>> -> we already moved internal helpers to >>> >>>>>>>> org.apache.deltaspike.core.util >>> >>>>>>>>> if< we need them in the api-module. >>> >>>>>>>> they might not provide a stable api (over >> time) or are quite >>> special. >>> >>>>>>>> we moved them there to remove the >> visibility via an organizational >>> >>>>>>> approach. >>> >>>>>>> >>> >>>>>>> I have no problem with this approach. >>> >>>>>>> >>> >>>>>>> Perhaps you could expand on what you mean here >> then? Do you mean >>> extract >>> >>>>>>> interfaces from these classes and move the >> implementation to core? >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> >>> >>>>>>> I can't see how you can reduce the >> visibility without changing the >>> API? >>> >>>>>>> >>> >>>>>>>> >>> >>>>>>>> regards, >>> >>>>>>>> gerhard >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> >>> >>>>>>>> 2012/3/25 Pete Muir >> <[email protected]> >>> >>>>>>>> >>> >>>>>>>>> I assume you mean the visibility of >> the constructors of >>> >>>>>>> AnnotationBuilder, >>> >>>>>>>>> ImmutableInjectioPoint, >> InjectableMethod, and ParameterValue? >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> Begin forwarded message: >>> >>>>>>>>> >>> >>>>>>>>>> From: "Gerhard Petracek >> (Created) (JIRA)" >>> >>>>>>> <[email protected]> >>> >>>>>>>>>> Subject: [jira] [Created] >> (DELTASPIKE-129) re-visit visibility >>> of >>> >>>>>>>>> AnnotationBuilder, >> ImmutableInjectionPoint, InjectableMethod and >>> >>>>>>>>> ParameterValueRedefiner >>> >>>>>>>>>> Date: 25 March 2012 16:39:27 >> GMT+01:00 >>> >>>>>>>>>> To: >> [email protected] >>> >>>>>>>>>> >>> >>>>>>>>>> re-visit visibility of >> AnnotationBuilder, >>> ImmutableInjectionPoint, >>> >>>>>>>>> InjectableMethod and >> ParameterValueRedefiner >>> >>>>>>>>>> >>> >>>>>>>>> >>> >>>>>>> >>> >>>>> >>> >> --------------------------------------------------------------------------------------------------------------- >>> >>>>>>>>>> >>> >>>>>>>>>> Key: DELTASPIKE-129 >>> >>>>>>>>>> URL: >>> >>>>>>>>> >> https://issues.apache.org/jira/browse/DELTASPIKE-129 >>> >>>>>>>>>> Project: DeltaSpike >>> >>>>>>>>>> Issue Type: Task >>> >>>>>>>>>> Components: Core >>> >>>>>>>>>> Affects Versions: 0.1-incubating >>> >>>>>>>>>> Reporter: Gerhard Petracek >>> >>>>>>>>>> Assignee: Jason Porter >>> >>>>>>>>>> Fix For: 0.2-incubating >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>>> ... since those classes aren't >> intended to be used by users, we >>> >>>>>>> should >>> >>>>>>>>> re-visit them. >>> >>>>>>>>>> if we can't keep them >> package-private, we could move them to >>> >>>>>>> the >>> >>>>>>>>> util-package (like we did with >> ClassDeactivation now >>> >>>>>>> ClassDeactivationUtils) >>> >>>>>>>>>> >>> >>>>>>>>>> -- >>> >>>>>>>>>> This message is automatically >> generated by JIRA. >>> >>>>>>>>>> If you think it was sent >> incorrectly, please contact your JIRA >>> >>>>>>>>> administrators: >>> >>>>>>>>> >>> >>>>>>> >>> >>>>> >>> https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa >>> >>>>>>>>>> For more information on JIRA, see: >>> >>>>>>>>> http://www.atlassian.com/software/jira >>> >>>>>>>>>> >>> >>>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>> >>> >>>>> >>> >>>>> >>> >>> >>> >> >>> >> >> >> >> -- >> Jason Porter >> http://lightguard-jp.blogspot.com >> http://twitter.com/lightguardjp >> >> Software Engineer >> Open Source Advocate >> Author of Seam Catch - Next Generation Java Exception Handling >> >> PGP key id: 926CCFF5 >> PGP key available at: keyserver.net, pgp.mit.edu >>
