[forge-dev] invoking project classes

[Lincoln Baxter, III]

Use the Component "Brainstorming"

On Wed, Mar 30, 2011 at 12:32 PM, Lincoln Baxter, III <
lincolnbaxter at gmail.com> wrote:

> Paul, that's actually a very clever solution for this issue. Could you add
> an issue in JIRA? I think I'd like to provide some kind of wrapper around
> this functionality or at least consider it. Let's track this issue so we
> don't forget.
>
> ~Lincoln
>
>
> On Wed, Mar 30, 2011 at 5:49 AM, Paul Bakker <paul.bakker.nl at gmail.com>wrote:
>
>> For the Arquillian plugin I will just implement it another way for now.
>> This small feature doesn't justify adding something large to the core like
>> this.
>>
>> For the plugin I now just generate a new class with a main method to the
>> project's test-source folder. After that I use an mvn exec:java to run the
>> class. It's less ideal because the plugin now adds a user visible utility
>> class to the project, but it's not really a problem I believe. The exporter
>> class is also runnable outside of Forge, so that's good too.
>>
>> Paul
>>
>>
>>
>> On Tue, Mar 29, 2011 at 11:04 PM, Lincoln Baxter, III <
>> lincolnbaxter at gmail.com> wrote:
>>
>>> 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"
>>>
>>
>>
>> _______________________________________________
>> 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"
>



-- 
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/20110330/20328cd9/attachment-0001.html