Re: [forge-dev] invoking project classes

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(a)gmail.com&gt;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(a)gmail.com&gt; 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(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" >> > > > _______________________________________________ > 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"