[forge-dev] invoking project classes

Lincoln Baxter, III lincolnbaxter at gmail.com
Wed Mar 30 12:32:27 EDT 2011


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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/forge-dev/attachments/20110330/32d739e0/attachment.html 


More information about the forge-dev mailing list