On Fri, Feb 21, 2014 at 10:36 AM, Manjula Rathnayake manju...@wso2.comwrote:
Hi all,
$Subject happens in current released packs. We are addressing this issue
in M12(next milestone).
Current pom.xml as below. We have to make sure that below highlighted
entries are not changed by developers even by mistakes.
modelVersion4.0.0/modelVersion
groupIdorg.wso2.af/groupId
* artifactIdbar/artifactId*
* version1.0.0/version*
* packagingwar/packaging*
namebar/name
descriptionbar/description
*Why AF functionality breaks if someone changed the above highlighted
entries?*
We set the applicationId as the artifact Id. This is the unique identifier
for applications developed using AF. Currently this applicationId is being
used in many places in AF code base. Examples, to provision application in
source repository, issue tracker and in build tool, to isolate application
from another application in the context of resource isolation, security.
And version is used to identify correct branch, issues related to given
branch and so on. In future, application resource versioning too come into
the picture.
If we change the packaging type, it causes failures at deployment time
where we identify application type using packaging type.
This cause us to prevent users modifying above entries. How to achieve
this?
1. We inform the user that these entries are non-modifiable by adding a
comment in pom.xml. But this won't handle mistakes by the developers.
2. We can implement a git pre-commit hook to validate if above entries are
changed and abort committing.
3. For non-buildable application types such as jaggery, php we remove the
entire pom.xml when generating the initial code.(currently pom.xml is
present in jaggery apps).
Another related issue where current AF functionality breaks is when
developers change the current application context by introducing it in
web.xml. However this is not supported by web app deployer. So we do not
need to consider this scenario.
+1
And since we support uploading war files to AF and create an application,
we do the validation to make sure that war file name is matched with
applicationId. If that is different, we get the confirmation from user to
change the war file name or applicationId without moving forward.
In that case, what if we uploading the war file lets not ask for the
applicationId, but rather generate the application Id based on the
artefact? We inform the user if there is a problem (conflict with existing
name, invalid characters) only.
thanks,
dimuthi
This might cause usability issues such as not being able to get a friendly
name for their applications in case of single tenant contains lot of
applications. However, we are planning to provide URL mapping functionality
so application can be accessed with an end user friendly link.
Please share your thought on this.
thank you.
--
Manjula Rathnayaka
Software Engineer
WSO2, Inc.
Mobile:+94 77 743 1987
--
Dimuthu Leelarathne
Architect Product Lead of App Factory
WSO2, Inc. (http://wso2.com)
email: dimut...@wso2.com
Mobile : 0773661935
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
