[forge-dev] invoking project classes

[Paul Bakker]

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