If anyone is willing to work on this I can help with testing all this on
IDEA.
At the moment there are no many active developers in the main code so I
don't find working on such helper projects valueable.


On Tue, Jan 15, 2013 at 3:02 PM, Martijn Dashorst <
[email protected]> wrote:

> On Tue, Jan 15, 2013 at 1:37 PM, Martin Grigorov <[email protected]>
> wrote:
> > I.e. the resource jar (a binary) will be committed somewhere, and
> uploaded
> > to Maven repo and finally exploded again ?
> > I don't know how all this work but I'd prefer text files to be committed
> in
> > SCM as now, instead of Maven dependencies which are not needed by my IDE.
>
> The .settings files will be stored in wicket-commons repository (which
> sends notifications to commits@), and a maven release process will
> package and deploy to maven central. Maven should then be able to
> download those files for eclipse.
>
> We use it at €€€ day job (as Emond noted) and it works like a charm,
> as long as one uses the command line maven-eclipse-plugin (version
> 2.9), and obviously Eclipse as the editor.
>
> We could make it a proper project, enjoying the wonders of releases
> and dev@ discussions (and bike shedding about spaces versus tabs,
> curly braces on the same line, line lengths, etc), and ensure that
> IDEA and Eclipse settings are properly maintained—provided that IDEA
> is able to work in a similar fashion. Something like
>
>     wicket-ide-settings
>         wicket-checkstyle-settings
>         wicket-eclipse-settings
>         wicket-intellij-settings
>
> As for diverging IDE settings, perhaps we should get pedantic and add
> a checkstyle enforcement to our build, ensuring that different
> formatting rules will get caught?
>
> In the very least I'd like everyone to start communicating about
> changes made to such files, and in a grander scheme about more changes
> (e.g. changes to pom dependencies or plugins). Depending on the
> change, lazy consensus can be assumed (though formatting changes
> should be discussed prior to modification).
>
> Martijn
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>

Reply via email to