Community
Participate
Working Groups
1. Create a new utility project called util 2. Go to util Deployment Assembly. 3. Add a few entries such as External Archive or Classpath Container. Hit Finish. 4. Create a new web project. 5. Go to web Deployment Assembly. 6. Add -> Project -> util 7. Export the web project as WAR. 8. Look at the util.jar inside WAR's web-inf/lib directory. It will include the referenced jars inside it. Expected behavior is for these jars to appear alongside util.jar in web-inf/lib.
This is user error. You need to add the external archives to the web project just as you did the util project. Not sure why you chose to add the external archives to the util project.
> This is user error. You need to add the external archives to the web project > just as you did the util project. Not sure why you chose to add the external > archives to the util project. Because the jars are a dependency of the utility project, not the web project. The utility project needs them on its classpath to compile and they need to be packaged wherever the utility project is packaged. The web project doesn't care about these jars. It just cares about the utility project. In either case, user error or not, the tooling should never package jars in jars.
(In reply to comment #2) > > This is user error. You need to add the external archives to the web project > > just as you did the util project. Not sure why you chose to add the external > > archives to the util project. > > Because the jars are a dependency of the utility project, not the web project. > The utility project needs them on its classpath to compile and they need to be > packaged wherever the utility project is packaged. The web project doesn't care > about these jars. It just cares about the utility project. > > In either case, user error or not, the tooling should never package jars in > jars. I don't understand your complaint here. When adding a reference using the assembly deploy page it means exactly that. To package the referenced archive into this component. This is the exact same behavior as when you added a reference to the web project. You added a project reference and it packaged it inside the web component (under the web-inf/lib). I can understand your complaint that it does not make sense to do this in Java EE when adding references to non Web and EAR components. However, having a different behavior based on component is confusing and convoluted. Pre-Helios you could only add these references to EAR and web. I understand the argument to do the same here since adding references in this manner to non EAR and web does not follow specification. I had this conversation many times with Rob. He felt it was up to the adopting product to limit this if desired, but otherwise let the user make mistakes and package it exactly as specified. This is what it is doing. Packaging it exactly as you specified. Use the manifest references page to add references for compile time purposes.
(In reply to comment #2) > In either case, user error or not, the tooling should never package jars in > jars. Except that there are now cases outside of Java EE where jars within jars are needed. One of the main purposes of the Deployment Assembly page is for the user to have flexibility in their packaging. We also added in a hook for a validation framework such that adopters can add their own "prevention" in the case of a configuration that they do not support. The exact case described herein was discussed in the Java EE Status meeting. The design decision that was made was the one that was implemented- we will allow the user (and, by extension, app servers) to configure their deployables as they desire, and adopters to limit that configuration as their server/tooling needs. But the default for the generic Deployment Assembly needs to remain as flexible as possible. Assigning to Rob for further investigation.
> I don't understand your complaint here. When adding a reference using the > assembly deploy page it means exactly that. To package the referenced > archive into this component. This is confusing as it doesn't do what practically every user expects it to do. If I add a reference that looks like a Java library, I expect it to be referenced on the project classpath and dev-time and runtime. That's not what happens here. They just get dumped inside the jar as plain resources. The utility of this is next to nothing, but there is plenty of user confusion as the tooling didn't do what the user expected it to do. > I can understand your complaint that it does not make sense to do this in > Java EE when adding references to non Web and EAR components. However, > having a different behavior based on component is confusing and convoluted. I don't see why the behavior shouldn't different based on component type. In fact, it already does in some cases. When I am in a web project and a java library reference, they are mapped to web-inf/lib. That's a component type specific behavior. From usability perspective, I would be fine with one of the two: 1. Default java library additions to utility project to "../" deploy path. Make sure that they are visible on utility project's classpath and get packed into the referenced project. The user could still change the deploy path if they really want the libraries packaged inside the util jar (unlikely, but might as well allow it, but not as default). 2. Remove the options to add java library type entries in the utility projects. > Pre-Helios you could only add these references to EAR and web. I understand > the argument to do the same here since adding references in this manner to > non EAR and web does not follow specification. Pre-Helios you also had classpath tagging accessible via Module Dependencies page and users solved this usecase primarily using the classpath tags. New UI makes the use of classpath tags convoluted and the new tools placed prominently for the user to discover don't do what is expected.
> Except that there are now cases outside of Java EE where jars within jars are > needed. One of the main purposes of the Deployment Assembly page is for the > user to have flexibility in their packaging. We also added in a hook for a > validation framework such that adopters can add their own "prevention" in the > case of a configuration that they do not support. The cases outside of Java EE where it is important and sensible to package jars inside jars could be handled by different module types. I don't see why these cases should impact the usability of the Java EE utility project. WTP's #1 goal is to deliver usable Java EE tooling. Adopters should not be on the hook for patching over usability issues in basic Java EE scenarios.
Adding "Deployment Assembly" entries in the utility project is declaring that, when assembling the utility jar, you wish to put those other entries inside. That's all there is to it. That is what you're declaring. If you're suggesting that utility projects should not have such a page, and should be replaced with a page that only allows you to deploy "alongside" the utility jar, I would argue that is tragically flawed. Many Many MANY people use Utility projects as the default flexible project type when creating a project they want with no j2ee-specific uses and welcome the ability to customize what goes inside their utility project when packaged. >2. Remove the options to add java library type entries in the utility projects. So I specifically disagree with suggestion 2 for the reason above. >1. Default java library additions to utility project to "../" deploy path. Again, I disagree with this tremendously for the number of people who use a utility project as the default flexible / deployable project type. Many, I'm sure, may even not have a parent project associated with this utility project. The "../" default makes no sense for standalone utility projects with no parents. Imagine, for instance, a utility project with 3 other jars in it's assembly page, all with deploy paths of "../". I know of no server adapters (not to say they don't exist), where when presented with such a standalone utility project, would correctly ask the utility project for its references directly and try to find if it has anything which also needs to be deployed next to it. Any server adapter that *does* do this is obviously accessing the underlying virtual component directly and ignoring the servertools api. That would entirely break the server adapter suggested workflow, if when asked to deploy a util.jar project, you also deploy 4 other things next to it. Since those other things have no modules they wouldn't be listed as child modules (since they're not children and the general concept of a child module is that it is deployed inside or as a child to the parent). I can understand your points about UI, after much explanation, but I am still struggling to find a solution that is acceptable and makes sense.
>I don't see why the behavior shouldn't different based on component type. In >fact, it already does in some cases. When I am in a web project and a java >library reference, they are mapped to web-inf/lib. That's a component type >specific behavior. That's an easy specific behaviour to add, simply changing the default folder, and not at all confusing to anyone. What you're suggesting is very different: having adding a reference in one project actually add a line to .component xml file and be bundled inside, vs in another project having it only modify a .classpath entry and NOT modify the .component xml file and then still expect the viewer to SHOW this entity which is not persisted in the .component.xml file. This is CLEARLY a much bigger change and one that makes a little less sense in terms of flow. Let's try to think creatively about new additional UIs to solve this usecase...
> Many Many MANY people use Utility projects as the default flexible project > type when creating a project they want with no j2ee-specific uses and welcome > the ability to customize what goes inside their utility project when > packaged. Priority #1 should be that usability of core Java EE scenarios is not compromised by extensibility goals. The default behavior of the utility project should favor what's expected by Java EE users. Third parties using utility projects for non Java EE goals can extend / customize the behavior of utility projects for their specific needs. Creating jars inside jars makes no sense in Java EE scenarios and confuses users who expect a different behavior already described. So we have a problem with a core Java EE scenario that needs to be addressed. > > 1. Default java library additions to utility project to "../" deploy path. > > Again, I disagree with this tremendously for the number of people who use a > utility project as the default flexible / deployable project type. Many, I'm > sure, may even not have a parent project associated with this utility project. > The "../" default makes no sense for standalone utility projects with no > parents. In the core Java EE scenarios, the utility project cannot exist without a parent. As such, the default of "../" for the deploy path makes the most sense. Users explicitly needing nesting or third parties wishing to use utility projects outside Java EE scenarios can change this default in their context. > Imagine, for instance, a utility project with 3 other jars in it's assembly > page, all with deploy paths of "../". I know of no server adapters (not to > say they don't exist), where when presented with such a standalone utility > project, would correctly ask the utility project for its references directly > and try to find if it has anything which also needs to be deployed next to > it. > > Any server adapter that *does* do this is obviously accessing the underlying > virtual component directly and ignoring the servertools api. > > That would entirely break the server adapter suggested workflow, if when > asked to deploy a util.jar project, you also deploy 4 other things next to > it. Since those other things have no modules they wouldn't be listed as child > modules (since they're not children and the general concept of a child module > is that it is deployed inside or as a child to the parent). There is no reason that supporting this needs to break any server adapter. Classpath entry tagging has an analogous scenario and that all works transparently for users of IVirtualComponent api. > I can understand your points about UI, after much explanation, but I am still > struggling to find a solution that is acceptable and makes sense. I propose that we align the behavior of adding library-type entries via Deployment Assembly page in jar-type projects (utility, ejb, connector, etc.) to that of the web project. In the web project, the deploy path is set to the location that will make jars visible on the web app's classloader. In that case it's the web-inf/lib directory. Design-time classpath visibility is accomplished with a classpath container provided by WTP. In jar-type projects, the default deploy path should be "../", design time classpath visibility can be accomplished via the WTP classpath container already present on the project and the runtime classpath visibility can be accomplished by contributing an entry to the manifest. > What you're suggesting is very different: having adding a reference in one > project actually add a line to .component xml file and be bundled inside, vs > in another project having it only modify a .classpath entry and NOT modify > the .component xml file and then still expect the viewer to SHOW this entity > which is not persisted in the .component.xml file. This is CLEARLY a much > bigger change and one that makes a little less sense in terms of flow. It sounds like you are mixing up two separate topics... (a) the issue being discussed in this bug and (b) how to properly support classpath entry tagging in the ui.
Konstantin - one of the biggest problems with WTP is that it for unknown reasons to me have over time beein pestered with "short circuits" to cover J2EE packaging making it almost impossible to do even the most basic assembly tasks of jars and other resources outside of the J2EE world. This has lead to people hating WTP and simply dropping it as a usable construct to do any development since it was so limited. The module assembly page now finally has features that allows users to actually create jars in a declarative manner in a way that will work across server adapters since it is now using the virtual component API most server adapters will actually respect. Meaning it can actually be used easier to describe dependencies, and sometimes a jar in a jar makes sense (just look at osgi bundles); having to introduce a new module type for these would prevent you from deploying it to servers adapters that doesn't support these notions even though the matching sever runtime does not care at all and works fine. I do not understand how you can see this as a bad thing ? I do though agree completely that the UI could need some polishing/validation that is for sure!
Max, Flexibility is great, but it cannot come at the expense of usability of core scenarios. The default behavior should make sense for Java EE scenarios (that's the charter of the Java EE Tools project) and it doesn't right now. If adopters want to support other scenarios where different defaults make sense, that could be handled via extensions triggered via module types or facets or whatever. Our QA has a series of app structure scenarios that they build with every release. Many of these scenarios utilized classpath tags in past WTP releases. Our QA was accustomed to going to Java EE Module Dependencies page to tag an entry for assembly. Since classpath tagging was obfuscated so much in Helios, none of them could figure out how to get it to work. They looked for a reasonable substitute and they found these new classpathy wizards in the new Deployment Assembly page. They appeared to fit the bill, but when they added them, the *expected* thing did not happen. No one could figure out what this feature was supposed to do in the context of a jar-type project. It was labeled as buggy behavior. You can further look at forums for similar evidence of user confusion. The core issue is that the *expected* behavior when a user adds a classpathy thing is that it is configured in such a way as to be on design-time and runtime classpath. Note that the behavior expectation would have been completely different if the user invoked a hypothetical "Add File" wizard and selected a jar file rather than invoking "Add Library" or one of its kin. Consider what happens in the web project. The classpathy things are defaulted to WEB-INF/lib target and that satisfies user's expectations. I have not heard anyone complain that they can't figure out why tooling is working the way it is when they explicitly change WEB-INF/lib target to something else. Similar setup (as described in Comment #9) could be used to salvage the usability of Deployment Assembly with jar-type projects without sacrificing the flexibility. No major UI re-design required. Really, the only thing that's necessary is expansion of the mental model for the Deployment Assembly to allow it to assemble a collection of files instead of a single file. Ability to do that is also critical in salvaging classpath entry tagging.
> Flexibility is great, but it cannot come at the expense of usability of core > scenarios. Agree, but one of the core scenarios of WTP is also to actually work without tying yourself to specific server adaptors. I cringe everytime I have to say to a user "sorry, but incremental packaging and inclusion of the resources you want in WTP will only work with JBoss Server Adapters". Of course that is great lock-in, but that is really not where I want to have it ;) > The default behavior should make sense for Java EE scenarios (that's > the charter of the Java EE Tools project) and it doesn't right now. If adopters > want to support other scenarios where different defaults make sense, that could > be handled via extensions triggered via module types or facets or whatever. If module types/facets weren't dependent on server adaptors to specify their support then I would agree...but afaik it is not - but lets have that talk in seperate thread ;) > Our QA has a series of app structure scenarios that they build with every > release. Many of these scenarios utilized classpath tags in past WTP releases. > Our QA was accustomed to going to Java EE Module Dependencies page to tag an > entry for assembly. Since classpath tagging was obfuscated so much in Helios, > none of them could figure out how to get it to work. And this we definitely need to fix/make more obvious - if better defaults can handle that then great; lets apply those. > They looked for a > reasonable substitute and they found these new classpathy wizards in the new > Deployment Assembly page. They appeared to fit the bill, but when they added > them, the *expected* thing did not happen. No one could figure out what this > feature was supposed to do in the context of a jar-type project. It was labeled as buggy behavior. Well, I would argue that those who found the previous behavior of the assembly page good and logical is a very special set of people that might gotten too much used to how things were broken before is how it should continue to be broken going forward. I completely understand that we need to do what we can to absorb the impact. > The core issue is that the *expected* behavior when a user adds a classpathy > thing is that it is configured in such a way as to be on design-time and > runtime classpath. Note that the behavior expectation would have been > completely different if the user invoked a hypothetical "Add File" wizard and > selected a jar file rather than invoking "Add Library" or one of its kin. I agree better defaults could make it more sane, but this is not about adding a single file, it is about getting a list of resources based on whatever hihgerlevel construct in Eclipse that can provide theses without hard coding the actual resource names. Thus not having to have the user update the classpaths AND the assembly page to keep things in sync. > Consider what happens in the web project. The classpathy things are defaulted > to WEB-INF/lib target and that satisfies user's expectations. I have not heard > anyone complain that they can't figure out why tooling is working the way it is > when they explicitly change WEB-INF/lib target to something else. > > Similar setup (as described in Comment #9) could be used to salvage the > usability of Deployment Assembly with jar-type projects without sacrificing the > flexibility. No major UI re-design required. Really, the only thing that's > necessary is expansion of the mental model for the Deployment Assembly to allow > it to assemble a collection of files instead of a single file. Ability to do > that is also critical in salvaging classpath entry tagging. Sorry, you lost me there...you want assembly of resources from classpath entries to still go *outside* the utility-jar or something else ? Assembly outside the jar would again completely go against what the usecase is for (general assembly). Maybe we need to give the UI for this a different name so your QA does not think this is something more than assembly ? It seems they think adding some resources is supposed to respect classpath behavior based on whatever quirky rules there are ?
Again, if it were just as easy as making the default path "../" instead of "/" I'd gladly agree... and I understand what Konstantin means when he says: > Really, the only thing that's > necessary is expansion of the mental model for the Deployment Assembly to allow > it to assemble a collection of files instead of a single file. Unfortunately, I think this would also need to expand out to server adapters and the underlying deployables in order ot handle this. It might even require a new flat component participant to properly handle references that point to ../ I do see what Konstantin is saying as having value. In fact, I could even see in non-j2ee usecases the idea of having a utility project that, when deployed, also deploys items next to it instead of inside it.... ... ... but I think this would actually be a HUGE change in terms of functionality and something that I find it very very hard to justify with the way the current page is designed. Also, if we're adding these as IVirtualReferences with a ../ path, that means they'll be hard references actually inside the component.xml file rather than only attributes / properties in the .classpath file, which also changes things drastically. This is definitely a hard issue.
(In reply to comment #13) > Again, if it were just as easy as making the default path "../" instead of "/" > I'd gladly agree... and I understand what Konstantin means when he says: > Unfortunately, I think this would also need to expand out to server adapters > and the underlying deployables in order ot handle this. It might even require a > new flat component participant to properly handle references that point to ../ Okey, now I understand the suggestion. But yes, this sounds like requiring major IVirtualComponent changes or we again are back to adding "black magic" to the handling of assembly individually in every moduletype ;( > I do see what Konstantin is saying as having value. In fact, I could even see > in non-j2ee usecases the idea of having a utility project that, when deployed, > also deploys items next to it instead of inside it.... ... ... but I think this > would actually be a HUGE change in terms of functionality and something that I > find it very very hard to justify with the way the current page is designed. > > Also, if we're adding these as IVirtualReferences with a ../ path, that means > they'll be hard references actually inside the component.xml file rather than > only attributes / properties in the .classpath file, which also changes things > drastically. Not following that ;(
>Not following that ;( The current method that things published "along side" use to be published alongside are not to be hard-coded references inside the component.xml file, but rather, to be a property in the .classpath file which the parent project will look for. What Konstantin is asking is for the generic "jar reference" type, which is a hard reference stored in the component xml file, to behave differently by way of a "../" path. Unfortunately there's really no API for this type of support. We have support for things in the .classpath file tagged with the right attribute to be "pushed up" into a parent project through a different mechanism. It still fits into the Flat virtual component model, but it clearly doesn't fit the natural pattern. So Konstantin asking for regular hard references to add support for the "../" actually would require significant changes to the underlying list of flatten participants to be able to properly handle this. Sad but true =/
Ok. So it sounds like there is an API limitation in virtual component references that makes handling targets like "../" difficult. On the other hand, we have a working solution that can handle all of these cases in the form of classpath tags. We just need to fix its UI. So... How about we remove all of the "add library", "add external library", "add classpath container", items items that create virtual component references and replace them with a single "add build path entry"? That would fix usability issue with classpath tagging, address the big unfixable issue with the new "add classpath container" feature and allow us to default deploy path to "../" for utility projects without running into virtual component reference api limitations. The existing virtual component references would of course still work and they would be displayed on the assembly page, but users wouldn't be able to create new ones. Classpath tags can be used to pack jar-in-jars if that's important for some scenarios. The default wouldn't configure it that way, but there is no reason there couldn't be an extension point for influencing the default. I would argue that this would be a logic step in the rationalization of this UI done in Helios as it would get this page out of biz of managing classpath. It would only do assembly tasks. Adding and removing classpath tags is a pure assembly operation. It just happens to serialize to a different file. Adding and removing libraries via virtual component references is mixing classpath operations with assembly and has led to many problems. Perhaps it is time to have a Java EE team phone call to hash this out?
(In reply to comment #16) > The existing virtual component references would of course still work and they > would be displayed on the assembly page, but users wouldn't be able to create > new ones. *please* no - the whole point of the assembly page is to provide a hook for others to provide *pragmatic* assembly. i.e. we plan to add more generic fileset driven options for this in JBoss Tools/JBoss Developer Studio and are working with m2eclipse contributors to make this a way for them to provide Maven based assembly including resource filtering. > Classpath tags can be used to pack jar-in-jars if that's important for some > scenarios. The default wouldn't configure it that way, but there is no reason > there couldn't be an extension point for influencing the default. > I would argue that this would be a logic step in the rationalization of this UI > done in Helios as it would get this page out of biz of managing classpath. It > would only do assembly tasks. Adding and removing classpath tags is a pure > assembly operation. It just happens to serialize to a different file. Adding > and removing libraries via virtual component references is mixing classpath > operations with assembly and has led to many problems. But your solution is talking about enforcing/mixing up more classpath operation with the assembly page... Note: I'm all for trying to find better names/UI fixes for the IMO *very* special case of "two-way" assembly/classpath monging case to support old J2EE style deployments. > Perhaps it is time to have a Java EE team phone call to hash this out? Yes - I think it is.
> > The existing virtual component references would of course still work > > and they would be displayed on the assembly page, but users wouldn't > > be able to create new ones. > > *please* no - the whole point of the assembly page is to provide a hook for > others to provide *pragmatic* assembly. > > i.e. we plan to add more generic fileset driven options for this in JBoss > Tools/JBoss Developer Studio and are working with m2eclipse contributors to > make this a way for them to provide Maven based assembly including resource > filtering. You misunderstand what I am proposing. I am only proposing to remove the add options for classpathy virtual component references. That would resolve the usability issues we are discussing here along with other problems tracked by other bugs. There is no usability issue with adding more options like "Add file", "Add folder", "Add fileset", etc. as there would be no user expectation that these actions have affect on the classpath. It would be great to see more options like this in base WTP in the future. > But your solution is talking about enforcing/mixing up more classpath > operation with the assembly page... Separation of concerns... Users would go to Build Path to manage the project classpath... Users would go to Deployment Assembly to manage how the module is packaged. It would clean things up considerably especially in light of the new name (Deployment Assembly) for this page in Helios. > Note: I'm all for trying to find better names/UI fixes for the IMO *very* > special case of "two-way" assembly/classpath monging case to support old J2EE > style deployments. The problems we have with classpath tagging in Helios aren't going to be resolved by terminology change. The inversion of tag management is very limiting and confusing compared to how it worked in Galileo. You are also not going to be able to sideline this feature. It is the only viable way to handle classpath containers. The classpath container virtual component reference added in Helios is fundamentally broken and will need to be removed. Also note, that just fixing classpath tagging is not going to resolve this particular issue. To resolve this issue, we must either make classpathy virtual component references behave in a classpathy manner in jar-type projects (something that was identified as not feasible with the current API) or we must do away with those options.
*** This bug has been marked as a duplicate of bug 318068 ***
