[forge-dev] invoking project classes

Paul Bakker paul.bakker.nl at gmail.com
Tue Mar 29 16:45:24 EDT 2011


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


More information about the forge-dev mailing list