(Copying forge-dev)<br><br>Agreed. I&#39;ve put this on the roadmap for Alpha4. We have a lot of work to do in this regard.<br><br>~Lincoln<br><br><div class="gmail_quote">On Sun, Apr 3, 2011 at 4:46 PM, Paul Bakker <span dir="ltr">&lt;<a href="http://paul.bakker.nl">paul.bakker.nl</a>@<a href="http://gmail.com">gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>Hi Lincoln,</div><div><br></div><div>I started using the source-plugin mechanism and that works great!</div>
<div><br></div><div>About public APIs, that&#39;s really difficult. I&#39;m afraid many plugins need other core plugins on the classpath, even if it&#39;s only to check if a certain facet is installed because @RequiresFacet needs a Class as an argument.</div>

<div>What would be needed is an *-API module for some of the important core plugins I think such as project-model, and the J2EE plugins. What exactly should and shouldn&#39;t be in the API is hard to say. Maybe it&#39;s an idea to create a list of dependencies that are needed in the non-core plugins created so far. That would at least give a first impression on what should be in the API. It&#39;s difficult to figure this out before people actually start to use it, but it&#39;s too late to figure this out after a lot of plugins are created because all of them will brake after refactoring.</div>

<div><br></div><font color="#888888"><div>Paul</div></font><div><div></div><div class="h5"><div><br></div><div><div><br><div class="gmail_quote">On Fri, Apr 1, 2011 at 11:50 PM, Lincoln Baxter, III <span dir="ltr">&lt;<a href="mailto:lincolnbaxter@gmail.com" target="_blank">lincolnbaxter@gmail.com</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hey Paul,<br><br>(Copying forge-dev)<br><br>You&#39;re right, this should probably be clarified in the docs. It&#39;s safe to assume that the<b> forge-shell-api </b>is what will be made available, as the plugin guide states (only indirectly because it&#39;s the only depenency in the POM). I&#39;m not really sure how best to handle other requirements yet at this point, like if you needed to reference the MavenCoreFacet directly, for instance, how to handle exposing other &quot;core plugins&quot; that aren&#39;t really part of the core API yet.<br>



<br>Loving your ideas for plugins. Keep em coming! I&#39;m going to be working with management at JBoss to get the central plugin index up and running so we can make it even easier to share, though, It will probably take a while.<br>



<br>Your thoughts on this would be greatly appreciated :)<br>~Lincoln<div><div></div><div><br><br><div class="gmail_quote">On Fri, Apr 1, 2011 at 5:07 PM, Paul Bakker <span dir="ltr">&lt;<a href="http://paul.bakker.nl" target="_blank">paul.bakker.nl</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>&gt;</span> wrote:<br>



<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi Lincoln,<div><br></div><div>The dependencies that you found in the Arquillian plugin where actually obsolete. I needed them for the first approach I tried (loading project classes) which I abandoned later. I removed them and all is still working.</div>





<div><br></div><div>I noticed something that might be confusing in the docs. There&#39;s a warning not to include libs that are provided by Forge. How does someone know which libraries to include and which not? Maybe we should  provide a list of provided libraries in the docs? Another thing that&#39;s not completely clear now is what Forge classes/interfaces are safe to use in a plugin. Are all classes in *-api modules usable, and all others not? And how does someone know about those api modules without looking at the source code? This should be specified clearly in the docs. If people start writing plugins using implementation classes they might brake easily with new versions of Forge. </div>





<div><br></div><div>I have a few new ideas for plugins too:</div><div>-Code quality plugin -&gt; configure checkstyle/findbugs/sonar in Maven with single commands </div><div>-JSF components plugin -&gt; configure Richfaces / Primefaces with a single command</div>





<div>-Hibernate 2nd level cache -&gt; configure 2nd level caching using one of the many implementations</div><div><br></div><div>All of them just do configuration on the project. To my experience those types of configuration normally involve a lot of copy/paste from manuals while setting them up. Forge can do that for us :-) </div>





<div>What do you think about them? I have some time again this weekend, so I&#39;ll get started on one of them.</div><div><br></div><div>Let me say again that it&#39;s incredibly fun to work and discuss on this! Wish I have more time :-)</div>




<div><br></div><font color="#888888"><div>Paul</div>
</font></blockquote></div><br><br clear="all"><br></div></div><font color="#888888">-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.com" target="_blank">http://ocpsoft.com</a><br><a href="http://scrumshark.com" target="_blank">http://scrumshark.com</a><br>


&quot;Keep it Simple&quot;<br>

</font></blockquote></div><br></div></div>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.com">http://ocpsoft.com</a><br><a href="http://scrumshark.com">http://scrumshark.com</a><br>&quot;Keep it Simple&quot;<br>