(Copying forge-dev)
Agreed. I've put this on the roadmap for Alpha4. We have a lot of work to do
in this regard.
~Lincoln
On Sun, Apr 3, 2011 at 4:46 PM, Paul Bakker <paul.bakker.nl(a)gmail.com>wrote:
Hi Lincoln,
I started using the source-plugin mechanism and that works great!
About public APIs, that's really difficult. I'm afraid many plugins need
other core plugins on the classpath, even if it's only to check if a certain
facet is installed because @RequiresFacet needs a Class as an argument.
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't be in the API is hard to say. Maybe it'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's difficult to figure this out before people actually
start to use it, but it's too late to figure this out after a lot of plugins
are created because all of them will brake after refactoring.
Paul
On Fri, Apr 1, 2011 at 11:50 PM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
> Hey Paul,
>
> (Copying forge-dev)
>
> You're right, this should probably be clarified in the docs. It's safe to
> assume that the* forge-shell-api *is what will be made available, as the
> plugin guide states (only indirectly because it's the only depenency in the
> POM). I'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 "core plugins" that aren't
really
> part of the core API yet.
>
> Loving your ideas for plugins. Keep em coming! I'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.
>
> Your thoughts on this would be greatly appreciated :)
> ~Lincoln
>
>
> On Fri, Apr 1, 2011 at 5:07 PM, Paul Bakker <paul.bakker.nl(a)gmail.com>wrote:
>
>> Hi Lincoln,
>>
>> 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.
>>
>> I noticed something that might be confusing in the docs. There'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'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.
>>
>> I have a few new ideas for plugins too:
>> -Code quality plugin -> configure checkstyle/findbugs/sonar in Maven with
>> single commands
>> -JSF components plugin -> configure Richfaces / Primefaces with a single
>> command
>> -Hibernate 2nd level cache -> configure 2nd level caching using one of
>> the many implementations
>>
>> 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 :-)
>> What do you think about them? I have some time again this weekend, so
>> I'll get started on one of them.
>>
>> Let me say again that it's incredibly fun to work and discuss on this!
>> Wish I have more time :-)
>>
>> Paul
>>
>
>
>
> --
> Lincoln Baxter, III
>
http://ocpsoft.com
>
http://scrumshark.com
> "Keep it Simple"
>