> 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

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

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

Use the Component "Brainstorming" On Wed, Mar 30, 2011 at 12:32 PM, Lincoln Baxter, III < lincolnbaxter(a)gmail.com&gt; wrote: > 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" > -- 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