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(a)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(a)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(a)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(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/forge-dev
>
>
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev