[forge-dev] invoking project classes

Lincoln Baxter, III lincolnbaxter at gmail.com
Tue Mar 29 17:04:56 EDT 2011


I agree with you. But if someone wants to work on this, I'm not going to
stop them :) It need only be another plugin.

No use-cases come to mind right away, but I'm sure there's use.

~Lincoln

On Tue, Mar 29, 2011 at 4:45 PM, Paul Bakker <paul.bakker.nl at gmail.com>wrote:

> Before we start on something large like this (it's far from trivial to get
> this right) I think we should think about cases where we would really need
> it to decide if it's worth the time at this moment. The export feature in
> the Arquillian plugin isn't important enough to start this work I think.
> It's a useful feature, but not a showstopper. Maybe it's better to first
> stabilize and finish more core features that 99% of the users will use.
>
> Any other cases where this is needed at this moment?
>
> Paul
>
> On Tue, Mar 29, 2011 at 7:52 PM, Lincoln Baxter, III <
> lincolnbaxter at gmail.com> wrote:
>
>> We can work on prototyping this feature in Forge. This is within the forge
>> Vision, but needs to be done carefully. Maven has some tools for getting
>> information about a project's dependencies and deliverables. See the
>> MavenDependencyFacet and RepositoryLookup classes. The MavenSystemSession
>> class in RepositoryLookup has methods for reading a project POM. Perhaps we
>> could leverage those. Although, wouldn't this kind of Export better be
>> handled by the test framework itself, since it is already classloading
>> everything?
>>
>> ~Lincoln
>>
>>
>> On Tue, Mar 29, 2011 at 10:36 AM, Max Rydahl Andersen <
>> max.andersen at redhat.com> wrote:
>>
>>> > I'm working on a feature in the Arquillian plugin that Dan asked about,
>>> which is to be able to export @Deployments that are part of the project's
>>> tests. To do this I need to invoke the static method on a test class to
>>> create the Archive that has to be exported.
>>>
>>> Not only do you need access to the method you need the full classpath
>>> initialized for the project for it work.
>>>
>>> > The problem is that is seems to be impossible to load a class that is
>>> in the user's project, although I already have an instance of the JavaSource
>>> object that describes the class. I believe it would be best to not rely on
>>> the question if the user's project has been compiled or not. So what should
>>> happen is the following:
>>>
>>> > -Compile the class based on the JavaSource object
>>> > -(optionally) Create a temporarily .class object
>>> > -Load the class
>>> > -(optionally) instantiate it
>>> >
>>> > I guess this is something that other plugins might need too in the
>>> future, so it would be better to find a reusable solution instead of hacking
>>> my way around it.
>>>
>>>
>>> yeah, Dan asked the same for eclipse tooling and I don't really have a
>>> good answer beyond creating an isolated classloader
>>> that loads the users full classpath and execute (optimally under a
>>> security manager to avoid too many accidents).
>>>
>>> /max
>>> http://about.me/maxandersen
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> forge-dev mailing list
>>> forge-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>
>>
>>
>> --
>> Lincoln Baxter, III
>> http://ocpsoft.com
>> http://scrumshark.com
>> "Keep it Simple"
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
>


-- 
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20110329/78af1402/attachment.html 


More information about the forge-dev mailing list