As for the RegexpSingleline issue, this might help: http://stackoverflow.com/questions/9100059/checkstyle-trailing-spaces-regexp-issue
As for the NewlineAtEndOfFile issue, I would suggest that files should NEVER be committed to SVN with CRLF endings. This is an incorrect ending. This is one place Git got it right: CRLF is prohibited everywhere, and Git for Windows automatically converts on commit. My suggestion here: - Find all files in the project with CRLF endings and convert them. - Add a pre-commit check in SVN that prohibits the commit if any files have CRLF in them. My $0.02. Nick On Apr 28, 2013, at 4:00 PM, Remko Popma wrote: > About CheckStyle: > I would like to change the "RegexpSingleline" rule to allow spaces in javadoc > after a '*'. > > Also, the NewlineAtEndOfFile check seems broken. > (http://checkstyle.sf.net/config_misc.html#NewlineAtEndOfFile) > If I commit something on a PC the file will end with "crlf". > Then someone on a Mac builds the site with mvn site, that file will be marked > as an error (even though it ends in a newline). > The NewlineAtEndOfFile seems to only allow one kind of new line, which you > can hard-code or make system dependent. > But it won't allow all newlines... System dependent only works if all devs > use the same system. > (Sorry for ranting... :-) Bed time for me.) > > From: Nick Williams <nicho...@nicholaswilliams.net> > To: Log4J Developers List <log4j-dev@logging.apache.org> > Sent: Monday, April 29, 2013 5:48 AM > Subject: Re: Restrict JPA classes to specific package? > > Using the CheckStyle ImportControl module, I was able to restrict uses of > javax.persistence to o.a.l.l.core.appender.db.jpa, uses of org.mongodb to > o.a.l.l.core.appender.db.nosql.mongo, etc. It doesn't "break the build" if > someone violates this rule, which would be ideal. Currently it's just a nag > on the CheckStyle report if someone violates this rule. > > Other projects (Tomcat is the first that comes to mind) run CheckStyle > pre-compile and fail if CheckStyle finds errors. Currently, there are too > many other errors to do this in Log4j ... it would be weeks before it built > again. However, at some point we could consider making this change to enforce > the CheckStyle rules, after they have all been cleaned up. > > Nick > > On Apr 27, 2013, at 8:36 PM, Remko Popma wrote: > >> Nick, >> >> I think it is possible to restrict access from package A to package B in >> Eclipse, >> but this would be IDE-dependent. Not sure if that is good enough for you. >> (I found this link, which may be outdated: >> http://www.eclipsezone.com/eclipse/forums/t53736.html ) >> >> An alternative would be to use a naming convention like >> >> org.some.package.some.func >> org.some.package.some.func.internal >> >> where the internal stuff should only be used in the func packages. >> >> >> From: Nick Williams <nicho...@nicholaswilliams.net> >> To: Log4J Developers List <log4j-dev@logging.apache.org> >> Sent: Sunday, April 28, 2013 5:56 AM >> Subject: Re: Restrict JPA classes to specific package? >> >> Ralph nailed it. >> >> Also to an earlier point/question Ralph raised that isn't included below: >> >> > However, note that we have o.a.l.log4j.net which has all the networking >> > related managers. Perhaps it should have been under appenders as well, but >> > it also supports servers as well as managers, which probably isn't as >> > likely with db appenders...? >> >> The SocketAppender, SmtpAppender, JMSQueueAppender, and JMSTopicAppender are >> all in o.a.l.log4j.appender. o.a.l.log4j.net appears to mostly be servers >> and receivers and a few managers. I think the db package is in the right >> place. I would actually argue that some of the net package classes actually >> belong in the appender package. But I digress... >> >> Back to the original question :-) how would I achieve restricting access to >> javax.persistence so that other parts of the Core aren't polluted with JPA >> classes? I know it's possible (re: Tomcat), I just don't know how to do it >> in Log4j. >> >> Nick >> >> On Apr 27, 2013, at 3:17 PM, Ralph Goers wrote: >> >> > That would probably be extremely confusing. >> > >> > The managers initialize in the constructor and stop in the release method. >> > But AbstractManager takes care of the release method by checking for the >> > counter going down to zero and then calling releaseSub (yes - that is a >> > horrible name). Managers actually override that method to perform >> > whatever cleanup they need to do. My guess is that >> > AbstractDatabaseManager's releaseSub method will call the disconnect >> > method. So if anything is going to be renamed to stop it would be >> > releaseSub. connect and disconnect sound right to me. >> > >> > Ralph >> > >> > >> > On Apr 27, 2013, at 12:58 PM, Gary Gregory wrote: >> > >> >> Should connect/disconnect just be start/stop? >> >> >> >> Gary >> >> >> >> On Apr 27, 2013, at 11:20, Nick Williams <nicho...@nicholaswilliams.net> >> >> wrote: >> >> >> >>> >> >>> On Apr 27, 2013, at 9:50 AM, Gary Gregory wrote: >> >>> >> >>>> On Sat, Apr 27, 2013 at 10:43 AM, Nick Williams >> >>>> <nicho...@nicholaswilliams.net> wrote: >> >>>> There already existed an o.a.l.log4j.core.appender.db package that was >> >>>> empty. I discovered that I could create a base AbstractDatabaseAppender >> >>>> that took care of some operations common to JDBC, JPA /and/ NoSQL >> >>>> appenders. That led me to use the existing db package as follows: >> >>>> >> >>>> db/ >> >>>> common DB appender classes >> >>>> >> >>>> What is in common? >> >>>> >> >>>> Gary >> >>> >> >>> - An AbstractDatabaseManager that defines connect and disconnect methods >> >>> for concrete managers to implement, defines an isConnected method, >> >>> defines a buffer size property, and controls buffering (which all types >> >>> will support). >> >>> >> >>> - An AbstractDatabaseAppender that has a type parameter of LogEvent, >> >>> requires an AbstractDatabaseManager implementation in its constructor, >> >>> calls the manager's connect and disconnect methods when the appended is >> >>> started and stopped (respectively), allows for manager replacement >> >>> (configuration reloading) without event loss, and forwards events to the >> >>> manager for writing to the database. >> >>> >> >>> This way, each database type will only need to implement >> >>> connect/disconnect/write methods in the manager, implement an appender >> >>> with a simple factory method to create the correct manager, and create >> >>> whatever classes are necessary (if necessary) to support configuration. >> >>> >> >>>> >> >>>> jdbc/ >> >>>> JDBC appender classes >> >>>> jpa/ >> >>>> JPA appender classes >> >>>> nosql/ >> >>>> NoSQL appender classes >> >>>> >> >>>> I think that package structure makes a lot of sense. I'm open to >> >>>> convincing arguments otherwise. >> >>>> >> >>>> Nick >> >>>> >> >>>> On Apr 27, 2013, at 9:37 AM, Gary Gregory wrote: >> >>>> >> >>>> > I think we should keep the packaging simpler: >> >>>> > o.a.l.log4j.core.appender.jpa >> >>>> > >> >>>> > Gary >> >>>> > >> >>>> > On Apr 27, 2013, at 10:15, Nick Williams >> >>>> > <nicho...@nicholaswilliams.net> wrote: >> >>>> > >> >>>> >> o.a.l.log4j.core.appender.db.jpa >> >>>> > >> >>>> > --------------------------------------------------------------------- >> >>>> > To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org >> >>>> > For additional commands, e-mail: log4j-dev-h...@logging.apache.org >> >>>> > >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> >>>> Java Persistence with Hibernate, Second Edition >> >>>> JUnit in Action, Second Edition >> >>>> Spring Batch in Action >> >>>> Blog: http://garygregory.wordpress.com >> >>>> Home: http://garygregory.com/ >> >>>> Tweet! http://twitter.com/GaryGregory >> >>> >> > >> >> > > >
smime.p7s
Description: S/MIME cryptographic signature
