Re: Checkstyle and PMD
On 7/25/07, Kit Plummer <[EMAIL PROTECTED]> wrote:
As long as I can "comment out" the feature at one place I don't mind the
styleguide stuff. But, you are right...seems like it would be more of a
pre-commit hook thing.
Well the problem is that Subversion commits don't go through the Maven
build; they are a completely separate process. What we might consider
doing is providing one install goal for development, one install goal
to be used prior to doing a commit and the deploy goal:
1) development install goal - used to develop, debug and experiment
with the Subversion code
2) pre-commit install goal - used immediately prior to performing a
Subversion commit to ensure that code conventions are followed
3) deploy goal - handles standard deployment to Maven repos and source
packaging
What do you guys think?
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Castor - http://castor.org/
Re: Checkstyle and PMD
On 7/25/07, Bruce Snyder <[EMAIL PROTECTED]> wrote:
On 7/25/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
> If people find this configuration too painful, we can easily disable
> the checks by default but i thought it was a good way to enforce a
> coherent code format. And yes, all the configuration will be moved to
> a single place when all the components pass the checks.
Yeah, I was going to suggest this because they make experimentation
very difficult. I also think that creating the source tarballs/zips
should be part of deploy goal and not part of install goal. I agree
that it's a good idea to enforce the code conventions when something
is going to be committed, but not during every build cycle while I'm
debugging and experimenting.
Bruce
--
perl -e 'print
unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Castor - http://castor.org/
As long as I can "comment out" the feature at one place I don't mind the
styleguide stuff. But, you are right...seems like it would be more of a
pre-commit hook thing.
--
Kit Plummer
Nobody-in-Charge @ Black:Hole:Logic
http://www.blackholelogic.com
Re: Checkstyle and PMD
On 7/25/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
If people find this configuration too painful, we can easily disable
the checks by default but i thought it was a good way to enforce a
coherent code format. And yes, all the configuration will be moved to
a single place when all the components pass the checks.
Yeah, I was going to suggest this because they make experimentation
very difficult. I also think that creating the source tarballs/zips
should be part of deploy goal and not part of install goal. I agree
that it's a good idea to enforce the code conventions when something
is going to be committed, but not during every build cycle while I'm
debugging and experimenting.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Castor - http://castor.org/
Re: Two steps build
Never mind. It has to do with the packaging type handlers and such. I understand now. Interesting issue. Dan On Wednesday 25 July 2007 16:15, Daniel Kulp wrote: > On Wednesday 25 July 2007 15:52, Guillaume Nodet wrote: > > Yes it should. The main problem comes from the servicemix maven > > plugin: it relies ou maven extensions plugins which can not be built > > and used in the same run :-( Other ways include fixing maven (if > > possible), splitting the release cycles as discussed in an earlier > > thread, using an ant file or batch for the main build... > > Umm you can build and use maven plugins in the same run. > That's not a problem. CXF does it in several places. > > Dan > > > On 7/25/07, Gert Vanthienen <[EMAIL PROTECTED]> wrote: > > > Guillaume, > > > > > > What is causing the two step build in the first place? Shouldn't > > > Maven take care of building everything in the right order > > > automatically, based on the interdependencies of the subprojects? > > > > > > > > > Gert > > > > > > Guillaume Nodet wrote: > > > > I was wondering if someone knows a way to spawn a maven build > > > > from within maven. Maybe this would be a way to remove the two > > > > steps build needed the first time (and when releasing too). -- J. Daniel Kulp Principal Engineer IONA P: 781-902-8727C: 508-380-7194 [EMAIL PROTECTED] http://www.dankulp.com/blog
Re: Two steps build
Yes it should. The main problem comes from the servicemix maven plugin: it relies ou maven extensions plugins which can not be built and used in the same run :-( Other ways include fixing maven (if possible), splitting the release cycles as discussed in an earlier thread, using an ant file or batch for the main build... On 7/25/07, Gert Vanthienen <[EMAIL PROTECTED]> wrote: Guillaume, What is causing the two step build in the first place? Shouldn't Maven take care of building everything in the right order automatically, based on the interdependencies of the subprojects? Gert Guillaume Nodet wrote: > I was wondering if someone knows a way to spawn a maven build from > within maven. Maybe this would be a way to remove the two steps build > needed the first time (and when releasing too). > -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
Re: Two steps build
Guillaume, What is causing the two step build in the first place? Shouldn't Maven take care of building everything in the right order automatically, based on the interdependencies of the subprojects? Gert Guillaume Nodet wrote: I was wondering if someone knows a way to spawn a maven build from within maven. Maybe this would be a way to remove the two steps build needed the first time (and when releasing too).
Two steps build
I was wondering if someone knows a way to spawn a maven build from within maven. Maybe this would be a way to remove the two steps build needed the first time (and when releasing too). -- Cheers, Guillaume Nodet Principal Engineer, IONA Blog: http://gnodet.blogspot.com/
Re: Checkstyle and PMD
If people find this configuration too painful, we can easily disable
the checks by default but i thought it was a good way to enforce a
coherent code format. And yes, all the configuration will be moved to
a single place when all the components pass the checks.
On 7/25/07, Bruce Snyder <[EMAIL PROTECTED]> wrote:
On 7/25/07, Thomas Termin <[EMAIL PROTECTED]> wrote:
> Bruce Snyder wrote:
> > 1) Is there a reason why the maven-checkstyle-plugin is enabled in
> > many subproject level POMs instead of just in the build module POM? It
> > seems like this should be enabled in one location instead of being
> > spread throughout 14 POMs across the code base. Even the PMD ruleset
> > is only enabled in build module POM.
> I guess it is because not all components are refactored.
OK, I see now - it's a work in progress.
> See for example https://issues.apache.org/activemq/browse/SM-933
>
> On some day there should be all components refactored and the checkstyle
> will be enabled in only one POM.
>
> > 2) It is a *major* pain to have a build fail simply because the code
> > is not formatted according to the Checkstyle and PMD conventions being
> > used in ServiceMix. So I've taken a stab at creating a code formatter
> > profile for Eclipse and some quick docs located here:
> This prevents a user to checkin stuff which is not in the correct style.
> There were a hint from Guillaume some day.
Yes, I understand, hence my creation of the Eclipse code formatter
profile. The Eclipse Checkstyle plugin (http://eclipse-cs.sf.net/)
would work as well.
A few years back I used to use an automatic code formatter with Ant,
but I can't remember the name of it now. It wasn't Jalopy but I
suppose Jalopy would work just fine. The idea with Jalopy is that it
automatically formats the code according to the coding conventions.
BTW, there's a whole list of code verifiers here:
http://javatoolbox.com/categories/code-analysers-standards-verifiers
Some will auto-reformat the source and some won't. Just thinking...
Bruce
--
perl -e 'print
unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Castor - http://castor.org/
--
Cheers,
Guillaume Nodet
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/
[jira] Updated: (SM-939) CXF based Service Engine and Bnding Component
[ https://issues.apache.org/activemq/browse/SM-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang updated SM-939: Attachment: patch0720.txt > CXF based Service Engine and Bnding Component > - > > Key: SM-939 > URL: https://issues.apache.org/activemq/browse/SM-939 > Project: ServiceMix > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Freeman Fang >Priority: Critical > Fix For: 3.2 > > Attachments: patch.txt, patch0627.txt, patch0702.txt, patch0720.txt > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SM-939) CXF based Service Engine and Bnding Component
[ https://issues.apache.org/activemq/browse/SM-939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang updated SM-939: Attachment: (was: patch0720.txt) > CXF based Service Engine and Bnding Component > - > > Key: SM-939 > URL: https://issues.apache.org/activemq/browse/SM-939 > Project: ServiceMix > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Freeman Fang >Priority: Critical > Fix For: 3.2 > > Attachments: patch.txt, patch0627.txt, patch0702.txt, patch0720.txt > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ActiveMQ Causing OutOfMemoryError After Service Deployment
Armen H., We usually don't pick up SNAPSHOT builds in our releases. However, we are planning to a 3.1.2 release sometime in the near future, so if ActiveMQ has released the patch by then, we can include it at that time. Can you already provide me with a reference to a thread on the mailing list or a an ActiveMQ JIRA issue to document this issue? In the meantime, could you try replacing the JAR files for ActiveMQ in your installation with a recent build of ActiveMQ to see if it really resolves the problems you're experiencing? Gert ArmenH wrote: Hi Gert, We're using HTTP BC and JSR 181 SEs. We have custom business logic (very simple) that uses POJOs generated from the JAXB version of the JDK 1.6.0_01. We are also dependent on JDK 1.6 JAX-WS to generate our service interface (WSDL). We will check the number of service endpoints and let you know. By the way, I have another thread on the ActiveMQ forums and other folks have experienced very similar issues with ActiveMQ as that causes the heap overflow. The fix for this issue was put on July 24 but it's unclear which version it will end up in and also more importantly when would ServiceMix pick up the latest 4.1.x SNAPSHOT from ActiveMQ. Armen H. Gert Vanthienen wrote: Armen H., What JBI Components (JMS, HTTP, JSR-181, ...) are you using? From your description, I assume you at least have a few custom built components as well... Can you try to use jconsole (http://incubator.apache.org/servicemix/15-tutorial-using-jmx-to-look-inside-the-esb.html) to look at the number of service endpoint that are actually registered? Also, can you take a look at the number of threads that are in use? What version of Java are you using? Gert ArmenH wrote: Gert, We use the Windows version for development phase of our services. We are deploying services by dropping the files in the deploy and install directories. We don't use JMX for the development phase. We're using ServiceMix version 3.1 in stand-alone mode. We deploy SAs as well. Regards, Armen H. Gert Vanthienen wrote: L.S., One of my customers is running ServiceMix on Windows as well, but even with a dozen SA deployed, the memory usage doesn't raise to the amounts you mention here, although there are using several types of services (HTTP, JMS, FTP, File, Saxon, EIP, bean, lwcontainer). What version of ServiceMix and/or Java are you using? Are you using ServiceMix in stand-alone or web application 'mode'? What is the type of service you are trying to deploy? Can you try to check the number of threads that are running with a JMX console? Regards, Gert ArmenH wrote: We have found out that after just one service deployed on Windows ServiceMix the memory usage jumps to 500 MB and it increases linearly after each service deployment until ServiceMix dies with an OutOfMemoryError. We tried increasing the heap size and it helped up to a certain number of services deployed in the container, after that the Error happened as expected. We used jhatfor heap analysis and found out that the following instance usage (after just one service deployment): 1673478 instances of class org.apache.activemq.filter.DestinationMapNode 3001 instances of class edu.emory.mathcs.backport.java.util.concurrent.locks.ReentrantLock$NonfairSync This is a critical issue for us. Please advise. Regards. Armen H.
