Hi, I've pushed my changes for review [1]. I still need help with Rat plugin. The global maven-war-plugin configuration is creating an extra *-classes.jar file that's bothering the Rat. I also have a proposal of making the deb build part original core and console and dumping the sub-projects.
@Francesco: Once you make all configs external consuming debs and wars, rpm's should be, IMHO, the default approach: encourage people to use Syncope AS IS, for custom stuff call a developer. The archetype is good for developers but not for non-developers (like sys-admins and similar). If you like to have a successful project make it easy for non-developers to consume it. This way you get more users, bigger market . Waiting for some thoughts on this: [1] https://github.com/apache/syncope/pull/1/files P.S. I would make Syncope work with default Active Directory install (from Samba for example) and market this feature. I've worked with a client on building unified IDM with AD and found a big lack of tools to manage AD outside Windows. I'm no expert on this subject but If Syncope can manage AD users, groups and computers out of the box via a web console you'll be in business. 2014-07-25 11:22 GMT+03:00 Francesco Chicchiriccò <ilgro...@apache.org>: > On 24/07/2014 20:14, Guido Wimmel wrote: >> >> Hi, >> >> sounds good to me too. >> +1 >> >> [...] >>>> >>>> This boils down to separating the application in: configuration, >>> >>> > binaries (jars) and application data (logs, data, database). You >>> should >>> > be able to supply the path to the main configuration file via system >>> > property and all other configuration files should be referenced from >>> > this one. >>> >>> >>> As you might have seen from this wiki page: >>> >>> >>> https://cwiki.apache.org/confluence/display/SYNCOPE/Run+Syncope+in+real+environments#RunSyncopeinrealenvironments-Buildanddeploy >>> >>> the paths for the bundles and logs directories are already to be >>> provided for production environments. >>> >>> There are, however, other configuration files (.properties) that should >>> be possible to put outside of syncope.war and syncope-console.war (and >>> then placed, for example, into /etc/default/apache-syncope on a Debian >>> system). >>> >>> This might require some additional Spring configuration (as did in the >>> past for console's configuration.properties - that absolutely needs to >>> be renamed BTW) and possibly some minor Java adjustments, but it is >>> definitely feasible. >> >> In our installation of Syncope we already externalized the >> .properties-Files >> (so one can use the same .war-File both in test and in production), which >> works very well. >> We simply changed the search path for the properties files in the Spring >> configuration though; >> for the general case one might have to do a little bit more (e.g. keep >> looking in the classpath >> if the system property is not set). >> >> Another thing that one IMO might want to be able to put outside of >> syncope.war are the notification mail templates. >> This also should not be too difficult, by configuration of proper resource >> loaders for Velocity. > > > +1 > I will open an issue for this kind of refactoring and link it to > SYNCOPE-535. > > Regards. > > > -- > Francesco Chicchiriccò > > Tirasa - Open Source Excellence > http://www.tirasa.net/ > > Involved at The Apache Software Foundation: > member, Syncope PMC chair, Cocoon PMC, Olingo PMC > http://people.apache.org/~ilgrosso/ > -- Ioan Eugen Stan / ieugen.ro
