This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
[ BUILD # : 200408121535 ] [ JDK VERSION : J2SE 1.5.0 ] Suppose this scenario: Project Lib requires project SubLib. Project App requires project Lib. App -> Properties will show on Required Projects: Lib SubLib But SubLib wont be added in runtime classpath. You are forced to 'Add [SubLib] Project' to App, despite it was already detected as a 'required project'
You need to explicitly add whatever you need to the runtime classpath. "Required Projects" is just a summary of related projects that will be opened together with this one; it does not correspond directly to anything in the project's build or run semantics. Might never fix for j2seproject's since there is no defined packaging standard for them. A technology with a well-defined packaging and aggregation notation, such as Java WebStart, could handle this cleanly.
Note that it is intentional that SubLib is not in App's *compile* classpath - you may well not want it to be, if it is only used "privately" inside Lib and not "exported". Might additionally be nice to have an option to export SubLib from Lib, or from the other perspective to pick up Lib's complete classpath in App. Not the same issue as the runtime classpath, however.
Ok, then there is something unclear to me. In ClassPath for Running Project, one of the options reads 'ClassPath for Compiling Sources'. Well, when I click on Build & Clear it will build and clear App, Lib and SubLib. How can it be that clicking on Run will not run? Maybe 'ClassPath for Compiling Sources' should read 'ClassPath for Compiling Sources except subnested projects'? Don't you think is one defect?
Jesse, I posted before reading your last comment. SubLib is included in App's compile classpath!!! The problem is not in App's runtime classpath.
Correction to the last post: The problem is IN App's runtime classpath. I just re-assigned project dependencies and tried it once more. It Cleans and Builds, but doesn't Run.
The compile-time classpath for App probably contains just Lib, not Sublib - unless you explicitly added Sublib. The runtime classpath is normally a superset of the compile-time classpath; you can explicitly add further items you do not need to compile against (e.g. JDBC drivers or JAXP implementations, or a subsubproject as in this case). When you select Clean & Build, all recursive subprojects are built in turn. "Maybe 'ClassPath for Compiling Sources' should read 'ClassPath for Compiling Sources except subnested projects'?" - not sure what you're getting at. It is exactly what it says - the classpath used when compiling sources in this project. Nothing more nor less.
Adding JDBC, JAXP and the like I do using Library Manager. I'm talking about Projects. You want me to understand the interiors, something I could only try at much, to excuse an unclear project behavior. I lost time before I understood SubLib existed as required project, I could clean and build, but was missing in runtime classpath. Your projects are too a good thing to have this missing.
Simplest and safest improvement I can think of: when customizing compile-time classpath of j2seproject A by adding B (j2seproject only? or any project?), if B contains some (transitive) subproject C (again, j2seproject only, or any project?) which is not already in either the compile-time or run-time classpath for A, prompt the user: 1. Just add B. (Current behavior.) 2. Add B, and also add C to the compile-time (and thus implicitly also run-time) classpath. Suitable if C is "exported" by B. 3. Add B, and also add C to the run-time classpath only. Suitable if C is "privately used" by B. This choice would need to be presented for each such C. If adding B to the run-time classpath, choice #2 would be skipped; the user would just be prompted to also add C to the r/t classpath. Of course this would not prompt you to readjust A's classpath should B's classpath change to not include C (or to include a new C2), but it would at least handle many situations correctly, and alert the user in an appropriate context to the possibility of making this kind of adjustment. Need some clarification on border cases - applicable only to j2seproject subprojects, or any subprojects? If j2seproject subprojects only, it is possible to know *how* B is using C - whether it is using it in the c/t or only r/t classpath. (If the latter, would skip choice #2 even if adding B to A's c/t cp.) If any subprojects, then you only know "C is a subproject of A", no more. Jano should something like this be considered for 4.0? We are long after UI freeze of course, but it would be a reasonably simple dialog that might improve usability in the case of complex project dependencies (and discoverability of the distinction between c/t and r/t cp's and their use). Might be able to get an exemption for it.
Here I'm bothering again. I found two more things involved in this issue: 1) Code completion don't see SubLib. 2) SubLib.jar isn't copied to WEB-INF/lib folder on web applications.
Re. code completion on SubLib - will be there if you add it to the compile classpath of App. If you don't, you will not have code completion on it - this is intentional. Re. web apps - don't know anything about it, please file a separate issue (component 'web').
I think I understand your point of view and I agree is desirable to have some freedom at the moment to include, or not, libraries. It was not my original point when I started this issue. I was refering exclusively to projects. Those ones get opened along with the 'main project' when 'Open required projects' is checked. Libraries wont show on project's view, but required projects will do, so you have to agree there is a difference. Maybe that's the reason you send me to webapp regarding to web application's reference, but to me is much of the same problem. Why do they open if they wont finally be included in runtime?
I *am* talking about projects, not libraries. The list called "Required Projects" does not really mean much; does not correspond to anything in the main project's behavior as such. There is no implication that they will all be used in the main project's runtime classpath, etc. It is simply a recursive (transitive) list of projects by "project dependency" relationship, which will be opened if you keep that checkbox checked, on the assumption that you may be interested in editing them. (If not, don't bother opening them.) For j2seproject's, a direct project dependency occurs when one project is used in at least one of another project's classpaths (compiling, running, or compiling tests), and means that the subproject will be built before the main project is built. Other kinds of projects may assign different meanings to the project dependency relationship: e.g. an EAR project (when EJB support is added) will have as subprojects web apps and EJB-JARs, and the web apps may have as subprojects tag libs.
I have been thinking of similar enhancement for a week. I concluded that 'best solution' would be like Jesse's #3, but not adding C to A's r/t cp - better could be offer adding of whole B's r/t cp as subset of A's r/t cp. This would avoid problems of synchronization when you change B's r/t cp.
*** Issue 47799 has been marked as a duplicate of this issue. ***
since i would guess that in most cases people would want 'C' added to the runtime classpath, perhaps an 'opt-out' strategy is in order. if 'B' is added as a dependency to 'A', then all of B's dependencies are recursively added to the runtime classpath of A as separate entries (sort of like an automatic option 3). users that do not want them in the compile time path can manually remove them if they like. i think it's best to have the extra step in the remove case because it will probably be less common.
correction: users that do not want them in the *run* time path can manually remove them if they like.
Re. inclusion of B's r/t CP as a portion of A's - probably not possible, sorry. Re. other suggestions - plausible, but will not do them for 4.0. (Anyway you would not have synchronization after changes in CP of subprojects without a rather more complex system.) Will just remove "Required Projects" from the customizer dialog as it is more misleading than helpful.
"Will just remove Required Projects from the customizer dialog as it is more misleading than helpful." - done. Checkbox "Build Required Projects" was moved to compilation panel and renamed to "Build Projects on Classpath". Done in: src/org/netbeans/modules/java/j2seproject/ui/customizer/Bundle.properties; new revision: 1.31; previous revision: 1.30 src/org/netbeans/modules/java/j2seproject/ui/customizer/CustomizerCompile.form; new revision: 1.7; previous revision: 1.6 src/org/netbeans/modules/java/j2seproject/ui/customizer/CustomizerCompile.java; new revision: 1.10; previous revision: 1.9 src/org/netbeans/modules/java/j2seproject/ui/customizer/CustomizerGeneral.form; new revision: 1.7; previous revision: 1.6 src/org/netbeans/modules/java/j2seproject/ui/customizer/CustomizerGeneral.java; new revision: 1.12; previous revision: 1.11
Removing of list of Required Projects - verified. Renaming of checkbox - verified. Both in dev-200408291800.
Sorry, so what remains from this enhancement? What additional changes are still required? I am getting lost. Thanks.
The whole issue is still valid (though whether it should ever be solved in j2seproject, as opposed to e.g. a Web Start project type, is an open question). All we did for 4.0 was remove the display of "Required Projects" from the properties dialog on the grounds that it misleadingly implied that all of those projects would actually be in your runtime classpath, which is not necessarily the case.
*** Issue 47493 has been marked as a duplicate of this issue. ***
Possible fix: define a property to project.properties called 'run.classpath.transitive'. Add ${run.classpath.transitive} to the definition of 'run.classpath'. When the project is opened and run.classpath.transitive is defined, go through all entries in the evaluated version of ${run.classpath} - ${run.classpath.transitive}, try to map them back to sources (SFBQ), then find ClassPath.EXECUTE for each. Update run.classpath.transitive to be those entries in the union of those ClassPath's which are not present in ${run.classpath} - ${run.classpath.transitive}. Attach listeners to those ClassPath's and also to ${run.classpath} and maybe to the SFBQ's, so that run.classpath.transitive always reflects the correct value, even if you e.g. change the configuration of subprojects. Should be listening to changes only while the project is open. For purposes of upgrade, if there is no run.classpath.transitive in project.properties, create it and add to run.classpath. Otherwise do not add it (in case the user intentionally removed it in project.properties). The GUI should show a new entry in the runtime CP customizer, "Runtime classpaths of subprojects" (or something like this); should not be removable, I guess. Should also make sure that the CP customizer shows tooltips or something making it clear what is going into this classpath, so things are more transparent. Could that work?
Was this intentionally not buildsys-e-cand?
Created attachment 19121 [details] dup in web folder
Created attachment 19122 [details] dup in build folder
Created attachment 19123 [details] dup in project view
Sorry, those screenshots were intended for another issue... ufff!
Tomas, moving java project specific issues to you for now.
*** Issue 55089 has been marked as a duplicate of this issue. ***
*** Issue 59357 has been marked as a duplicate of this issue. ***
*** Issue 61176 has been marked as a duplicate of this issue. ***
I was about to report this as a bug for netbeans 5.0 but then I found this bug. As I understand it, the autocomplete classpath is intentionally different from the compile classpath? I have valid, compiling (actually working) code. If I do a alt+f (fix imports) I get an error about a class that can't be found. The class is indeed in a library dependency of a library on the project. Autocomplete doesn't seem to be working either for this class. However there are no red lines for compile errors (which is correct) if I add the code manually. I don't see why the autocomplete classpath should be anything else then the compile classpath.
jillesvangurp: whatever problem you're having sounds unrelated and should probably be filed separately with details to reproduce from scratch if at all possible.
*** Issue 79404 has been marked as a duplicate of this issue. ***
What's the status of this ? Since there have been many duplicates filed, we need a solution This proposal would work for me: "Possible fix: define a property to project.properties called 'run.classpath.transitive'. Add ${run.classpath.transitive} to the definition of 'run.classpath'. When the project is opened and run.classpath.transitive is defined, go through all entries in the evaluated version of ${run.classpath} - ${run.classpath.transitive}" Thanks
I doubt it will work, it will affect head less build since it depends on the project open in the IDE.
The headless build would not depend on the project being open. It just means that *changes* to subproject classpaths would not propagate into the superproject's classpath unless they were made through the IDE, with the superproject open. You would need to be careful to ensure that if a subproject depends on a library that the dep in the superproject is given as a library dep, not a raw JAR dep, so that the path could be overridden consistently in a headless build. The root problem BTW is that Ant does not really permit the superproject to call the subproject's property evaluation as a subroutine and collect the results. It would be possible (by writing and reading named .properties files) but complex, probably inefficient, and hard to make work across different project types.
*** Issue 80618 has been marked as a duplicate of this issue. ***
See also issue #51052 re. deps among libs.
*** Issue 96526 has been marked as a duplicate of this issue. ***
*** Issue 99569 has been marked as a duplicate of this issue. ***
*** Issue 120220 has been marked as a duplicate of this issue. ***
*** Issue 121610 has been marked as a duplicate of this issue. ***
*** Issue 124842 has been marked as a duplicate of this issue. ***
There doesn't seem to be much activity on this RFE. In the last 2 years dupe after dupe has been added (there are more dupes than votes! buggy issue tracker...) Are there any plans to add this essential feature in upcoming releases? Most of the competing IDEs have this as it is necessary for codebases with library projects.
this is a p2
at this point, though, you may want to consider completely integrating Maven.
Just so that it is here with the bug report... my workaround is that for every "project" I define a library in the Library Manager called "library.dep". Here is where I define the classpath, sources and javadocs for that project's dependencies. Then if another project ever depends on "project", I add "project.dep" to its runtime (and test runtime) dependencies. This is an unsatisfactory solution because the Library Manager is a local definition and cannot be shared across a team, much more so in this hack because "project.dep" is not particularly descriptive and may change without developers realising. It also requires effort to add this dependency to the runtime paths.
This is a P1 but nobody has assigned it to a milestone yet... anyone care to comment on if they think this will make 7.0?
(sorry, meant P2, not P1)
For 7.0 it should be doable, unfortunately there is no milestone for 7.0 yet. It was not doable for 6.1 release which is rather bug fixing release containing already lots of new features.
*** Issue 133442 has been marked as a duplicate of this issue. ***
*** Issue 140382 has been marked as a duplicate of this issue. ***
*** Issue 142962 has been marked as a duplicate of this issue. ***
Now that there are 7.0 milestones, can someone assign a milestone? I would love to see this in 7.0.
*** Issue 162337 has been marked as a duplicate of this issue. ***
Well, i just spend a lot of time searching the web, before realising that this (in my opinion) essential feature is indeed missing. What's the point of including another project as dependency but additionally having to reference all of its libraries by hand. Doesn't this kind of behaviour defy the whole notion of the concept of dependent projects? I know there are workarounds but they are all kind of ugly and clutter up my projects. Why not handle it more like the way eclipse does it? Looks a lot more thought through to me.
*** Bug 180686 has been marked as a duplicate of this bug. ***
*** Bug 186208 has been marked as a duplicate of this bug. ***
*** Bug 195336 has been marked as a duplicate of this bug. ***
Any update on this?
Users needing nontrivial dependency management facilities are advised to use Maven projects.
So, the answer to transitive dependencies is "use maven"??? Huh? If you have more than two projects with transitive dependencies in anything like a professional environment, you need this kind of feature, otherwise it becomes too hard to maintain. OK, so using maven is a solution, but so is using Eclipse (which I'd rather not go to). I really like the ant-based NB build system and I'm not sure I want to give it up just to get this feature.. :(
Unfortunately it's not easily doable with Ant. See Jesse's comment #38
So far I have yet to find any working solution to this problem that does not involve maven. Done it in Eclipse using Eclipse projects and got toasted the very moment another developer tried to check out and build the project on his machine without having most of the dependencies attached to Eclipse projects (via variables, local file system references, ...) available. So from this point of view, the recommendation to use maven seems fine in both Eclipse and NetBeans.
1: In response to #38 then: Here I'm going to show my ignorance of the nuances of Ant, but could a target be added to the build file that output the classpath somehow (even if it meant writing a properties file somewhere temporary?) that the consuming project could then read? 2: On the basis of this being lots of work, is perhaps first-class Ivy integration lower fruit? If so (and depending on specific features, for example refactoring working across dependant projects - at least optionally), this would be a better solution IMHO than having to switch to Maven... Background: ----------- For context, and perhaps I'm unusual here, I tend to have a regularised workspace (all developers having the same layout) for related projects where all dependant projects are checked out into the same parent directory and I work on them all simultaneously. This is handled through Maven/Ivy or by Eclipse project dependencies fine, with the downside for Maven/Ivy of requiring a build/refresh cycle to access the changes to dependency projects. For example, I might have a product that is composed of projects {A,B,C,D,E} where I have dependencies: {B->A,C->A,D->B,D->C,E->A} perhaps D and E are separate deployables. I might even have other dependencies like F->A or something in my suite of projects, but I don't really care for this product. For this example, I'll setup my workspace as /projects/[A..E] and develop on them all in parallel. I find it unusual to have a (even mature) dependancy (like A above) without needing to change *something* while changing the product, so I'll need to propagate refactorings and plain code changes easily between these projects. Because I check out all the projects, I'm happy to have the IDE assume that they're there; but even if it didn't if it took extra advantage *if* they were there, that would benefit me equivalently. So, the current state of play is Maven or Ivy (Eclipse only) or Eclipse projects. Eclipse projects are a bit nasty in general when you need to build on a build server, so that leaves Maven or Ivy (with a possible manually configured Eclipse project structure to make it work better). Out of these three options, only Maven works with NB, but having had too much of my development time wasted by Maven's finicky nature, I'd rather play in the Ant-Ivy space for now... until something better comes along. So, in short, I'd *like* to use Netbeans for this (as I prefer it), but it's a bit hard to sell to others when it's either "switch to Maven" or "maintain deps by hand". [/rant]
(In reply to comment #67) > could a target > be added to the build file that output the classpath somehow (even if it meant > writing a properties file somewhere temporary?) that the consuming project > could then read? That is basically the approach I suggested at the end of comment #38. > is perhaps first-class Ivy integration lower fruit? That fruit would be juicy but it is at the top of the tree, I think - certainly more of a commitment than implementing this RFE. You can look at [1]. > refactoring working across dependent projects Probably nothing special needs to be done for that. [1] http://code.google.com/p/ivybeans/
Jesse, Thanks for responding - sorry I clearly didn't read your comment closely enough. I did look at that IvyBeans project, but it is not up to date for 7 yet. I may yet investigate further if that's my only option currently. This doesn't seem to be an 'official' Netbeans project - are there any plans to bring it into the fold? In terms of the difficulty of implementing/performance, these are problems that obviously come up with any feature being added to an application. Is this more a matter of priorities then? I'm just noticing that this has been an issue since [40cat] in '04, that's a long time for something fairly fundamental to wait. Of course, I'd anticipate that there have probably been more important issues? In which case, is there anything we can do about it?
> could a target > be added to the build file that output the classpath somehow (even if it meant > writing a properties file somewhere temporary?) that the consuming project > could then read? I did some experiments with something like this a few years ago (and I'd guess that Jesse's automatic projects do something similar): Invoke Ant programmatically and programmatically add a target which collects the closure of the dependency's classpath (and does the same recursively for its dependencies); it would be easy enough to keep a cached copy of that information tied to a hash of the build files if necessary. Having used it a little bit (Ivy, not IvyBeans specifically), I wouldn't waste time with Ivy.
(In reply to comment #69) > I did look at that IvyBeans project, but it is not up to date for 7 yet. [1] says otherwise as of today! (I have no experience with this plugin.) > This doesn't seem to be an 'official' NetBeans project - > are there any plans to bring it into the fold? I do not know of any plans. > Is this more a matter of priorities then? Yes, no one has gotten to working on it yet. While it affects a lot of people, you can always add transitive dependencies to the runtime CP by hand, and people with large multimodule projects often use Maven anyway. (In reply to comment #70) > I'd guess that Jesse's automatic projects do something similar No, autoprojects [2] just watch how a user's build script actually calls <javac>. If that script somehow implements transitive dependency management, whether manually or via a tool like Ivy, then the IDE's editor keeps up. [1] http://code.google.com/p/ivybeans/#20110113_:_1.2_released [2] http://wiki.netbeans.org/AutomaticProjects
As far as I know this enhancement is not planed. Tim you will need to have a MD5 or some other hash of project.properties + private.properties (or evaluated javac.classpath) of all dependent projects. It has significant performance impact on the java support. The problem is that the transitive classpath is needed not only by build but also by java.source (editor and any java feature). When there is no such a cache or the cache is invalid the call of ClassPath.entries() will need to execute the Ant script to reevaluate this transitive props. The CP.entires() should be fast and is allowed to be called from EDT. It's used for example by code completion, navigation, etc.
(In reply to comment #69) > In terms of the difficulty of implementing/performance, these are problems that > obviously come up with any feature being added to an application. Is this more > a matter of priorities then? I'm just noticing that this has been an issue > since [40cat] in '04, that's a long time for something fairly fundamental to > wait. <rant ignorable="true"> I honestly don't have much interest in this bug (and I'm not a Netbeans developer) but I can't resist chiming in. It's not fair to imply that a "fundamental" feature such as transitive deps is "low priority". The fact is, it *was* a high priority and the netbeans developers implemented it through the use of Maven projects. So please keep the rhetoric somewhat honest; if anything is low priority, it's implementing transitive deps using a second mechanism when the original mechanism is perfectly adequate. </rant> Just out of curiosity (serious question): why do you prefer the "classic" ant-based netbeans project format over the Maven version? I've been using the Maven version exclusively for years now and I've found it to be better in most respects.
athompson, <rant> I've also been using Maven for years. The ideas behind Maven are great. The implementation is crap. The documentation is horrible, typos in configurations cause silent failures (by virtue of the fact that Maven ignores unknown tags/attributes), and JNI support is nonexistent (try building a project that contains native code and see how far you get). If you do everything "the Maven way" it works fine, but the minute you wonder off course it's extremely difficult to get anything done. You have to write your own plugin, with all the complexity that entails. Ironically, people recommend Ant for simple projects and Maven for more complex ones. I don't know about Ant, but in my experience Maven is very poorly suited for complex projects. I've spent weeks debugging problems with build scripts. It was a nightmare. And I've actually authored a few Maven plugins so I know more about its internals than most users. </rant>
quote: "Force users to use use hammer instead of a fork and you will get the hammer thrown back at you. If you have lots of users you may not be able to escape all hammers!" I vote for having both maven and ant and maybe other systems. Users needs choices to build a solution that match their needs. Hammer here: I dumped netbeans 2 years ago because of this lack of dependecy tracking based on ant which was (not sure if this still holds true ) the default build system for netbeans projects!
@athompson: really @_ gtzabari said most of it. Although I would add that I think Maven takes the project model idea too far. It's very hard to stay inside the 'norm' for anything of significant complexity, and you end up configuring modules rather than defining a project model. But really the clincher for me is that when you *do* have a problem, there tends to be only one possible solution (some switch on a plugin), and you end up searching the Internet for ages to find someone, *anyone* that has actually located that configuration </frustration> To contrast, with Ant (as imperfect as it is) if you run into a problem, even if you can't find the 'proper' fix, you can still work around stuff by scripting in the build.xml I should mention that I haven't actually used Maven for a few years - these are the reasons I ditched it back then. So: project model = great, but implemented all too-encompassing, so IMO not worth it dependency management = great, but can use Ivy for that (assuming tool support!) Also note that depending on the *kind* of tool support, Ivy can be a bit of overhead, so not worth it for small-ish project that still have transitive dependancies. Yes, in this case dependencies could be manually copied, but that's more work than strictly necessary. Overall I can understand your comment; if Maven is considered good, then clearly NB's transitive support is also fine (and the Maven integration is excellent IMO). It just requires buying into Maven too.
just saw this discussion on (roughly) ant vs ivy: http://stackoverflow.com/questions/318804/maven-or-ivy-for-managing-dependencies-from-ant
Thanks for the comments, guys. I guess my project layouts have all been fairly straightforward; I haven't had any problems with Maven (aside from dep conflicts), even when converting existing projects. Maven does have an Ant plugin. Why not have Maven handle the deps and attach Ant tasks to phases to handle the fancy stuff where Maven isn't a good fit?
*** Bug 241265 has been marked as a duplicate of this bug. ***
(In reply to cumberland from comment #58) > Well, i just spend a lot of time searching the web, before realising that > this (in my opinion) essential feature is > indeed missing. What's the point of including another project as dependency > but additionally having to reference all of > its libraries by hand. Doesn't this kind of behaviour defy the whole notion > of the concept of dependent projects? > I know there are workarounds but they are all kind of ugly and clutter up my > projects. > Why not handle it more like the way eclipse does it? Looks a lot more > thought through to me. Completely agree.
(In reply to cumberland from comment #58) > Well, i just spend a lot of time searching the web, before realising that > this (in my opinion) essential feature is > indeed missing. What's the point of including another project as dependency > but additionally having to reference all of > its libraries by hand. Doesn't this kind of behaviour defy the whole notion > of the concept of dependent projects? > I know there are workarounds but they are all kind of ugly and clutter up my > projects. > Why not handle it more like the way eclipse does it? Looks a lot more > thought through to me. +1
Nice to find information about finding solutions for Apache issue tracking system for new NetBeans issues and here users can find bug and solutions about transitively required libraries not automatically added to runtime classpath. Jack, <a href="http://www.qualitydissertation.co.uk/">http://www.qualitydissertation.co.uk/</a>
Good to learning about transitively which required libraries and are also not automatically added to runtime classpat. Keep updating us. Caroline, Psychology personal statement writer -http://www.personalstatementfolks.co.uk/psychology-personal-statement/ of Personal Statement Folks.
[url=https://google.co.uk/]google[/url] <a href="https://google.co.uk/">google</a>
I published earlier than reading your last comment. SubLib is blanketed in App's collect classpath!!! The problem is not in App's runtime classpath. https://dissertationeducators.co.uk/
This is Caspar Lee from the UK. He is an expert writer in the domain of custom dissertation writing services and working for https://dissertationfirm.co.uk | Dissertation Firm. All UK students are getting high-grade coursework papers at the lowest price and achieving success. His aim is to satisfy a student's paper writing requirement and supplies before the deadline.
The last comment here is obvious spam. Anybody around empowered to delete stuff on here these days?