Re: [forge-dev] invoking project classes

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