Re: [forge-dev] invoking project classes

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&gt;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&gt; 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&gt; 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 > > -- Lincoln Baxter, III http://ocpsoft.com http://scrumshark.com "Keep it Simple"