Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
RE: Which build target for liferayportal.war
I want to build the portal war ( not for any specific app server). The idea is to build the war for deployment to any app server. This is a first step toward customizing my war. When I get this right, I will add customizations as part of build process to be deployed on our server.
Which target builds the portal war file without assuming anything about the app server ? I couldn't find any. I tried the zip-portal-war - that looks for the webapp dir under tomcat to zip up and create a war. It seems that the build process works in 'reverse' - it needs a tomcat installation to 'deploy' to ( the concept of deployment here being seriously misinterpreted) and then it wars the folder under tomcat that the stuff was copied (err deployed ) to. Is my interpretation correct ( I hope not!) ?
I really want to build the portal war file to be deployed to some server. I will configure the server as necessary ( for context path, data sources etc); I do NOT need the build to automate deployment - in fact that is a HORRIBLY bad practice.
So, can anyone help me here ?
Which target builds the portal war file without assuming anything about the app server ? I couldn't find any. I tried the zip-portal-war - that looks for the webapp dir under tomcat to zip up and create a war. It seems that the build process works in 'reverse' - it needs a tomcat installation to 'deploy' to ( the concept of deployment here being seriously misinterpreted) and then it wars the folder under tomcat that the stuff was copied (err deployed ) to. Is my interpretation correct ( I hope not!) ?
I really want to build the portal war file to be deployed to some server. I will configure the server as necessary ( for context path, data sources etc); I do NOT need the build to automate deployment - in fact that is a HORRIBLY bad practice.
So, can anyone help me here ?
V M:
I do NOT need the build to automate deployment - in fact that is a HORRIBLY bad practice.
Automating deployment to a production server is commonly recognized a horribly bad practice. However, using your production server to build code is also commonly recognized as a horribly bad practice. Therefore, our build scripts are written with the belief that the build process will only occur in a development environment on a development machine.
Given that we intend to run everything in a development environment, I find it hard to see why one would choose not to automate the deployment, as it saves time and reduces the probability that you try to test changes that forgot to deploy to your local test server.
If you are still concerned, can you clarify why you believe that time-saving practices which are practical in a development environment are undesirable?
V M:
It seems that the build process works in 'reverse' - it needs a tomcat installation to 'deploy' to ...
Your interpretation is mostly correct. What you seem to be missing from your interpretation of the build script is that Liferay does not require a valid application server. The following in your app.server.USERNAME.properties file will ask Liferay's build script to deploy to a fake application server called "none" stored in a directory called "D:/liferay/noserver".
app.server.type=none
app.server.parent.dir=D:/liferay
app.server.none.dir=${app.server.parent.dir}/noserver
app.server.none.deploy.dir=${app.server.none.dir}/servlets
app.server.none.log.dir=${app.server.none.dir}/logs
app.server.none.temp.dir=${app.server.none.dir}/logs
app.server.none.work.dir=${app.server.none.dir}/logs
app.server.none.bin.dir=${app.server.none.dir}/bin
app.server.none.classes.global.dir=${app.server.none.dir}/classes
app.server.none.classes.portal.dir=${app.server.none.portal.dir}/WEB-INF/classes
app.server.none.lib.global.dir=${app.server.none.dir}/lib
app.server.none.lib.portal.dir=${app.server.none.portal.dir}/WEB-INF/lib
app.server.none.portal.dir=${app.server.none.deploy.dir}/liferay-portalYou've probably noticed that if you delete the 'dist' folder from the Liferay source and try to run the zip-portal-war target on its own, it will fail because the 'dist' directory is missing. Similar failures also occur if you run the clean target before you run the zip-portal-war target without running the start or deploy targets.
I believe this is because generating a WAR is not considered a standard part of the build process. Instead, it was introduced in order to meet an end-user demand. Because it's run so infrequently, making it a central part of our build process makes less sense to me than simply reusing what's generated by a target that already exists and is also run as part of the distribution process.
If you are still concerned, can you clarify why you feel that reusing an existing build script which will run anyway for a build script which is run very infrequently is considered an undesirable practice?
>> Automating deployment to a production server is commonly recognized a horribly bad practice.
Agreed.
>> However, using your production server to build code is also commonly recognized as a horribly bad practice.
agreed.
>> Therefore, our build scripts are written with the belief that the build process will only occur in a development environment on a development machine.
Well, then, HOW do you build for the production environment ? Let me explain. The NORMAL way to build for a production env IS to build on a dev workstation ! The same build process should work - we just check out different stuff from the SCCS. Then we deploy the war that we built that was specifically for production.
>> Given that we intend to run everything in a development environment, I find it hard to see why one would choose not to automate the deployment, as it saves time and reduces the probability that you try to test changes that forgot to deploy to your local test server.
You are running in circles. First of all, WHY automate deployment to development ? Then there is the issue of building for production - who is going to do that and how ?
>> If you are still concerned, can you clarify why you believe that time-saving practices which are practical in a development environment are undesirable?
Your build process is anything but time saving. I find using an IDE much faster. I find that using the build scripts generated by an IDE such as netbeans or IDEAJ far more desirable. In fact, we have manually built ant scripts that compile far more in far less time than liferay. I am not sure what you are comparing with here but I don't agree with your findings.
>> Your interpretation is mostly correct. What you seem to be missing from your interpretation of the build script is that Liferay does not require a valid application server. The following in your app.server.USERNAME.properties file will ask Liferay's build script to deploy to a fake application server called "none" stored in a directory called "D:/liferay/noserver".
I got the build to work pretending to be using a dummy app server, as suggested here. But my point it that it is wrong practice. This method, unfortunately, does not build the default theme. That requires a 'valid' application server type. I wonder where that valid types are defined. This exemplifies the deficiencies in the build system - it is not portable and it requires a lot of maintenance esp if you change something structurally.
>> You've probably noticed that if you delete the 'dist' folder from the Liferay source and try to run the zip-portal-war target on its own, it will fail because the 'dist' directory is missing.
Well, that shouldn't happen - the build should create the output folder if it doesn't exist. Of course, in this case, the build is EXPECTING the output folder to not only exist but to provide some (external) input to the build process, which is a circular dependency and breaks all build norms I am familar with.
>> Similar failures also occur if you run the clean target before you run the zip-portal-war target without running the start or deploy targets.
'clean' is usually the first target anyone runs in a build and it should NEVER have a dependency.
>> I believe this is because generating a WAR is not considered a standard part of the build process.
It should be ! It is THE standard way to deploy a J2EE application/module. Try to introduce standardization to the build process.
>> Instead, it was introduced in order to meet an end-user demand.
Did it occur to you that some of your 'users' are also J2EE developers ? Some of them may also want to contribute. And a proprietary build process gets in the way of that.
>> Because it's run so infrequently, making it a central part of our build process makes less sense to me than simply reusing what's generated by a target that already exists and is also run as part of the distribution process.
I understand the way you distribute your zips but that doesn't mean that the process cannot be changed to be more standards compliant. Instead of building for specific app servers, you should have war/ear and then documentation for each app server ( which I believe you already do). If some users have deployed websphere in production, I am sure they are savvy enough to administer or learn to administer it. It is not your job to automate that process - in fact, in most cases, they already have app servers configured for their need.
>> If you are still concerned, can you clarify why you feel that reusing an existing build script which will run anyway for a build script which is run very infrequently is considered an undesirable practice?
??
Agreed.
>> However, using your production server to build code is also commonly recognized as a horribly bad practice.
agreed.
>> Therefore, our build scripts are written with the belief that the build process will only occur in a development environment on a development machine.
Well, then, HOW do you build for the production environment ? Let me explain. The NORMAL way to build for a production env IS to build on a dev workstation ! The same build process should work - we just check out different stuff from the SCCS. Then we deploy the war that we built that was specifically for production.
>> Given that we intend to run everything in a development environment, I find it hard to see why one would choose not to automate the deployment, as it saves time and reduces the probability that you try to test changes that forgot to deploy to your local test server.
You are running in circles. First of all, WHY automate deployment to development ? Then there is the issue of building for production - who is going to do that and how ?
>> If you are still concerned, can you clarify why you believe that time-saving practices which are practical in a development environment are undesirable?
Your build process is anything but time saving. I find using an IDE much faster. I find that using the build scripts generated by an IDE such as netbeans or IDEAJ far more desirable. In fact, we have manually built ant scripts that compile far more in far less time than liferay. I am not sure what you are comparing with here but I don't agree with your findings.
>> Your interpretation is mostly correct. What you seem to be missing from your interpretation of the build script is that Liferay does not require a valid application server. The following in your app.server.USERNAME.properties file will ask Liferay's build script to deploy to a fake application server called "none" stored in a directory called "D:/liferay/noserver".
I got the build to work pretending to be using a dummy app server, as suggested here. But my point it that it is wrong practice. This method, unfortunately, does not build the default theme. That requires a 'valid' application server type. I wonder where that valid types are defined. This exemplifies the deficiencies in the build system - it is not portable and it requires a lot of maintenance esp if you change something structurally.
>> You've probably noticed that if you delete the 'dist' folder from the Liferay source and try to run the zip-portal-war target on its own, it will fail because the 'dist' directory is missing.
Well, that shouldn't happen - the build should create the output folder if it doesn't exist. Of course, in this case, the build is EXPECTING the output folder to not only exist but to provide some (external) input to the build process, which is a circular dependency and breaks all build norms I am familar with.
>> Similar failures also occur if you run the clean target before you run the zip-portal-war target without running the start or deploy targets.
'clean' is usually the first target anyone runs in a build and it should NEVER have a dependency.
>> I believe this is because generating a WAR is not considered a standard part of the build process.
It should be ! It is THE standard way to deploy a J2EE application/module. Try to introduce standardization to the build process.
>> Instead, it was introduced in order to meet an end-user demand.
Did it occur to you that some of your 'users' are also J2EE developers ? Some of them may also want to contribute. And a proprietary build process gets in the way of that.
>> Because it's run so infrequently, making it a central part of our build process makes less sense to me than simply reusing what's generated by a target that already exists and is also run as part of the distribution process.
I understand the way you distribute your zips but that doesn't mean that the process cannot be changed to be more standards compliant. Instead of building for specific app servers, you should have war/ear and then documentation for each app server ( which I believe you already do). If some users have deployed websphere in production, I am sure they are savvy enough to administer or learn to administer it. It is not your job to automate that process - in fact, in most cases, they already have app servers configured for their need.
>> If you are still concerned, can you clarify why you feel that reusing an existing build script which will run anyway for a build script which is run very infrequently is considered an undesirable practice?
??
I agree with VM Rank. We are attempting to do the same thing - simply build a liferay war file that we can deploy to our glassfish server instance that has been setup with nodeagent. The app server bundles don't cut it for a production environment.
There are already tasks build into the LR build files for creating the WAR files. In the build-dist.xml file, you have all the tasks you need to package the WAR file, the SQL file, the EXT environments, the dependent libraries, and etc.
Try:
Try:
- ant -f build-dist.xml zip-portal-war or
- ant -f build-dist.xml zip-portal-war-2.4
Michael C. Han:
There are already tasks build into the LR build files for creating the WAR files. In the build-dist.xml file, you have all the tasks you need to package the WAR file, the SQL file, the EXT environments, the dependent libraries, and etc.
Try:
- ant -f build-dist.xml zip-portal-war or
- ant -f build-dist.xml zip-portal-war-2.4
The above targets create a war but they are still dependent on an App Server. The question was is there a way to create an app server independant war that can be seamlessly deployed from one app server to another. This is a critical requirement and hoping that a mature platform as Liferay would be able to support this.
We already have a JBoss server in production, we are not going to use a bundle to install Liferay. We will use a war file to install liferay into our production JBoss server. I was trying to figure out how to do this very thing also. I guess there is a workaround for it, but it would be nice if the Liferay build scripts had a target to release the .war file and dependencies .zip file. It would make much easier deployments for my development environment.
Thanks,
Dennis Przybyla
Thanks,
Dennis Przybyla
i agreed, i also prefer if ant script come with "war output" directly and once we finished compile, all we have to do is move the war to our existing application server.
may i know what workaround you folks do to create war file?
may i know what workaround you folks do to create war file?