Community
Participate
Working Groups
This is a request for an enhancement so that classpath containers can be made module-resources so that they can become j2ee module dependencies? The JSF Tools project has implemented a feature we call JSF libraries which are simply named collections of jars. In WTP 1.0, at JSF Facet install time, we are copying these jars directly to WEB-INF/lib in the source folder as post R0.7, there was no way to defer the copying. For WTP 1.5 we would like to explore the possibility of relying on J2EE Module Dependencies for external jar deployment. We will have UI that allows a user to add and remove JSF Libary references to a JSF faceted project. The libraries will appear as classpath containers in the navigator. We would like these containers, and not the individual jars, to appear in the module dependencies so that we can take advantage of jar deployment. At JSF library definition time we currently allow the developer to choose whether the library will be deployed or not. The module dependency's checkbox would initially be checked based upon the jsf library deploy flag but could be overridden in the module dependency UI. Ultimately we are considering having individual jars in a library be deployable or not. This would require a callback to our container at deploy time to get list of jars for deployment. We also have an additional requirement that deployment/copying of jars within jars be supported. If you can suggest an alternative mechanism for us, we would gladly consider.
If you want to investigate and propose a patch, we'd be happy to look at it. Thanks.
Just wanted to note that Maven<->WTP integration would also benefit from this facility. At the moment, both JSF and Maven integration are rolling their own solutions to this. It would be beneficial for WTP as a whole if this issue was addressed so that there is a common way that this can be done in both API and UI.
I'll take a look at this for 2.0
I wonder how this JSF libraries are fifferent from JDT libraries? Anyways, this is more an more convincing me that custom attributes on JDT's jars would be much better option and will make packaging and deploying much more transparent for 3rd party components that are not necessary want know about WTP internals.
A JSF library has an attribute as option to deploy.
Have the initial runtime code working for adding classpath container dependencies to the WTP component file (I'll add a patch with this logic here soon so folks can experiment). The logic currently exposes all library entries resolved by the cp container; I think this is the right initial step - filtering specific container contributions at export/publish time using a custom "deploy" attribute needs further consideration (use of multiple cp containers can be used to achieve that filtering in lieu of custom attributes) For both WEB-INF/lib and EAR dependencies, the cp container dependency is added via a "dependent-module" entry whose "handle" attribute takes the following form (this is very similar to how cp variables are currently supported): module:/classpath/con/<cp container path> -WEB-INF/lib dependency: added directly to component file for dynamic web project; the library classpath entries resolved by the container will be exposed to the project classpath via the "Web App Libraries" cp container and will be added to WEB-INF/lib on WAR export and publish. Example entry: <dependent-module deploy-path="/WEB-INF/lib" handle="module:/classpath/con/org.eclipse.jdt.USER_LIBRARY/MyUserLibrary"> <dependency-type>uses</dependency-type> </dependent-module> -EAR dependency: added to the component file for an EAR project and then available as a dependency target to child module projects (similar to how addition of Jars/cp vars to the EAR currently works); the library entries resolved by the cp container will be added to the classpath of referencing module projects via the "EAR Libraries" cp container, on export/publish these entries will be added to the root of the EAR and dynamically added to manifest classpath of referencing module projects. Example component entry: <dependent-module deploy-path="/" handle="module:/classpath/con/org.eclipse.jdt.USER_LIBRARY/MyUserLibrary"> <dependency-type>uses</dependency-type> </dependent-module>
note: issues involving container refresh handling will necessitate some degree of change to this approach so a patch is going to be delayed...
*** Bug 165832 has been marked as a duplicate of this bug. ***
Created attachment 56651 [details] Initial patch Initial patch (based on HEAD version of WTP 2.0) containing logic that support flagging Java classpath entries (library and container) as contributions to the virtual component model (either WEB-INF/lib or MANIFEST classpath in EAR, depending on context) using the classpath entry attribute "org.eclipse.wst.component.dependency". Example: <classpathentry kind="con" path="org.eclipse.jdt.USER_LIBRARY/MyLibrary"> <attributes> <attribute name="org.eclipse.wst.component.dependency"/> </attributes> </classpathentry> When using the "org.eclipse.wst.component.dependency" attribute, all valid resolved entries for classpath containers will be mapped into the virtual component tree regardless of whether they themselves have the special attribute. Support for partial mapping of resolved classpath container entries is provided by the attribute "org.eclipse.wst.component.dependency.partial": when used, only those resolved entries that have the "org.eclipse.wst.component.dependency" attribute will be mapped. NOTE: the current patch does not include UI support for adding this attribute; I wanted to get the core logic out there and let folks experiment and comment before deciding on how best to expose to the user (likely "Add Container" buttons can be included on the web lib and non-EAR J2EE module dependency prop pages that let users add the attribute to existing cp containers on the classpath - or add the container to the classpath and add the attribute in a single operation) Several use cases are supported: -Tagging the classpath entries of a dynamic web project: valid entries with the attribute will be mapped to the /WEB-INF/lib folder of the web project -Tagging the classpath entries of a utility project (or EJB or connector project): this is only supported if the util project is referenced by an EAR project or as a WEB-INF/lib dependency by a dynamic web project. -For the EAR reference case, the valid entries are added to the root of the EAR as jar archives (validation is performed on the EAR to detect conflicts) and the MANIFEST classpath of the utility project is dynamically modified during export/publish to include references to all classpath dependencies. -For the WEB-INF/lib reference case, the valid entries are added to the WEB-INF/lib folder of the referencing web project (validation is performed on the web project to detect conflicts). Partial list of other validation checks (some of these generate problem markers via a WTP validator): -The WTP classpath containers specifically filter out virtual references derived from classpath entries. -All tagged classpath entries on non-web projects must be exported (the contributions will be exposed to referencing components in the exported/published app so the IDE must reflect that visibility) -It is invalid if any of the following classpath entry types have the attribute: project, src, lib entries that map to folders rather than jar archives -The "partial" attribute can only be specified on container entries -etc.
Should note that in addition to UI support, optimization and code consoliditation/polishing are also still pending.
That is great to see some progress on this. Please note that AJDT team recently switched to a similar approach. So, you may want to look trough the following bug report (i.e. Eclipse 3.3M4 have some critical fixes and new API to support this). 160393: More open AJDT project configuration https://bugs.eclipse.org/bugs/show_bug.cgi?id=160393 166036: [build path] IClasspathAttribute gets lost https://bugs.eclipse.org/bugs/show_bug.cgi?id=166036 Also see some comments and questions below. > When using the "org.eclipse.wst.component.dependency" attribute, all valid > resolved entries for classpath containers will be mapped into the virtual > component tree regardless of whether they themselves have the special > attribute. Support for partial mapping of resolved classpath container entries > is provided by the attribute "org.eclipse.wst.component.dependency.partial": > when used, only those resolved entries that have the > "org.eclipse.wst.component.dependency" attribute will be mapped. Can you please elaborate on partial mapping? I also think it would be useful to allow to specify separate attributes for dependencies that are required for different project types, war, ear, rar, etc. I.e. org.eclipse.wst.component.dependency.war Also, it would be useful of that attribute can be specified on individual classpath entries, including those managed by custom classpath containers. I.e. maven dependencies (for those .classpath file will have single container entry and all details about included jars resolved dynamically at the run time (though can still query that container for all entries and read individual attributes on each entry from that container): <classpathentry exported="true" kind="con" path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/> > Partial list of other validation checks (some of these generate problem markers > via a WTP validator): > > -The WTP classpath containers specifically filter out virtual references > derived from classpath entries. Can you please elaborate on this? > -All tagged classpath entries on non-web projects must be exported (the > contributions will be exposed to referencing components in the > exported/published app so the IDE must reflect that visibility) I think this may not be acceptable in some cases. Especially if you have .classpath in the same project that creates a WAR file. Exporting jars and including them into a WAR are othogonal, so you should be able to include non exported jars from the same project. But it is ok to require jars from other projects to be explicitly exported. Am I missing somethhing? > -It is invalid if any of the following classpath entry types have the > attribute: project, src, lib entries that map to folders rather than jar > archives Those are really huge limitations. I would think that project and class folders should be allowed, as long as they have *.wst.component.dependency attribute declared. For project you can take all its exported target folders and its exported jars that have "dependency" attribute. Maybe class folders can be copied or somehow mapped to the WEB-INF/classes or, as a last resort, a jar can be packaged from those folders. This will greatly simplify multi-project configuration, i.e. when war project has dependency on some utility jar which code is sitting in a separate project. Thanks
Thanks for providing such rapid and detailed feedback, Eugene. Let me try to answer your questions: -Regarding "org.eclipse.wst.component.dependency.partial": This exists to provide exactly what you are looking for wrt to support for attributes on individual entries resolved by classpath containers. If you want all contributions from you container to be mapped into the virtual component tree (which is the only possibility if a user is marking a classpath container whose implementation does not specifically support these WTP attributes), then the "org.eclipse.wst.component.dependency" attribute would be used. If you want only a subset of the container contributions to be mapped, then you need to specify the distinct attribute "org.eclipse.wst.component.dependency.partial" on the container entry and then flag those resolved container entries that should be mapped with the standard ""org.eclipse.wst.component.dependency" attribute. -Regarding module-type specific attributes: I'll have to give that one more thought; my initial reaction is that this type of granularity is probably not a very common requirement and the initial implementation should not include module-type specific information. There are a number of use cases (e.g. util project with flagged cp container that is referenced by multiple other module projects in an EAR) where enforcing those module constraints could lead to a somewhat confusing and non-intuitive user experience. -Regarding the WTP cp container filtering: This is done, for example, to ensure that the WebAppLibraries container does not create a duplicate cp entry for the WEB-INF/lib mapping added for an existing web project cp entry with the dependency attribute (the existing duplicate entry prevention logic relies on container resolution order and can therefore fail in certain cases). -On the export requirement: I think there is a misunderstanding here; this requirement does not apply to web projects (a web project can certainly create WEB-INF/lib mappings for non-exported cp entries; one could even argue that they should NOT be exported but that doesn't need to be validated). -On the project and class folder limitation: I agree that this is a limitation (and a somewhat arbitrary one - the src entry restriction is necessary). I included that restriction to limit the initial scope and impact of the work (esp. the project rule) and it will definitely be possible to remove these restrictions in future iterations of the feature.
(In reply to comment #12) > -Regarding "org.eclipse.wst.component.dependency.partial": > > This exists to provide exactly what you are looking for wrt to support for > attributes on individual entries resolved by classpath containers. If you want > all contributions from you container to be mapped into the virtual component > tree (which is the only possibility if a user is marking a classpath container > whose implementation does not specifically support these WTP attributes), then > the "org.eclipse.wst.component.dependency" attribute would be used. If you want > only a subset of the container contributions to be mapped, then you need to > specify the distinct attribute "org.eclipse.wst.component.dependency.partial" > on the container entry and then flag those resolved container entries that > should be mapped with the standard ""org.eclipse.wst.component.dependency" > attribute. Hmm. Wouldn't it be more natural to always look trough container entries even if container don't have any attribute specified? This way I can only worry about container entries I create dynamically, and won't need to touch container attributes. > -Regarding module-type specific attributes: > > I'll have to give that one more thought; my initial reaction is that this type > of granularity is probably not a very common requirement and the initial > implementation should not include module-type specific information. There are a > number of use cases (e.g. util project with flagged cp container that is > referenced by multiple other module projects in an EAR) where enforcing those > module constraints could lead to a somewhat confusing and non-intuitive user > experience. My concerns came from Maven's war and ear plugins that allow quite sofisitcated packaging. http://maven.apache.org/plugins/maven-war-plugin/ http://maven.apache.org/plugins/maven-ear-plugin/ > -On the project and class folder limitation: > > I agree that this is a limitation (and a somewhat arbitrary one - the src entry > restriction is necessary). I included that restriction to limit the initial > scope and impact of the work (esp. the project rule) and it will definitely be > possible to remove these restrictions in future iterations of the feature. That would be really nice. Currently, Maven 2.x integration plug-in creates a project entry in Maven dependencies if it can find a project in the Workspace, with matching artifact id (including transient dependencies). JDT handle those really well. All the classes and sources from that project automatically available to the compiler and debugger, which is really handy. We were thinking to improve this and use individual class folders from these projects, in order to narrow down dependencies for multi-module Maven project imported as a single Eclipse project into Eclipse. All in all, we would at least need support for the class folders with linked source folders.
(In reply to comment #13) > Hmm. Wouldn't it be more natural to always look trough container entries even > if container don't have any attribute specified? This way I can only worry > about container entries I create dynamically, and won't need to touch container > attributes. I don't believe direct look through can work; the attribute is needed on the container entry since you need a way to control whether the contributions from a particular classpath container entry added to the virtual component tree (this is the only way users can map in containers that are not coded to support these attributes). One change I am thinking about making in this area is to eliminate the "partial" attribute in favor of a "non-dependency" attribute that can be added to resolved container attributes that should NOT be mapped. This way all raw entries will use the same attribute (which makes logic to generate the attributes much more tractable) and containers that need to filter entries will just handle that by flagging the non-mapped entries.
Created attachment 56676 [details] non-dependency attribute Removes the "org.eclipse.wst.component.dependency.partial" attribute and adds a "org.eclipse.wst.component.nondependency" attribute. The "org.eclipse.wst.component.dependency" attribute must now be used for all raw cp entries; for containers that want to only expose a subset of the entries, the "nondependency" attribute can be added to those entries that should be filtered out.
(In reply to comment #14) > I don't believe direct look through can work; the attribute is needed on the > container entry since you need a way to control whether the contributions from a > particular classpath container entry added to the virtual component tree (this > is the only way users can map in containers that are not coded to support these > attributes). So, dependency attribute could be specified either on the whole container on on individual dependencies. You would have to iterate trough dependencies either way and should be able to tell if whole container need to be included or pick entries individually. > One change I am thinking about making in this area is to eliminate > the "partial" attribute in favor of a "non-dependency" attribute that can be > added to resolved container attributes that should NOT be mapped. This way all > raw entries will use the same attribute (which makes logic to generate the > attributes much more tractable) and containers that need to filter entries will > just handle that by flagging the non-mapped entries. That seems twisted. It would be great to avoid changing container entry (including its attributes) in .classpath (leaving it unchanged even all container entries excluded from wst dependencies or all included) and only manage attributes on container entries without denormalizing information about what entries need to be included between container and its entries. Don't you think that logic like "if attribute is at container, then include all container entries; if it is on entry - include this entry" would be more natural?
Hmmm, I think there is a misunderstanding here, Eugene; let me try to elaborate some of the motivations behind this and see if I can clarify the current design. A key use case that drives this is the following: -A user decides to map the contributions for a classpath container into the virtual component API of a WTP project. The implementation of the containers is fully independent of WTP (e.g. user library containers) so there is no way for individual resolved entries to specifically contain the attribute. -The only way this can be handled is to tag the cp container entry with the attribute and to treat all unresolved entries for this case as mapped (all of the unresolved entries in this case will lack WTP attributes). Given this, there are a couple of problems with a design that attempts to represent partial mapping using an unflagged container entry and resolved entries that have a positive attribute (i.e. the "org.eclipse.wst.component.dependency" attribute): -If you map resolved container entries with the attribute regardless of whether the container entry has the attribute, you are forcing all uses of that classpath container in all projects to be mapped into the virtual component API. I do not think this will always be the case. I think it will be better if the logic that adds the cp container entry to the project classpath programmatically determines whether the contributions from that container should in fact be published/exported for that project (potentially with user input). -So, I think you want to always require a positive attribute on the cp container entry itself. Given this need, use of a negative attribute on the resolved container entries (or what had previously been done via the distinct "partial" container attribute) is necessary to eliminate ambiguity between the partial mapping case and the case of a cp container for which all entries should be mapped (e.g. if I get a container with one resolved entry lacking a positive attribute, should that be treated as a user library-type case or as a partial mapping case where nothing should be mapped?)
> -A user decides to map the contributions for a classpath container into the > virtual component API of a WTP project. The implementation of the containers is > fully independent of WTP (e.g. user library containers) so there is no way for > individual resolved entries to specifically contain the attribute. Rob, those attributes can be set automatically by the container implementation and user don't have to worry about setting those attributes. The beauty of this approach, that there is no harm in setting those attributes even if WTP is not available. What I am trying to avoid is the situation when such container would flip between this <classpathentry kind="con" path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/> and this <classpathentry kind="con" path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"> <attributes> <attribute name="org.eclipse.wst.component.dependency"/> </attributes> </classpathentry> depends from its dynamically resolved entries that are managed in a separate descriptor. So, container implementation will be responsible to set that attribute on individual entries and user don't have to do anything at all. I am fine with "negative" attribute on entries for the case when container has "positive" attribute. But please allow to use "positive" attribute on entries when container don't have any attribute. So, it will be always like this: <classpathentry kind="con" path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/> > -The only way this can be handled is to tag the cp container entry with the > attribute and to treat all unresolved entries for this case as mapped (all of > the unresolved entries in this case will lack WTP attributes). Not really. Attributes can be also set on individual container entries. User can't do that for container that automatically manages entries, but container implementation can do that and that is exactly my case. > -If you map resolved container entries with the attribute regardless of whether > the container entry has the attribute, you are forcing all uses of that > classpath container in all projects to be mapped into the virtual component > API. I do not think this will always be the case. I think it will be better if > the logic that adds the cp container entry to the project classpath > programmatically determines whether the contributions from that container > should in fact be published/exported for that project (potentially with user > input). The only case I can think of when dependencies are different is only when they are included into a different artifact type. I.e. jar may not be needed in a war, if that jar is included into a parent ear module. That is why I thought that it could be a good idea to have different attributes for different module types. > -So, I think you want to always require a positive attribute on the cp > container entry itself. Given this need, use of a negative attribute on the > resolved container entries (or what had previously been done via the distinct > "partial" container attribute) is necessary to eliminate ambiguity between the > partial mapping case and the case of a cp container for which all entries > should be mapped (e.g. if I get a container with one resolved entry lacking a > positive attribute, should that be treated as a user library-type case or as a > partial mapping case where nothing should be mapped?) I would say that if there is no attribute on container and on none of its entries, those entries should not be included into dependencies.
(In reply to comment #18) > > -A user decides to map the contributions for a classpath container into the > > virtual component API of a WTP project. The implementation of the containers is > > fully independent of WTP (e.g. user library containers) so there is no way for > > individual resolved entries to specifically contain the attribute. > > Rob, those attributes can be set automatically by the container implementation > and user don't have to worry about setting those attributes. Note: the key here is container implementations that have not dependence on WTP and will therefore never add those attributes to resolved entries (e.g. "User Libraries"). You want to support mapping these types of container implementations into the virtual component API. > The beauty of this > approach, that there is no harm in setting those attributes even if WTP is not > available. note: there is also no harm to setting the container entry attribute with WTP not available > > What I am trying to avoid is the situation when such container would flip > between this > > <classpathentry kind="con" > path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/> > > and this > > <classpathentry kind="con" > path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"> > <attributes> > <attribute name="org.eclipse.wst.component.dependency"/> > </attributes> > </classpathentry> > > depends from its dynamically resolved entries that are managed in a separate > descriptor. So, container implementation will be responsible to set that > attribute on individual entries and user don't have to do anything at all. > I think this issue (also discussed below) is the only real point on which we disagree. What you outline above is actually exactly the case that I think should be supported. While it may be the case that the Maven container should always be assumed to have it's tagged contributions deployed, I'm not convinced that we should assume that for all containers that provide partial mappings. In the current design, if the container entry was added to the project without the attribute, that would indicate that the user (or logic that added the entry) wanted the class visibility but did not want to expose those contributions during publish/export (there could certainly be some project-specific reason for that which you don't or can't code into the cp container so that the attributes on the entries are dynamically altered instead). A question for you: Will ensuring the attribute on the container entry be problematic for the Maven container? (i.e. isn't the container entry added to the project classpath by Maven plugin code?). If adding the attribute to the container entry is not going to be problematic for you, then I think it is worth keeping the current ability to fully enable/disable paritial mapping containers at the container entry level. NOTE: If we are comfortable assuming that all container implementations that support partial mappings will ALWAYS want those mappings applied (or can alter the dynamic attributes appropriately), then we can switch to a "look through" model and just remove the "non-dependency" attribute. I don't feel comfortable making that assumption yet but could certainly be convinced otherwise. > I am fine with "negative" attribute on entries for the case when container has > "positive" attribute. But please allow to use "positive" attribute on entries > when container don't have any attribute. So, it will be always like this: > > <classpathentry kind="con" > path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/> > > > -The only way this can be handled is to tag the cp container entry with the > > attribute and to treat all unresolved entries for this case as mapped (all of > > the unresolved entries in this case will lack WTP attributes). > > Not really. Attributes can be also set on individual container entries. User > can't do that for container that automatically manages entries, but container > implementation can do that and that is exactly my case. Only classpath container implementations specifically coded for this WTP feature will support that; we need to support container implementations that will not at the attribute to individual container entries. The "User Libraries" container is the key example here. > > > -If you map resolved container entries with the attribute regardless of whether > > the container entry has the attribute, you are forcing all uses of that > > classpath container in all projects to be mapped into the virtual component > > API. I do not think this will always be the case. I think it will be better if > > the logic that adds the cp container entry to the project classpath > > programmatically determines whether the contributions from that container > > should in fact be published/exported for that project (potentially with user > > input). > > The only case I can think of when dependencies are different is only when they > are included into a different artifact type. I.e. jar may not be needed in a > war, if that jar is included into a parent ear module. That is why I thought > that it could be a good idea to have different attributes for different module > types. > This is discussed above.
It may be educational to see how JDT does this for the "exported" attribute, since the user can export the raw container entry and the container implementation can export the individual resolved entries.
Good example, Konstantin; regarding handling of the exported attribute, I think the current approach is consistent; for example, if the classpath includes a project cp entry, the exported cp entries for that project will only be re-exported if the project cp entry itself is marked as exported (i.e. "look through" is not performed).
(In reply to comment #19) > Note: the key here is container implementations that have not dependence on WTP > and will therefore never add those attributes to resolved entries (e.g. "User > Libraries"). You want to support mapping these types of container > implementations into the virtual component API. Is it note for me or for yourself? :-) I think it should support both. Also note that presence of the attribute on container or on individual entry don't really mean dependency on WTP. It is more like a hint. Said that, I wonder if attribute names should have more WTP-neutral names. > note: there is also no harm to setting the container entry attribute with WTP > not available Regardless of the availability of WTP, setting or unsetting this attribute at container level (even trough JDT API) will cause .classpath modification. Given that .classpath file is usually under version control, it would be a good idea if we can avoid that. > I think this issue (also discussed below) is the only real point on which we > disagree. What you outline above is actually exactly the case that I think > should be supported. I don't disagree. It is completely fine to use attributes at the container level to support container like "user libraries" and such. But I think that at the same time it should be possible to not use it at container but mark individual entries instead. So, more sophisticated containers can take care of individual entries automatically. > In the current design, if the container entry was added to the project without > the attribute, that would indicate that the user (or logic that added the > entry) wanted the class visibility but did not want to expose those > contributions during publish/export (there could certainly be some > project-specific reason for that which you don't or can't code into the cp > container so that the attributes on the entries are dynamically altered > instead). That is what I thought and it is completely makes sense and also in line with JDT's features around "exported" classpath entries. > A question for you: Will ensuring the attribute on the container entry be > problematic for the Maven container? (i.e. isn't the container entry added to > the project classpath by Maven plugin code?). There is no technical issue there. But that would be a big usability problem because .classpath fill will be modified and will constantly jump into outgoing changes for version control, triggered by changes in Maven's project model, which is not obvious, confusing and annoying to the end user. > If adding the attribute to the > container entry is not going to be problematic for you, then I think it is > worth keeping the current ability to fully enable/disable paritial mapping > containers at the container entry level. What I've been tried to suggest that if there is no attribute at container level, you still scan trough individual entries from that container and pickup entries that have "dependency" attribute. Then it would work for both of us. > NOTE: If we are comfortable assuming that all container implementations that > support partial mappings will ALWAYS want those mappings applied (or can alter > the dynamic attributes appropriately), then we can switch to a "look through" > model and just remove the "non-dependency" attribute. I don't feel comfortable > making that assumption yet but could certainly be convinced otherwise. I am not sure what you mean. However it seems like "partial" flag at container is a denormalization of the information from individual attributes. So, having "partial" attribute flat at container is essentially the same as having no attribure at container and scan trough container entries for those that have "dependency" attribute declared. > Only classpath container implementations specifically coded for this WTP > feature will support that; we need to support container implementations that > will not at the attribute to individual container entries. The "User Libraries" > container is the key example here. Right. And I am not arguing that and completely fine if would support attribute at the container level. I am just truing to make sure that it will work not only for those containers. On an unrelated note, there is a chance that user actually will be able to specify "dependency" attributes on individual entries even for "User Libraries" container. See bug 166036 [1], which is describing new extension point introduced in Eclipse 3.3M4 that allows you to define how custom classpath attributes are rendered and configured in the build path dialog. So, it might be possible to add those attributes right from the "User Libraries" configuration, but I haven't confirmed that. [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=166036#c3
The "partial" attribute is now gone; just a single attribute is used to mark the raw entries (and if a raw entry doesn't have it, nothing associated with that entry is mapped); the "non-dependency" attribute can be used by containers to handle resolved entry filtering.
Rob, as I understand, if container has "dependency" attribute then its entries will be included, unless they specify "non-dependency" attribute. Can you please elaborate, why do you think it is a problem to scan individual entries when "dependency" attribute is not specified at the container level? I don't see any conflict with the above use case.
(In reply to comment #24) > Rob, as I understand, if container has "dependency" attribute then its entries > will be included, unless they specify "non-dependency" attribute. > > Can you please elaborate, why do you think it is a problem to scan individual > entries when "dependency" attribute is not specified at the container level? I > don't see any conflict with the above use case. > This is to allow users to control (in a uniform way that is independent of the container implementation) whether or not a specific container's entries are deployed/exported. Example: I may want to include the Maven (Maven is not a great example here...) cp container in my project (and that container will go ahead and tag the resolved entries as if they would be mapped) but decide (for some reason) not to deploy any of the container contributions. It can also be a performance bonus: if none of the raw entries are marked, you don't need to scan any resolved entries.
(In reply to comment #25) > This is to allow users to control (in a uniform way that is independent of the > container implementation) whether or not a specific container's entries are > deployed/exported. Example: I may want to include the Maven (Maven is not a > great example here...) cp container in my project (and that container will go > ahead and tag the resolved entries as if they would be mapped) but decide (for > some reason) not to deploy any of the container contributions. Sorry, I still don't see any advantages of forcing attribute at the container level. You would have to scan trough entries even if container has that attribute. So, why don't allow to not specify that attribute at the container level if container or container provider wants that? As I mentioned above, the uniform rule could be "if container has an attribute, include its entries (unless entry say to skip it), if container has no attribute, include only entries from that container that explicitly say include". > It can also be a performance bonus: if none of the raw entries are marked, you > don't need to scan any resolved entries. I'd say that this is quite weak argument. First of all if container say that entries need to be included you would scan trough it. But even then, how much time do you think it will take to iterate trough array of 100 or even 1000 entries? :-)
Really, the biggest argument is not in perf but in consistency and control. While it might be easier for some container implementors if the raw entry flag is not necessary, it takes away important user control and decreases usability in that it is no longer simple to build a ui that allows the user to check off those (raw) classpath entries that they want included. On the flip side, I don't really get what's all the fuss is about. You have to write code anyway to add maven classpath container to the project. It seems pretty simple to add the flag on the entry as part of that logic if that default behavior makes sense to you. It's not like that flag would have to be set or unset depending on maven metadata changes. What am I missing that makes this such a big deal and worth taking away user control as well as breaking the parallels to how the "export" flag works?
(In reply to comment #26) > > Sorry, I still don't see any advantages of forcing attribute at the container > level. You would have to scan trough entries even if container has that > attribute. So, why don't allow to not specify that attribute at the container > level if container or container provider wants that? > The advantage is control independent of the container implementation. It is the binding of the container to the project, as represented by the container entry, that should ultimately control whether or not the container contributes to the virtual component tree. If enabled, container implementations can filter what they contribute but they can not by themselves control whether they are contributing (that is up the to logic that adds the cp container entry). This allows us to have generic WTP UI tooling that supports disabling (or enabling) any container (this type of tooling is not possible with the "look through" model).
First of all it is not fuss and has very little to do with Maven specifics. Personally I will be happy with any solution, that would address my concern about changing versioned .classpath file, which seem ignored by the currently chosen approach. I also don't see how this simple logic I suggested in my previous comment would prevent WTP UI tooling to manage contributed dependencies? This is only for the case when WTP won't be managing those dependencies and will be provided with the preconfigured ones. By the way, the whole purpose of Maven container is to eliminate need in manually changing configuration. So, configuration is provided automatically based on the information from Maven's project model. Please let me know if I am asking too much.
(In reply to comment #27) > On the flip side, I don't really get what's all the fuss is about. You have to > write code anyway to add maven classpath container to the project. It seems > pretty simple to add the flag on the entry as part of that logic if that > default behavior makes sense to you. It's not like that flag would have to be > set or unset depending on maven metadata changes. That is exactly what it is! Flag does set based on maven metadata changes.
(In reply to comment #30) > (In reply to comment #27) > > On the flip side, I don't really get what's all the fuss is about. You have to > > write code anyway to add maven classpath container to the project. It seems > > pretty simple to add the flag on the entry as part of that logic if that > > default behavior makes sense to you. It's not like that flag would have to be > > set or unset depending on maven metadata changes. > > That is exactly what it is! Flag does set based on maven metadata changes. > I think there is a misunderstanding here, the flag on the classpath container entry should not need to change at all with maven metadata changes. I would expect that in the Maven case when the Maven classpath container entry is added the "dependency" attribute would be added and it would never be removed (i.e. the user would always want the Maven dependendencies to be reflected). What would change are the "nondependency" attributes added to the resolved entries returned by the Maven classpath container, but altering those does not change the signature of the .classpath file.
(In reply to comment #29) > I also don't see how this simple logic I suggested in my previous comment would > prevent WTP UI tooling to manage contributed dependencies? This is only for the > case when WTP won't be managing those dependencies and will be provided with > the preconfigured ones. > Here is the problem: if cp container entries lacking the "dependency" attribute must still be scanned (and tagged resolved entries mapped), there is no way for WTP UI tooling to disable the contributions from such containers. The user needs a way to enable/disable the contributions from any container (Maven or otherwise) using generic tooling; the way you accomplish this is require the "dependency" attribute on the container entry.
(In reply to comment #32) > Here is the problem: if cp container entries lacking the "dependency" attribute > must still be scanned (and tagged resolved entries mapped), there is no way for > WTP UI tooling to disable the contributions from such containers. The user > needs a way to enable/disable the contributions from any container (Maven or > otherwise) using generic tooling; the way you accomplish this is require the > "dependency" attribute on the container entry. I can certainly understand your intention to require world to spin around WTP. :-) However I would have to say that in case of container like Maven's one, there will be no need in overriding configuration that container provided. So, you should probably make those entries non-editable and let container to take care of those and delegate responsibility to the container provider to manage that information. This does make sense, because Maven would allow to use the same source of the metadata for the IDE as well as for the command line builds.
(In reply to comment #31) > I think there is a misunderstanding here, the flag on the classpath container > entry should not need to change at all with maven metadata changes. Unfortunately there is no misunderstanding. There are use cases when flag would change. See below. > I would > expect that in the Maven case when the Maven classpath container entry is added > the "dependency" attribute would be added and it would never be removed (i.e. > the user would always want the Maven dependendencies to be reflected). What > would change are the "nondependency" attributes added to the resolved entries > returned by the Maven classpath container, but altering those does not change > the signature of the .classpath file. Let's say somebody have pom.xml with jar packaging (no attribute) and then change packaging to ear or war (attribute would have to appear on container for that pom.xml). Then user can edit pom.xml to include or exclude certain dependencies for the packaging and hence will affect the presence of the attribute for individual entries. Well, I can work it around, by always adding WTP attribute to the container, no matter what the module packaging is, and exclude individual entries. But that rather ugly hack and I would really like to avoid that.
> Well, I can work it around, by always adding WTP attribute to the container, > no matter what the module packaging is, and exclude individual entries. But > that rather ugly hack and I would really like to avoid that. That's exactly what we are talking about. I am not sure why you consider this a hack. You are basically saying with the container flag: "consider contributions from this container". Then insider your container you control exactly what's contributed.
I should note that it is great to see such detailed design discussion. So, thanks, Eugene for really digging in the details, examining the feature from the different angles of the Maven use case (which is likely one of the more demanding) and helping ensure that the design is done right.
(In reply to comment #35) > > Well, I can work it around, by always adding WTP attribute to the container, > > no matter what the module packaging is, and exclude individual entries. But > > that rather ugly hack and I would really like to avoid that. > > That's exactly what we are talking about. I am not sure why you consider this a > hack. You are basically saying with the container flag: "consider contributions > from this container". Then insider your container you control exactly what's > contributed. I don't really see any logical reason why do we need a redundant attribute on the module/container that has nothing todo with WTP or even web projects, except the hack to get around WTP restrictions and to avoid unexpected changes on versioned resources like I explained above.
(In reply to comment #36) > I should note that it is great to see such detailed design discussion. So, > thanks, Eugene for really digging in the details, examining the feature from > the different angles of the Maven use case (which is likely one of the more > demanding) and helping ensure that the design is done right. Thanks Rob. I also appreciate this discussion and hope that we can come up with something acceptable for all interested parties. I should also say, that we received really great used feedback on Maven container support for the plain Java projects. Users really love that they don't need to manage their build path manually and automatically downloaded dependencies. So, we are really looking forward to make similar functionality work with WTP projects.
Perhaps an extension point could be used to register a classpath container as receiving the "dependency" treatment without needing to have the "dependency" attribute. For us at SAS Institute, the user shouldn't be allowed to change the "dependency" setting for our classpath container in any UI that might be available in the future. Perhaps using such an extension point my also imply the "dependency" setting is read-only.
Larry, that is actually similar to what I am looking for Maven support. There is already an extension point for registering custom containers and the discussed approach with attributes (used by JDT and AJDT) would allow to annotate any buildpath entries without creating strict bindings or dependencies on any specific API. It seems like an absence of such attributes at container level could indicate to WTP that container want to manage its own entries.
Any update on this or any comments on my last concerns?
hi Eugene, I've had to focus on some other work but am now tackling the UI support. For the reasons outlined already, I am going to proceed with the current attribute design for this initial version: raw classpath entry must always be tagged with an attribute to be mapped (and basic WTP tooling will support the removal of this attribute from the raw entry). Containers that can support more granular filtering can do so by marking resolved entries that should not be mapped with a special "exclusion" attribute. Larry: I can understand the desire to disallow removal of the attribute in your case but giving the user that support is consistent with other areas of Eclipse (i.e. a user has full UI control over the raw classpath entries for a project; they can certainly get themselves into trouble by exercising this control but Eclipse gives them the control). I'd like to take up your suggestion re: extension point enablement after this first iteration is fully working. Once this initial version of the feature is fully working (including UI support) and all impacted developers/adopters have had a chance to evaluate the feature, we can consider potential modifications to the classpath attribute design.
Rob, just to clarify, any attributes at the Maven's container or its children should not be modified trough the WTP UI. Can you also please elaborate why exactly classpath container absolutely has to have these attribute at the container level and why having it on children level is not sufficient? Once again, this container does not expect these entries to be edited by WTP, because information about what need to be included into the web app came from other places (i.e. Maven's pom.xml) and expected to be edited up there.
(In reply to comment #43) > Rob, just to clarify, any attributes at the Maven's container or its children > should not be modified trough the WTP UI. > > Can you also please elaborate why exactly classpath container absolutely has to > have these attribute at the container level and why having it on children level > is not sufficient? Once again, this container does not expect these entries to > be edited by WTP, because information about what need to be included into the > web app came from other places (i.e. Maven's pom.xml) and expected to be edited > up there. > Eugene, please refer back to the prior thread for the details on this but the key motivation is support for user enablement/disablement of the virtual component mapping of these classpath contributions; although for the Maven case you may want this attribute to be non-editable, in general it is best to give users control over whether specific raw classpath entries are deployed/exported and I think we should adopt this more flexible design for the first iteration. Adding the extension point-based enablement feature suggested by Larry during a second phase of this work is definitely something to consider (this would both allow cp containers like Maven to be mapped by default without having to tag the raw container entry and it would provide the WTP tooling the information it needed to efficiently process the resolved contributions from these entries and to correctly filter the raw entries out from the enablement/disablment UI).
(In reply to comment #44) > Eugene, please refer back to the prior thread for the details on this but the > key motivation is support for user enablement/disablement of the virtual > component mapping of these classpath contributions; Sorry, but that does not explain why container has to have special attribute. If attribute is not on the container, WTP could simply look trough individual entries to check if any of them need to be included into the web module or other WTP packages. Scan trough few hundreds entries in memory (in the worst case) wont hurt performance. You can always add caching later if it will turn as an issue. > although for the Maven case you may want this attribute to be non-editable, For the Maven case it is much preferable to have no attribute at the container level, because it does not make sense and would be really misleading there. As I mentioned before, Maven's container content can completely change triggered from the external descriptor, and that should NOT require to change .classpath file. > in general it is best to give users control over whether specific raw > classpath entries are deployed/exported and I think we should adopt this > more flexible design for the first iteration. Agree. But I am not sure if that WTP should provide such "service" for containers that are not part of Eclipse platform or explicitly requested that. > Adding the extension point-based enablement feature suggested by Larry during a > second phase of this work is definitely something to consider (this would both > allow cp containers like Maven to be mapped by default without having to tag > the raw container entry and it would provide the WTP tooling the information it > needed to efficiently process the resolved contributions from these entries and > to correctly filter the raw entries out from the enablement/disablment UI). Extension point is definitely useful. However I think it is more natural if it would work the opposite way. So, if it is present for specific container type then editing/mapping will be enabled. This will be more in line with the JDT's extension point for editing custom attributes, which only enable editing when it is registered for the particular attribute. So, if there is no extension point editing is not available.
(In reply to comment #45) > If attribute is not on the container, WTP could simply look trough individual > entries to check if any of them need to be included into the web module or > other WTP packages. Scan trough few hundreds entries in memory (in the worst > case) wont hurt performance. You can always add caching later if it will turn > as an issue. No, please don't do this. This would require all containers to be resolved which could be a long running operation causing a build, etc. You don't want to cause that, do you? > For the Maven case it is much preferable to have no attribute at the container > level, because it does not make sense and would be really misleading there. As > I mentioned before, Maven's container content can completely change triggered > from the external descriptor, and that should NOT require to change .classpath > file. As I see it, the ".classpath" change is only necessary when the attribute is removed or added. But this is supposed to be controlled by the user in the UI and not magically "enforced" by the container. So it will only change when the user includes or excludes the container in the UI. The container would just generate exclude rules as they like and annotate resolved entries with exclude rules. That doesn't cause a change to the ".classpath" file. > > in general it is best to give users control over whether specific raw > > classpath entries are deployed/exported and I think we should adopt this > > more flexible design for the first iteration. > > Agree. But I am not sure if that WTP should provide such "service" for > containers that are not part of Eclipse platform or explicitly requested that. Eugen, for some people Maven (or whatever technology else) is the center of the universe. But that doesn't mean that the tools have to act that way from the beginning. Let the user include or exclude the container as a dependency as he/she likes. You can always generate a warning marker for the project with a nice quick fix to enable it if the user disabled it or to ignore the warning. I'm pretty sure that a broader range of user would appreciate this behavior in favor of the enforcing one. Don't you agree?
Thanks for the comments, Gunnar; avoiding unnecessary container resolution is definitely another benefit of the current approach. Eugene, it seems like there is still some confusion here, so let me clarify the issue raised by your last question and then let's wait and revisit this whole topic after the first iteration is functional: (In reply to comment #45) > (In reply to comment #44) > > Eugene, please refer back to the prior thread for the details on this but the > > key motivation is support for user enablement/disablement of the virtual > > component mapping of these classpath contributions; > > Sorry, but that does not explain why container has to have special attribute. Actually, it does: if look-through must be done regardless of whether the container-level attribute is present, there is no way for a user to disable the contributions from that container (i.e. they will always be contributed if that container is part of the classpath).
(In reply to comment #46) > No, please don't do this. This would require all containers to be resolved > which could be a long running operation causing a build, etc. You don't want to > cause that, do you? You do too! There is no point to have unresolved classpath container. So, it will be resolved as soon as one would iterate trough its entries, and you would have to take my word that it is better to do it sooner then later. Sorry, but this does not count as an argument. > As I see it, the ".classpath" change is only necessary when the attribute is > removed or added. But this is supposed to be controlled by the user in the UI > and not magically "enforced" by the container. I would agree with you, IF container is not aware of web applications. However if it has an additional metadata it does make sense to use that metadata then duplicating it in some proprietary UI. > So it will only change when the > user includes or excludes the container in the UI. As I described before that does not work too well. The major issue is that when metadata changes user won't expect to change in some other versioned files, including .classpath. More over it is quite serious issue with some version control providers. > The container would just generate exclude rules as they like and annotate > resolved entries with exclude rules. That doesn't cause a change to the > ".classpath" file. It doesn't, but as I said, the attribute on the container would have to be either always present (even for non-web projects), which does not make sense, or .classpath would have to be changed when project type changed in the metadata. > Eugen, for some people Maven (or whatever technology else) is the center of the > universe. Gunnar, first of all it is Eugene. And second, please stay on topic without going personal. We are not discussing Maven here. > But that doesn't mean that the tools have to act that way from the > beginning. Let the user include or exclude the container as a dependency as > he/she likes. Nobody is arguing that. So, it will be up to the user to decide if he is want Maven or not. What I am trying to do is to make Maven integration as transparent as possible, meaning that user should not be required to edit anything if he is using Maven. > You can always generate a warning marker for the project with a > nice quick fix to enable it if the user disabled it or to ignore the warning. > I'm pretty sure that a broader range of user would appreciate this behavior in > favor of the enforcing one. Don't you agree? I am afraid you are missing the point. Maven container does have knowledge how web application should be packaged. There is no need in any warning or quickfixes. It should just work the same way as it does from the command line. I am also not sure what exactly you are arguing. There was two use cases presented that do require read-only scenario and only one is related to Maven.
(In reply to comment #47) > Thanks for the comments, Gunnar; avoiding unnecessary container resolution is > definitely another benefit of the current approach. Rob, it is not. There is no point to have unresolved classpath container in the project. Besides, you can't make it to stay unresolved forever, and it will be forced to resolve on first project compilation. Which does make sense. > > Sorry, but that does not explain why container has to have special attribute. > > Actually, it does: if look-through must be done regardless of whether the > container-level attribute is present, there is no way for a user to disable the > contributions from that container (i.e. they will always be contributed if that > container is part of the classpath). Exactly right! That is what I've been trying to explain you from the beginning. User don't have to disable anything and there is no need for that. In case of Maven such disablement will happens in some other place and some other UI, because same metadata need to be used between command line and the IDE. As I already suggested, I have nothing against have attribute at the container level, BUT if it is not there - look trough the entries. Why exactly this is a problem?
(In reply to comment #48) > Nobody is arguing that. So, it will be up to the user to decide if he is want > Maven or not. What I am trying to do is to make Maven integration as > transparent as possible, meaning that user should not be required to edit > anything if he is using Maven. The point I'm trying to make is that this transparent integration is good but not always preferred by everybody. The transparent integration can be achieved in the moment the user associates the Maven container with the project. I assume that this is a mandatory operation that the Maven plug-in provides for its users. The classpath will be changed anyway during that operation so the attribute can be set right away together with the container. However, all subsequent changes can be made in the UI by advanced users or whatever. The warning marker and quick fix was just a suggestion for the tooling to assist users that potentially switched off the publishing off the container accidentally. As for the read-only scenarios I don't really see this happen in a backwards compatible way for existing projects with existing setups without touching the .classpath and other files. You cannot start publishing classpath containers after upgrading WTP right away. This may break existing workspaces which should be avoided.
(In reply to comment #50) > The point I'm trying to make is that this transparent integration is good but > not always preferred by everybody. Sure. That is why everyone is free to use or not to use this integration. > The transparent integration can be achieved in the moment the user associates > the Maven container with the project. I assume that this is a mandatory > operation that the Maven plug-in provides for its users. The classpath will be > changed anyway during that operation so the attribute can be set right away > together with the container. Correct, but that is only half of the story. After it is enabled, user can edit project metadata or worse, get new metadata from the version control. Note that other team members not necessary are Eclipse users, so .classpath will get out of sync. > However, all subsequent changes can be made in the UI by advanced users or > whatever. The warning marker and quick fix was just a suggestion for the > tooling to assist users that potentially switched off the publishing off the > container accidentally. I understand that you are not Maven user, but can you please think about it? What those "advanced users" are going to edit if there is no need for this? It will only make things confusing and you are trying to solve this non existent problem with additional redundant markers. Once again, I am not saying that user should use Maven (or any other tool or container), but if he wants to, then there should be no need to maintain or edit the same information in two places, so as there should be no need to synchronize that information in two places. > As for the read-only scenarios I don't really see this happen in a backwards > compatible way for existing projects with existing setups without touching the > .classpath and other files. You cannot start publishing classpath containers > after upgrading WTP right away. This may break existing workspaces which should > be avoided. This is also barely an issue. First of all there has to be a migration path from old WTP project configuration to the new one. Also, when user is adding new container - he is aware that project configuration is about to change. So, can we please stay on the topic and address practical use cases and not something made up?
Created attachment 59200 [details] Patch that includes UI support and programmatic API This patch includes UI support for adding/removing the classpath entry attribute. Classpath entries must first be added via the JDT UI for the project. After that, "legal" raw cp entries will appear on the J2EE Module Dependencies page for the project (with a "(Classpath)" prefix) and the standard checkbox selection/deselection will add/remove the WTP-specific classpath attribute from the raw cp entry. Archives that are contributed to either the root of EAR projects or the WEB-INF/lib dir of Web projects via classpath dependencies of dependent utility projects will also be displayed in the J2EE Module Dependencies table (as "grayed" entries). The code that comprises the programmatic API for this functionality resides in the org.eclipse.jst.j2ee project in the org.eclipse.jst.j2ee.classpathdep package.
Created attachment 59201 [details] Unit tests for classpath dependency functionality Set of unit tests that exercise programmatic creation/removal of the classpath attribute, virtual component logic based on this attribute, validation rules, web project export and publish scenarios and EAR export and publish scenarios. This patch and the previous patch are both based on the WTP 2.0 build 200702150946
Pending a review by the appropriate WTP team leads/members (j2ee/common) and PMC members, I'd like to target releasing these changes during the beginning of M6 and then having the remainder of the M6 cycle to resolve issues.
+1 Module dependencies mechanism is a nice way to organize projects and dependencies and managing complex classpath issues. Classpath containers addition is very useful in scenarios such as JSF and Maven style projects -as amply discussed here- Thank you Rob for taking the lead to provide this work
(In reply to comment #55) > Classpath containers addition is very useful in scenarios such as JSF and Maven > style projects -as amply discussed here- Please note that we won't be able to provide transparent Maven integration for the contract proposed/planned for WTP container/attribute support. It will either require always present dummy attribute at the container level (effectively negating performance-related considerations of the chosen approach), or integration would have to force changes the .classpath file, which can be under version control and hence could be prohibited for changes.
(In reply to comment #56) > (In reply to comment #55) > > Classpath containers addition is very useful in scenarios such as JSF and Maven > > style projects -as amply discussed here- > > Please note that we won't be able to provide transparent Maven integration for > the contract proposed/planned for WTP container/attribute support. It will > either require always present dummy attribute at the container level > (effectively negating performance-related considerations of the chosen > approach), or integration would have to force changes the .classpath file, > which can be under version control and hence could be prohibited for changes. > I (and others) feel that user control over this behavior is more important in the first interation than support for fully transparent (i.e. no attribute in the .classpath file), and thus uneditable, enablement for some containers. Note: from a user perspective, the support can still be effectively transparent (i.e. the Maven integration logic can use the API to programmatically add the necessary attribute to the cp container entry). Regarding issues with alteration to the .classpath file: If the .classpath file for an existing project is locked for some reason (e.g. version control, etc.), the user probably does not want to see the exported/published structure of their project suddenly change when they move to a new version of the associated container implementation (i.e. if all project files remain fixed, a cp container should not just magically start contributing it's resolved archives to the exported/published application; this would likely be quite undesirable since the project would have been structured to function without those contributions). I think it is much better for such behavioral changes to be accompanied by a visible change in the project metadata files (i.e. the classpath file).
(In reply to comment #57) > I (and others) feel that user control over this behavior is more important in > the first interation than support for fully transparent (i.e. no attribute in > the .classpath file), and thus uneditable, enablement for some containers. I think you have wrong assumption that users actually want to edit something. Besides, they still have control on this, but that control won't be in hands of the WTP code, and WTP should just take configuration as given. > Note: from a user perspective, the support can still be effectively transparent > (i.e. the Maven integration logic can use the API to programmatically add the > necessary attribute to the cp container entry). That is not quite true. It will be necessary to implement tricky logic to keep external metadata and the state of .classpath in sync and transparently update them. It is also errorprone, because if somebody would change .classpath without updating external metadata, IDE configuration would be different from the command line and will lead to confusion. Note that external metadata can be used for the command line builds or continuous integration (i.e. to run tests, or build releases) and tmost of those environments don't need any IDE-specific stuff. Another case is when team is not using single IDE, but still want to standardize on metadata without duplicating or rereproducing it in every IDE. It is very important for that configuration to be reproduceable. > Regarding issues with alteration to the .classpath file: > > If the .classpath file for an existing project is locked for some reason (e.g. > version control, etc.), the user probably does not want to see the > exported/published structure of their project suddenly change when they move to > a new version of the associated container implementation (i.e. if all project > files remain fixed, a cp container should not just magically start contributing > it's resolved archives to the exported/published application; this would likely > be quite undesirable since the project would have been structured to function > without those contributions). I think it is much better for such behavioral > changes to be accompanied by a visible change in the project metadata files > (i.e. the classpath file). I think you are making too many assumptions. Classpath containers CAN and SHOULD contribute entries managed elsewhere without need to change .classpath. I believe that is actually very desirable. Once again, I am not arguing the whole idea, but trying to resolve present sharp corners that don't allow to provide transparent integration.
This may be a bit out of place here - still, might be worth saying. It seems to me that the problem here is that WTP (and Eclipse generally) have far too great a dependence on their own, Eclipse and WTP specific, file based descriptors. What constitutes the classpath and build mechanism of a project is something particular to the project, not to the IDE in which it is developed. As such it should be maintained in an IDE neutral manner (whether via Ant or via Maven or some other project description mechanism). The IDE should then have a pluggable framework such that its in memory classpath can be constructed by various different implementations. By all means have the existing default one that depends on a .classpath and a .component file, but allow 3rd party tools to replace that with their own mechanism. As I see it with a proper Maven 2 POM there should really be absolutely need to have a .classpath or .component file at all - a 3rd party plugin should be able to provide Eclipse and WTP with all the necessary in memory information from the POM. (This is what the M2Eclipse project tries to do using the classpath container - it means that at least the .classpath file is reduced to merely a declaration of the container, whilst M2Eclipse manages what is actually on the classpath in memory on the basis of the POM.) So basically I think that there's a job to be done to decouple Eclipse and WTP from the .classpath and .component files and instead provide an API to allow plugins to do the work of those files however they see fit.
FYI, I am wondering (and just wondering, since I have limited knowledge ... ) If a new API coming in the platform will help this scenerio ... see bug 168077.
(In reply to comment #60) > FYI, I am wondering (and just wondering, since I have limited knowledge ... ) > > If a new API coming in the platform will help this scenerio ... see bug 168077. > This potential enhancement is definitely relevant, thanks for the pointer David; this new API can be used in two ways: -allow containers to indicate non-support for this WTP dependency attribute -allow containers to veto changes to the existing value of the attribute This second item would satisfy the desire of certain containers (e.g. Maven) to prevent changes in the dependency behavior while also ensuring backward compatibility for exisiting projects (since export/publish exposure is not enabled until the cp entry attribute is added).
Hi Rob, Is this bug still targeted for M6? Will it be released into an I-build anytime soon? Thanks
I hope to release for this week...
(In reply to comment #63) > I hope to release for this week... Rob, how about issues we discussed at EclipseCon? Namely, allowing better flexibility and probably introduce include/exclude attributes and drilling down to the container elements if container don't declare any attributes. This should allow to better support containers that manage their elements using external metadata. So, it would be possible to avoid explicit info at the container level and container can dynamically specify/change attributes for individual entries when external metadata changes.
hi Eugene, It was great to talk to you at EclipseCon and gain some additional insight into the Maven use case. Although I can definitely understand your motivation, I have decided to go ahead with the current model of requiring the attribute on the raw cp entry based on the original reasons I outlined and additional discussions I had on this topic with two PMC members (Naci and David). I also think that there is an aissue you are going to hit with Maven cp container integration (duplicate resolution of dependent project entries) that will actually make the required raw cp entry attribute useful from the Maven perspective (you can use it to control whether the Maven cp container should return resolved entries for dependent projects: for WTP projects, the Maven container does not want to return these entries since the WTP EAR Libraries container resolves them). Naci and David both agreed that it was important to ensure that we have a design that maintains consistent (i.e. backward compatible) behavior for existing projects: it is not acceptable if the publish/export behavior for a project can change between versions of WTP without any change in the project metadata (this issue may not be as relevant for Maven but we have to design for all use cases). This design also allows for user control over publish/export (in a way that does not require the awkward use of the nondependency attribute on raw entries) and keeps publish/export behavior explicitly represented in the .classpath file. In terms of adopter/user support, the special cp entry attribute can be either added by users using the J2EE Module Dependencies UI or by custom logic (i.e. the Maven enablement action) via the supported programmatic API. I'm happy to talk to you more off-line about adding this support to the Maven plugin code.
(In reply to comment #65) > the Maven use case. Although I can definitely understand your motivation, I > have decided to go ahead with the current model of requiring the attribute on > the raw cp entry based on the original reasons I outlined and additional > discussions I had on this topic with two PMC members (Naci and David). That is too bad, because it would significantly reduce integration possibilities with WTP. > I also > think that there is an aissue you are going to hit with Maven cp container > integration (duplicate resolution of dependent project entries) that will > actually make the required raw cp entry attribute useful from the Maven > perspective (you can use it to control whether the Maven cp container should > return resolved entries for dependent projects: for WTP projects, the Maven > container does not want to return these entries since the WTP EAR Libraries > container resolves them). That is not an issue, because Maven users usually want to take configuration as is. So, there is no need to manually manage anything, and as a result WTP's container became really obsolete for such projects and can be just dropped. Also note that such flexibility would also allow better decoupling between WTP and eliminate redundancy for projects that decide not to use WTP at all, since there are several widely adopted alternatives available and we need to support them as well. > Naci and David both agreed that it was important to ensure that we have a > design that maintains consistent (i.e. backward compatible) behavior for > existing projects: it is not acceptable if the publish/export behavior for a > project can change between versions of WTP without any change in the project > metadata (this issue may not be as relevant for Maven but we have to design for > all use cases). This design also allows for user control over publish/export > (in a way that does not require the awkward use of the nondependency attribute > on raw entries) and keeps publish/export behavior explicitly represented in the > .classpath file. That is fine. However the approach we came up at the EclipseCon (the one I outlined above) should allow more flexibility if container provider want so. For instance change will happens not in a .claspath but in external metadata like pom.xml (note that pom.xml can declare only few dependencies to be packaged with war/ear, so container-level attribute don't help with that anyways). > In terms of adopter/user support, the special cp entry attribute can be either > added by users using the J2EE Module Dependencies UI or by custom logic (i.e. > the Maven enablement action) via the supported programmatic API. Not sure what API you are referring to.
Regarding the API, I had mentioned this in an email I sent to the WTP dev list with details on the feature; the code that comprises the programmatic API for this functionality resides in the org.eclipse.jst.j2ee project in the org.eclipse.jst.j2ee.classpathdep package (the UpdateClasspathAttributeUtil class is relevant for this use case)
Changes are committed and released to the 2.0 stream (will be in this week's I-build) - I'll try to get out a more detailed write up on the functionality (from both the user and adopter perspectives) here soon
Just for your own and WTP PMC information here is kind of emails I am receiving in Maven integration mailing list. Great job! -------- Original Message -------- Subject: [m2eclipse-user] Alternatives to WTP Date: Tue, 20 Mar 2007 13:23:22 +0100 From: xxxxx To: user@m2eclipse.codehaus.org Hello, based on https://bugs.eclipse.org/bugs/show_bug.cgi?id=128851 things aren't moving in the direction of Maven web developmnet with WTP. Any alternatives?
Eugene, I think perhaps this rather long and confusing thread may be incorrectly giving users the impression that the current design poses some actual technical problems with Maven integration, which it does not (as we discussed at EclipseCon and as can be deciphered from this thread). Your "Maven enable" action can check if the project has the WTP Module core nature when you add the Maven cp container, and if it does, you add the special dependency attribute (using the API) to the raw entry; this entry need never be removed and you can then perform filtering of resolved entries as desired in your actual container implementation (you also do need to prevent resolution of entries that will clash with the other WTP cp containers)
Eugene, comments like this one from you on the m2eclipse list also do not help to clarify this situation for your users: "So, if you also think that WTP should allow automatically picking up configuration from external metadata (such as pom.xml), please raise your voice now before it is too late." This is inaccurate: if you add the dependency attribute to the Maven cp container entry for all WTP projects, your container implementation can filter how the actual resolved contributions are exported/deployed based on the content of the pom.xml with complete flexibility (using the nondependency attribute). You dislike having to include the attribute in the .classpath file and giving the user the ability to manually turn off contributions from Maven, however, these issues do not interfere with basing contributions dynamically on POM content.
(In reply to comment #70) > Eugene, I think perhaps this rather long and confusing thread may be > incorrectly giving users the impression that the current design poses some > actual technical problems with Maven integration, which it does not (as we > discussed at EclipseCon and as can be deciphered from this thread). I am not sure what exactly you have encrypted in this sentence. The way it look for me can be summarized like this "yes I understood your issues, and think that approach you suggesting would resolve them, but I talk to my buddies here and we decided NOT to do it". Of course it is confusing. > Your "Maven enable" action can check if the project has the WTP Module core > nature when you add the Maven cp container, and if it does, you add the special > dependency attribute (using the API) to the raw entry; this entry need never be > removed and you can then perform filtering of resolved entries as desired in > your actual container implementation (you also do need to prevent resolution of > entries that will clash with the other WTP cp containers) I already explained several times why it is NOT an appropriate solution, why it is really bad idea to do any filtering in the container, and why "other WTP containers" will be obsolete in such case. Thanks for listening. (In reply to comment #71) > Eugene, comments like this one from you on the m2eclipse list also do not help > to clarify this situation for your users: > > "So, if you also think that WTP should allow automatically picking up > configuration from external metadata (such as pom.xml), please raise > your voice now before it is too late." > > This is inaccurate: if you add the dependency attribute to the Maven cp > container entry for all WTP projects, your container implementation can filter > how the actual resolved contributions are exported/deployed based on the > content of the pom.xml with complete flexibility (using the nondependency > attribute). I don't dislike, but see real issues with approach you are trying to force on WTP integrators. Not sure where that "filtering" idea came from, but that is NOT how classpath containers work. > You dislike having to include the attribute in the .classpath file and giving > the user the ability to manually turn off contributions from Maven, however, > these issues do not interfere with basing contributions dynamically on POM > content. Again, as I explained you several times, you too much worried how WTP can keep control on all the classpath containers and how it could disable functiunality that custome container can actually provide better (just because it has more information). For instance, "disabling" scenario can be provided by container itself (i.e. by additional parameter in container entry), so there is no point to force that into container implementation.
I think the point is that WTP can use existing classpath container's jar automatically. The comment 5's idea is very good and appropriate I think. I like that approach: <dependent-module deploy-path="/WEB-INF/lib" handle="module:/classpath/con/org.eclipse.jdt.USER_LIBRARY/MyUserLibrary"> <dependency-type>uses</dependency-type> </dependent-module>
That had been my original design (and I implemented and initial version of it) but there are a number of issues (mainly revolving around the dual representation in both the component file and the .classpath file) that make the attribute on the classpath entry a much superior design in practice (more dependencies will likely be moved out of the component file and represented solely in the .classpath file, with attributes for publish/export, in the future).
Should taglib resolution be working with this? I have added my Maven classpath container, which includes the standard-1.0.6 JSTL jar, using the dependency attribute. However, I still get a nasty red squiggle under the JSTL taglib URI <%@ taglib uri="http://java.sun.com/jstl/core" prefix="c" %> in my JSPs and the error "Cannot find the tag library descriptor for http://java.sun.com/jstl/core". The c.tld file is definitely in the standard-1.0.6.jar's META-INF directory with tag <uri>http://java.sun.com/jstl/core</uri>. My feeling is that should be enough for WTP to be able to find the tld and remove those nasty validation errors.
Robert, I don't know why it isn't working in your situation, but in our tests here at SAS, tag libraries in jars are working fine when adding our classpath container as a J2EE dependency. The repository our classpath container connects to happens to contain a older version of JSTL for legacy reasons. Including this JSTL in our classpath container allows "<%@ taglib uri="http://java.sun.com/jstl/core" prefix="c" %>" to make the tag library available to JSPs in our case. Thus, the behavior you are encountering doesn't seem to be inherent in the current implementation of this feature. Unfortunately, I can't tell what else may be coming into play that's causing this issue for you.
(In reply to comment #75) > Should taglib resolution be working with this? I have added my Maven classpath > container, which includes the standard-1.0.6 JSTL jar, using the dependency > attribute. However, I still get a nasty red squiggle under the JSTL taglib URI > <%@ taglib uri="http://java.sun.com/jstl/core" prefix="c" %> > in my JSPs and the error "Cannot find the tag library descriptor for > http://java.sun.com/jstl/core". The c.tld file is definitely in the > standard-1.0.6.jar's META-INF directory with tag > <uri>http://java.sun.com/jstl/core</uri>. > > My feeling is that should be enough for WTP to be able to find the tld and > remove those nasty validation errors. It is, but unless a classpath change notification was fired, the additions wouldn't have been noticed. Try closing and reopening the project. M6 contains content assist on the taglib URI attribute--you can use that to double-check what's available versus your expactations.
Opened a different bug 183756 for this as it seems to be independent of the classpath container enhancement. I'm not seeing the behaviour you guys describe, not sure why...
OK, clean workspace and now it's working as you describe. Not sure what's confusing it in my other workspace. Sorry for the spam.
I'm trying to integrate the Maven2 plugin with WTP using this new functionality, and I've a few questions: 1) How do I notify WTP programatically that the contents of a classpath container have changed? I've noticed that at present when the plugin adds and removes items from the classpath container (or adds or removes the nondependency attribute) my server still thinks it is synchronised. I daresa 2) Any idea of when we might get project references in a classpath container working? The Maven plugin puts project references in the classpath, so basically I can't make this work without having that functionality. Is it OK if I go and try and create a patch myself to do this? 3) Ideally the nondependency attribute would then work for source folders, so that I can stop WTP jarring up test classes to include, whether in the WEB-INF/classes folder or as part of a jar in the WEB-INF/lib directory as a result of including a project as in 2) above. Again, is it OK if I try and add this functionality?
(In reply to comment #80) > I'm trying to integrate the Maven2 plugin with WTP using this new > functionality, and I've a few questions: > > 1) How do I notify WTP programatically that the contents of a classpath > container have changed? I've noticed that at present when the plugin adds and > removes items from the classpath container (or adds or removes the > nondependency attribute) my server still thinks it is synchronised. What server are you using? I'll investigate this in more detail but please go ahead and open a new bugzilla for this. > > 2) Any idea of when we might get project references in a classpath container > working? The Maven plugin puts project references in the classpath, so > basically I can't make this work without having that functionality. Is it OK > if I go and try and create a patch myself to do t There are no immediate plans to add project cp entry support because project references are currently handled by WTP via the Web App Libraries and EAR Libraries cp containers (and component references are handled via other mechanisms). Until these can be reconciled, project references should be managed via the existing WTP mechanisms. I've added https://bugs.eclipse.org/bugs/show_bug.cgi?id=184125 to track this eventual enhancement (likely 3.0 timeframe) > > 3) Ideally the nondependency attribute would then work for source folders, so > that I can stop WTP jarring up test classes to include, whether in the > WEB-INF/classes folder or as part of a jar in the WEB-INF/lib directory as a > result of including a project as in 2) above. Again, is it OK if I try and add Source folders are currently ignored so you should not need the nondependency attribute - are you discovering something different? If it looks like there is a bug here, let's get a separate bugzilla opened for this one.
(In reply to comment #81) > (In reply to comment #80) > > I'm trying to integrate the Maven2 plugin with WTP using this new > > functionality, and I've a few questions: > > > > 1) How do I notify WTP programatically that the contents of a classpath > > container have changed? I've noticed that at present when the plugin adds and > > removes items from the classpath container (or adds or removes the > > nondependency attribute) my server still thinks it is synchronised. > > What server are you using? I'll investigate this in more detail but please go > ahead and open a new bugzilla for this. See reply in bug 184132. > > > > 2) Any idea of when we might get project references in a classpath container > > working? The Maven plugin puts project references in the classpath, so > > basically I can't make this work without having that functionality. Is it OK > > if I go and try and create a patch myself to do t > > There are no immediate plans to add project cp entry support because project > references are currently handled by WTP via the Web App Libraries and EAR > Libraries cp containers (and component references are handled via other > mechanisms). Until these can be reconciled, project references should be > managed via the existing WTP mechanisms. > > I've added https://bugs.eclipse.org/bugs/show_bug.cgi?id=184125 to track this > eventual enhancement (likely 3.0 timeframe) Thanks. > > > > > 3) Ideally the nondependency attribute would then work for source folders, so > > that I can stop WTP jarring up test classes to include, whether in the > > WEB-INF/classes folder or as part of a jar in the WEB-INF/lib directory as a > > result of including a project as in 2) above. Again, is it OK if I try and add > > Source folders are currently ignored so you should not need the nondependency > attribute - are you discovering something different? If it looks like there is > a bug here, let's get a separate bugzilla opened for this one. > I wasn't referring to source folders in a classpath container but to source folders generally. Looks like I missed the fact that you can control which src folders are included in a war's web-inf/classes folder or jarred up in a client jar using the project's .component file. Doesn't seem to be a GUI way of doing it, but you can control it in the XML.
This feature does not seem to be fully supported in Tomcat with the option "Serve modules without publishing" enabled. I've opened but 188163 to track this.
(In reply to comment #83) > This feature does not seem to be fully supported in Tomcat with the option > "Serve modules without publishing" enabled. I've opened but 188163 to track > this. > See the comments in bug 188163 but this looks like an an issue with the Tomcat "Serve modules without publishing" feature rather than a problem with the classpath entry publish/export support (i.e. you get the same behavior with other types of virtual JAR references)
