- This topic has 2 replies, 2 voices, and was last updated 20 years, 5 months ago by wayne.
-
AuthorPosts
-
binyanMemberI was looking through the plugin registry and I didn’t see ME sharing any extension points other than the com.genuitec.eclipse.j2eedt.core.xmlentityresolver extension point. While I can understand the desire to protect what you do, you could also gain from the contributions of others. Just as you use ME to extend the eclipse framework, I wouild like to personally extend parts of ME.
I could log a feature request, but not everything that would make life easier here is relevant for the Eclipse/ME community as a whole because somethings here are seriously ‘jacked up’ and we just need to deal with it. Also community created and contributed extensions have the potential to be better in some cases than ME provided ones.
For my projects I would like to be able to tag all my projects with the type of artificats they need to produce. For one project that might be a single war file, while for another it might be a utility jar file and an ejb jar file. Then at the app level I would like to integrate in where the project artifacts go in the resulting ear file from dependent projects. I would also like to tag where an artifact goes in the manifest classpath or not. That fact that I can do this with ant proves it’s doable, but there is no way for me to integrate an IMyEclipseEarDeployer plugin.
Binyan
binyanMemberI was looking at the .mymetadata.xml and the general structure has the makings for supporting multiple jars and such.
<?xml version=”1.0″ encoding=”UTF-8″?>
<project-module context-root=”/FooAppWeb” name=”FooAppWeb”
archive=”FooAppWeb.war” type=”WEB” id=”myeclipse.1089919203984″>
<attributes>
<attribute name=”webrootdir” value=”webapp”/>
</attributes>
</project-module>From the above xml we can see that several changes would be required to allow for mutliple jar builds. Move the context-root, archive type and possibly id to subelements of a higher level <artifact> element. Give each <artifact> elements its own <includes> and <excludes> to control artifact contents. The <include> element should support folder prefixing to allow the user to include files in the appropriate folder in the artifact.
From this alone we have the FooAppWeb project potentially building any number of artifacts from one project. Deployment could still be farely the same since the type of the artifact would dictate how you would deploy it (i.e. artifacts of type war would still need to be legal war files).
And if we add an extentsion point so that I can create my IMyEclipseDistributedEarDeplorer plugin that twould take the artifacts produced and deploy them to all of our servers configurations in one go. Then my IMyEclipseDistributedTest plugin would run the server tests against them all in parallel and report the results in a distributed test view. The view is relativly easy because Eclipse provides extention points, ME does not though and IMHO it should.
wayneModeratorDang it! My session timed out and my nice reply to you was deleted. So you get the short version.
MyEclipse recently celebrated its 1st birthday. This is a huge accomplishment for what was initially a very small community. From your survey you can infer that all of our efforts and energy are channeled into end-user features as our goal is to establish MyEclipse as a long term leader in the new software economy that Eclipse is fostering. We expect to release a MyEclipse SDK near the end of ’04. But no promises since our feature priorities are driven by user demand. You can bet that at the top of the SDK feature list will include pluggable deployment strategies.
I’m very interested in hearing from other developers on this topic. If you have extension needs please feel free to continue this thread or you can send suggestions directly to me (wayne@genuitec.com).
-
AuthorPosts